The NOCK paper

An autonomous network of agents coordinating capital on Robinhood Chain.

Abstract

NOCK is an autonomous capital network built on Robinhood Chain.

It begins differently from a conventional protocol. At deployment there is no circulating token supply, no Agent ID, no protocol-owned liquidity and no active capital network. Everything is created during a short Genesis period.

Every wallet that takes part in Genesis creates a unique Agent ID. Every contribution increases that Agent's Power. At the same time the protocol creates its fixed token supply, accumulates protocol-owned liquidity and capitalizes the first Engines.

Genesis ends permanently once the maximum supply has been minted or the window expires. From then on no new tokens can be minted, no new Genesis Agent IDs can be created, and Genesis Power can never increase.

The network then enters its permanent operating state. Users deposit capital into autonomous Engines built for liquidity provision, market-neutral strategies, yield and execution. Agent IDs allocate their finite Power across those Engines. Power sets how much capital an Engine may accept. Engines that produce economic activity produce fees, and those fees strengthen protocol-owned liquidity, reinforce the reserve and flow back to the Agent IDs supporting the network.

Genesis creates the network. The network then goes to work.

The name is the method. To nock an arrow is to set it on the string before the shot: a short, careful setup, then a release that cannot be taken back.

1. Why NOCK exists

Robinhood Chain brings a large retail and tokenized-asset audience onchain, on an Ethereum-aligned L2. That creates an unusual environment for autonomous financial software.

An agent does not only need intelligence. It needs capital, execution, liquidity, risk constraints, reputation and economic coordination. NOCK provides that coordination layer.

Instead of one monolithic AI managing every dollar, NOCK creates a network of specialized Engines. Each Engine has a mandate. Each mandate has explicit onchain constraints. Agent IDs decide where the network places its confidence. Capital follows that confidence. Revenue follows productive activity.

2. The model

$NOCK is liquid. Agent IDs are scarce identities. Power cannot be separated from the Agent ID that created it. Engines are productive infrastructure. None of them alone is NOCK; the interaction between them is.

3. Genesis

At deployment:

NOCK supply                 0
Agent IDs                   0
Genesis Power               0
Protocol-owned liquidity    $0
Engine Reserve              $0
Protocol revenue            $0

No team premine. No investor allocation. No liquidity allocation waiting in a deployer wallet. No farming schedule. The system starts empty.

The Opening Window

Maximum duration        48 hours
Maximum supply          10,000,000 NOCK
Genesis asset           USDG
Mint rate               10 gross NOCK / USDG
Minimum first mint      100 USDG

The window ends the moment 10,000,000 NOCK exist, or after 48 hours. If the cap is not reached, the unused capacity disappears. It is not minted to the team, the treasury, market makers, future incentives or investors.

Final supply = actual Genesis minted supply  (≤ 10,000,000)

The mint

For every 1 USDG, 10 gross NOCK are created and split immediately:

80%  →  the participant
20%  →  Liquidity Escrow

So 1 USDG gives the participant 8 NOCK: an effective price of $0.125.

The USDG is split as well:

25%  →  Liquidity Escrow
65%  →  Engine Reserve
10%  →  Protocol Reserve

For every 1 USDG, the escrow receives 2 NOCK and 0.25 USDG. 0.25 / 2 = $0.125. The first market price equals the Genesis price exactly, so the mint and the market are never disconnected.

Example

A wallet commits 1,000 USDG. The protocol creates 10,000 NOCK: 8,000 to the participant, 2,000 to escrow. The USDG goes 250 to escrow, 650 to the Engine Reserve, 100 to the Protocol Reserve. The Agent gains 1,000 Power.

One transaction creates NOCK, creates or grows an Agent, builds future liquidity and capitalizes the network. There is no separate liquidity raise later.

A full Genesis

Total contributions         $1,000,000
Final supply                10,000,000 NOCK
Held by participants         8,000,000 NOCK
Allocated to POL             2,000,000 NOCK + $250,000
Engine Reserve                 $650,000
Protocol Reserve               $100,000
Total Genesis Power           1,000,000

Every NOCK that exists can be traced to a participant or to liquidity created by Genesis.

4. Liquidity

Liquidity forms progressively during Genesis and is visible in real time, but trading does not open until Genesis is finalized. Tokens are non-transferable until then. Nobody can sell into capital supplied by later participants.

