The contract suite, what each component does, and network details for Robinhood Chain.

Contracts

The protocol is a set of contracts on Robinhood Chain. None is deployed. There are no addresses to publish and no audit to cite.

Network

	Mainnet	Testnet
Name	Robinhood Chain	Robinhood Chain testnet
Chain ID	`4663`	`46630`
Stack	Arbitrum Orbit L2	Arbitrum Orbit L2
RPC endpoint	`TBD`	`TBD`
Block explorer	`TBD`	`TBD`
Native gas asset	`TBD`	`TBD`

RPC and explorer URLs are left undetermined rather than guessed. Verify them against Robinhood Chain's own published documentation before pointing a wallet or a script at anything. Do not take a network endpoint from a third party.

Suite

Contract	Standard	Responsibility
`WattToken`	ERC20	Fixed-supply token. No mint function after deployment. Launched externally.
`StakingVault`	,	Holds staked $WATT. Accrues stake-seconds per account per epoch.
`EpochRegistry`	,	Opens and closes epochs. Stores the attested surplus budget `B(e)` after each close.
`EnergyPoints`	,	Non-transferable kWh-denominated ledger. Mints on claim, burns on voucher mint.
`SkuRegistry`	,	Defines SKUs, their units, and their price in kWh. Governs which expiry buckets are open.
`VoucherToken`	ERC1155	Compute vouchers. One deployment, one id per (SKU, expiry bucket).
`VoucherMinter`	,	Burns points, applies the mint fee, issues vouchers.
`RedemptionManager`	,	Job escrow and lifecycle: request, dispatch, quorum, settle, refund, reclaim.
`AttesterSet`	,	Registry of attesters and quorum thresholds for energy and delivery attestations.
`OperatorRegistry`	,	Operator registration, bonding and slashing.
`Marketplace`	,	Verifies EIP-712 orders, tracks partial fills, settles both legs atomically.
`FeeTreasury`	,	Receives mint and marketplace fees.

How they connect

  WattToken ──stake──► StakingVault
                            │ stake-seconds
                            ▼
  attesters ──► EpochRegistry ──budget B(e)──► EnergyPoints
                                                    │ burn
                            SkuRegistry ──────► VoucherMinter ──fee──► FeeTreasury
                                                    │ mint
                                                    ▼
                                              VoucherToken (ERC1155)
                                              ╱                  ╲
                              RedemptionManager                Marketplace ──fee──► FeeTreasury
                                    │                                │
                        AttesterSet ┘ OperatorRegistry               └── EIP-712 orders

Two boundaries are worth naming. EnergyPoints is the only contract that can be credited by EpochRegistry, and VoucherMinter is the only contract that can burn points. Everything else downstream deals in vouchers, which are ordinary transferable tokens.

Component notes

StakingVault maintains a cumulative stake-seconds accumulator plus a per-account checkpoint, so a staker's epoch weight is recoverable in constant gas at claim time. It never iterates over stakers.

EpochRegistry writes B(e) only after epoch e has closed. Nothing in the contract can set a budget for an open or future epoch. This is the on-chain enforcement of the retroactive rule in Energy Points.

VoucherToken encodes (version, skuId, expiryBucket) in the id and rejects ids with reserved bits set. Transfers of expired ids revert. See Vouchers for the packing layout.

RedemptionManager guarantees that escrowed vouchers reach exactly one terminal state, settled (burned), refunded, or reclaimed. The reclaim path is permissionless for the holder and gated only on a timestamp. See Redemption.

Marketplace holds no inventory and takes no custody. Orders are signed off-chain; the contract only verifies and settles.

Parameters

Every parameter below is undetermined.

Parameter	Value
Epoch length	`TBD`
Expiry bucket width	`TBD`
Furthest open bucket	`TBD`
Voucher mint fee	`TBD`
Marketplace taker fee	`TBD`
Attestation quorum `m` of `n`	`TBD`
Operator bond	`TBD`
Reclaim grace period	`TBD`
Accepted quote assets	`TBD`

Admin and upgradeability

The upgrade model, the admin key structure and the governance process are TBD. This is a material question for anyone assessing the protocol, and it will be answered explicitly, with addresses, timelocks and roles, before any deployment. Until then, assume nothing about it.

Verification

When contracts are deployed, addresses will be published here and should be checked against the block explorer's verified source. Until that happens:

There is no $WATT token address.
There is no staking contract to interact with.
Any address circulating as one of these is not one.