The reward vault

From collected fees to a claim

SPY creator revenue is collected into the rewards vault. The publisher then chooses a completed holding period and an allocation budget from the available SPY.

Wallet holding weights and allocations are calculated, and a public record is prepared. Publication records the allocation on-chain and reserves its SPY budget. Eligible wallets can then submit claims.

The contract does not calculate and publish periods on its own. No automatic publication cadence is currently configured.

Three balances to understand

Vault balance: all SPY currently held by the rewards contract.

Reserved SPY: the unpaid budgets already committed to published reward periods.

Available SPY: vault balance minus reserved SPY. Only this available amount can fund a new allocation.

Example: 1,000 SPY in the vault

Suppose the vault contains 1,000 SPY, with 600 SPY already reserved for earlier periods. There are 400 SPY available for a new allocation.

If the next period receives a 100 SPY budget, reserved SPY rises to 700 and available SPY falls to 300. The vault still holds 1,000 SPY until claims are paid.

If your weight is 1% for that new period, your allocation is 1 SPY—not 1% of the whole 1,000-SPY vault.

What happens when someone claims

Continuing the example, when a holder claims 1 SPY, the vault balance falls from 1,000 to 999 and reserved SPY falls from 700 to 699. Available SPY remains 300.

Paying an existing claim therefore does not consume the funds available for a new period. The claim was already backed by its reserved budget.

Periods, budgets and rounding

Each reward period records a starting block, an ending block, a fixed SPY budget and the amount paid so far. The calculation includes the starting block and excludes the ending block. Published periods cannot overlap.

The publisher can allocate less than the available balance. Allocation amounts are rounded down, and the generated period budget is the sum of those rounded amounts. Unallocated rounding dust remains available rather than creating an unsupported claim.

If there are no eligible holdings, the snapshot builder does not generate an allocation. Funds remain in the vault for a later period.

The public allocation record

Each published record identifies the chain, token, rewards contract, period boundaries, excluded addresses, wallet holding weights and SPY amounts. It also includes the proof needed for each claim.

A fingerprint of the record is stored on-chain alongside a compact commitment to the allocations, called a Merkle root. The record must remain accessible so wallets can retrieve their proofs.

What a claim proof establishes

The contract checks that a wallet and SPY amount belong to the published allocation, that the wallet has not claimed that period already, and that payment fits within the remaining period budget.

A proof is tied to the chain, rewards contract, reward period, wallet and amount. Someone else can relay the transaction and pay its gas, but the payment still goes to the entitled wallet.

The publisher’s role

The snapshot publisher is responsible for selecting period boundaries, reviewing excluded addresses, calculating allocations and publishing the record. Only the contract owner can publish new periods.

A valid claim proof establishes inclusion in that published record; it does not independently prove the historical allocation was fair. Holders can inspect the public transfer history and recalculate the published weights to check the publisher’s work.

What stays fixed after publication

A published period’s allocation cannot be replaced, and the contract provides no owner withdrawal function. Its unpaid budget stays reserved for claims.

There is no claim-expiry timer. Losing access to a wallet or its allocation proof does not make its reserved SPY automatically available for a new period.

Gas and processing

Collecting revenue, publishing a period and claiming SPY are separate transactions. The party submitting each transaction pays its gas in ETH. The holder normally pays for a claim made through the dashboard.

Claims are paid individually rather than by sending SPY to every holder in one large transaction. There is no requirement that all wallets claim together.

Reading the dashboard

Wallet PASSIVE is the connected wallet’s current token balance. It is not a display of historical holding weight.

Claimable SPY is the sum of that wallet’s published, unclaimed allocations. New revenue awaiting allocation is not included.

ETH for gas is the wallet’s native balance. Reward-period rows identify the allocations available to claim and those already claimed.