no value digital asset
Fund the liquidity of this no value digital asset. Anyone can pull the lever.
Draft v0.3 · Pons v2 liquidity implementation · Robinhood Chain
The name is unserious. The accounting should be exact. This document describes a token paired with tokenized NVDA and the implemented contract system that reserves half of project fee receipts for liquidity, with a public function to trigger the injections.
Implementation status: The fee receiver and signed reference oracle are deployed and source-verified on Robinhood Chain. The token has not launched, so the receiver is not bound and the permanent vault does not exist yet. The 26-test Solidity suite includes a live-state fork that creates a new token through the real Pons V2 factory, binds it to our receiver, and creates the vault. Independent oracle operation, review of the reporting policy, and an independent contract security review are still required. Implementation source, tests and notes are available from the source page.
I. The whole idea
Launch through Pons. Trade against tokenized NVDA. Route project fees to a contract. Reserve half to deepen that same market. Let anyone trigger an injection when conditions permit.
The receiver contract enforces the allocation, so reinvestment does not depend on someone manually forwarding funds from a personal wallet. The other half of receipts remains allocated to the project treasury. This creates no holder entitlement to dividends, fee distributions, bonus claims, or a fixed redemption value.
Liquidity is capital available for trading. Increasing active liquidity can reduce price impact for a given trade, all else equal. It does not guarantee buyers, profits, a price floor, or a particular exit price.
II. What the token is paired with
The intended quote asset is NVIDIA • Robinhood Token on Robinhood Chain. Our token and the quote asset are separate assets.
Robinhood describes Stock Tokens as tokenized debt securities providing economic exposure to the underlying security, without ownership rights in the underlying shares. Our project token is not a NVIDIA share or a Robinhood Stock Token.
A trading pair is not a peg. Our token can fall against tokenized NVDA while NVDA also falls in dollar terms. The project is independent and is not affiliated with NVIDIA, Robinhood, or Pons.
Asset availability and participant eligibility depend on the relevant platform and jurisdiction. Consult the Robinhood Stock Token documentation and Pons access terms.
III. The launch path
The token is intended to launch through the Pons v2 factory, using its fixed-supply launch mechanism. Final supply, pairing address, graduation settings, and fee terms must be checked and published at creation.
Trading starts on the Pons bonding curve. Once graduation completes, trading moves into a Uniswap v4 pool with Pons’s original liquidity position locked.
Our additional liquidity program only starts depositing after that pool exists. During the curve phase, its share of claimed fees accumulates in the dedicated receiver.
If the token never graduates, that budget remains undeployed. The deployed receiver has no recovery path for the liquidity allocation; its permanent-funds policy cannot be changed.
IV. Two percent, with the arithmetic showing
The intended ordinary trading fee is 2% on buys and 2% on sells. Under the Pons fee settings checked on 4 September 2026, this means a 1% base trading fee plus a 1% creator tax, with native Pons buybacks disabled.
| Destination | Nominal allocation |
|---|---|
| Pons protocol | 0.30% of the fee basis |
| Liquidity budget | 0.85% of the fee basis |
| Project treasury | 0.85% of the fee basis |
| Total ordinary trading fee | 2.00% |
Pons takes 30% of the 1% base fee. The remaining 0.70% plus the entire 1% creator tax totals 1.70%. Pons calls this the creator share; the designated recipient will be our receiver contract. The contract splits actual receipts equally between liquidity and the project treasury.
These are target allocations, not guaranteed net deposits. Execution, conversion, rounding, swap fees, and operating costs affect the final amounts. Opening-buy protections can impose additional temporary charges; they are separate from the ordinary 2% schedule.
A 2% creator-tax setting would produce a 3% combined fee at the current base rate. Final launch settings must be checked rather than inferred from the label in a launch form.
V. Fees into a contract. Liquidity out.
At launch, creatorFeeRecipient will be set to the deployed receiver at 0x13038CeFF8B614226816a4A42988c21c12fF8039. That address holds the claim on Pons fees; a personal wallet never needs to collect them first.
Pons uses a pull-based escrow with balances indexed by recipient and asset. The receiver reads its quote balance and calls claimToken(quoteAsset) itself. A public caller invokes our wrapper. A local fork test against the deployed escrow confirmed that a contract recipient can collect its credited tokens while a bystander cannot take that balance. This test used a test ERC-20; a separate integration test used real tokenized NVDA in an existing Pons pool.
For an illustrative claim of 100 tokenized NVDA units:
| Allocation | Amount |
|---|---|
| Liquidity budget | 50 NVDA |
| Project treasury | 50 NVDA |
The liquidity budget buys the required quantity of our project token and combines it with the remaining NVDA to add liquidity. The correct ratio depends on price, the full-range position, accumulated balances, and execution costs; it is not always an exact 25/25 split.
The implementation requires the caller to pay gas externally; it deducts no caller reward or gas reimbursement from the liquidity budget. The dashboard should distinguish gross allocations, swap costs, funds awaiting execution, and amounts actually deposited.
The treasury allocation remains separate from the liquidity budget. Its control and spending policy must be published; calling it a project treasury does not make that half locked liquidity.
The developer withdrawal function is payTreasury(). It transfers only treasuryAccrued to the immutable treasury address and clears that accrued balance. It cannot transfer the reserved liquidity budget or withdraw the vault’s position. Anyone may trigger the payment, but only the configured treasury receives it. claimFees() first collects any available escrow fees when a developer wants to accrue their share without requesting an injection.
VI. A deeper pool, not a donation address
The implementation adds a separate position in the same Pons Uniswap v4 pool. It does not attempt to withdraw or take control of Pons’s original locked position.
A custom vault owns the additional position directly in Uniswap v4 core. It has no position NFT to transfer, owner, upgrade path, arbitrary-call function, or withdrawal entry point. Its only liquidity operation is an increase. These code restrictions still require independent review before launch binding creates the vault.
The vault uses a full-range position so it does not require an operator to continually choose a narrow price band. Deployment must verify the exact pool key, token ordering, hook, tick spacing, approvals, and deployed position manager.
Transferring tokens to a pool address does not by itself create active liquidity. The program must execute a proper liquidity mint or increase.
An additional position is intended to provide trading depth. It does not create a new entitlement to Pons creator revenue or a promised LP yield.
VII. Anyone can feed the pool
The public entry point is claimFeesAndInject() on the deployed receiver. Any address can call it, including an optional automation bot. No team signature is needed to trigger an eligible injection. The caller pays transaction gas and gains no right to receive fees, change recipients, or withdraw the position. No caller reward is included in the fee model.
The public execution panel now connects to the deployed receiver for wallet connection and live fee balances. Token-specific execution stays inactive until the Pons token is launched and bound. It reports successful deposits separately from transactions that only collect fees or defer an injection. The developer section exposes accrued treasury fees and the separate payment action.
After source verification, the same public function can be called through the receiver’s Write Contract tab on Robinhood Chain Blockscout. Users connect their wallet to Blockscout rather than this website, select claimFeesAndInject() with no arguments, send no ETH value, and pay the transaction gas. See Blockscout’s contract interaction guide.
The function collects available fees, accounts for the 50/50 split, and uses the accumulated liquidity budget to buy the required project tokens and increase the vault’s position. Claims remain possible before graduation or while injections are paused by execution conditions, with the liquidity share retained for later. New claims and previously reserved funds are tracked separately so an existing budget is never split twice.
The implementation fixes the pool, assets, recipients and allocation. It enforces minimum budgets, maximum batches and swap amounts, reference-price deviation limits, minimum output and reentrancy protection. Public callers cannot change those limits. Stale, future-dated or unavailable oracle data stops injections. The signed oracle requires a deployment-time quorum and permits anyone to relay a valid report. The accompanying reporter calculates a 30-minute time-weighted arithmetic mean tick from confirmed pool events. Its signer operation and calculation policy still require independent review; no oracle removes the risk of sustained manipulation in a thin market.
Unsafe execution should leave funds pending rather than force a swap. An injection should also be able to use an existing budget when there are no new escrow fees to claim. A reverted transaction must not corrupt split accounting or lose funds. Public access removes reliance on a single bot, but someone still needs to submit a transaction.
Fees first accumulate on the curve or hook, then reach the escrow through a sweep. Recipient-authorized sweeps without internal swaps can be included where supported. Sweeps that convert launch-token fees or perform a buyback require Pons’s authorized operator. Our public function cannot force those conversions. Reporting must distinguish accrued fees, claimable escrow balances, reserved liquidity funds, and completed deposits.
Pons’s native buyback-and-vesting feature is not this liquidity program. The launch configuration leaves that feature disabled.
VIII. What holders should expect
No holding-duration bonus. No personal reward claim. No protocol promise to redeem our token at a fixed price. The public execution function claims fees for the liquidity system; it does not pay a reward to the person clicking it.
The intended benefit is shared market depth from reinvested trading revenue. Holders do not receive the 0.85% project treasury allocation or own a redeemable share of the liquidity vault.
The name does not remove market risk. Both assets can lose value, smart contracts can fail, execution can be manipulated, and automation can stop. Locked liquidity is a restriction on withdrawal, not protection from trading losses.
IX. What must happen before launch
- Review the published receiver, vault and public execution implementation; optionally run a bot using the same entry point.
- Distribute oracle signer keys across independent reporters and test a complete new-token launch with the final price-reporting policy.
- Re-run the existing repeated-call, existing-budget, reentrancy, manipulated-price, and failed-execution tests against the final configuration.
- Review withdrawal restrictions, approval paths, treasury control, and failure behavior.
- Document Pons fee-recipient redirection and operator dependencies; do not present the entire system as ownerless.
- Publish security-review findings and resolve material issues.
- Finalize cost funding, minimum execution budgets, and any stranded-fund policy.
- Verify the launch transaction and publish project-specific addresses.
The first implementation and its test results do not establish that the complete system is ready for real funds. Pending liquidity funds have no recovery path if graduation never occurs or the oracle permanently fails. The deployed receiver makes that permanent-funds policy immutable.
X. Show the receipts
As activity begins, public reporting should distinguish:
- Project fees accrued, claimable, and received in tokenized NVDA.
- Project treasury allocations and payouts.
- Liquidity funds waiting to be used.
- Costs incurred during reinvestment.
- Actual liquidity added, with pool and position identifiers.
- Transaction links for completed actions.
Until those transactions exist, the site displays launch status and planned economics rather than unrelated prices, balances, or historical token addresses.
Fund the liquidity of this no value digital asset. Then show exactly where the funding went.