Security & trust

Robin’s Reserve has deployed basket contracts, but the reviewed repository reports no independent contract audit. Public explorer source verification is pending in the deployment record. Local tests, fork execution and bytecode checks provide different kinds of evidence; none is a security guarantee.

This page describes the implemented fixed-basket design reviewed on September 10, 2026. It does not treat the project’s earlier design threat model as a current implementation audit.

Who controls what

Component	Authority and dependency
Your wallet	Signs transactions and grants token allowances. The application backend does not hold a user signing key.
Fixed basket vault	Holds constituent tokens and accounts for shares and withdrawal claims. Its implementation has no owner, upgrade, asset-sweep or portfolio-trading entry point.
Basket creator	Chooses the initial constituents, targets, metadata, and immutable issuance-fee terms. Creating a fixed basket does not grant a right to withdraw other holders’ backing.
Native and liquidity routers	Execute supported routes using fixed registry and venue bindings. They depend on the configured DEX and token contracts.
Constituent issuer	Controls whatever powers the constituent’s own token contract grants, which can include transfer restrictions or upgrades. The basket cannot remove those powers.
Liquidity provider	Owns their pool position. Supported position NFTs are not locked, and their owner can withdraw liquidity.
Website, API and RPC providers	Supply discovery, metadata, quotes and chain reads. Their availability and accuracy affect the user experience and transaction preparation.

Managed baskets are a separate implementation with additional keeper and price-source assumptions. They are outside the recorded mainnet contract set; see release status.

Constituent risk follows the token

Permissionless creation means a basket can include speculative, illiquid or unreliable assets. A token can lose value, stop transferring, restrict a holder, change its behavior, or become impossible to sell. Admission and transfer checks cannot establish that a token will remain compatible indefinitely.

The fixed vault separates active backing from pending withdrawal claims. A redemption request uses internal accounting, and claims are paid one constituent at a time. If one constituent cannot be paid, the implementation allows healthy constituents to be claimed independently. It checks that the affected token can cover its active reserves and pending claims before paying a claim; it does not silently distribute a shortfall by rewarding the first claimant.

These mechanisms do not recover assets frozen, confiscated or destroyed by an issuer. A damaged constituent can leave its own claim unavailable. An atomic sale into ETH also depends on every required constituent transfer and swap succeeding; the independent in-kind exit is a different path.

Prices and liquidity

Launch target weights allocate the initial ETH budget. They are not a guarantee of current market-value percentages, and fixed baskets do not automatically rebalance. Constituent prices can drift, and losses in several correlated assets can occur together.

Trade quotes are size dependent and expire. Pool liquidity can move or disappear between preview and execution. Slippage bounds and deadlines constrain a transaction; they do not promise a profitable trade, an unchanged quote, or the best execution available across all markets.

An ETF pool trades existing shares at a market price. That price can differ from the value of the underlying tokens. Arbitrage is not automatic, and no share price peg is promised. Providing liquidity exposes the provider to changing token prices and a changing mix of assets in the position.

Approvals, identity and external applications

Check the chain, contract, spending amount, receiver and transaction action in your wallet. A token allowance is separate from the site’s connection permission: disconnecting the site does not revoke an existing on-chain allowance.

Creator-supplied names and images are descriptions, not proof of identity. Compare contract addresses with the network and address reference. A token appearing in discovery, a funded pool, or an external-app link does not establish that the asset is endorsed or that an external app can execute your trade.

Service and network assumptions

The application relies on Robinhood Chain, its infrastructure, the configured DEX, RPC reads and the indexer. A service outage or stale index can delay discovery and transaction status. Browser storage also affects locally retained drafts and receipt recovery. Preserve transaction hashes and verify ambiguous outcomes before preparing a new transaction.

Direct contract access remains subject to wallet access, gas, the chain, and the behavior of each underlying token. An available direct exit is not a promise that every token can always be transferred or converted into ETH.

Reading the evidence correctly

• Tests exercise selected behavior against the tested implementation and inputs.
• Fork tests execute against a local copy of chain state. They do not demonstrate that a public-chain transaction was sent.
• Code presence confirms that an RPC returned bytecode at an address.
• Source verification matches published source and compiler input to deployment bytecode; it is distinct from a security audit.
• Independent review must identify its exact scope and release version. No such audit is claimed here.

The release status and known limits pages describe what remains outside the reviewed release evidence.