VORT reward flow

• Arc records proceeds and holder snapshots. Creator funds the exact Arc holder budget to an independent Reward Executor, which distributes USDC directly or swaps for supported Arc reward assets. The Robinhood Chain route continues through the separate Robin Treasury.
• The browser reads one backend projection. It does not calculate balances, holder eligibility or settlement results itself.
• Each Epoch freezes its snapshot, holder preferences, asset metadata and configuration when it is created. It retains receipts for the operations required by its routes; direct USDC distribution needs no bridge or purchase.

1. 01

   Accumulate Argus trading fees and read the Creator amount that can actually be claimed.

2. 02

   At the threshold, pin one confirmed Arc block and its hash.

3. 03

   Enumerate token holders at that block, apply the eligibility policy, and freeze eligible holders, reward preferences and configuration when creating the Epoch.

4. 04

   Call the Argus distribution path once; Argus performs its configured buyback-and-burn share and makes Creator proceeds claimable.

5. 05

   Claim the Creator proceeds and freeze 10% for operations and 90% for holder rewards.

6. 06

   Transfer the exact operations budget to the operations wallet and the exact Arc holder budget to the independent Arc Reward Executor. Both transfers require confirmed receipts.

7. 07

   Keep the Robinhood Chain portion with Creator until its Relay source transaction sends it to the configured Robin Treasury.

8. 08

   Use the frozen preferences to group required swaps or purchases by network, contract and asset UID. Direct USDC rewards do not require a purchase.

9. 09

   Distribute direct USDC entitlements or actual swap and purchase output according to frozen eligible holdings, retaining receipts or explicit pending liabilities.

• The current minimum is 0.05% of ERC-20 totalSupply at the pinned block. It is a versioned configuration value and can be changed for a future Epoch without rewriting history.
• Trading pools, burn addresses and explicitly configured blacklist addresses are excluded.
• Contract wallets are not excluded merely because they contain code. Safe and other real owner wallets remain eligible when they satisfy the same rules.
• If the minimum proceeds or minimum holder count is not met, funds keep accumulating and no Epoch is opened.

• Argus first applies its configured platform share. In the current launch configuration, 10% is the Argus buyback-and-burn path and 90% becomes Creator proceeds.
• VORT budgets only the Creator amount actually received. From that receipt, 10% is operations and 90% is the holder reward budget.
• Argus burn, Creator receipt, operations allocation and holder distribution must never be added as if they were the same amount.
• Burn totals are published only from official events or auditable onchain evidence; an estimate is never presented as settlement.

• The Arc and Robinhood Chain recipient use the same EVM address; no separate address registration is required.
• Saving a preference requires a wallet signature and does not send an onchain transaction.
• Each wallet has one reward preference. A saved change starts with the next Epoch and remains in use until changed or unavailable. It cannot alter an Epoch that has already been created.
• At Epoch creation, an absent or unavailable preference falls back to the configured default asset. If that default is unavailable, the backend waits instead of opening an Epoch. The default follows the protocol configuration at creation.
• The signature deadline limits when the signed request may be submitted; it does not expire a successfully saved preference.
• Holdings, preferences and asset metadata are frozen at Epoch creation. Required purchases are grouped by network, contract and asset UID; direct USDC needs no purchase, and different assets are accounted for separately.

• Epoch ID, opened/closed UTC timestamps, configuration fingerprint, snapshot block number and block hash.
• Holder addresses, balances, eligible supply, reward preferences and proportional entitlement frozen at creation, with each asset identified by network, contract and UID.
• Creator claim/receipt evidence and the frozen operations and holder budgets.
• For Robinhood Chain routes, bridge operation ID, Arc source transaction, destination receipt, sent amount, received amount and recorded cost.
• For routes requiring a swap or purchase, actual fill, recorded fees and transaction hash. All routes retain per-wallet paid amounts, pending amounts and distribution hashes; direct USDC has no purchase receipt.

• A meaningful cache revision notifies the browser immediately. Ordinary new blocks do not force the entire page to refresh.
• If an upstream RPC or provider is unavailable, the last known good value stays visible with freshness metadata; unknown values remain unavailable instead of becoming zero.
• QuickNode deliveries are replay-safe. External writes keep stable operation and payment IDs so a restart resumes from the recorded step.
• An unknown bridge, purchase or payment result remains pending for reconciliation. The worker does not silently repeat a non-idempotent transaction.

• Public wallet and contract addresses are safe to disclose; signer private keys, RPC credentials and webhook secrets are never part of this response.
• A missing deployment field is shown as unavailable. The page does not guess an address from transaction history.

Always verify the chain, role and address in your wallet before signing.

• Amounts remain integer decimal strings at API boundaries. USDC uses 6 decimals; other reward assets use their frozen asset metadata. Amounts from different networks, contracts or asset UIDs are kept separate.
• Timestamps are ISO 8601 UTC. Freshness, stale state, block identifiers and partial errors must be preserved by integrations.
• Transaction and address links are created only for a valid hash/address and the explorer configured for that chain.

• Use GET /backend/api/v1/configuration for chains, public addresses and versioned policy values.
• Use GET /backend/api/v1/overview, /epochs and /epochs/<epoch-id> for live state and complete Epoch evidence.
• Use GET /backend/api/v1/wallets/<0x-address> for frozen holdings, entitlement, selected asset and payment receipts.
• Use GET /backend/api/v1/reward-assets for configured Arc reward assets, the available Robinhood Chain Stock Token catalog and logo metadata.
• Every response preserves schemaVersion, asOf, freshness/stale metadata, block identifiers and partial errors where applicable.
• Amounts are decimal integer strings, timestamps are ISO 8601 UTC, and addresses/hashes should be validated before linking.

GET /backend/api/v1/configuration
GET /backend/api/v1/overview
GET /backend/api/v1/epochs
GET /backend/api/v1/epochs/<epoch-id>
GET /backend/api/v1/wallets/<0x-address>
GET /backend/api/v1/reward-assets

• Stock Tokens on Robinhood Chain are onchain reward assets and do not represent direct ownership of the underlying shares.
• Bridge routes, market liquidity, slippage, token availability and Robinhood Chain gas can change between Epochs.
• A settled Epoch may still show a pending payment liability. Pending funds stay assigned to the original wallet and asset until confirmed.
• Configuration upgrades apply prospectively and are identified by a new fingerprint; historical Epoch records stay immutable.