How $EARLY rewards work
This program redistributes creator fees actually collected from trading. It is not outside investment income. There is no guaranteed payment amount, return, token price or break-even time, and no future volume is assumed.
How much do I get?
Your share depends on your eligible EARLY balance, each purchase's early bonus, and how long you hold. That share is applied to the ETH actually collected for rewards. More eligible holding weight can reduce your percentage; more fees can increase the amount. There is no fixed payout.
When do I get paid?
Payments are scheduled every five minutes, after confirmation and fee collection. You do not need to stake or claim. Rewards under 0.00001 ETH accumulate; network delays or unavailable fees can postpone payment.
What does buying early change?
Verified purchases receive up to 2× reward weight at launch. The bonus declines to 1× over seven days and stays fixed for each purchase while held. Tokens received by transfer start at 1×.
What happens if I sell?
Selling beyond the cumulative allowance ends future rewards for that address. Buying back does not reset the limit. ETH already earned remains payable. The small dollar allowance for launch is being finalized; this demo still uses the token-based rule described below.
Full rules and technical specification
What funds the pool
100% of this launch's creator proceeds received by the reward vault: the 5% creator tax (creatorTaxBps = 500) plus any ordinary creator fee share. Nothing is deducted for the operator; gas and operating costs are funded separately. Protocol fees, LP fees belonging to others and money still inside Pons are not part of the pool.
Only ETH actually claimed into the vault is distributable. Nominal fee accrual, escrow credit and EARLY-denominated fee inventory are tracked and displayed but are not budget. A receipt belongs to the epoch containing its vault-receipt timestamp even when the trades happened earlier. This cash-basis convention will not change after launch without a separately disclosed program.
Time
T0is the block timestamp of the verified launch transaction. Epocheis[T0 + 300e, T0 + 300(e+1)). An event exactly at an epoch end belongs to the next epoch.- All accounting uses canonical chain timestamps, never server or browser time. Countdowns on this site are display only.
- Five-minute batching is a schedule, not a guarantee of payment within five minutes of a purchase. Safety confirmations, Pons sweeps, the payout threshold, congestion and rejecting receivers can delay payment.
Early multiplier
multiplier_bps = 10000 + ⌊10000 × max(0, 604800 − (t − T0)) / 604800⌋. Each verified purchase is its own lot fixed at that multiplier; it does not keep decaying and it is not an interest rate.
Scroll to see all columns →
| Purchase time after launch | Multiplier |
|---|---|
| Launch | 2.0000× |
| Day 1 | 1.8571× |
| Day 3 | 1.5714× |
| Day 3.5 | 1.5000× |
| Day 7 and later | 1.0000× |
1,000,000 tokens at 2× plus 1,000,000 at 1× is 3,000,000 base-equivalent units, not 4,000,000. An early dust purchase does not upgrade later purchases. Tokens received by ordinary transfer, gift, liquidity withdrawal, buyback distribution, bridging or an unrecognised route are 1× lots. The early bonus requires a supported, verified purchase route; when a route is ambiguous the affected epoch pauses rather than guessing.
The 100,000-token rule
Cumulative gross outbound EARLY since first receipt, per address: sales, transfers, LP deposits, exchange deposits, moves to your own other wallet, burns. Approvals are not outflows; moving ETH rewards is not an outflow; self-transfers are ignored. The comparison is strictly greater than: exactly 100,000 is fine, the next smallest unit is not. Incoming tokens never reduce the counter and nothing resets it. Inventory is consumed FIFO.
Scroll to see all columns →
| Event history | Result |
|---|---|
| Sell 60,000; later sell 60,000 | 120,000 cumulative: disqualified |
| Sell 100,000 exactly | Still eligible on remaining holdings |
| Then send one smallest unit | Disqualified |
| Sell 150,000 then rebuy 150,000 in one transaction | Disqualified; final net balance is irrelevant |
| Transfer 120,000 to another wallet | Sender disqualified; recipient has a new 1× lot |
| Buy another 1,000,000 after disqualification | No reactivation |
| Sell all 80,000 tokens | Zero current weight; counter stays 80,000; later purchases earn until the limit is exceeded |
| Receive or spend ETH rewards | No effect on the counter |
| Receive unsolicited EARLY | Adds a 1× lot; no reset, no age upgrade |
After disqualification no new weight accrues, but previous epoch participation, allocations and payments are preserved. A last payment can arrive after selling: that is settlement of earlier participation, not restored eligibility.
Score and allocation
active_weight = Σ remaining_raw × multiplier_bps while eligible and holding, else 0. score = ∫ active_weight dt over the epoch, piecewise constant between events and split at every epoch boundary. Two events at the same timestamp have zero time between them, so a receive-and-return in one transaction earns nothing. Then allocation = ⌊budget × score ÷ total_score⌋ across every positive-score address; rounding dust and zero-score budgets roll forward. No leftover goes to the creator.
provisional_score, allocated_unpaid and paid are separate fields everywhere. A score is a share of an epoch pool, not an entitlement to the exact fee at each second.
Payouts
- Automatic payment when accumulated unpaid credit reaches 0.00001 ETH. Smaller credits are retained and accumulate; the threshold is not a minimum holding and not a forfeiture rule.
- Empty and disqualified addresses with residual credit, including below threshold, are swept out by a gas-funded closeout, targeted within 24 hours of the relevant safe state.
- Native ETH rejected by a destination stays allocated and is retried. It is never converted or redirected.
- Payment is cumulative: the vault pays
proven_cumulative − paid[account], so no proof or root can pay the same credit twice, and older approved roots remain valid.
What this is not
- Not trustless. The operator computes the allocation; two independent validators must approve identical roots, and every manifest is published so anyone can recompute it. A Merkle root proves membership in an approved list, not that the list was honest.
- Not per person. Anyone can open another wallet, which starts fresh with current multipliers or 1× transferred lots and its own 100,000 allowance. Not Sybil-proof.
- Not a total-fee statement. Platform, pool, routing and network costs apply in addition to the 5% creator tax.
- No wallet connection, registration, signature, approval, staking, burn, deposit or claim button exists or will be added to this site.
Excluded infrastructure
Only objectively identified market infrastructure and disclosed project wallets are excluded. Smart-account holders are not excluded for having code.
Scroll to see all columns →
| Role | Address |
|---|---|
| factory | 0x93c06b18f6651cac7ab469feda7defaa2b1023cd |
| curve | 0xe6c1cf08f35564b470ede4155f3c07c03f2fbd1a |
| hook | 0xd7824376c8ea9fe8cb44b87256390e31b0759528 |
| poolManager | 0xdbcde2ccb677b899826db8a4a08b7254268a4580 |
| router | 0x2d27558d21f1fda49975d30a234c494d833400e3 |
| feeEscrow | 0xbded98f98c36646085228400d39f45b89ab7513f |
| rewardVault | 0x4d3036f9e68bff4b7f13fec9c378189c2c82bc95 |
| projectWallet | 0x71e53774bc727cb262cb1ac1a624207b27f3e8ea |
| token | 0x0647745467c34004f339c6a50a2783a4bd696153 |
Read-only API
Scroll to see all columns →
| GET /api/config | Program, rule constants, excluded infrastructure. |
| GET /api/stats | Cash position, schedule, multiplier, holder counts. |
| GET /api/epochs?cursor= | Settled epochs newest first, plus open/confirming epochs. |
| GET /api/epochs/:id | Receipts and allocations for one epoch. |
| GET /api/address/:address | Holding, eligibility, provisional score, allocations, payouts. |
| GET /api/address/:address/lots | FIFO purchase lots with multipliers. |
| GET /api/address/:address/payments | Payout attempts and allocation history. |
| GET /api/proofs/:address?checkpoint= | Merkle proof for the latest or a given checkpoint. |
| GET /api/checkpoints | Published roots. |
| GET /api/checkpoints/:sequence/manifest | Full manifest incl. entitlements. |
| GET /api/activity | Recent ledger tape. |
| GET /api/health | Conservation check, lag, pause state, integration-lock status. |
Every response carries asOfBlock, block hash, confirmation state, rulesVersion, rulesHash and the last indexed timestamp. There is no write endpoint. Responses are cached for a few seconds and lookups are rate limited.
Status
Shadow mode. The history on this site is synthetic and deterministic, produced by the same rules engine and ledger that will run against Robinhood Chain. No token is deployed, no funds are collected and no ETH is paid until every gate in integration-lock.json passes: verified Pons V2 contracts, pre- and post-graduation sweep and claim tests, Fomo receive-and-spend evidence, safe-head semantics, independent root replay, vault security review, gas funding and legal review.