Hosts

§What a host is

A host is the token a virus trades against. In Pons terms, it is the virus's pairToken: the asset the virus's bonding curve accepts on buys, pays out on sells, and is paired with in the graduated Uniswap V4 pool. Every fee a virus generates is denominated in its host, and every burn VIRUS performs for that virus reduces the host's supply.

A host is fixed at launch. Pons records pairToken in the launch record, the feeder stores host in its immutable clone arguments, and VirusRegistry writes the virus's host once. Nothing can change it afterwards.

§Only Pons V2 launch tokens can be hosts

The purpose of a virus is to burn its host. VIRUS therefore needs a host whose burn(uint256) really destroys tokens and reduces totalSupply.

Pons V2 launch tokens (PonsV2LauncherToken) are ERC20 + ERC20Burnable from OpenZeppelin. Their burn calls _burn, which reduces totalSupply (VERIFIED_PONS, published source). That is the property VIRUS relies on, and it is asserted at run time: every feed() compares the host's totalSupply before and after the burn and reverts with BurnNotReflected unless it fell by exactly the burned amount.

Pons can also approve assets that are not launch tokens as pair tokens, such as tokenized stocks, stablecoins or cbBTC. VIRUS never accepts these as hosts, even when Pons has approved them (VIRUS_ADAPTATION A17). VIRUS has no guarantee that such a token exposes a burn that reduces supply, and a host that could not be burned would break the core promise.

§Eligibility checks A–H

The coordinator's hostCheck(address host) runs the on-chain checks. The app's host resolver (packages/chain/src/hosts.ts) runs the same checks, labels them A–H, and adds two that exist only in the app (C and D). When the VIRUS coordinator is deployed, the app calls hostCheck directly. Without it (LAB MODE), the app performs the same reads against Pons; check G then needs a registry to read.

On chain, a host is viable only when every check passes:

viable = ponsLaunchToken && provenance && pairApproved
      && economicsUsable && notDisabled && depthOk;

hostCheck returns early with every flag false if the address has no code. inoculate reverts with HostNotViable(host) when viable is false.

The full return value is:

struct HostCheck {
    bool isContract;
    bool ponsLaunchToken;
    bool provenance;
    bool pairApproved;
    bool economicsUsable;
    bool notDisabled;
    bool depthOk;
    bool viable;
    uint8 hostDepth;
    uint8 childDepth;
    uint8 decimals;
    address ponsCurve;
    address ponsPairToken;
    uint256 phantomQuote;
    uint256 graduationThreshold;
}

§Host statuses

The app turns the checks into one status per address. Statuses are evaluated in this order, and the first match wins:

A VIABLE host can still be blocked by the launch gate: Pons canLaunch for you and for the coordinator, VIRUS launchesPaused, and an enabled Pons launch config. See Launching.

The app also shows the reason for each failing check, for example "NOT A PONS V2 LAUNCH TOKEN — VIRUS CANNOT BURN IT", "PAIRING NOT YET APPROVED BY PONS", "PONS PAIR ECONOMICS UNUSABLE FOR A HOST", "DISABLED FOR NEW INFECTIONS", or "CHILD WOULD BE DEPTH 4 (MAX 3)".

§Pons must approve every host

A Pons launch can only use a pair token the Pons owner has approved. Approval is two owner-only Pons calls (BLOCKED_BY_PONS B1, VERIFIED_PONS F3):

• setPairTokenApproved(token, true), which sets approvedPairTokens(token). Pons requires the token to have code, stored economics, and a matching decimals().
• setPairTokenEconomics(token, ...), which stores pairTokenEconomics(token): the phantom quote reserve, the graduation threshold and the decimals, all in the pair token's own units.

VIRUS cannot approve anything and never submits an approval request on anyone's behalf. A valid Pons launch token that Pons has not approved is shown as SPECIMEN FOUND — PAIRING NOT YET APPROVED BY PONS, with INOCULATE disabled.

This is the largest external dependency of the protocol. If Pons approves no launch tokens as pair tokens, VIRUS has zero viable hosts. Whether Pons will do so is an open question recorded in the reference audit.

Pair economics matter beyond eligibility. For a launch paired with a custom token, Pons uses the pair token's phantomQuote and graduationThreshold from pairTokenEconomics, not the ETH-denominated figures in the launch config (VERIFIED_PONS F4). A virus's graduation threshold is therefore measured in host tokens and is set by Pons per host.

§Depth

Depth measures how many VIRUS layers sit between a token and its root market.

depth(token) = 0                      if its Pons pairToken is ETH or a non-Pons asset
depth(token) = depth(pairToken) + 1   otherwise
child depth  = host depth + 1         must be ≤ 3

The coordinator computes depth by walking getLaunchedToken(t).pairToken upward, at most MAX_DEPTH + 1 = 4 steps. If the chain is longer than that, the walk reports itself unbounded and depthOk is false. registerVirus independently rejects a depth of 0 (InvalidDepth) or above 3 (DepthExceeded).

A depth-0 host is not necessarily paired with ETH. A Pons launch paired with a non-Pons approved asset (a stablecoin, for example) also has depth 0, and its infection route begins with a leg outside Pons. See Infection routes.

§Viruses as hosts

Parasite allows parasites to host parasites, up to three deep (VERIFIED_PARASITE P7). VIRUS keeps the same maximum, enforced on chain. Recursion happens only where Pons has approved the virus itself as a pair token, because a virus is just another Pons launch token as far as Pons is concerned. Each virus that becomes a host goes through the same checks A–H.

§No warm-up phase

The VIRUS product brief describes a price-observation warm-up before a Parasite host becomes usable. That description is UNVERIFIED (brief only, not confirmed from Parasite's own pages). VIRUS deliberately does not reproduce it (VIRUS_ADAPTATION A6):

• Pons bonding curves and hooked pools price trades from their own reserves. Nothing in a VIRUS launch reads an external price, so there is nothing to observe.
• VIRUS does not fake an oracle or a waiting period that does not protect anything.
• The gate that does exist is Pons pair approval plus the VIRUS checks above. A host becomes usable the moment both hold.

§Disabled hosts

The VIRUS admin can call setHostDisabled(host, true) on VirusRegistry. A disabled host:

• shows as DISABLED and fails check G, so inoculate reverts, and registerVirus would also revert with HostIsDisabled(host);
• keeps every existing virus exactly as it was. Their feeders continue to feed, burn and pay the developer. Disabling affects new launches only.

The flag is reversible with setHostDisabled(host, false). Both calls emit HostDisabled(host, disabled).

§The host record

VirusRegistry registers a host automatically when its first virus is registered, and emits HostRegistered(host, depth, ponsCurve, ponsPairToken). The record never changes except through accumulating totals and the disabled flag:

Read it with registry.getHost(host). Candidate hosts are discovered from Pons PairTokenApprovalUpdated and TokenLaunched logs, and from VirusRegistry HostRegistered.