At finalization the escrow is released to the LiquidityManager, which opens the NOCK / USDG market on approved Robinhood Chain venues at the Genesis reference price. Venue allocation is set before deployment and published. Market activation is a controlled, separate step, and at no point does it create supply.

GENESIS FINALIZATION
  mint authority destroyed
  Agent creation closed
  NOCK transfers unlocked
        ↓
MARKET ACTIVATION
  escrow released to LiquidityManager
  NOCK / USDG market opened at $0.125

5. Agent IDs

The first successful mint from a wallet creates one Agent ID:

AGENT #0042
Genesis Power      14,200
Born at            block N
Genesis rank       #42
NOCK minted        113,600

Later mints from the same wallet grow the same Agent.

Power

1 USDG contributed = 1 Genesis Power

No quadratic weighting, no early-wallet multiplier, no hidden rarity, no staking multiplier. Any nonlinear formula pays people to split across wallets; linear Power does not. When Genesis ends, Power freezes. Buying NOCK later, holding more NOCK or depositing into an Engine never increases it.

A finite population

If Genesis creates 4,281 Agent IDs, 4,281 is the permanent Genesis population. New users can still buy NOCK, deposit, route and build. They cannot recreate a Genesis Agent.

Transfers

After Genesis, Agent IDs are transferable but indivisible: the ID, all its Power and its history move together. A wallet may hold only one. Rewards accrued before a transfer are checkpointed to the previous owner; future rewards follow the new one.

The Agent ID is an economic identity, not a picture collection. Its face is drawn from its number and Power, and can evolve with its activity.

6. Engines

After finalization NOCK becomes an autonomous capital network. Users deposit into Engines: autonomous mandates operating under explicit onchain constraints. The AI analyses and decides. The contracts hold authority.

Liquidity Engine. Market making, range management, inventory balancing, hedged liquidity. It weighs spread, depth, volume, volatility, inventory, fees and slippage. The goal is risk-adjusted liquidity revenue, not headline APR.

Carry Engine. Basis, funding differentials, cash-and-carry and hedged spot, within explicit leverage, asset, venue, liquidation-buffer and exposure caps.

Yield Engine. Approved lending and stablecoin primitives through registered adapters only. Capital preservation, liquidity, diversification, then yield.

Execution Engine. Other apps and agents request routes ("$100,000 USDG to asset X, 8 bps max slippage, 20 seconds") and pay an explicit fee. Revenue that does not depend on NOCK trading.

Tokenized Equity Engine (proposed). Liquidity and hedged carry on stock tokens available on Robinhood Chain, once venues are approved and added to PolicyGuard.

The user side

CAPITAL   $25,000 USDG
MANDATE   Liquidity
RISK      Medium
[ Deploy ]

The user receives vault shares and can monitor NAV, performance, exposure, positions and fees. The product stands on its own: even without NOCK, it should have a reason to exist.

Engines never own user capital

Each Engine has an isolated vault. An Engine can only interact with approved contracts, assets, adapters and markets. A policy looks like:

Allowed assets              USDG, ETH, approved assets
Max asset exposure          30%
Max venue exposure          25%
Max leverage                1.30x
Min liquid capital          20%
Max single rebalance        10% of NAV
Allowed contracts           whitelisted only

The AI decides inside the box. It cannot move the box.

7. Intelligence and authority

The agent may observe, reason, compare, construct transactions, propose allocations and trigger approved rebalances.

It may not mint NOCK, create Power, change its own risk limits, upgrade contracts, withdraw to arbitrary addresses, change fee splits or bypass exposure limits.

The model is not the custodian. The contracts are. If the model goes offline, the protocol does not lose custody of anything.

8. Power after Genesis

Agents allocate their finite Power across Engines. No Power is created; it is only pointed somewhere.

AGENT #0042    20,000 Power
  Liquidity    10,000
  Carry         6,000
  Yield         4,000

Power is not a vote over other people's assets. It sets an Engine's capacity:

Capacity_j = min( HardRiskCap_j , BaseCapacity_j + α_j × AssignedPower_j )

Example: base $500,000, 250,000 Power, α = $20 per Power, hard cap $10,000,000. Capacity = $5,500,000. However much Power piles in, the hard cap holds. Agents express confidence; they cannot buy past risk.

Epochs. Allocation works in 7-day epochs. Changes take effect at the next boundary, and rewards use checkpointed Power, so nobody can jump in front of a fee event and leave.

When Power leaves. If capacity falls below AUM, the Engine becomes capacity-limited: new deposits stop, withdrawals stay open, the strategy shrinks naturally. Power changes affect growth, never solvency.

