YUPPIES

Yuppies combines YUP, a DN-404 fungible token, with materialized mirror NFTs. Each live NFT has one deterministic ERC-6551 account. The NFT's current owner controls that account, chooses one deterministic policy, supplies capital, and may withdraw the account's assets.

A policy never wakes itself. A qualifying YUP swap or a permissionless processTurns transaction selects an eligible account. The account asks its policy for one bounded next action. If that action is a trade, an adapter settles it and returns the output to the same Yuppie account.

Owner setup from zero to active

1. 1
   Own a materialized Yuppie

   Confirm mirror ownership, not only a fractional or skip-NFT YUP balance. Smart wallets may need to disable skipNFT before materialization.

2. 2
   Resolve the account

   Read accountOf(tokenId). If materializationPending(tokenId) is true, anyone may call materializeAccount(tokenId).

3. 3
   Choose a mandate

   Select one standalone template or one Trading Universe combining fixed markets, New Issues sources, or both.

4. 4
   Prepare markets

   For V1 fixed markets, permissionlessly register a compatible unhooked v4 pool. For New Issues, select compatible launch-source contracts and submit eligible candidates through their registry path.

5. 5
   Create the policy

   Call the appropriate factory with the account, market, oracle, limits, and strategy parameters. Configuration is immutable; review every field before signing.

6. 6
   Fund the account

   Use depositERC20 after approving the account, or send native currency directly. Capital belongs to the account, not to a shared vault.

7. 7
   Authorize and activate

   From the current NFT owner, call authorizePolicy(policy), then confirm isActivationReady() and canExecute(). Use refreshActiveSet() after direct balance changes.

8. 8
   Trigger turns

   Wait for organic YUP heartbeats or call processTurns(maxTurns). New Issues entries deliberately require several separated turns.

9. 9
   Monitor or stop

   Watch policy, adapter, and account events. To stop new actions, call deauthorizePolicy(); then withdraw assets you intend to keep.

Production chain ID is 4663. Contract names, symbols, or links may be copied by impersonators; verify the complete address before every interaction. The addresses below were read from the live deployment on 2026-08-19.

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.

skipNFT and missing mirror NFTs

DN-404 supports skipNFT for exchanges, contracts, and wallets that want fungible YUP without mirror NFTs. Read getSkipNFT(holder) on the YUP contract. A wallet that wants materialized NFTs may call the inherited setSkipNFT(false) from that same address before acquiring whole units. Some smart wallets default to skip-NFT behavior. Disabling the flag does not identify a particular desired token ID; DN-404 assignment follows the balance lifecycle.

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.

Resolve and prepare an account

1. 1
   Find the address

   Call YUP.accountOf(tokenId). The result is deterministic even before code is deployed there.

2. 2
   Check lifecycle state

   Call materializationPending(tokenId). For a currently owned live ID, anyone may complete owed work with materializeAccount(tokenId).

3. 3
   Verify control

   Read account.owner() and confirm it matches the current mirror owner before funding or authorizing a policy.

Deposit capital

Any address may fund a Yuppie. For ERC-20 capital, first approve the Yuppie account for the exact amount, then call account.depositERC20(asset, amount). The account pulls the tokens from the caller and reconciles scheduler eligibility. Native currency may be sent directly to the account; call refreshActiveSet() afterward when that balance affects activation.

account = YUP.accountOf(tokenId)
ERC20.approve(account, amount)
account.depositERC20(asset, amount)
account.refreshActiveSet()

Withdraw assets

Only the current NFT owner may use the typed withdrawal functions. The owner chooses the recipient. Deauthorize the policy first when winding down an account, then withdraw each known balance.

account.deauthorizePolicy()
account.withdrawETH(recipient, amount)
account.withdrawERC20(asset, recipient, amount)
account.withdrawERC721(collection, recipient, tokenId)
account.withdrawERC1155(collection, recipient, tokenId, amount, data)

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.

Before selling or transferring the NFT

1. 1
   Stop trading

   Call deauthorizePolicy() and confirm activePolicy() is zero.

2. 2
   Inventory the account

   Inspect native currency, every known ERC-20, NFT, ERC-1155, child Yuppie, allowance, and abandoned-approval disclosure.

3. 3
   Withdraw what you intend to keep

   Account contents do not move to the seller when the NFT moves.

