Documentation

00 Overview

GridPad is a hub-and-spoke protocol. Every token lives on a master hub on Robinhood Chain, where one invariant engine prices it. The hub is live on Robinhood Chain Mainnet: tokens, trades, ragequits and receiveYield() payments are real transactions, settled in ETH. Four execution spokes, Solana, Base, BNB Chain and Arc, connect over LayerZero V2 in phase 2. Spokes never hold liquidity: they lock funds in escrow and pass signed intents to the hub.

01 Contract index

The GridPad contracts on Robinhood Chain Mainnet and the LayerZero V2 endpoint of every chain in the topology, each checked for deployed code (a check is reused for up to five minutes).

GridPad contracts · Robinhood Chain Mainnet

Deployed at block 81,879,450 · owner 0xc264cb…537F7f. The owner can upgrade the logic and pause buys and new tokens. The deployed logic has no pause for sells, ragequits or receiveYield(); an upgrade by the owner (one wallet, no timelock) could change that. Each token is a GridPadToken deployed by the hub with CREATE2 (salt keccak256(ticker), init code hash 0x84c3b3e3…f9309c0c); only the hub can mint or burn it.

LayerZero V2 endpoints

Verified live: the API reads each address with eth_getCode (EVM) or getAccountInfo (Solana) on the configured RPC, and source verification from the hub chain's Blockscout explorer, with Sourcify as the fallback.

02 Deployment record

The hub as it runs on Robinhood Chain Mainnet: the version, every transaction that put it there, and the results of checking it against the live chain at one block. All 20 checks held and all 152 tests passed. The same record is served as JSON, and pnpm hub:check:mainnet runs the checks again; they send no transaction.

Transactions

Verification results

Test suites

A snapshot at block 90,882,978, taken on 2026-10-17 11:14 UTC. The hub is upgradeable by its owner (one wallet, no timelock), so the live check above reads the implementation the proxy runs on every visit.

03 The ratchet math

A token is a linear bonding curve plus a second reserve that only the compute floor can spend. State is four numbers: supply $S$, curve reserve $R_c$, floor reserve $R_f$ and curve slope $k$, which starts at $k_0 = 7.5 \times 10^{-13}$ ETH per token².

Prices

Buying

Selling and ragequitting

Since hub 1.1.0, exit(token, sellAmount, ragequitAmount, minEthOut, deadline) runs (8) and then (9) in one transaction under one minimum. A sale pays the curve's marginal price $kS$, which falls as supply shrinks; a ragequit pays the floor share, which rises. Selling down to where the two meet and burning the rest pays a large holder close to its whole share even when someone else holds a sliver, where selling everything would leave the floor reserve to that sliver. The cockpit's Sell picks this split by itself.

Researcher rent

The two guarantees

04 Transaction flow

Every action is one transaction on the hub. The interface renders it the moment you sign, then confirms it from the block, then reads the result from the event, with no server in between.

1. 1Quote

   The interface prices the trade with an exact integer mirror of the contract math, tested against the deployed bytecode to the wei.

2. 2Simulate

   The call runs as eth_call first, so a revert (slippage, an expired deadline, a paused hub) is explained before you sign or spend gas.

3. 3Sign

   Your wallet signs the transaction with a minimum out and a deadline.

4. 4Execute

   The hub splits, mints, burns or pays in one block, about 0.1 s on Robinhood Chain, and enforces the minimum out and the floor ratchet.

5. 5Emit

   Trade carries the full pool state after the action, YieldReceived the new floor reserve and supply, and TokenCreated the token's name, ticker, manifest and logo.

6. 6Index

   Charts, floors and balances rebuild from those events alone, in your browser and in the API, within a poll of the block.

Hub interface

interface IGridPadHub {
  struct CreateParams {
    string name;          // 2–48 bytes
    string ticker;        // 2–6 of A–Z 0–9, starting with a letter
    uint8 profile;        // 0 biomedical · 1 AI
    uint32[] spokeEids;   // LayerZero EIDs of the spokes (routes open in phase 2)
    bytes32 manifestHash; // keccak256 of the canonical manifest
  }

