Reflections DOCUMENTS · RFLCT10

How RFLCT10
actually works.

The ten-token basket, creator-fee split, holder accounting, variable settlement periods, and automated in-kind payouts on Robinhood Chain.

The protocol at a glanceTen assets.
One reward flow.

Creator fees fund equal-input basket purchases. Eligible holders receive a proportional share of the purchased tokens after settlement.

Explore the architecture →
01
/ Overview /

One fee stream.
Ten reward assets.

Reflections uses Pons V2 on Robinhood Chain, chain ID 4663. A fee router splits creator fees, while one distributor / basket vault accrues WETH, purchases the basket, and pays holders against a Merkle snapshot.

01

People trade RFLCT10

Five percent of trading volume is allocated to basket purchases.

PONS V2
02

The router directs fees

The 5.00% basket allocation moves through the fee router into the basket vault.

FIXED ALLOCATION
03

The basket buys ten

Fees accrue until settlement is worthwhile. WETH input is allocated equally across ten assets.

VARIABLE PERIODS
04

Holders receive

Automation pays each eligible holder their pro-rata share of the actual basket tokens.

IN-KIND PAYOUTS
Normal holder experience

Hold at least 500,000 RFLCT10 at the snapshot. No staking, approval, claim page, or wallet connection is required for the normal automated path. Automated delivery still depends on funded, functioning offchain services.

Automated Reflexive Looping. The basket includes assets with their own reward mechanisms or stock-pair exposure. Those are different relationships: a stock pair or vault does not by itself pay stock tokens to holders. This design does not borrow funds or guarantee a multiplier. Including an asset in the basket does not mean all of its underlying rewards automatically pass through to RFLCT10 holders.

INDEX · Rewards

NVIDIANVDAMicronMUAppleAAPLGoogleGOOGLMicrosoftMSFTAmazonAMZNTeslaTSLAMetaMETACoinbaseCOINPalantirPLTR
Many more

The Index lists these among its supported tokenized-stock rewards. Its own eligibility and distribution rules apply; this is not the full list.

Project reference ↗

HOOD10 · Underlying basket

DeltaDELTACash CatCASHCATPonsPONSStonkBrokerSTONKBROKERArtificial InuAImicroduckMICRODUCKThe JuggernautJUGGERNAUTThe IndexINDEXTendiesTENDIESYOLOYOLO

HOOD10 connects to its own ten-token basket. These are upstream assets, not additional constituents of RFLCT10's base basket. HOOD10's eligibility and distribution rules apply.

Project reference ↗

GG · Rewards

GoldGLD

The Golden Goose ledger reports GLD deliveries to listed recipients. Owning GG alone does not guarantee inclusion in a distribution.

Project reference ↗

AI · Exposure

NVIDIANVDA

Artificial Inu describes an NVDA pair and community vault, not NVDA payouts to holders. Its website says holders cannot redeem the vault assets.

Project reference ↗
Tokenized assets. Stock reward tokens are not brokerage shares. The Index's published disclaimer states they do not include voting rights or corporate dividends. “Dividends” on this site describes token-project reward mechanisms, not guaranteed issuer dividends.
02
/ The money flow /

The fixed 5%
basket model.

Five percent of trading volume is directed to basket purchases. This rate drives the basket illustrations and reward calculator throughout the site.

Basket purchases5.00%

The basket allocation funds ten equal WETH purchase inputs. Each asset therefore receives 0.50% of modeled trading volume before trading costs.

Basket arithmetic. The 5.00% allocation is divided into ten equal purchase inputs, equivalent to 0.50% of modeled trading volume per basket asset before execution differences.
Steady-state scope. Opening-window launch taxes, if configured on Pons V2, are separate from this steady-state model. Basket allocation is purchase input, not a guaranteed dollar value received after trading costs and market movement.
03
/ Permanent basket /

Ten assets.
Equal purchase input.

The basket contains the ten assets below. Each constituent receives one-tenth of the basket's allocated WETH input, not an equal number of tokens.

AssetTokenBasket inputDecimals
01 · PONSPons0x39dBE…C4571 ↗1 / 10 WETH input18
02 · DELTADelta0xe8ffd…9a791 ↗1 / 10 WETH input18
03 · HOOD10Robinhood10 Index0x0D257…838cc ↗1 / 10 WETH input18
04 · GGGolden Goose0xcaCB0…Bcb68 ↗1 / 10 WETH input18
05 · GTRGTR0x68461…ab0f5 ↗1 / 10 WETH input18
06 · MICRODUCKmicroduck0xD5f1a…9E725 ↗1 / 10 WETH input18
07 · NETNetNet0xCA9c7…30eDf ↗1 / 10 WETH input9
08 · AIArtificial Inu0x2E8c3…11e18 ↗1 / 10 WETH input18
09 · INDEXThe Index0x56910…89870 ↗1 / 10 WETH input18
10 · CASHCATCash Cat0x020bf…018b4 ↗1 / 10 WETH input18

Equal-input rule

Ten equal WETH allocations fund the basket. Output quantities differ with token prices, decimals, liquidity, and trading costs. Equal input does not keep portfolio market values equal over time.

Token precision

NET has 9 decimals. Every other basket asset has 18. Token amounts must be interpreted in each asset's native units before displaying human-readable balances.

