Holder stock rewards

After the canonical revenue router enters its open state, the reviewed Functional policy deposits 35% of recognized Hook revenue into an isolated Holder budget. Holder Rewards purchases approved assets through a configured venue and records actual USDG spent and reward tokens received.

Manifest-bound ordered basket

stockNvda → stockAapl → stockTsla → stockAmzn → stockMeta.

Rotation anchor

Each new purchase starts at purchaseCount % 5, then wraps through the same ordered basket.

Minimum purchase

1,000,000 raw USDG = 1 USDG in the current Testnet worker configuration.

Maximum purchase

10,000,000 raw USDG = 10 USDG; this cap is also bound as riskPolicy.epochCaps.holderPurchaseRaw in the release policy.

Exact input

min(availableBudgetUsdRaw, 10,000,000, route.maxUsdgInRaw); it must still be at least 1,000,000.

For each candidate, the worker requires Holder approval, an enabled nonzero route version, an executable route cap, a non-expired preview with the same version/validity, nonzero output, and enough Testnet venue inventory. If the rotation’s first asset fails, it tries the next asset in the manifest basket; it never substitutes an asset outside that basket. If all five fail, no purchase is sent. A later worker tick retries the same durable purchase ID; this pre-send no-route branch does not currently schedule the transaction-revert backoff.

1. 01

   Freeze a finalized snapshot

   Reconstruct FLIP balances, exclude protocol/pool/lock/Treasury/Game/Router/vesting/dead addresses, and keep non-excluded accounts holding at least 0.001% of fixed total FLIP supply.

2. 02

   Purchase reward inventory

   Entitlements are based on the asset amount actually received, not an unfilled USDG estimate.

3. 03

   Fund the epoch

   The Publisher commits purchased stock inventory, asset, snapshot block and metadata hash. Funding alone cannot activate claims.

4. 04

   Approve and activate independently

   A separate rootApprover first replays the complete finalized snapshot through distinct Primary and Backup control planes, then signs the exact EIP-712 epoch/root/entitlement/deadline. The signed metadata commitment also binds Source A, the release manifest and its address set. Only then may the Publisher activate it; Mainnet may replace the EOA approver with ERC-1271 governance.

5. 05

   Claim to the proof account

   Anyone can submit the proof, but the token is sent only to the account encoded in the leaf. A bitmap prevents double claim.

Funded → Active → Exhausted

Funded means real purchased reward inventory is reserved, but claims are still closed. The independent root approval and Publisher activation move the Epoch to Active. Claims reduce the remaining entitlement; the final entitlement moves it to Exhausted. None of these labels may be inferred from an offchain spreadsheet alone.

The Holder publisher prepares and submits activateEpoch, but the transaction succeeds only with a non-expired EIP-712 approval from the separate rootApprover. The approval digest binds the exact epoch ID, stock asset, finalized snapshot block, metadata hash, funded amount, Merkle root, total entitlement, and approval deadline. The metadata preimage includes the exact Source-A commit, release manifest hash and canonical address-set hash, so an otherwise identical activation signature cannot be transplanted into another release ceremony.

• The contract requires publisher != rootApprover at deployment and after either role rotates.
• The publisher cannot activate or redirect an Epoch without the independent root approval; the root approver cannot activate one without the publisher transaction.
• Before signing, the isolated approver replays the same artifact through short-lived Primary and Backup read-only capabilities. Both must reproduce the snapshot hash, finality, FLIP runtime, complete Transfer history and resulting artifact.
• The root approver may be an EOA or an ERC-1271 contract, so Mainnet can replace the Testnet signer with governed authorization.
• The owner can rotate both roles and therefore remains a governance trust boundary; Mainnet must place that authority behind the approved multisig and Timelock policy.

thresholdRaw = ceil(totalFlipSupplyRaw / 100,000)   // minimum raw units reaching 0.001%
eligible = !excluded && balanceRaw >= thresholdRaw
eligibleSupplyRaw = Σ eligible balanceRaw
entitlementRaw(account) = floor(fundedStockRaw × balanceRaw / eligibleSupplyRaw)
recycledDustRaw = fundedStockRaw - Σ entitlementRaw

The threshold uses canonical fixed supply, not circulating supply or USD value. Pro-rata division floors each account independently. An eligible account whose computed entitlement is zero cannot be included in an activated tree; aggregate rounding dust stays accounted as reusable stock inventory rather than being silently assigned.

/usr/bin/python3 -I -S infra/protocol_v3_operator.py holder-root-approve \
  --repository-root "$PWD" \
  --operator-env <independent-mode-0600-holder-signer-env> \
  --request "$PWD/deployments/46630/<release-id>/release/runtime/live/workers/holder/epoch-<id>-root-approval-request.json" \
  --output "$PWD/deployments/46630/<release-id>/release/runtime/live/workers/holder-approvals/epoch-<id>.json" \
  --deadline <future-unix-seconds> \
  --expected-manifest-hash <independently-verified-ceremony-manifest-hash> \
  --expected-address-set-hash <independently-verified-ceremony-address-set-hash>

# Run this in the independent root-approver process only.
# Obtain both expected hashes from the independently verified release-ceremony record through an out-of-band channel.
# Never copy either expected hash from the pending request being signed; doing so would make the anchor check circular.
# The signer env must bind the same Source-A commit and release ID, and remain mode 0600.
# The Holder worker must not receive V3_HOLDER_ROOT_APPROVER_PRIVATE_KEY.

• No staking is required by the current design.
• The reviewed Functional manifest excludes 35 exact accounts across 54 named protocol roles from Holder weight. The dataset must explicitly cover the canonical Pair/Pool, Routers, Vaults, burn/dead accounts, Factories, Treasury, Lockers, and all other manifest-bound protocol custody accounts that apply; an omitted custody class fails the snapshot review.
• V3 source fixes eligibility at 0.001% of total FLIP supply. Changing that Mainnet rule requires an explicit new rulesVersion; Epoch duration, basket, and batch policy remain Mainnet launch decisions.
• A single failed claim reverts without consuming the bitmap and can be retried.
• Activation dust is accounted separately and can be reused; it cannot be silently promised as entitlement.
• The contract verifies two independent authorities, the exact signed root, funding and Merkle claims. It does not replay the complete historical FLIP Transfer ledger onchain; the indexer artifact and accepted evidence prove that reconstruction.
• The user API cross-checks proof, leaf, root, Epoch state, claim bitmap, and finalized journal before returning claimable state.