  function createToken(CreateParams calldata params, bytes calldata logo, uint256 minTokensOut, uint256 deadline)
    external payable returns (address token, uint256 minted);
  function buy(address token, uint256 minTokensOut, uint256 deadline) external payable returns (uint256 minted);
  function sell(address token, uint256 amount, uint256 minEthOut, uint256 deadline) external returns (uint256 ethOut);
  function ragequit(address token, uint256 amount, uint256 minEthOut, uint256 deadline) external returns (uint256 ethOut);
  // Hub 1.1.0: a sale, then a ragequit, in one transaction under one minimum (emits one Trade per leg).
  function exit(address token, uint256 sellAmount, uint256 ragequitAmount, uint256 minEthOut, uint256 deadline)
    external returns (uint256 ethOut);
  function receiveYield(address token, bytes32 ref) external payable;

  event TokenCreated(address indexed token, address indexed creator, bytes32 indexed tickerHash, string ticker,
    string name, uint8 profile, uint32[] spokeEids, bytes32 manifestHash, bytes logo, uint256 timestamp);
  event Trade(address indexed token, address indexed trader, uint8 indexed kind, uint256 ethAmount, uint256 tokenAmount,
    uint256 supply, uint256 curveReserve, uint256 floorReserve, uint256 k, uint256 timestamp);  // kind: 1 buy · 2 sell · 3 ragequit
  event YieldReceived(address indexed token, address indexed from, bytes32 indexed ref, uint256 amount,
    uint256 supply, uint256 floorReserve, uint256 timestamp);
}

Cross-chain intents · phase 2

From phase 2, spokes lock funds in escrow and send intents to the hub over LayerZero V2. The hub executes them in arrival order per token with the same minimum-out and deadline checks, and settles back: minted tokens as OFT transfers, native proceeds through Across on EVM spokes and deBridge on Solana.

payload = abi.encode(uint8 msgType, bytes32 token, bytes32 recipient,
                     uint256 amountIn, uint256 minOut, uint64 deadline, uint64 nonce)
// msgType: 1 buy · 2 sell · 3 ragequit

guid = keccak256(abi.encodePacked(uint64 nonce, uint32 srcEid, bytes32 sender,
                                  uint32 dstEid, bytes32 receiver))

0x0003010011010000000000000000000000000002bf20

0x00030100210100000000000000000000000000030d40000000000000000000000000002625a0

05 Token analytics

Every token page reads its economics from the hub contract and lists its history from the hub's own events. The figures are the integers the chain holds (wei, token-wei, and $k$ scaled by $10^{36}$), every formula is evaluated with the contract's own rounding, and a figure that cannot be read is shown as unavailable rather than estimated.

The economics panel

One eth_call through Multicall3, pinned to the block the page's event index has reached, returns the pool, the token's totalSupply(), the hub's balance, every pool's reserves and the hub's version; the block header and the proxy's implementation slot come in the same JSON-RPC batch. The read goes through the browser's own connection to Robinhood Chain Mainnet, not through GridPad's server, and repeats after every event for the token, every 30 seconds and on request.

The checks

States

Dollar figures appear only beside a live ETH/USD quote, marked as reference: the contract prices in ETH. The cockpit's header keeps to the same rule. Without a live quote it shows a dash with the ETH figure beside it, never a reference price, and its line above the panels says whether the event index is live and which block it has reached.

Activity history

Below the panels, every hub event for the token, newest first and 25 at a time: TokenCreated, Trade (a buy, a sell or a ragequit) and YieldReceived (rent). Each entry has its time, its kind, the wallet, the ETH and tokens it moved, the floor after it, and links to its block and transaction on the explorer; a creation's first buy and the two legs of an exit() are marked as such. The entries come from the page's event index, which the browser builds from the hub's logs. A transaction still waiting for its block is not an entry: it stays under Your transactions until its event arrives. When the index stops updating, the history says from which block on events may be missing.

