Risks
Smart-contract risk, dependence on Pons, what is still unverified, market and host risks, fee delays, severed feeders, and what $VIRUS is not.
§Read this first
Viruses are highly speculative tokens priced in other highly speculative tokens. You can lose everything you put in. Nothing in these docs or on the VIRUS site is investment advice, a recommendation to buy or sell any token, or a promise of any return.
§Smart-contract risk
VIRUS is five contracts and a library, written for this protocol. They are non-upgradeable and covered by unit, fuzz and invariant tests that run against mock Pons contracts written for the test suite. Each security invariant names the test that exercises it.
That is not a guarantee:
- These docs make no claim that the VIRUS contracts have been audited.
- Those tests exercise VIRUS against mocks of Pons, built from the published Pons source. They say nothing about behavior against the deployed Pons contracts (see below).
- Non-upgradeability cuts both ways. No one can change an existing feeder, including to fix a bug in it.
- If a feeder's host ever failed the burn assertion, that feeder's
feed()would revert every time and its undistributed host would stay in the feeder. Only the already-booked developer balance could still be claimed.
§Dependence on Pons
A virus is a Pons V2 launch. Its token, curve, pricing, anti-snipe tax, graduation, pool, locked liquidity and fee escrow are all Pons contracts. VIRUS inherits every risk of Pons and adds its own on top.
§Pons audit status
VIRUS displays the Pons audit status only from a hand-maintained record, and never upgrades it without a link to a published report. The current record reads:
| Field | Value |
|---|---|
| Status | UNCONFIRMED |
| Summary | No Pons V2 audit report was reviewed for this build. |
| Source | July 2026 press coverage (secondary) reported the V2 contracts as under audit with two partners. docs.ponsfamily.com could not be reached from the build environment. Check the Pons docs before relying on any audit claim. |
| Report | None linked |
| Reviewed | 2026-09-29 |
§Trust assumptions
| Assumption | If it fails |
|---|---|
| The Pons owner does not redirect a virus's creator fees | After a 3-day timelock and within a 3-day window, future fees of that virus stop reaching its feeder. The feeder is severed; already-credited fees still reach it. |
| The Pons fee sweep operator converts post-graduation virus-denominated fees | Those fees stay on the hook, and the feeder shows AWAITING_PONS_SWEEP indefinitely. |
| The Pons owner does not use rescue powers against a virus | Fees can be paid out directly (VIRUS feeds them anyway), and after 7 days in Swept the reserves can be sent elsewhere, leaving the virus with no market. |
| Pons keeps approving hosts and keeps the launch gate open to VIRUS | No new viruses can be launched. If Pons never approves launch tokens as pair tokens, VIRUS has no viable hosts at all. |
| Pons fee policy stays compatible with the 80bps target | New launches revert with CreatorTaxUnreachable and the site stays in LAB MODE. Existing viruses are unaffected. |
| The Pons fee escrow pays the claimant | Credited fees could stay in the escrow. The escrow implementation is not published (UNVERIFIED T4). |
The full list is in Admin powers.
§What is still unverified
§Deployed Pons may differ from published Pons
VIRUS's Pons interfaces were written from the published Pons source (ponsdotdev/pons-labs, commit 4bea1cf). Reading that source revealed internal inconsistencies, which show it cannot be the exact deployed code:
| # | Finding | Consequence |
|---|---|---|
| X1 | The factory calls exemptFromSnipeTax on the curve, but the published curve has no such function and no snipe-tax logic. |
How the deployed snipe tax keys buyers (msg.sender or recipient) is unknown. The VIRUS first buy is exempt either way; quotes inside the window are flagged. |
| X2 | The factory passes a salt that the published deployer ignores, and refers to a prediction function that does not exist. |
Virus token and curve addresses are not assumed predictable. The feeder is bound after launch in the same transaction. |
| X3 | The Pons launch-and-buy router is referenced but not published, and launchTokenFor is restricted to it. |
VIRUS uses its own atomic coordinator. |
| X4 | The fee escrow implementation is not published. | Claim semantics are unconfirmed. |
| X5 | The published snipe window default is 15 seconds; a secondary source says the tax decays to zero over 5 seconds. | The window is read live, never assumed. |
§Fork tests not yet run
A suite of fork tests (contracts/test/fork/PonsFork.t.sol) checks VIRUS's Pons and Uniswap assumptions against the live chain: factory and Uniswap wiring, live economics, the digest formula, approved-pair inspection, that the deployed launchToken decodes VIRUS's parameters, a full inoculation where Pons allows it (never bypassing the whitelist), that a developer cannot redirect fees, escrow claim semantics, the post-graduation sweep gate, and the Universal Router swap encoding. Several need optional inputs, such as a host address or a graduated launch, and skip without them. None of them determines how the deployed curve keys the snipe tax (X1), which remains an open question. As of the reference audit (2026-09-29), the build environment could not reach Robinhood Chain and the fork tests had not been run. No VIRUS contract may be deployed to mainnet until they pass.
§Other unverified items
- Robinhood Chain's chain ID, public RPC and explorer URL are consistent across sources but classified
UNVERIFIED. - The Pons factory address and every Uniswap address listed in Parameters are
UNVERIFIED: bytecode was not checked. - Graduated-pool trading through the Universal Router stays disabled in the production app until
test_fork_UniversalRouterSwappasses. - Several Parasite behaviors the product brief attributes to Parasite (first-buy fee, supply, 40 SOL threshold, warm-up) are unverified. See Parasite → VIRUS differences.
§Market risks
- Thin liquidity. A new virus's curve starts with only phantom reserves in host units. Small trades can move the price a lot. The graduated pool can also be thin.
- Nested routes. Buying a deep virus with ETH crosses up to four markets, each with its own fee and price impact, signed as separate transactions. Prices can move between hops, and if you stop partway you hold an intermediate token. Exiting repeats the costs in reverse.
- Compounded exposure. A virus is priced in its host. Its ETH value moves with its own market and with its host's, and with every layer above that.
- Snipe tax. Trading in the window right after a launch may pay a Pons snipe tax. Its published-source default starting rate is 9,900bps (99%); its exact schedule and keying on the deployed curve are unverified.
- Migration stalls. A sold-out curve cannot trade until someone completes the migration, and a launch that Pons rescues has no market at all.
- Price data. Quotes are computed from live reserves at the time you request them. They are not guarantees; the minimum output protects you from receiving less than your slippage allows, not from a bad price.
§Host risk
A virus depends on its host for its whole life:
- Host collapse. If the host loses value, so does everything priced in it: the virus's curve reserves, its graduated pool, the developer's booked fees and the treasury's share. The graduation threshold is fixed in host units and does not adjust.
- Host illiquidity. If the host's own market is thin, stalled in migration, or rescued, the route to the virus is impaired even if the virus's own market is fine.
- Host disabled by VIRUS. Affects new launches only. Existing viruses keep trading and feeding.
- Fees are host. All fees a virus's feeder distributes, including the developer's share, are paid in the host token.
§Fee delays
- Nothing happens until someone calls
feed(). Fees sit on the Pons curve, hook or escrow until then. Anyone can call it, but no one is paid to. AWAITING_PONS_SWEEP. After graduation, buys of a virus pay fees in the virus token. Only the Pons operator can convert them, and while any are pending, Pons also blocks the feeder from sweeping host-denominated fees. VIRUS cannot say when the operator will act, and the host received depends on the conversion.CurveSweepFailed. If a curve sweep reverts, fees remain on the curve until a later feed succeeds.
§Severed feeders
If the Pons owner executes a creator fee recipient change on a virus, its future fees go to the new recipient, outside VIRUS. The virus keeps trading, but its trades no longer burn the host through VIRUS, and the developer and treasury stop accruing from it. The virus page shows a pending change during its 3-day timelock and a severed status afterwards.
§Indexer lag
The optional indexer can lag the chain or rewind after a reorganization. VIRUS never uses it for transaction-critical values; balances, devOwed, reserves, approvals and quotes are read from chain at the moment of use. History and aggregate stats shown from the indexer can briefly trail the chain.
§$VIRUS
$VIRUS is a plain Pons launch. It has no staking, no dividends, no revenue share and no auto-buyback (VIRUS_ADAPTATION A18). Holding it gives no claim on treasury funds, fees, or anything else. The treasury is controlled by its owner, and no on-chain rule restricts how the owner uses treasury funds.
If the site shows CA SOON, no canonical $VIRUS contract address has been configured. Treat any address offered to you elsewhere with suspicion.