Robinhood Chain is home to a fast-growing number of tokens and communities. Most of them share the same limit: a token is a balance and nothing more. Paying holders means deploying a staking contract or running airdrop scripts. Holder votes mean a governance contract or an off-chain tool. Knowing who holds what means indexing events and building snapshots by hand.
With an upcoming network upgrade, any Robinhood Chain project will be able to bring its token to Aeva Mainnet as an AE-20 asset: the same token, backed one to one, with ownership, income and voting rights built into the chain itself.
What a project gets
Pay holders in one click. Fund a distribution in AEVA or aeUSD and the chain credits every holder pro rata. No staking contract, no snapshot, no list of addresses.
Holder votes, native. Call a vote on the asset and the chain tallies it by holdings at a fixed height. Nothing to deploy or audit.
A cap table at any block. Exact holdings at any height, straight from chain state.
Rules enforced everywhere. Lockups for team allocations, vesting, per-holder caps: evaluated by the chain on every transfer and settlement, whichever app or wallet initiates it.
A second market. Income is a separate right, so holders can sell a token's future payouts while keeping the token, or buy only the payouts. Trustless OTC. Large trades settle in one block: asset and payment move together or not at all.
Nothing to migrate. The token stays on Robinhood Chain with its liquidity. The AE-20 version is backed one to one and can be bridged back at any time.
Architecture
The path has three parts: a collateral router on Robinhood Chain, Hyperlane messaging verified by Aeva's bridge validators, and an ASSET_IN route in Aeva's bridge module that creates and controls the AE-20 asset.
Robinhood Chain side. Each token gets its own collateral router, Hyperlane's standard HypERC20Collateral, owned by the Aeva Treasury Safe (2-of-3). The router's post-dispatch hook and its interchain security module are both AevaBridgeGuard. As a hook, the guard refuses a dispatch while paused, above the route's per-transfer limit, or beyond its daily limit (counted per UTC day); otherwise it forwards to the Mailbox's merkle tree hook. As an ISM, it applies the same limits to inbound releases, then delegates verification to a message-id multisig ISM requiring two of two validator signatures. The guard holds no tokens and can only refuse.
Messaging. A transfer is a standard Hyperlane warp message: a 32-byte recipient and an amount in the router's units. Aeva's bridge validators sign checkpoints of the Mailbox's merkle tree; a relayer delivers the message and the signatures. The relayer cannot forge or alter a transfer: without both signatures, verification fails on the destination.
Aeva side. Aeva's Mailbox is owned by the bridge module (x/bridge) and verifies inbound messages against its own immutable two-of-two ISM. x/bridge keeps a registry of routes, each bound to one remote router and one local asset. Today it supports NATIVE_ESCROW (native AEVA against $AEVA), SYNTHETIC_IN (plain bridged coins such as aeUSD) and RIGHT_OUT. The upgrade adds ASSET_IN.
The ASSET_IN route
An ASSET_IN route creates its AE-20 asset when the route is opened, through the asset module (x/asset), with the route as the only account allowed to mint or burn it. Each asset is created with three right kinds: ownership, income and vote.
Inbound. On a verified message, the route converts the amount from router units into the asset's units, checks its rolling 24-hour inbound cap, then mints one unit of each right to the recipient. The rights are recorded as positions in the rights module (x/rights). Minting runs through the asset's policy: if the recipient isn't eligible under the asset's rules, the mint is refused and the message stays undelivered rather than minting to the wrong account.
Outbound. A holder bridging back must burn a complete bundle: one ownership unit, one income unit and one vote unit for every token released. This is deliberate. If a holder has sold the income right, they must buy it back before redeeming; otherwise income units could outlive the collateral backing them. The route checks its outbound cap, burns the bundle and dispatches the release.
Conservation. Two invariants hold at every block. For each right kind, the sum of all positions equals the asset's supply. For each route, the tokens locked in the router on Robinhood Chain (its balance, less any LP deposits held under its ERC-4626 interface) equal the asset's supply on Aeva plus messages in flight. Both are checkable by anyone from public state on the two chains.
Income
Distributions use the payout module (x/payout), which is pull-based. When a project funds a distribution, the module updates a per-unit index for the asset's income right. Every holder's claimable amount is their income units multiplied by the index increase since they last settled. Transfers of income units settle the sender's and receiver's accrued amounts first, so a buyer never receives payouts earned before the purchase. Holders collect with a single claim, and the app shows what each holder can claim at any time.
Because accounting is per index rather than per address, a distribution costs the same whether the asset has ten holders or a hundred thousand.
Votes
Per-asset votes run in the vote module (x/vote). A vote records a snapshot height; voting weight is each holder's vote-right units at that height. Selling the vote right separately from ownership is possible by design, which lets a community decide who governs independently of who holds economic exposure.
Policies
Each asset carries a policy evaluated by the policy module on the state after a transfer or settlement would apply. Available rules include per-holder caps, lockups through encumbrances, and credential requirements backed by attestations from trusted attesters. Evaluating on the post-state means a rule can't be bypassed by splitting a transfer into pieces or routing it through an intermediary.
Settlement
AE-20 assets settle against AEVA, aeUSD or each other through the settlement module (x/settlement): every leg is checked and either all legs execute in the same block or none do. OTC trades and income-right sales require no escrow contract and no trusted third party.
Project roles
Roles on an AE-20 asset (who may fund distributions and call votes) are bound when the route is opened. They are assigned only to an address the project proves it controls on Robinhood Chain, for example by a signed attestation from the token's owner or deployer address. No one can open a route for someone else's token and claim to act for it.
Opening a route
Opening a route takes two steps. On Robinhood Chain, the Safe deploys the token's collateral router behind the guard and sets its limits. On Aeva, a governance proposal registers the ASSET_IN route, its caps and the project's roles. Once both are in place, holders can bridge.
Security model
Users rely on the following: the two bridge validators (both signatures are required for every release, in both directions); the Treasury Safe, which owns the routers and the guard and could change their configuration; Aeva governance, which controls route parameters; and the Hyperlane contracts at their pinned versions. Transfers above a limit are held, not lost: the message waits until it fits within the limits. The guard can pause every route in a single transaction.
An independent security audit of the chain and the bridge is in progress, and its report will be published in full.
What's next
ASSET_IN ships with an upcoming network upgrade. We will open it first with a small group of Robinhood Chain projects that want holder payouts or on-chain voting, and widen the program from there.
If your project wants to be among the first, reach out.
Your token. Native rights. On Aeva.
aevachain.org · aevachain.app