4. 4
   Transfer only after verification

   The buyer becomes the account controller through mirror ownership. Treat account contents as part of the sale unless removed beforehand.

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.

Choose the policy surface

Create and activate

1. 1
   Build the immutable configuration

   Use canonical token units, bounded input sizes, reserves, exposure, liquidity, slippage, cooldown, and strategy parameters.

2. 2
   Call the factory

   The factory deploys the policy and registers it for exactly one account. Creating a policy does not authorize it.

3. 3
   Authorize from the NFT owner

   Call account.authorizePolicy(policy). Authorizing a replacement clears the prior policy and tracked approvals.

4. 4
   Meet activation capital

   Fund the configured activation asset and confirm isActivationReady(), canExecute(), and scheduler membership.

Policy state is not migrated when replacing a policy. Account assets remain in the account, but staged entries, armed actions, grid levels, and New Issues positions recorded inside the old policy do not move into the replacement.

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

The V1 general-market adapter is an execution surface for owner-selected Uniswap v4 pools. Pool registration is permissionless; the protocol does not manually list every token. A Yuppie still trades only the immutable markets selected in its authorized policy.

What V1 accepts

Register and configure a market

1. 1
   Inspect the pool

   Confirm PoolManager, both token contracts, ordering, fee, tick spacing, hook address, initialized price, active liquidity, and trading behavior.

2. 2
   Register the PoolKey

   Call registerPool(PoolKey) on the V1 adapter. The returned marketId is the pool ID the policy must pin.

3. 3
   Select a reference price

   Fixed-market policies require a compatible price oracle for the same ordered asset pair. The oracle's live market must differ from the execution market.

4. 4
   Build the policy

   Set asset units, maximum inputs, minimum reserves, maximum exposures, minimum liquidity, slippage, spot-deviation limit, cooldown, and strategy parameters.

5. 5
   Fund and authorize

   Deposit one or both assets into the Yuppie account, authorize the policy, and verify activation before triggering turns.

marketId = GENERAL_ADAPTER.registerPool({
  currency0,
  currency1,
  fee,
  tickSpacing,
  hooks: address(0)
})

Reference price versus execution price

The adapter exposes current pool liquidity, pool fee, and a fee-adjusted spot quote. The policy compares that live execution market with its configured reference oracle. Spot may suppress a trade; it does not replace the reference price. The deployed Hook TWAP oracle currently prices YUP/WETH from the main YUP pool. Arbitrary pairs require their own compatible price source.

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.

HOOK.processTurns(8)
HOOK.processUrgentTurns(8)

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.

The transaction sender pays gas and receives no protocol reimbursement. Calling either function does not guarantee a swap: the selected policy may observe, prepare, arm, hold, decline, or discover that its capital or market conditions are no longer valid. The caller advances the deterministic scheduler; the caller does not control its result.

Confirm scheduler membership

Read account.canExecute(), account.activePolicy(), and the hook's active, deferred, and urgent queue views. If an eligible funded account is missing after a direct transfer, call account.refreshActiveSet(). Do not repeatedly sponsor turns for an account that is not activation-ready.

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 V1 general-market adapter excludes the heartbeat pool and every other hooked action pool.

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.

What to monitor

Trading Universe contracts compose bounded fixed-market configuration and isolated New Issues modules. Standalone templates require catalog-approved venues. The Trading Universe factory validates owner-selected inputs at construction and registers its modules as execution delegates for the bound account.

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 does not require an owner to preselect individual tokens. The owner selects one or more compatible launch-source contracts and immutable risk rules. Eligible token addresses are then submitted into a bounded candidate ring. The policy scans that ring over later turns and independently decides whether to observe, enter, manage, or discard each candidate.

Factory source, candidate registry, and adapter are different roles

Configure a New Issues mandate

1. 1
   Select compatible sources

   A raw factory address works only if it exposes the required ILaunchpadFactoryRecords interface. Otherwise select a compatible source or registry that represents the factory.

2. 2
   Set risk limits

   Choose quote asset, per-entry size, minimum quote reserve, maximum exposure, maximum positions, age window, liquidity floor, slippage, observation window, cooldown, stop loss, take profit, trailing stop, creator-balance response, and lifetime entries.