Multi-hop purchases

GTR uses WETH → VIRTUAL → GTR. NET uses WETH → USDG → NET. An asset does not need a direct WETH pair to be included.

Market links versus execution

MICRODUCK's contract route is V3/WETH at 1%. Its Dexscreener link points to the public V4/USDG market. Public market IDs are informational and must not be treated as execution-pool addresses. HOOD10 uses a V4 ETH pool with the CashCat hook.

Trade execution

Basket purchases depend on available liquidity and market prices. Slippage settings limit acceptable output differences; they do not guarantee the best available price or remove execution risk.

Actual tokens received

Holder allocations use the tokens acquired for a settled period. A quoted value, equal WETH input, or calculator estimate is not a fixed amount of output tokens.

04
/ Holder calculation /

A holder snapshot.
A proportional share.

For each variable-length period, the publisher prepares a Merkle snapshot of eligible holders. A wallet's share uses its balance at that snapshot, not a live balance read when a payout transaction arrives.

REWARD FORMULA · FOR EACH OF TEN ASSETSfloor(epoch reward × eligible wallet balance ÷ total eligible balance)
  1. Period snapshotEach settled period has an associated holder snapshot. “Epoch” in the formula means a variable-length period, not a fixed duration.
  2. MinimumA wallet must hold at least 500,000 RFLCT10 at the snapshot and meet the protocol's eligibility and exclusion rules.
  3. DenominatorThe balances of all eligible wallets form the denominator. The 1,000,000,000 RFLCT10 total supply is not automatically the reward denominator.
  4. Per-asset calculationThe formula applies to each asset's actual period rewards in base units, rounding down. Holders receive tokens in kind, not a promised ETH or dollar amount.
  5. Merkle commitmentThe publisher commits the holder snapshot. Payouts are checked against that commitment and the distributor's accounting rules.
Publisher trust boundary. A Merkle proof verifies membership in a published snapshot; it does not independently prove that the offchain holder list is complete or correct. Correct allocations depend on the publisher's holder data, exclusions, and total eligible balance.
05
/ Distribution cycle /

Fees set the pace.
Automation delivers.

There is no fixed onchain epoch duration and no fixed payout interval. Periods close when accrued fees justify settlement. The keeper runs roughly every few hours, not on a fixed clock; actual delivery depends on settlement and service availability.

AccrueFees build up in WETH
→
SettleBuy the basket when justified
→
DistributeAutomated in-kind payouts
→
180 daysFallback claim window

Automatic path

The project funds the keeper's transactions to deliver rewards to eligible wallets. Holders do not need to connect to this website or press a claim button for normal automated delivery.

Direct-claim fallback

If automated delivery is interrupted, the direct-claim fallback remains available during the 180-day claim window. A manual fallback requires an onchain transaction, separate from this informational website.

Not a countdown

Settlement and delivery are distinct operations. Low fee accrual, transaction failures, or service downtime can delay completion. “Every few hours” describes the intended keeper cadence, not an entitlement to timed payments.

Expiry behavior

The fallback is not indefinite. Once the period's 180-day claim window expires, claims close and unpaid balances follow the distributor's expiry handling. Use the actual onchain deadline for a published period.

Calculator interpretation. Daily and yearly outputs are modeled averages based on your chosen trading volume and eligible balance pool. They do not imply daily payments, fixed period counts, or guaranteed profit.
Optional 1.6× scenario. The calculator can multiply its base reward estimate by 1.6, modeling an extra 60% from hypothetical upstream rewards. The base-only option uses 1×. This is a modeling assumption, not a measured return, contract-enforced multiplier, or compounded yield. Actual extra rewards may be lower or zero and depend on each upstream project's minimums, exclusions, distribution rules, and asset values.
06
/ Onchain transparency /

Two core contracts.
One reward flow.

The architecture separates fee routing from basket accounting and payouts. The distributor and basket vault share one contract, linking fee accrual, purchases, and holder distributions.

Distributor / basket vaultAccrues WETH, buys the ten-token basket, and pays holders in kind against a Merkle snapshotPons7IndexDistributor
Fee routerReceives creator fees and routes the 5% basket allocation into the basket vaultPons7FeeRouter
Contract reference. The names above identify software components, not wallet addresses. Core contract addresses are not available on this page. The basket table links to each constituent token on Robinhood Chain.
07
/ Roles & trust /

Automation needs
accountable operators.

Offchain services prepare holder data and submit transactions. Onchain contracts account for fees, basket purchases, and payouts. Reliable delivery depends on both layers working together.

Snapshot publisher

Prepares and publishes the eligible-holder Merkle snapshot. Correct balances, exclusions, and the total eligible denominator are critical to correct payouts.

Keeper

Submits settlement and distribution transactions. It supplies per-swap minimum outputs, so sensible slippage settings, monitoring, and transaction funding matter.

Operations Safe

Supports infrastructure, monitoring, and transaction gas for the automated settlement and delivery services.

Holders

Receive their proportional share in the ten basket tokens through normal automation. The direct-claim fallback is available within the 180-day window if needed.

What can affect rewards? Trading volume, token prices, liquidity, snapshot eligibility, and service availability all affect the amount or timing of rewards. Basket assets can lose value, and automated delivery does not eliminate market or operational risk.