A clear view of
what you hold.

01. The idea

ETFONS brings multiple tokenized exposures into a single vault position. Every ETFONS share is intended to represent a proportional claim on the assets actually held by that vault. Its value can rise or fall with those assets.

The initial draft includes ten assets across five categories, inspired by the SECTOR basket concept. The list and target weights on the homepage are proposals, not actual holdings. Final token contracts, issuer terms and transfer behavior must be verified before launch.

The proposed network is Robinhood Chain. ETFONS is independent from SECTOR and Robinhood. It is not presented as a registered ETF or a promise of direct legal ownership of the underlying companies.

02. The 100 million ceiling

The proposed cap is 100,000,000 ETFONS outstanding at any moment. It is immutable in the intended contract design. The number outstanding increases when backed shares are minted and decreases when shares are burned on redemption.

At the cap, additional minting must revert. Redemption must remain available subject to the underlying assets’ ability to transfer. Burned shares reopen minting capacity. A lifetime mint limit, which would never reopen after a burn, is a different model and is not the model used here.

This is not a 100 million token premint. The initial share value is planned at $1, with each opening share backed by $1 of net basket value at the verified bootstrap valuation. The seed amount, asset quantities and valuation procedure still require a final specification. The cap does not mean all 100 million shares exist at launch.

Every issuance path must respect the same cap, including bootstrap, fees and any future administrative mechanism. No privileged mint exception is proposed.

03. Direct minting and redemption

Mint

The user supplies the required proportional quantities of all basket assets. New shares are issued only against assets received. Maximum input amounts, minimum shares received and an expiry protect the user against a changing quote. Tiny amounts that round to zero must be rejected.

Redeem

The user returns shares to the vault. Shares are burned and the corresponding quantities of underlying assets are transferred to the recipient, after finalized fees. Minimum amounts for each asset and an expiry bound the result.

These formulas describe proportional accounting after initialization, before fees and bootstrap protections. They are not a complete smart contract specification.

No ETFONS liquidity pool

The base flow exchanges basket assets directly for ETFONS. It does not need an ETFONS trading pair, an LP deposit, or a pool price.

Converting a single asset such as USDG into the basket, or converting the basket back to USDG, would require swaps and adequate underlying market liquidity. Such a route is not implemented in this preview.

When an asset cannot transfer

The proposed default is atomic settlement: if a required leg fails, the transaction reverts. The design must not silently burn shares while skipping an asset payout. Asset freezes can therefore block redemption until resolved.

04. A $1 start, then basket value

The planned initial price is $1 per ETFONS. This is an opening valuation, not a dollar peg, price floor or guaranteed redemption price.

Once initialized, the value per share moves as the basket changes in value. New shares require proportional backing at the current vault ratio. Fees, gas and execution costs are separate from NAV. When no shares exist, the bootstrap process must establish the opening ratio; it cannot divide by zero.

For example, a $100,000 seed basket at the agreed initial valuation would back 100,000 ETFONS. A 100 million share cap does not create $100 million of assets. Current NAV remains unavailable until verified holdings and pricing are connected.

05. Two tokens. Two staking groups.

ETFONS is the backed basket share. FONS is the separate governance token planned for launch on Pons. The 100M cap and $1 initial value apply to ETFONS; FONS supply, launch price and launch terms have not been specified.

The proposed staking contracts will accept ETFONS and FONS in separate accounting pools. Staking receipts will record voting power. The voting formula, delegation, snapshots, lock terms and withdrawal rules require specification before implementation.

Eligible stakers in both groups will share funded ETFONS airdrops. Simply holding ETFONS or FONS in a wallet does not establish staking eligibility. The allocation between these groups, reward periods and claim rules are not finalized; the design does not assume an equal split or equal voting weight between tokens.

Deposited principal must stay separate from reward inventory. This matters particularly when ETFONS is both a staking asset and the reward token. Claiming rewards must never spend another user’s stake or withdraw basket backing.

Staking, receipt, voting and reward contracts are not implemented or deployed. The app is a design preview with stake, withdrawal and claim actions unavailable. No fixed APR or guaranteed airdrop is promised.

06. FONS revenue, returned

The planned funding source is revenue from FONS, the governance token to be launched on Pons. It is separate from ETFONS holders’ deposited capital. The precise revenue stream and collection integration will be specified before launch.

The 50% airdrop allocation is one shared budget for eligible ETFONS and FONS stakers. It is not 50% per staking group. The other 50% is held as ETFONS by the treasury, not burned. Both percentages apply after ETFONS acquisition.

Because ETFONS has no official trading pool, the proposed acquisition route is to use FONS revenue to assemble the underlying basket and mint backed ETFONS. It must obey the same prices, execution limits and 100M outstanding cap as any other mint.

At full capacity, revenue cannot create additional ETFONS. There can be no new airdrop from revenue that has not yet acquired shares. The treatment of pending revenue, acquisition costs and execution timing needs explicit contract rules before activation. Already funded rewards remain separate from this acquisition constraint.

Vault deposits are backing, not revenue. Existing basket assets and staking principal cannot be diverted to finance this distribution. Reward rates depend on actual FONS revenue and funded allocations.

07. Fees must fit the cap

ETFONS fee rates and recipients are not finalized. The preview excludes fees and gas. It does not promise zero fee trading.

Management or performance fees paid by issuing additional shares can conflict with a hard cap. The contract design must avoid making redemption depend on a fee mint that reverts at the cap. Transferring a fee from existing shares or charging a disclosed asset fee are possible alternatives, each requiring separate accounting and tests.

No SECTOR fee mechanism has been copied into this project. The final fee model must be selected and reviewed before the transaction interface can be enabled.

08. Security review

ETFONS is not audited or approved for live funds. The current deliverable is a website and an illustrative calculation model. There is no ETFONS Solidity contract in this release. Interface tests are not a substitute for a contract audit.

ERC 4626 provides a useful reference for share accounting and capacity limits, but it describes a single asset vault. A multiple asset ETFONS vault cannot simply be assumed to implement that standard. Read ERC 4626.

Bootstrap and donation risks also need explicit review. OpenZeppelin’s vault security guidance explains why naïve share accounting can be unsafe.

09. Know the limits

• Market risk. The basket can lose value. A cap does not protect its price.
• Issuer risk. Tokenized assets may carry redemption restrictions, custody dependencies, pauses or freezes.
• Smart contract risk. Bugs can cause losses or prevent withdrawals, including after a review.
• Liquidity risk. Direct redemption returns the basket. Selling those assets for a single currency may be costly or unavailable.
• Concentration and drift. Target weights do not remain exact as prices change. Rebalancing rules are not finalized.

10. What is ready

Return to the interactive preview ↗