The API serves both from its own index: /api/v1/tokens/{ticker}/economics reads the contract at the block the server's index has reached and returns the figures with their checks, and /api/v1/tokens/{ticker}/activity pages through the history with a cursor (Integration APIs).

06 Integration APIs

JSON over HTTPS, no key required, served from GridPad's own index of the hub's events and, for a token's economics, from the contract itself. Errors use one shape, { "error": { "status", "message" } }. Lease and job tickets are HMAC-signed by the server and act as bearer tokens, so the API keeps no session state. Write endpoints are rate limited per client address (an IPv6 /64 counts as one): 40 image lookups, 20 leases and 20 jobs per minute, on a best-effort basis per server instance.

Paying for a lease · phase 3

The rent is the payment and the proof. Pay receiveYield(token, ref) on the hub with a reference that commits to the terms; the API reads the transaction's YieldReceived event and opens exactly the lease it paid for. Changing any term changes the reference, and the claim fails. Paid leasing opens in phase 3, when real nodes run the jobs. Until then the lease and job endpoints answer 503, so do not pay rent expecting a lease. The flow below is the integration it will use.

import { createPublicClient, createWalletClient, custom, encodeAbiParameters, http, keccak256 } from 'viem'
import { robinhood } from 'viem/chains'

const hub = '0x68B25B61BBAb323F4C022DeaF9a481B19b9Bbf26'
const wallet = createWalletClient({ chain: robinhood, transport: custom(window.ethereum) })
const client = createPublicClient({ chain: robinhood, transport: http() })
const [payer] = await wallet.requestAddresses()

// 1. Terms and price: rate × nodes × hours, in ETH at the oracle price.
const terms = { payer, token: '0x…', ticker: 'FOLD', tier: 'a100_80', cluster: 'sin-02', nodes: 1, hours: 6, nonce: 7n }
const { prices } = await (await fetch('/api/v1/prices')).json()
const usd = 1.6 * terms.nodes * terms.hours
const value = BigInt(Math.ceil((usd / prices.ETH) * 1e18))

// 2. The reference commits the payment to exactly these terms.
const ref = keccak256(encodeAbiParameters(
  [{ type: 'string' }, { type: 'uint256' }, { type: 'address' }, { type: 'address' }, { type: 'address' },
   { type: 'string' }, { type: 'string' }, { type: 'string' }, { type: 'uint16' }, { type: 'uint16' }, { type: 'uint64' }],
  ['GRIDPAD_LEASE_V1', 4663n, hub, terms.payer, terms.token, terms.ticker, terms.tier, terms.cluster,
   terms.nodes, terms.hours, terms.nonce],
))

// 3. Pay the rent: it lands in the token's floor reserve in this transaction.
const tx = await wallet.writeContract({
  address: hub, account: payer, value,
  abi: [{ type: 'function', name: 'receiveYield', stateMutability: 'payable', outputs: [],
          inputs: [{ name: 'token', type: 'address' }, { name: 'ref', type: 'bytes32' }] }],
  functionName: 'receiveYield', args: [terms.token, ref],
})
await client.waitForTransactionReceipt({ hash: tx })

// 4. Claim the lease: the API checks the YieldReceived event and returns a ticket that authorises jobs.
const res = await fetch('/api/v1/compute/leases', {
  method: 'POST',
  headers: { 'content-type': 'application/json' },
  body: JSON.stringify({ tx, terms: { ...terms, nonce: terms.nonce.toString() } }),
})
const { lease, ticket } = await res.json()

Endpoints

curl 'https://gridpad.network/api/v1/status'

curl 'https://gridpad.network/api/v1/tokens'

curl 'https://gridpad.network/api/v1/tokens/FOLD'

curl 'https://gridpad.network/api/v1/tokens/FOLD/candles?interval=900&count=4'

curl 'https://gridpad.network/api/v1/tokens/FOLD/floor'

curl 'https://gridpad.network/api/v1/tokens/FOLD/economics'

curl 'https://gridpad.network/api/v1/tokens/FOLD/activity?limit=5'

curl 'https://gridpad.network/api/v1/prices'

curl 'https://gridpad.network/api/v1/contracts'

