Documentation

Overview

This document describes the GRONK routing protocol: the split ratio, the routing cycle, the venue registry, and the keeper network. It is written to be read alongside the contract, not instead of it.

1 · Design constraints

The kernel is built against four constraints, in priority order:

1. No admin discretion. If a parameter can be changed, it is changeable only by governance. If it is not governed, it is immutable.
2. No custody. The kernel never holds user funds. Routed capital moves contract-to-contract.
3. No hidden state. Every action emits an event that fully reconstructs the cycle from chain data alone.
4. No bloat. Four responsibilities. Anything beyond that belongs in a venue or an external module.

2 · The split

At deployment the split ratio r is written to storage and never mutated. Each qualifying flow F contributes F x r to the kernel pool, and F x (1 - r) continues to its original destination unmodified.

Because r is immutable, the routing share of any flow can be computed by anyone from public data before it happens. That is the point.

3 · The routing cycle

A cycle executes in four stages:

4 · The venue registry

The registry is a governed list of contract addresses the kernel may route into. Each entry carries the venue's deposit interface, withdrawal interface, risk classification, and the address of the proposal that added it.

Additions require a full proposal cycle with a review window. Removals execute faster than additions by design — if a venue is compromised, the lag should favour the exit, not the entry.

5 · Keeper nodes

Keepers are permissionless. A keeper's only capabilities are to evaluate the cycle condition against current chain state and submit the consequent transaction. Invalid submissions revert on-chain, so a keeper cannot deviate — only fail.

Minimum node requirements at launch:

• A Solana RPC endpoint with transaction submission
• A funded keypair for transaction fees
• The reference keeper binary, or any client implementing the documented interface
• Uptime sufficient to submit within the cycle window

Keeper compensation is set by governance and drawn from the kernel operations allocation. It is designed to reward reliable submission rather than raw speed, so the network does not devolve into a gas auction.

6 · Governance interface

The governance module exposes proposal creation, weighted voting, delegation, and execution. Proposals carry an exact on-chain action — not a document to be interpreted later. A passed proposal executes; there is no discretionary execution step and no veto.

7 · Transparency

Every stage emits an event. The public ledger is reconstructed entirely from chain data: each accrual, each venue deployment, each settled return, each governance execution. If a claim about GRONK cannot be verified against those events, treat it as marketing rather than fact.