Verify It Yourself

This system's claims are designed to be checked by strangers. This page is the practical guide: where the addresses live, what the open stats API returns, and the exact commands that reproduce our numbers. The commands use cast from Foundry; any JSON-RPC client works the same way.

Addresses#

Nothing is deployed yet. No token, no FeeRouter, no BurnRedeemer, no DevVest, no treasury Safe. When deployment happens, these addresses will be published on the reserve page of this site, all at once:

Until an address appears here, any token named RUNTIME or ticked RUN is not this project. Names and symbols on this chain are not unique and are not verified by the launchpad; the address is the only identifier that cannot be copied.

Addresses that exist today and are safe to pin:

RPC endpoints: Robinhood Chain https://rpc.mainnet.chain.robinhood.com (chain id 4663); Base is chain id 8453 via any public RPC.

In the commands below, $TOKEN, $FEE_ROUTER, $REDEEMER, $VEST, and $RESERVE_SAFE stand for the published addresses. They are placeholders because the real values do not exist yet, and we do not print plausible-looking fakes.

The two RUN tokens: telling them apart#

The symbol RUN on Robinhood Chain already belongs to the tokenized Sunrun Inc. equity, and several unrelated tokens share it too. Check the name field, which is immutable per contract:

RPC=https://rpc.mainnet.chain.robinhood.com

cast call 0x756Bc80af765C82da966a788858d65aDF14f3793 "name()(string)" --rpc-url $RPC
# "Sunrun • Robinhood Token"  <- the tokenized stock, not us

cast call $TOKEN "name()(string)" --rpc-url $RPC
# "RUNTIME"                    <- us, once deployed

RUNTIME ($RUN) is not affiliated with Sunrun Inc. and is not a tokenized security. There is not and will never be a liquidity pool between the two.

Checking the disclaimer commitment#

On this venue the token stores no readable description bytes. Instead the launch transaction permanently commits metadataHash, the keccak256 of the published metadata document (name, symbol, description with the full disclaimer, links), in the launcher's DirectLaunched event. We publish the document's exact bytes; you verify that the fingerprint matches:

# keccak256 over the exact bytes of the published metadata file:
cast keccak "0x$(xxd -p -c 1000000 < metadata.json | tr -d '\n')"

# The same 32 bytes must appear in the DirectLaunched event of the launch
# transaction (published alongside the addresses):
cast receipt $LAUNCH_TX --rpc-url $RPC

If the hash we publish ever stops matching the committed one, the metadata was edited after launch and the edit is provable. This is tamper-evidence, not storage: weaker than the immutable on-chain description the earlier design had, and we say so rather than round it up. The name field, RUNTIME, remains fully immutable on chain.

Checking supply and burns#

# Total supply: fixed at 1e9 tokens, 18 decimals
cast call $TOKEN "totalSupply()(uint256)" --rpc-url $RPC
# 1000000000000000000000000000

# Burned supply: the dead-address balance
cast call $TOKEN "balanceOf(address)(uint256)" \
  0x000000000000000000000000000000000000dEaD --rpc-url $RPC

# Circulating supply = totalSupply - dead balance. That subtraction is the
# whole definition; there is no other list to trust.

The token contract has no burn() function and no admin. Burns are transfers to the dead address; the balance there is public and final.

Checking the claim registry#

# Cumulative tokens burned through the redeemer by one wallet:
cast call $REDEEMER "claims(address)(uint256)" $YOUR_WALLET --rpc-url $RPC

# Global counters:
cast call $REDEEMER "totalBurned()(uint256)" --rpc-url $RPC
cast call $REDEEMER "totalSwept()(uint256)"  --rpc-url $RPC
cast call $REDEEMER "nextClaimId()(uint256)" --rpc-url $RPC

Invariants you can hold us to:

• Every claimed token is really at the dead address: balanceOf(dEaD) >= totalBurned + totalSwept. (Greater-or-equal because anyone can also send tokens straight to the dead address outside the redeemer; those burns reduce supply but create no claim.)
• Claim ids are dense from 1: nextClaimId equals the number of burns plus one. Every Burned event carries the cumulative totals after the burn, so an indexer, including one you run yourself, can detect and recover from any inconsistency using contract state as ground truth.

Checking the reserve#

# USDC balance of the reserve Safe on Base (USDC has 6 decimals, so the
# raw value is micro-USD):
cast call 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913 \
  "balanceOf(address)(uint256)" $RESERVE_SAFE --rpc-url $BASE_RPC

This checks the liquid tranche. The working buffer (prepaid provider credit) is off-chain and cannot be verified this way; it is our statement, capped at 20% of the reserve and attested in a monthly signed snapshot. The stats endpoint labels it accordingly.