3. 3
   Create the module or policy

   The Trading Universe factory creates an isolated source registry and candidate ring for each mandate. Up to four modules are allowed, with up to eight sources per module.

4. 4
   Register an eligible launch

   For the standard live source, first register its signed and venue-verified launch record. Then permissionlessly call LaunchpadSwapAdapter.registerMarket(marketId) and submit the token to the applicable candidate registry.

5. 5
   Fund and trigger

   Fund the configured quote asset, authorize the parent policy, and advance turns. Candidate submission alone never trades.

// Per-Trading-Universe candidate path
launchRegistry.registerCandidate(sourceIndex, token)

// Standard execution-market cache, after verified provenance
LAUNCHPAD_ADAPTER.registerMarket(marketId)

Candidate checks include provenance, launch age, market status, liquidity, price movement, creator identity, creator balance, denylist state, account capital, and position limits. The policy holds at most two positions per New Issues module.

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.

The live heartbeat rate is 200 basis points on buys and 300 basis points on sells. The immutable registrar may lower either rate independently to zero and later restore it, but may never raise it above the 200 / 300 basis-point launch caps. Read feeRates() for the current value before quoting. The fee currency is the non-YUP counter asset.

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.

These fees apply to registered hooked YUP heartbeat pools. They do not apply to V1 general-market action pools, which are unhooked. A nested policy swap through a future hooked action market would follow that market's configured hook rules.

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.

Owner-selected does not mean risk-free

Permissionless pool or candidate registration is not project endorsement. A malicious token, hook, oracle, source, router, or shallow pool may revert, misprice, tax, blacklist, or otherwise produce economic loss. V1 limits each account action with immutable policy bounds, exact temporary allowance, minimum output, payer binding, one-swap execution, and failure isolation. Those controls reduce authority; they do not prove an asset is valuable or safe.

V1 versus future adapters

The current general-market adapter is immutable and accepts only unhooked v4 ERC-20 pools. It can coexist with later adapters. The catalog owner may approve a new adapter for standalone templates, and owners may create replacement policies that reference it. Existing YUP, mirror NFTs, accounts, balances, and unrelated policies do not need migration.

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
materializationPending(uint256 tokenId) → bool
getSkipNFT(address holder) → bool
setSkipNFT(bool state)
materializedSupply() → uint256
unmaterializedSupply() → uint256
protectYuppie(uint256 protectedId, uint256 sacrificialId)

Account

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

V1 general-market adapter

registerPool(PoolKey poolKey) → bytes32 marketId
poolKey(bytes32 marketId) → PoolKey
liquidity(bytes32 marketId, address asset0, address asset1) → uint256
swapFeePips(bytes32 marketId) → uint256
spotQuoteExactInput(bytes32 marketId, address assetIn, address assetOut, uint256 amountIn) → uint256

New Issues registration

VerifiedLaunchpadRegistry.registerLaunch(attestation, signature) → bytes32 marketId
LaunchpadSwapAdapter.registerMarket(bytes32 marketId)
LaunchpadCandidateRegistry.registerCandidate(address token) → uint256 sequence
TradingUniverseLaunchRegistry.registerCandidate(uint256 sourceIndex, address token) → uint256 sequence

Policy factories

createGrid(GridTradingPolicy.Config config) → address policy
createInventoryMarketMaking(InventoryMarketMakingPolicy.Config config) → address policy
create(PortfolioRebalancePolicy.Config config) → address policy
create(NewIssuesPolicyV2.Config config) → address policy
create(TradingUniversePolicy.Config config, NewIssuesMandateConfig[] mandates) → address policy

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)
feeRates() → (uint16 buyFeeBps, uint16 sellFeeBps)
feeClaimBalance(Currency currency) → uint256
withdrawFees(Currency currency) → uint256

Function signatures are orientation aids, not transaction recipes. Struct layouts, access control, approvals, canonical units, and constructor validation must be read from the exact deployed ABI before encoding a write.

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

The pool or venue an adapter uses for execution. The V1 general-market adapter accepts unhooked v4 ERC-20 pools.

Launch source

An owner-selected contract implementing launchpadTokenInfo(token) for New Issues provenance and live-state reads.

Candidate

A token address submitted to a bounded New Issues ring after its selected source returns a valid launch record.

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.