YUPPIES

Yuppies combines a capped fungible token with a linked non-fungible mirror. A whole fungible unit materializes as a numbered mirror NFT when DN-404 balance rules are satisfied. Each materialized token ID has a deterministic token-bound account that holds assets and authorizes one catalogued policy.

The account holds trading capital. The policy evaluates market state and returns a bounded action. An approved adapter performs any authorized market operation. The hook schedules accounts and accounts for fees; it does not own account capital or choose policy actions.

The fungible component uses 18 decimals and a maximum supply corresponding to 10,000 whole units. The mirror exposes numbered NFT ownership. Whole-unit balance changes materialize or dematerialize mirror representations through DN-404 lifecycle rules.

1. 1
   Materialization

   A whole-unit crossing assigns a mirror token ID and prepares its canonical account.

2. 2
   Transfer

   Mirror transfer changes current account control without moving account contents.

3. 3
   Dematerialization

   A fungible tail burn removes the mirror representation. The account and its contents remain at the deterministic address.

4. 4
   ID reuse

   The token ID enters the burned-ID pool and remains eligible for rematerialization under a new ownership epoch.

protectYuppie(protectedId, sacrificialId) allows an owner with multiple materialized IDs to choose which owned ID is moved to the burn tail. The operation requires a distinct sacrificial ID owned by the same caller.

Recursive ownership

A canonical Yuppie account holds YUP. Whole-unit YUP crossings inside that account materialize child Yuppies owned by the parent account. Parent and child accounts retain separate balances, policies, epochs, and scheduler membership. A selected parent turn does not recursively execute a child turn.

Each token ID maps to one deterministic ERC-6551 account using the configured registry, implementation, chain ID, mirror address, and token ID. The account's current owner is derived from current mirror ownership.

The account is not a general arbitrary-call executor. Policy execution is restricted to the configured hook, the currently authorized catalogued policy, registered approval pairs, and approved adapter paths. ERC-6551 signer validity and ERC-1271 signature validity follow the current owner.

Descendant-owner commands use a closed command set and an ownership path capped at 64 addresses. The path verifies direct child relationships at each step. This owner-control recursion is separate from heartbeat execution.

An ownership epoch is the interval during which one current mirror owner controls an account. A transfer, dematerialization, or other lifecycle transition closes the prior epoch before opening control for a new owner.

Approval pairs created through the account are recorded. If a token rejects an approval reset, transfer fails closed until the current owner acknowledges an abandoned approval entry. That entry remains queryable. Permit authority created outside this registry is outside the account's approval-pair list and requires independent allowance inspection.

An account authorizes at most one policy at a time. Policy configuration is immutable for each deployed policy. A configuration change replaces the active policy with a distinct deployed instance.

Factory creation alone grants no account authority. Adapters verify that their caller is an approved policy or execution delegate for the named payer account. Catalog revocation invalidates a live policy independently of account ownership.

Typical immutable controls

• Input or position size
• Market and asset identifiers
• Minimum liquidity
• Maximum price deviation
• Cooldown duration
• Exposure and reserve limits
• Stop-loss thresholds
• Take-profit thresholds
• Trailing-stop thresholds
• Maximum concurrent positions

Organic heartbeat

A nonzero-fill swap through a registered hooked YUP pool is a heartbeat. Input-side fee work occurs in beforeSwap. Account selection occurs in afterSwap, after the realized balance delta is known. Each organic heartbeat evaluates at most one account.

The active queue is account-anchored and round-robin. The hook checks lifecycle, current policy binding, catalog status, and policy-reported capital eligibility. If the transaction lacks the gas required for both the bounded account frame and post-swap settlement reserve, optional account work is skipped and the cursor remains anchored.

Permissionless sponsored turns

processTurns(maxTurns) and processUrgentTurns(maxTurns) allow an external transaction sender to pay gas for bounded queue progress. The caller supplies only an inspection count from 1 through 32 and cannot select an account, asset, action, policy, or parameter.

A sponsored call inspects at most one initial queue lap, processes an account at most once per block across sponsored lanes, and stops when its request, queue, or gas bound is reached. Processing occurs inside PoolManager.unlock so approved unhooked v4 action markets remain available.

A selected account asks its policy for one deterministic next action. For an approval-bearing execution, the account grants an exact temporary allowance to the approved spender, invokes the policy, and attempts to reset the allowance. A selected turn performs at most one policy action and at most one swap.

The organic fast path defers a valid nonzero approval request before granting an allowance. The account then joins the deferred queue for a full sponsored frame. These values are execution caps and reserves, not the amount consumed by every turn.

Trade authorization

Fixed-market policies derive minimum output from an independent reference price, configured asset units, fee, and slippage bounds. StateView spot data serves as a suppression check when the action market deviates from reference or does not satisfy the bound. The adapter enforces minimum output during settlement. The heartbeat pool is excluded from policy-adapter action markets.

Outcomes