Checking the dev lock#

cast call $VEST "BENEFICIARY()(address)" --rpc-url $RPC   # the published dev wallet
cast call $VEST "releasable()(uint256)"  --rpc-url $RPC   # 0 until the 180-day cliff
cast call $TOKEN "balanceOf(address)(uint256)" $VEST --rpc-url $RPC

release() is permissionless and pays only the immutable beneficiary: the public can verify and enforce the schedule.

Checking the fee inflow#

Our fees accrue in the launch venue's hook contract, not in a wallet we hold, and are collected by our FeeRouter, an immutable contract whose only job is the 2/3 : 1/3 split. Every claim below was run against the live chain, or against the real contracts on a mainnet fork, before publication.

HOOK=0x25a94C38de476F2170c065954B28F6aAA00Ea0CC

# The fee rate ceiling, read from the hook itself. Our pool is registered
# at this maximum; the trader pays 3.35%, of which 3.00% reaches us.
cast call $HOOK "MAX_TRADE_FEE_BPS()(uint256)" --rpc-url $RPC
# 335

# The hook is a plain contract, not a proxy: the EIP-1967 implementation
# slot reads zero (admin and beacon slots too), and its bytecode contains
# no DELEGATECALL. Nobody can swap its logic out later. First part:
cast storage $HOOK \
  0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc \
  --rpc-url $RPC
# 0x000...000

# Our pool's registration: fee rate and fee recipient, from the hook's own
# PoolRegistered event. topics[2] is the token, topics[3] is the permanent
# fee recipient (must be the published FeeRouter), and the first data word
# is the fee rate: 0x14f = 335.
cast logs 'PoolRegistered(bytes32,address,address,uint16,bool)' \
  --address $HOOK --rpc-url $RPC

# Accrued but unswept fees for the router, readable by anyone, two ways
# that must agree (native ETH is currency address zero):
cast call $HOOK "creatorOwed(address,address)(uint256)" \
  0x0000000000000000000000000000000000000000 $FEE_ROUTER --rpc-url $RPC
cast call $FEE_ROUTER "claimable()(uint256)" --rpc-url $RPC

# The two fixed destinations and the booked-but-undelivered amounts
# (normally zero; nonzero means a recipient temporarily rejected a payout
# and the money is waiting in the router, retryable by anyone):
cast call $FEE_ROUTER "RESERVE()(address)" --rpc-url $RPC
cast call $FEE_ROUTER "TEAM()(address)"    --rpc-url $RPC
cast call $FEE_ROUTER "owed(address)(uint256)" $RESERVE_SAFE --rpc-url $RPC

Three properties worth knowing, all stronger than what the design had before. First, collection is public: sweep() on the FeeRouter can be called by anyone, with no signature and no permission, and whoever calls it, the ETH can only move to the two fixed addresses in the fixed 2/3 : 1/3 ratio. The capital flow is enforced by code, not promised by people. Second, the fee recipient is permanent: the hook has no function to reassign it, so no future keyholder, including us, can redirect the stream. Third, so is the rate: no setFee exists anywhere. The flip side of all three is listed honestly in Risks: permanent also means uncorrectable.

Every sweep is reconcilable from logs alone: the hook emits CreatorFeesClaimed for the claim, and the router emits Swept (with the split) and one Paid per delivery, with cumulative totals in every event.

The open stats API: GET /api/stats#

No authentication, no cookie, CORS open (Access-Control-Allow-Origin: *), cached for 60 seconds at the CDN with the timestamp in the body. The response contains every input to the backing calculation, separately:

Two properties of the endpoint worth knowing:

1. Provenance is part of the payload. Each field says whether the chain guarantees it or we assert it. The difference between "the chain guarantees this" and "we claim this" is not allowed to vanish inside a column of numbers, and hasOperatorInputs is true as long as any asserted value is in the response.
2. It returns 503 rather than approximating. If any input is unavailable, the response names what is missing instead of emitting a zero that actually means "unknown".

Recomputing our numbers#

With the response above and the formulas from The Numbers, everything is a few lines of arithmetic:

b        = netReserveMicros / circulatingSupply * 10^7
g        = min(b / targetPer10M, 1)
alpha(g) = 0.25 * g^2                 next epoch's drip rate
rho(g)   = 0.85 + 0.13 * g            next epoch's redemption ratio

The reserve's share of fees is not in this list because it is not a parameter: it is a fixed 2/3 in the FeeRouter contract and cannot be recomputed, changed, or gotten wrong.

If your result differs from the published parameters of the following epoch, one of us has made an error, and the endpoint exists so that you can prove it was ours.