curl 'https://gridpad.network/api/v1/deployment'

curl 'https://gridpad.network/api/v1/compute/clusters'

curl 'https://gridpad.network/api/v1/compute/images?ref=python:3.12-slim'

curl -X POST 'https://gridpad.network/api/v1/compute/leases' \
  -H 'content-type: application/json' \
  -d '{"tx":"0x…","terms":{"payer":"0x…","token":"0x…","ticker":"FOLD","tier":"a100_80","cluster":"sin-02","nodes":1,"hours":6,"nonce":"7"}}'

curl -X POST 'https://gridpad.network/api/v1/compute/jobs' \
  -H 'content-type: application/json' \
  -d '{"ticket":"<lease ticket>","image":"gromacs/gromacs:latest","command":"gmx mdrun -deffnm npt","env":{"OMP_NUM_THREADS":"64"}}'

curl 'https://gridpad.network/api/v1/compute/jobs/JB-…' \
  -H 'Authorization: Bearer <job ticket>'

curl -N 'https://gridpad.network/api/v1/stream?ticker=FOLD'

07 Mainnet scope

This deployment runs on Robinhood Chain Mainnet: every token, trade, ragequit and floor is real ETH, settled by the hub contract. The contracts have not had a security audit yet. What is live, what is simulated, and the road from here:

The twelve genesis tokens were created by GridPad's deployer without an initial buy, so the first trader opens each curve; only tokens that account created carry the Genesis badge. Mainnet has no seeded trading history: what the board and the charts show is what traders have done.

Roadmap

Two milestones come before phase 2: 1.2 verified the hardened hub where it runs and published its deployment record, and 1.3 made each token's economics and activity inspectable from contract data. Both reuse what is live, with no new chains, contracts or tokenomics, before omnichain work adds its cost and complexity. A status changes, and a criterion is ticked, only once the work is built, tested and verified on the network it runs on; dates mark only what has happened.

1. 1

   Phase 1: Mainnet hub

   live

   The hub and twelve genesis tokens on Robinhood Chain Mainnet, with the board, cockpit, launcher, docs and API.

   Live since 6 October 2026 (block 81,879,450). The first trades came on 16 October 2026 (block 90,475,518).

   Scope

   • The hub contract and its twelve genesis tokens
   • Board, cockpit, token launcher, docs and the public API
   • Leases closed until phase 3

   Done when

   • Met: First trades on mainnet
   • Open: Uptime, with no incident

   Depends on phase 0, the testnet · Hub proxy ↗ · Contract index

2. 1.1

   Phase 1.1: Hardening

   complete

   Upgrade the hub to v1.1.0, with its security and exit improvements.

   Upgraded on 7 October 2026: the proxy has run v1.1.0 since block 82,337,221, and buys reopened the same day. The site moved to gridpad.network on 14 October.

   Scope

   • The fix for the empty-pool griefing vector: the slope never moves, a guarded buy sweeps its unused curve share into the floor, and an emptied pool restarts at k₀
   • exit(): the optimal way out, a sale then a ragequit in one transaction under one minimum
   • onlyProxy on every state-changing entry point
   • Documentation on the v1.1.0 math, and the gridpad.network domain

   Done when

   • Met: The proxy runs v1.1.0
   • Met: The deployment record is updated
   • Met: Buys reopened

   Depends on phase 1, and the owner's signature · Upgrade transaction (block 82,337,221) ↗ · Implementation v1.1.0 ↗ · Buys reopened ↗