A declined evaluation does not attempt a trade and does not increment the policy failure count. Three consecutive attempted-policy failures deauthorize the policy and remove the account from active scheduling.

Trading Universe contracts compose bounded market configuration and a New Issues module. Each template's execution path requires factory registration, catalog configuration, adapter approval, and oracle approval where applicable.

Grid, inventory, and portfolio templates accept a cooldown from zero through 30 days. Only a successful fill starts the cooldown. A zero value disables cooldown throttling.

New Issues uses factory-proven candidate records and venue-specific validation for supported launch sources. Candidate checks include provenance, launch age, market status, liquidity, price movement, creator identity, creator balance, denylist state, account capital, and position limits.

Setup turns request no allowance. Entry stages are separated across turns and blocks. This prevents one transaction or one-block observation from completing the full entry path. It does not create an independent fair-value oracle; market conditions sustained across the full observation interval satisfy the configured checks.

Position management evaluates take profit, stop loss, trailing stop, maximum age, and a persistent reduction in creator token balance. Exits also use confirmation, arming, and execution on a subsequent selected turn. Only an already armed exit qualifies for the urgent queue; an armed entry does not.

Registered heartbeat pools use immutable rates of 200 basis points on buys and 300 basis points on sells. The fee currency is the non-YUP counter asset. The rate is calculated as a share of gross counter value in each swap orientation.

For orientations charged before execution, the hook compares the realized fill with the charged fee basis and rejects a partial fill rather than repricing the fee after the swap. Native and ERC-20 counter assets use PoolManager claim accounting. Claims accrue to the hook and are withdrawn separately by the immutable fee recipient.

The mirror reports a 500-basis-point ERC-2981 royalty in the marketplace-reported sale currency. ERC-2981 communicates royalty information; collection and enforcement are external to the contracts. Hook fees and mirror royalties are separate mechanisms.

The collection contains 10,000 canonical token IDs. Artwork is composed on a 24 by 24 indexed grid using a shared 84-color palette and enlarged with nearest-neighbor scaling to 3000 by 3000 pixels. Build outputs include PNG, SVG, and JSON representations.

Renderer output depends on token ID and the configured art store. Account balance, policy state, execution history, and ownership epoch do not alter the artwork. A digest-confirmed art-store freeze seals the renderer pointer for the configured store.

A token-bound account cannot originate an EVM transaction. The sender of an organic swap or sponsored processing transaction pays gas. The contracts provide no gas reimbursement. Oracle availability, stale data, liquidity, price deviation, catalog state, capital, ownership, and scheduler membership are independent conditions.

Third-party dependencies include Robinhood Chain execution, Uniswap v4 components, the canonical ERC-6551 registry, token contracts, price feeds, launch venues, routers, and marketplaces. The source contains validation and bounded-failure paths, but those dependencies remain separate systems.

Signatures below identify primary read and control surfaces. They are not a complete ABI.

Token and lifecycle

accountOf(uint256 tokenId) → address
prepareAccount(uint256 tokenId) → address
materializeAccount(uint256 tokenId) → address
materializedSupply() → uint256
unmaterializedSupply() → uint256
protectYuppie(uint256 protectedId, uint256 sacrificialId)

Account

owner() → address
token() → (uint256 chainId, address tokenContract, uint256 tokenId)
authorizePolicy(address policy)
deauthorizePolicy()
canExecute() → bool
hasUrgentExit() → bool
hasDeferredExecution() → bool
refreshActiveSet()
depositERC20(address asset, uint256 amount)
withdrawETH(address recipient, uint256 amount)
withdrawERC20(address asset, address recipient, uint256 amount)

Scheduler and fees

activeCount() → uint256
urgentCount() → uint256
deferredCount() → uint256
nextActiveAccount() → address
nextUrgentAccount() → address
nextDeferredAccount() → address
processTurns(uint256 maxTurns) → (uint256 inspected, uint256 evaluated)
processUrgentTurns(uint256 maxTurns) → (uint256 inspected, uint256 evaluated)
feeClaimBalance(Currency currency) → uint256
withdrawFees(Currency currency) → uint256

YUP

The fungible DN-404 component.

Yuppie

A collection character, mirror NFT, or associated token ID depending on context.

Materialization

Assignment of a mirror NFT when a whole-unit balance condition is crossed.

Token-bound account

The deterministic ERC-6551 account associated with one token ID.

Epoch

The period during which one current mirror owner controls an account.

Policy

An immutable, catalogued contract authorized to choose bounded account actions.

Heartbeat

A nonzero-fill swap through a registered YUP pool that schedules at most one account.

Sponsored turn

A permissionless transaction that pays gas to process bounded scheduler work.

Deferred queue

Accounts awaiting a full execution frame for an approval-bearing action.

Urgent queue

Accounts whose current policy reports an already armed exit.

Action market

An approved unhooked market used by an execution adapter.

Decline

A policy evaluation that requests no trade because configured conditions are not met.

Failure

An attempted policy execution that does not complete and counts toward shutdown under the scheduler's failure classification.