Lifecycle. Proposed → Sandbox (low cap) → Active → Guarded (no new deposits) → Retired (unwound).

Operators. Third-party builders bond 25,000 NOCK to run an Engine. Objective violations (unauthorized adapter, attempted policy bypass) can be slashed. Losing money in a market is not a violation.

9. What NOCK does after Genesis

No inflationary staking. NOCK is operator collateral, access collateral for professional routing, a fee-reduction lock, the permanent other half of protocol-owned liquidity, and slashable economic security.

10. Revenue

After Genesis there are no new participants, so revenue must come from activity:

• Performance fees: 10% of realized net performance above the vault's high-water mark. No profit, no fee.
• Liquidity revenue from protocol-owned liquidity.
• Routing fees: target 2 bps, shown before execution.
• Engine revenue, with any builder share disclosed and capped at 10%.

Net network revenue is split:

50%  →  Agent ID rewards (USDG)
40%  →  Protocol-owned liquidity
10%  →  Protocol Reserve

For Engine j in epoch e, an Agent receives:

Reward(i,j,e) = 50% × Revenue(j,e) × AssignedPower(i,j,e) / TotalAssignedPower(j,e)

Example: an Engine's Agent pool is $80,000 with 800,000 Power behind it. Agent #0042 assigned 10,000. It receives $1,000.

Rewards use a cumulative reward-per-Power index per Engine, so the system never loops through every Agent. Claims are Power × (currentIndex − checkpoint).

Revenue for liquidity growth is split between buying NOCK on the market and keeping quote liquidity, so usage deepens the market without issuing a single token.

more users → more capital → more Engine activity → more fees
      → Agent IDs + POL → deeper liquidity → better execution → more activity

Example month: $300k strategy fees, $120k liquidity, $60k routing, $20k other. $500k net. $250k to Agents, $200k to liquidity, $50k to reserve. Zero NOCK emitted.

11. Reserves and accounting

The Engine Reserve seeds the first Engines so the network has real operating history before outside capital arrives. The protocol does not charge itself performance fees on its own capital.

The Protocol Reserve pays for audits, infrastructure, oracle and RPC redundancy, incident response and development. It is not reward capital.

User capital, protocol-owned capital and the Protocol Reserve are three separate accounting domains, and neither the interface nor the contracts blur them.

12. Execution

OBSERVATION → AGENT DECISION → POLICY VALIDATION → ONCHAIN EXECUTION

The agent writes an intent (Engine, action, amounts, max slippage, deadline, nonce). PolicyGuard verifies the asset, venue, post-trade exposure, slippage, capacity, leverage, deadline, nonce and any strategy-specific rule. Only then does anything execute.

13. Contracts

No contract combines all authority.

Immutable after Genesis: the token cap, the closing condition, no post-Genesis minting, one Agent per wallet, the Power rules, no post-Genesis Power.

Timelocked and adjustable: capacity coefficients, adapters, risk caps, fee ceilings, epoch length, routing limits, strategy parameters. Emergency pause can stop dangerous execution. It cannot seize user funds.

14. Failure modes

• Model failure. Capital stays in contracts, users keep their claims, manual unwind stays available.
• Bad decision. Risk limits bound the worst single action.
• Oracle failure. Price-sensitive actions pause.
• Venue failure. Adapters can be disabled; exposure caps prevent concentration.
• Power attack. Power cannot override a hard cap.
• Operator attack. Operators cannot send user assets anywhere.
• Genesis Sybil. Power is linear, so splitting creates no extra Power; the 100 USDG minimum makes dust Agents costly.

15. What cannot happen again

After finalization there is no mechanism for a second Genesis, new Genesis Power, token emissions, new Genesis Agent IDs, a team mint, a liquidity-mining mint or an inflation vote. The scarcity is structural, not discretionary.

Summary

NOCK starts from zero. During a short Opening Window every contribution mints NOCK, creates or strengthens an Agent ID, forms protocol-owned liquidity and capitalizes the first Engines. Then Genesis ends for good.

The finite Agent population allocates its Power. Power unlocks Engine capacity. Users provide capital. Engines put it to work on Robinhood Chain. Fees flow back to Agents, to liquidity and to the reserve.

The supply is created once. The Agents are born once. Then the network goes to work.

This document describes a protocol under development. Nothing in it is an offer to sell anything. Parameters may change before deployment; the ones marked immutable will not change after.