3. 1.2

   Phase 1.2: Protocol hardening and exit improvements

   complete

   Verify and deploy the existing protocol hardening work, validate exit and redemption behavior, and publish the resulting deployment record.

   Verified on 17 October 2026 against the live hub at block 90,882,978: the running code is this repository's build, the upgrade left every supply, balance and token address untouched, all 3 mainnet trades match the client math to the wei, and all 20 checks and 152 tests passed, among them the suites run on a fork of the deployed contract. The deployment record publishes the version, the transactions and the results.

   Scope

   • Verify the griefing fix, the optimal exit, floor redemption and reserve accounting on the live hub
   • Confirm that buys, sells and ragequits behave as before, that a reverted transaction leaves no partial state, and that the upgrade left supplies, balances and token addresses untouched
   • Re-run the Foundry unit, fuzz and invariant tests, the app tests and the exact contract/client math comparison, adding regression tests for any gap
   • Publish the deployment record: the version, its transactions and the verification results

   Done when

   • Met: v1.1.0 is the active implementation on Robinhood Chain Mainnet
   • Met: The deployment registry and the docs match the chain
   • Met: Security and regression tests pass against the deployed implementation
   • Met: Exit and redemption are verified against the deployed contract
   • Met: A deployment record with the version, the transactions and the verification results is published

   Depends on phase 1.1 · Deployment record · Contract index

4. 1.3

   Phase 1.3: On-chain transparency and token analytics

   complete

   Improve visibility into token economics and on-chain activity using verified contract data, transaction history, and the existing API.

   Released on 17 October 2026. Every token page reads its spot price, redemption floor, floor reserve and circulating supply from the hub contract at a pinned block, works the floor formula on them, reconciles them with the chain and the event index, and lists the token’s hub events with their transactions. Checked against the live hub at block 91,292,202: all 91 checks held for its 13 tokens, and all 16 of its events were found in their transactions’ receipts.

   Scope

   • An economics panel on each token page: spot price, the redemption floor (floor reserve ÷ circulating supply, in ETH), the floor reserve, the circulating supply, the network, the block it was read at, and contract links
   • An activity history from the hub's own events (creation, buys, sells, ragequits and rent), each entry with its transaction, block, wallet, amounts and explorer link, loaded page by page
   • Exact integer math for authoritative values, and an explicit stale or unavailable state instead of a guessed number
   • Built on the existing cockpit, indexer, event stream and API: no new contracts, chains or database

   Done when

   • Met: Token pages show the verified economic metrics the contract supports
   • Met: The floor formula and its displayed inputs reconcile with on-chain state
   • Met: Every activity entry comes from a real hub event and links to its transaction
   • Met: Stale, missing and inconsistent data is shown as such
   • Met: Trading and token creation work as before
   • Met: The API and UI documentation are updated
   • Met: Automated tests cover data integrity and rendering

   Depends on phase 1.2, whose verified contract it reads; it ships as a separate release · Token analytics · Integration APIs

5. 2

   Phase 2: Omnichain

   designed

   Extend token execution to Solana, Base, BNB Chain, and Arc through the planned cross-chain architecture.

   The packet payloads and executor options are specified; no spoke is deployed and no route is open.

   Scope

   • Spoke escrows on Solana, Base, BNB Chain and Arc
   • LayerZero V2 intents, the hub lockbox and OFTs
   • Proceeds through Across and deBridge; rent in dollars

   Done when

   • Open: Buys, sells and ragequits from every spoke settle within the latency budget, with refunds on rejection
   • Open: An external review of the new contracts

   Depends on phases 1.2 and 1.3 · Transaction flow

6. 3

   Phase 3: Compute

   designed

   Real compute provisioning, paid leases, and rent landing in the floors.

   Until then node counts, utilisation and telemetry are simulated on mainnet, and the lease endpoints take no rent.

   Scope

   • The compute adapter on Akash and io.net
   • The funding model
   • Paid leases on mainnet, compute receipts and real telemetry

   Done when

   • Open: Paying labs
   • Open: Rent landing in floors from real jobs
   • Open: Published receipts, with measured margin and utilisation

   Depends on a decision on the funding model, and real nodes on Akash and io.net

7. 4

   Phase 4: Durability

   proposed

   An external audit, upgrade governance and a funded operating plan.

   Scope

   • External audit
   • Upgrade governance
   • A sustainability decision: protocol revenue or none
   • Secondary-market integrations and research partnerships

   Done when

   • Open: An audit report is published
   • Open: Governance is in place
   • Open: A funded operating plan

   Depends on decisions on the audit, upgrade governance and protocol revenue