How rewards are decided

The rules below describe the current code path and policy defaults. The live application reads its policy from the server; where a deployed parameter differs, the live policy shown in Earn controls. No rule here guarantees a payout.

1. What counts as holding

CR is earned only by holding the configured token. The server records each wallet's balance of the token mint at regular snapshots. Snapshots are append-only and are never edited. Only tokens in the wallet you sign in with count: tokens on an exchange, in a liquidity pool or in a protocol address are held by someone else. A balance counts when it is at or above the published minimum. Trading, on its own, earns nothing.

2. How a share is calculated

For each epoch, your average balance is taken across all of the epoch's snapshots (a snapshot where you held less than the minimum counts as zero). A wallet must be present in at least half of the snapshots to count, so a purchase made just before a snapshot does little. Your weight is the square root of your average balance, which is sublinear: holding 100 times as many tokens gives about 10 times the weight.

Holding through consecutive epochs multiplies your weight, from 1.00× in the first epoch up to 1.50× after four in a row. If your average balance falls below half of the previous epoch's, the streak starts again. The epoch budget is then shared in proportion to weight, rounded by the largest-remainder method and limited by a per-wallet cap. These values can be changed only by an audited policy update; the live policy is displayed in the application.

CR is a program credit, not money. It is not transferable and cannot be withdrawn.

3. Review and abuse controls

Wallets the operator has linked to each other are held for review when both hold in the same epoch, and a held wallet is not paid until the operator decides. Protocol, pool and treasury addresses are listed in the policy and excluded, and restricted wallets are rejected. Automated reward rounds use six-hour checkpoints when enabled. Manual rounds follow their published opening and closing times.

Review is a screening mechanism, not complete sybil detection. Because weight is sublinear, splitting one position across many wallets would otherwise pay more; the minimum balance, the presence rule and linked-wallet review limit this but do not remove it. An excluded wallet earns no weight. An appeal is attached to the review record and does not automatically release rewards.

4. Reward funding

At most 70% of recorded, settled creator-fee-source USDC deposits is allocated to the reward budget. The remainder supports operating reserve, treasury reserve and reconciliation. Credits are issued only from a funded reward epoch and are finite, capped per wallet and allocated pro rata by holding weight. A pending estimate is not a balance and can change or disappear after review or reconciliation.

5. Community vaults

Community vaults reserve credits for stock only after a closed treasury period funds the vault and a procurement reference exists. Funding, reservation and procurement events are recorded. An open vault is not a promise of a specific product, delivery date or price. A restock is real only when it reaches the published catalogue with stocked inventory.

6. Redemptions and backing

Before a redemption, the server checks the exact voucher pool, availability, declared region, redemption pause state, active credit holds and backing. The ledger must not issue credits beyond funded allocation. A public “verify backing” check compares the configured treasury token account to the minimum unstocked credit liability at that moment. It does not prove deposit provenance, distributor performance or the future usability of a third-party code.

7. Transparency

Public pages show recorded reward budget, holder snapshot count, delivered rewards, standings, vault events and treasury controls. The public treasury statement and reward receipts provide inspectable records. No fake balances, invented participants, guaranteed APY or simulated market metrics are presented as real. Demo mode is labeled and isolated.

8. Region and product limits

Digital codes are region-specific. A code is delivered only for a supported account region declared by the user. Platform restrictions, issuer decisions, stock limits and lawful distribution requirements can make a product unavailable. SIXPASS does not sell publisher services, in-game items or virtual currency, and claims no affiliation with console or game publishers.

9. Changes and contact

These parameters and controls may change to protect backing, respond to abuse or comply with law. Material policy changes should be published. Authenticated reward issues can be raised in the Support Center; a dedicated general contact and complaint process must be published before real-customer operation.