How to play
DEED.

DEED is a finite onchain property game organized around 333 permanent Genesis Property NFTs. Every property belongs to one of four districts and begins as a House. An owner can burn DEED through four sequential upgrades to turn that House into a Residence, Building, Tower, and ultimately a Landmark. Each level has a fixed Reward Weight. Reward Weight determines the property's relative share of reward assets deposited into its district; it is a distribution variable, not a promised return.

The protocol connects six ideas that are normally separated: transferable property ownership, a hard NFT cap, permanent token burns, visible progression, Pons V2 trading activity, and externally sourced reward assets. Genesis minting and upgrades reduce DEED supply. Pons creator revenue is credited through its official Fee Escrow to immutable DEEDFeeRouter, which accounts the exact Treasury and streamed Genesis shares before district-specific Stock Tokens can be acquired and distributed by onchain Reward Weight.

DEED does not create inflationary rewards and does not promise income, APY, or a minimum reward amount. Rewards depend on actual assets deposited into a district, the total Reward Weight present when deposits occur, Pons fee sweeping and claims, market liquidity, and the property's ownership history. The production path uses canonical Robinhood Stock Tokens; local development deployments retain mock fixtures only for deterministic testing.

Most fungible-token experiences reduce ownership to a wallet balance and a price chart. DEED introduces a persistent object around that balance: a scarce digital property with a district, plot, architectural level, cumulative burn record, and reward-distribution weight. The purpose is not to obscure token mechanics behind a game. It is to make those mechanics legible through an asset that can be owned, progressed, transferred, and inspected onchain.

The city serves two functions. As an interface, it maps the 333 token IDs into visible plots and shows how each NFT has evolved. As an economic organization layer, it separates properties into four district ledgers. Each district has its own aggregate Reward Weight, reward asset, accumulator, deposits, and claims. The visual map therefore reflects real contract state rather than replacing it.

A participant may acquire DEED, use part of it to mint a Genesis Property while supply remains, burn additional DEED to progress an owned property, transfer that property on an ERC-721 marketplace, or claim rewards that have actually been deposited. These actions remain distinct. Holding DEED alone is not a claim on reward assets, and owning a property does not guarantee that its district will receive deposits.

DEED is designed as one finite city rather than an open-ended collection. The permanent limit of 333 Genesis Properties makes plot count knowable. Progression is one-way, so a property's form becomes a visible record of economic commitment. High-level properties are scarce not because an administrator assigns rarity, but because reaching them requires sequential ownership actions and large irreversible burns.

Own. Build. Grow. Collect.

• OWN — hold a transferable Genesis Property whose company, district, plot, and state remain onchain.
• BUILD — burn the exact schedule-defined amount of DEED to advance the property by one level.
• GROW — increase the property's Reward Weight from 100 toward 500 without resetting prior progression.
• COLLECT — claim a relative share of reward assets that were actually deposited into the property's district.

The vision combines permanence with liquidity. Progression stays attached to the deed when ownership changes, while reward accounting separates what accrued to the seller from what may accrue to the buyer later. The city can therefore develop over time without requiring properties to become non-transferable. The 333 original positions remain identifiable even as wallets, market conditions, visual rendering, and external integrations change.

The core lifecycle links user-held DEED to property creation and progression. The fee lifecycle begins when Pons credits DEEDFeeRouter in Fee Escrow. A permissionless claim atomically accounts floor(amount × 3333 / 10000) for immutable Treasury and routes the exact remainder—the nominal 6667-BPS share—through RewardStreamVault; matured district WETH enters RevenueVault, acquired Stock Tokens enter RewardDistributor, and holders claim only deposited assets.

1. 01Pons Fee Escrow pending
2. 02Permissionless DEEDFeeRouter claim
3. 033333 BPS Treasury liability
4. 046667 BPS Genesis WETH
5. 05Stream scheduled
6. 06WETH pending acquisition
7. 07Stock Token deposited
8. 08Holder claimed

The burn and reward lifecycles are not guaranteed to progress together. A user can burn DEED even if no reward asset has been deposited, and a stale oracle or unavailable route can leave matured WETH pending acquisition. Reward Weight acts only after RevenueVault acquires and RewardDistributor receives Stock Tokens. This avoids issuing new DEED as a reward and keeps holder liabilities bounded by assets actually held by the distributor.

Production DEED is the standard 18-decimal fixed-supply ERC-20Burnable token created by the official Pons V2 launch flow on Robinhood Chain. The verified launch configuration creates exactly 1,000,000,000 DEED directly into its bonding curve. The token exposes no post-launch mint function. Supply can decrease through standard ERC-20 burns, Genesis mint burns, and property upgrade burns, but it cannot increase.

A fixed supply makes every implemented sink measurable against a stable starting reference. The Genesis collection can burn at most 33.3 million DEED during primary minting. A property that reaches Landmark records 10.1 million DEED of lifetime protocol burns when the Genesis mint burn is included. These quantities do not predict price; they describe irreversible state transitions and the remaining token supply.

Burns and fees are different

DEED paid to GenesisMinter or PropertyManager is destroyed with burnFrom and reduces totalSupply. Pons trading fees and the 3% DEED creator tax are charged in the ETH quote leg and are not token burns. Creator revenue is credited through the official Pons Fee Escrow to immutable DEEDFeeRouter. Its permissionless claim wraps and streams the exact Genesis remainder while accounting Treasury liability; reporting must not combine that quote-denominated revenue with burned DEED.

GenesisProperty is an ERC-721 collection permanently capped at 333 token IDs. Token IDs are minted sequentially and also serve as plot identifiers in the city layer. Each token stores a company enum, a level, a Reward Weight value named rentPower in the current contracts, and the amount of DEED burned through upgrades. Genesis mint burn is a collection constant and is included when lifetime burn is queried.

The collection can configure its sole Genesis minter, property manager, reward transfer hook, and metadata renderer through narrow functions. The minter, manager, and reward hook are one-time assignments. The metadata renderer may be changed by the immutable metadata manager, but presentation changes cannot modify ownership, company, level, Reward Weight, or burn history.

GenesisMinter permits a maximum of three primary Genesis mints per calling wallet. This is a primary-sale allowance, not an ownership cap. A wallet that has used all three primary mints may still acquire additional Genesis Properties through transfers or secondary markets, and a wallet that never used its primary allowance may receive properties from others. Every transferred property retains its original district, plot, progression, Reward Weight, and accumulated burn record.

A Genesis mint costs exactly 100,000 DEED, or 0.01% of the one-billion initial supply. The caller selects a district, approves GenesisMinter to spend the exact cost, and calls mint after the contract can verify the exact canonical DEED launch through Pons. The complete launch proof repeats until the first successful Genesis mint permanently latches it; a reverted burn or NFT mint also reverts that latch. The minter checks its pause state, the wallet's primary mint count, the global 333 cap, and the selected district cap before burning DEED and requesting the ERC-721 mint. Each transaction creates one property; a wallet may call mint successfully up to three times in total across any districts with remaining supply.

1. 01Approve 100,000 DEED
2. 02Validate sale and caps
3. 03Burn 100,000 DEED
4. 04Mint Level 1 property
5. 05Record district and plot

At complete sellout, primary minting destroys 33,300,000 DEED, equal to 3.33% of initial supply. This arithmetic assumes all 333 properties are minted through the implemented minter. The contract cannot exceed the district or collection caps, and there is no owner-only bypass mint. If a burn or safe mint fails, the transaction reverts atomically.

The primary cost is intentionally small relative to the full progression schedule. Genesis scarcity comes first from the finite property count and three-primary-mints-per-wallet gate, while later economic commitment is expressed through million-DEED upgrades. Three successful primary mints burn exactly 300,000 DEED. Accessibility is therefore concentrated at entry, and differentiation emerges through ownership decisions, transfers, and progression rather than variable initial rarity pricing.

Property progression is an immutable five-level schedule held in the PropertyProgression library and enforced by PropertyManager and GenesisProperty. Only the current NFT owner may upgrade. The caller supplies only a token ID; the contracts derive the next level, required burn, and new Reward Weight. This removes user-supplied economic parameters from the transaction path.

Progression is sequential. A House can only become a Residence, a Residence can only become a Building, and so on. Levels cannot be skipped, reduced, reset, or supplied by an administrator. Landmark is terminal. Before each upgrade, RewardDistributor checkpoints rewards at the old Reward Weight; only then does PropertyManager burn DEED and apply the new state. This prevents the higher weight from being applied retroactively to earlier deposits.

Transfers do not affect progression. A buyer receives the property at its current level and with its existing burn history. The new owner may continue from that state if the property is not already a Landmark. The complete upgrade path burns 10,000,000 DEED after mint; including the Genesis cost, a fully evolved property represents 10,100,000 DEED of permanent protocol burns.

Reward Weight determines a property's relative share of rewards inside its district. The current contracts use the storage and function name rentPower, while the public interface uses Reward Weight to state the concept directly. Weight is attached to the NFT and increases only through the fixed progression schedule: 100, 160, 250, 365, and 500.

The denominator is the aggregate Reward Weight of all properties in the same district at the time a deposit updates that district's accumulator. A property's weight does not compare against properties in other districts. When an upgrade increases one property's weight, the district total increases by the exact difference. Future deposits then reflect the new relative composition.

Reward Weight is not an APY, interest rate, account balance, or guaranteed yield. It does not determine how frequently revenue is processed, how much a trading fee conversion produces, whether a district receives an asset deposit, or the market value of that asset. It only determines relative allocation after a qualifying deposit has been received by RewardDistributor.

The example above is intentionally simple. If a 500-weight Landmark is part of a district with 10,000 total weight, its mathematical share is 5%. If 20 units are distributed, the approximate allocation is one unit. Solidity's integer arithmetic rounds down, so fractional residuals remain in the distributor as dust. The protocol does not mint replacement assets to eliminate that dust.

The Genesis city contains four districts identified by the company enums NVIDIA, Apple, Google, and Meta and displayed through the tickers NVDA, AAPL, GOOGL, and META. District membership is assigned at mint and never changes. Each district has a hard NFT cap, its own total Reward Weight, an immutable reward-token address in the deployed distributor, and an independent reward accumulator.

Separate accounting prevents one district from consuming deposits intended for another. An NVIDIA property cannot claim an Apple deposit because its company enum resolves to the NVIDIA token and NVIDIA accumulator. Likewise, an increase in Google district Reward Weight does not dilute Meta properties. This isolation makes deposit provenance, accounting, and claims auditable per district.

The revenue allocation controller is permanently frozen at 2500 BPS for each of four companies. RewardStreamVault applies that allocation when funding arrives. An inactive district retains its 25% share as a reserve; its first fully successful mint schedules the reserve without an immediate release. Equal allocation is an immutable funding rule, not an assertion that the four Stock Tokens have equal price, risk, or liquidity.

RewardDistributor uses accumulator-based accounting so a deposit does not iterate over all 333 NFTs. Each district stores total deposited, total claimed, and an accumulator scaled by 1e36. Each property stores a checkpoint equal to the district accumulator at its most recent settlement. Each wallet also has a claimable balance per district for amounts already checkpointed during transfers, upgrades, or earlier claims.

Rewards activate atomically with the first fully successful Genesis mint; there is no activation role or transaction. Each later district activates on its own first mint. A late minter is checkpointed at the district's current accumulator before activation and external receiver callbacks, so it receives no historical Stock Tokens. RewardDistributor accepts deposits only from immutable RevenueVault.

RewardStreamVault stores append-only 300-second segments. Funding before global sellout is scheduled across 72 complete 300-second epochs; later funding uses 24 complete 300-second epochs. Existing segments retain their duration. Anyone may process bounded matured epochs without selecting an amount, split, duration, asset, or recipient.

A claim for a currently owned token first checkpoints that token at its current Reward Weight, credits the owner, and then pays the wallet's full credited balance for that district. claimCompany pays amounts that were already credited by prior checkpoints but does not itself scan or checkpoint all NFTs owned by the caller. Interfaces must therefore avoid presenting claimCompany as a universal claim-all action.

The central solvency property is conservative: total claimed for a district cannot exceed total reward assets deposited through the distributor. SafeERC20 transfers and balance-difference measurements support tokens that may not transfer the nominal amount. Fractional dust remains inside the contract, and there is no inflationary DEED fallback if deposits are absent or insufficient.

Genesis Properties remain standard transferable ERC-721 assets. The reward-transfer hook adds settlement immediately before a normal secondary transfer without changing marketplace custody or payment logic. Genesis minting does not call the hook because there is no prior owner. Burns are not exposed as a public property lifecycle in the current collection.

Alice to Bob

1. 01Alice owns Property #50
2. 02District deposits accrue
3. 03Alice initiates transfer
4. 04Alice is checkpointed before ownership changes
5. 05Credited rewards remain claimable by Alice
6. 06Bob becomes owner at the current checkpoint
7. 07Bob participates only in later deposits

The seller's earned reward assets are not automatically sent during the NFT sale. They are recorded in the seller's claimable district balance and can be withdrawn separately. This prevents an NFT transfer from forcing an external token transfer, preserves compatibility with marketplace settlement patterns, and avoids making the buyer responsible for the seller's reward-token reception behavior.

The transfer hook verifies that its caller is GenesisProperty and that the reported owner and Reward Weight match current onchain state. GenesisProperty also verifies that ownership did not change during reward settlement. If any check fails, the entire NFT transfer reverts. The property's company, level, Reward Weight, plot, and burn history remain unchanged and pass to Bob with token ID #50.

Production DEED is not fee-on-transfer. Pons V2 charges a creatorTaxBps value fixed at launch to 300 basis points, or 3%, on both bonding-curve buys and sells and through the shared Pons V2 hook after Uniswap V4 graduation. Pons also charges its own base trading fee. The correct user-facing description is Pons base trading fee plus 3% DEED Protocol creator tax, not a 3% total trading cost.

At the verified fork block, the native one-billion-supply launch config uses a 1% base curve fee and the current hook policy also uses 1%. Pons creator tax is set to exactly 3%. During the three-second opening window, Pons applies its own decaying anti-snipe tax to non-exempt recipients; that temporary amount joins Pons fee accounting and must not be represented as DEED creator-tax revenue alone.

The creator tax percentage is immutable for the launch. The standard ERC-20 token does not identify or tax arbitrary pools, routers, or wallet transfers. Official trading is concentrated through the Pons lifecycle: bonding curve before graduation and the Pons shared-hook V4 pool after graduation.

DEED applies a 3% creator tax on Pons trades. Fees first remain unswept on the bonding curve or graduated V4 hook. A Pons sweep later credits official Fee Escrow for immutable DEEDFeeRouter. Anyone may call claimAndRoute(); the claimed delta is atomically split into floor(amount × 3333 / 10000) Treasury liability and the exact Genesis remainder.

1. 01Pons DEED trade
2. 02Unswept creator fees
3. 03Pons sweep
4. 04Pons Fee Escrow
5. 05Permissionless router claim
6. 06Treasury liability + streamed Genesis WETH

Sweep timing remains asynchronous and may depend on the Pons trusted operator, especially when an internal swap is involved. Pons governance can also change the post-latch recipient under its own rules. Once Fee Escrow credits the router, no DEED operator chooses the split, assets, or destinations.

The claim, 3333/6667 accounting, Genesis-share wrapping, allowance, and stream funding are atomic. Treasury payment is a separately retryable permissionless flush: a beneficiary receive failure leaves exact native liability in the router without blocking Genesis WETH funding. Reward amounts can still be zero or delayed by sweep timing, schedule maturity, oracle freshness, liquidity, pause state, or Stock Token availability.

RewardStreamVault releases only matured company WETH to immutable RevenueVault through permissionless bounded processing. The permanent revenue processor may select company, pending amount, minimum Stock Token output, and deadline, but cannot select another asset, route, oracle, recipient, allocation, or fee split. IStockAcquisitionAdapter remains the guarded WETH-to-district-asset step.

Each district processes independently. A failed or halted route leaves only that company's WETH pending acquisition and cannot spend or redistribute another district's balance. RevenueVault gives the adapter an exact allowance, clears it, verifies WETH spent, measures Stock Tokens received, and deposits that measured amount into immutable RewardDistributor.

The production adapter permits only fixed Uniswap V3 routes from canonical WETH through USDG where needed to canonical NVDA, AAPL, GOOGL, or META Stock Tokens. Every conversion has caller-supplied minimum output and deadline protection plus positive, complete, fresh Chainlink feed checks and a configured maximum oracle deviation. These controls reject unsafe execution; they do not guarantee route availability, price, or reward output.

The implemented protocol has two economic burn categories: 100,000 DEED for each Genesis mint and four progression burns totaling 10,000,000 DEED for a property that advances from House to Landmark. Both use the Pons token's ERC20Burnable burnFrom implementation, reduce totalSupply, and cannot be reversed. Ordinary Pons trading fees and creator tax are quote-denominated revenue, not DEED burns.

A simple division of the initial supply by the 10,000,000-DEED upgrade path yields 100 theoretical complete upgrade paths if every DEED token were available only for upgrades. That is not a guaranteed Landmark cap. Genesis mint burns, partial upgrades, wallet distribution, market inventory, lost access, liquidity needs, and other holdings consume or immobilize supply. Actual reachable progression is therefore path-dependent and likely lower than the isolated arithmetic ceiling.

Future utility sinks may be considered, but they are not part of current locked economics unless separately specified, implemented, tested, and disclosed. No extension should be presented as a current burn mechanism. Supply reporting should distinguish total burned, DEED held by the Pons curve or locked V4 position, and circulating balances; revenue reporting should separately identify unswept fees, escrow credit, claimed ETH, and deposited WETH.

DEED's economic loop links activity and progression without promising that one causes the other at a fixed rate. Pons trading can accrue creator revenue in ETH. DEEDFeeRouter commits the exact claimed amount to immutable Treasury and Genesis paths; scheduled WETH may later acquire district reward assets. Deposited Stock Tokens give Reward Weight practical effect, while owners may burn DEED to increase only future relative weight.

1. 01Pons trading activity
2. 02Fee Escrow credit
3. 03Permissionless router claim
4. 04Immutable reward stream
5. 05District Stock Tokens
6. 06Property utility
7. 07Permanent DEED burns
8. 08Lower remaining supply

The route is deterministic but not a yield promise or timing guarantee. Pons sweep, permissionless epoch advancement, an authorized guarded acquisition, viable liquidity, and fresh oracles are distinct stages. A failure or pause delays the affected stage without changing custody, immutable economics, deterministic ownership, or burn state.

Transferability adds continuity. A progressed property can change owners without losing level or burn history, so prior investment remains visible in the city. At transfer, prior rewards are separated from future participation. This allows the property market and reward accounting to coexist while preserving the rule that deposited assets belong to the owners who held the relevant weight during accrual.

DEED uses three distinct scarcity layers. Genesis scarcity is absolute: only 333 token IDs can be created, divided among fixed district caps. Token scarcity begins with one billion DEED, no inflation, and irreversible burns. Progression scarcity emerges because higher forms require increasingly large burns and cannot be assigned directly.

• GENESIS SCARCITY — 333 permanent original properties.
• TOKEN SCARCITY — fixed initial supply plus one-way destruction.
• PROGRESSION SCARCITY — sequential million-DEED commitments for upper levels.

Landmark is intentionally expensive because it combines all prior transitions: 1 million, 2 million, 3 million, and 4 million DEED. Its 500 Reward Weight is five times the House value, but the cost is not linear with weight. The design treats Landmark as a high-commitment terminal form rather than a default destination for every property.

Scarcity does not establish market value. A finite supply can still face weak demand, thin liquidity, price volatility, or integration failure. The protocol guarantees only the onchain caps and schedules enforced by code. Secondary prices, conversion rates, reward values, and the number of properties that owners choose or manage to upgrade remain market outcomes.

DEED is positioned for Robinhood Chain. This is product direction, not a claim of endorsement, sponsorship, or official partnership by Robinhood. The integration verifies chain ID 4663, canonical WETH and USDG, the current Pons V2 stack, the four canonical Robinhood Stock Tokens, their Chainlink feeds, and fixed Uniswap V3 acquisition routes. No public DEED deployment has been broadcast.

The frontend fixes the verified chain identity while reading its RPC and every future DEED contract address from public environment configuration. When those deployment addresses are absent, production transaction controls remain unavailable. Local Anvil and legacy test-chain support are isolated for development and do not define the public launch network.

Core components are modular where practical: token, NFT, progression, reward accounting, fee conversion, quote revenue, and reward acquisition are separate. That structure can reduce the scope of venue-specific changes, but chain migration is not automatic. Final deployment must verify wallet support, RPC behavior, finality, token standards, DEX transfer semantics, adapter assumptions, explorer links, and operational roles.

The canonical production DEED launch uses Pons V2 rather than a custom bootstrap contract. Pons deterministically creates a standard fixed-supply token and bonding curve, places the whole supply on the curve, trades against native ETH, and automatically transitions at its configured threshold into permanently locked Uniswap V4 liquidity governed by the shared Pons hook.

Locked economics

• 1,000,000,000 Pons-created DEED with no post-launch minting.
• 333 Genesis Properties across immutable district caps.
• 100,000 DEED burned per Genesis mint and up to three primary mints per wallet.
• 1M / 2M / 3M / 4M sequential upgrade burns.
• 100 / 160 / 250 / 365 / 500 Reward Weight schedule.
• 3% Pons creator tax on official buys and sells, plus the Pons base fee.
• Native ETH pairing and buyback disabled by default.

Deterministic deployment order

• Verify the current Pons factory, dependencies, enabled one-billion config, and creator-tax ceiling.
• Freeze the reviewed salt and predict the exact DEED and curve addresses with deterministic DEEDFeeRouter as the Pons creator recipient.
• Deploy the ten DEED contracts at reviewed nonces 0 through 9, including RewardStreamVault before DEEDFeeRouter, with every predicted immutable address checked before submission.
• Configure the one-time Genesis links and freeze equal district allocation; RevenueVault accepts matured company WETH only from its immutable RewardStreamVault.
• Launch through the official Pons factory with DEEDFeeRouter as creatorFeeRecipient.
• Assert the predicted DEED, curve, router, nonce-derived contract addresses, and complete 17-operation sequence before enabling the application.

The verified config has 1.68 ETH phantom quote and a 4.2 ETH graduation threshold. Its opening marginal fully diluted valuation is 1.68 ETH, and its graduation marginal fully diluted valuation is 20.58 ETH. These ETH values are deterministic configuration results; their USD equivalents move with ETH/USD and are not guaranteed market values.

The protocol separates economic responsibilities so each contract can expose a narrow authority surface. Immutable references connect the deployed components, while one-time configuration links the property collection to its minter, manager, and reward hooks. The system is not a single upgradeable contract and does not rely on a global admin method that can rewrite every parameter.

IDEEDBurnable is the token surface required by GenesisMinter and PropertyManager. IStockAcquisitionAdapter abstracts guarded WETH-to-district-reward execution. Transfer and upgrade hook interfaces connect settlement to ERC-721 transfers and property progression. Router and stream vault expose no AccessControl or mutable economic setters; the distributor's sole depositor is immutable RevenueVault.

PropertyMetadataRenderer is presentation-only and emits metadata from canonical GenesisProperty state. Mock quote and reward contracts support deterministic local tests and are not production assets. Production revenue follows only the immutable Fee Escrow → router → stream → RevenueVault → distributor → holder custody path.

Security begins with constrained state transitions. Pons creates DEED supply once and exposes no later mint path. Genesis supply is capped independently in the NFT contract. Burns are one-way. Property levels advance through a library-defined sequence, and only the configured manager can apply a transition. Reward checkpoints occur before transfer and upgrade state changes, preventing later owners or higher weights from claiming earlier accrual.

• OpenZeppelin ERC-20, ERC-721, AccessControl, SafeERC20, Pausable, Math, and ReentrancyGuard primitives.
• Exact or temporary token approvals cleared after adapter and vault interactions.
• Balance-difference accounting for transferred, converted, and acquired assets.
• Role isolation between deposit, processing, allocation, pausing, and fee operations.
• O(1) reward deposits and per-token checkpoints rather than collection-wide iteration.
• Custom errors and state-mismatch checks around transfer and upgrade hooks.
• Unit, fuzz, invariant, and fork compatibility tests in the repository.

Key invariants include total supply never exceeding the constructor amount, Genesis supply never exceeding 333, district supplies respecting 84/83/83/83, levels never decreasing, Reward Weight matching level, checkpoints never decreasing, and total claimed reward assets never exceeding deposited assets. Revenue accounting distinguishes processed balances from unsolicited surplus.

These controls reduce known failure modes but do not make the system risk-free. External token behavior, adapters, DEXs, network conditions, administrator compromise, incorrect deployment wiring, and undiscovered contract defects remain relevant. A production release requires independent security review, verified configuration, operational controls, and clear incident procedures.

The single permanent admin EOA administers pausing for GenesisMinter, PropertyManager, and RevenueVault and holds the RevenueVault processor role. RewardDistributor, RewardStreamVault, and DEEDFeeRouter have no AccessControl. Pons V2 separately governs its factory, fee policy, trusted sweep operator, graduation components, and time-delayed creator-recipient recovery paths.

Anyone can claim and route Fee Escrow credit, flush Treasury liability, or process bounded matured stream epochs. The admin can delay minting, upgrades, or guarded Stock Token acquisition, and key loss or compromise is therefore an availability risk. It cannot redirect reward custody, change the router split, stream durations, frozen allocation, reward assets, or immutable depositor boundaries.

What administrators cannot do through current contracts

• Mint canonical Pons DEED beyond its one-billion launch supply.
• Increase Genesis supply beyond 333 or exceed district caps.
• Restore DEED that has been burned.
• Raise the launch-fixed 3% creator-tax rate.
• Skip, reverse, or arbitrarily edit property levels and Reward Weight.
• Move a property into another district or detach progression from its token ID.
• Withdraw WETH already deposited into RevenueVault through an administrative escape hatch.
• Redirect reward claims or take balances already credited to property owners.

Administrative restraint still depends on correct initial deployment. Before one-time links and freezes are completed, configuration authorities can choose the minter, manager, hooks, metadata renderer, district allocations, CREATE2 salt, Pons creator recipient, and operational roles within each contract's rules. Pons factory governance retains the externally documented ability to rotate global policy for future launches and recover a creator recipient through its timelock. Those powers and role holders must be disclosed and monitored.

Emergency controls are scoped rather than universal. GenesisMinter can pause and unpause primary minting. PropertyManager can pause and unpause upgrades. RevenueVault can pause and unpause guarded Stock Token processing. These controls can limit new state transitions while an incident is investigated without rewriting completed burns, property progression, stream custody, or matured WETH accounting.

RewardDistributor, RewardStreamVault, and DEEDFeeRouter have no general pause switch. User claims remain governed by ownership and checkpoint accounting; stream advancement remains permissionless; standard DEED wallet transfers and GenesisProperty secondary transfers are not globally pausable. A RevenueVault pause delays acquisition but does not redirect pending company WETH.

This scope reflects a tradeoff. Preserving ordinary token and NFT ownership movement reduces administrative custody over user assets, while pausing mint, upgrades, or revenue processing can contain certain operational failures. It also means an emergency response cannot stop every interaction. Production operations must document which contracts can be paused, who holds each pauser role, how keys are secured, and what evidence is required to resume.

GenesisProperty follows ERC-721 ownership and approval semantics and exposes ERC-4906 metadata update events. Standard transfers and safe transfers remain available. Token metadata is generated from canonical company, district, plot, level, Reward Weight, and lifetime burn data, allowing marketplaces and wallets to display the property's current progression state.

The reward hook runs inside the NFT transfer path before ownership changes. It checkpoints the seller but does not transfer the district reward token as part of marketplace settlement. The seller receives a claimable ledger balance, and the buyer starts at the current accumulator. This avoids coupling an NFT sale to reward-token transfer success or forcing a marketplace to understand the reward system.

Marketplace support still requires testing. Contracts or marketplaces that use unusual custody, wrapping, lending, escrow, or batch-transfer patterns may change who is considered the onchain owner during accrual. A wrapped or escrowed property earns for the address that owns the ERC-721 unless a separate application layer explains beneficial ownership. The protocol does not infer offchain agreements.

Progression remains attached to the original token ID throughout marketplace transfers. A listing should display current level, Reward Weight, district, and burn history at the time of inspection, while recognizing that state can change before execution. Reward balances earned by the seller are not included automatically in the asset being sold.

The city is a user-interface layer over the onchain Genesis registry. It maps 333 token IDs to square plots, groups them into four districts, and renders five architectural forms from contract level data. It is not a separate ownership database, metaverse land contract, or source of economic truth.

The frontend exposes ownership, progression, Reward Weight, district, total DEED burned, next upgrade cost, pending property rewards, and balances already checkpointed to a wallet. Transaction controls resolve addresses from the selected deployment and remain unavailable when production Robinhood parameters are missing. The interface does not fabricate ownership or enable mock production transactions.

Visual language is intentionally legible rather than simulated. A House, Residence, Building, Tower, and Landmark communicate progression; the city register communicates finite supply; and document-like property pages communicate durable state. These views can evolve without changing the ERC-721 or economic schedule because rendering is downstream of onchain data.

Interfaces must avoid compressing risk and accounting concepts into unexplained shorthand. Reward Weight should be defined before numbers are shown. Pending reward values must identify their asset and inactive state. Claims should distinguish current-NFT checkpointing from previously credited district balances. No screen should imply guaranteed income or fixed APY.

Participation involves technical, market, operational, and regulatory uncertainty. The following categories are not exhaustive, and their relevance can change as the target chain, liquidity venue, reward assets, and production adapters are finalized. Users should evaluate the deployed contracts and current integrations rather than rely solely on interface copy or this document.

• SMART-CONTRACT RISK — defects, unexpected token behavior, hook interactions, or deployment errors may cause loss or unavailability.
• LIQUIDITY RISK — DEED or reward assets may have shallow markets, high slippage, or no executable route.
• MARKET RISK — DEED, NFTs, quote assets, and reward assets may lose value or become difficult to price.
• EXTERNAL-ASSET RISK — a provider may suspend, restrict, reclassify, freeze, or discontinue a reward asset.
• INTEGRATION AND ORACLE RISK — future adapters, pricing inputs, routers, or bridges may fail or be manipulated.
• NETWORK RISK — congestion, reorganization, downtime, fee changes, wallet incompatibility, or chain policy may impair use.
• REGULATORY RISK — tokens, NFTs, trading fees, and stock-linked reward assets may receive different treatment across jurisdictions.
• FRONTEND RISK — hosting, DNS, RPC, indexing, browser, or wallet failures may make the interface unavailable while contracts remain live.
• ADMIN-KEY RISK — compromised configuration, role, processor, metadata, or pauser keys may disrupt operations within their authority.
• PONS DEPENDENCY RISK — factory, curve, hook, escrow, sweep-operator, graduation, or locked-liquidity behavior may fail or change for future launches.
• SWEEP-LIVENESS RISK — creator revenue is not usable until Pons fees are swept and claimed; timing is asynchronous and may require its trusted operator.
• VOLATILITY RISK — burns and upgrade costs are fixed in DEED units, so their market cost can vary materially.

Rewards are particularly contingent. Reward Weight creates a relative claim only on assets actually deposited into a district under the contract rules. It does not create a fixed APY, guaranteed conversion path, fixed fiat value, or ownership of an underlying company. Robinhood Stock Tokens are tokenised debt securities issued by Robinhood Assets (Jersey) Limited. They provide economic exposure to underlying securities but do not grant legal or beneficial ownership of those securities and are subject to jurisdictional restrictions.

Risk controls should include independent audits, reproducible deployments, strict custody procedures for the single permanent admin key, verified adapters, monitored accounting, conservative slippage limits, incident disclosure, and staged launch testing. This production model is not multisig-secured or decentralized. These measures reduce risk but cannot eliminate it.

The roadmap separates substantially implemented protocol work from production work that remains unresolved. It does not assign deadlines. Completion of a software component does not mean it has received an independent audit or is ready to custody production value.

Completed or substantially implemented

• Canonical Pons V2 fixed-supply DEED launch and ERC20Burnable compatibility validated on a pinned Robinhood fork.
• Permanently capped ERC-721 Genesis collection and district limits.
• Genesis primary mint opens only after the exact canonical Pons launch, with up to three mints per wallet and a 100,000-DEED burn per mint.
• Sequential property progression and immutable Reward Weight schedule.
• Accumulator-based rewards, transfer checkpoints, upgrade checkpoints, and first-mint activation.
• Launch-fixed 3% Pons creator tax with untaxed wallet transfers.
• Immutable DEEDFeeRouter claim with exact Treasury accounting and streamed Genesis funding.
• Official Pons curve graduation into locked Uniswap V4 liquidity.
• Wallet-connected frontend MVP with Pons BUY DEED routing, mint, city, portfolio, property, rewards, and whitepaper routes.

Future production work

• Complete independent review of DEED contracts, Pons integration assumptions, deployment manifests, and operational procedures.
• Monitor production Stock Token route liquidity and Chainlink freshness before every revenue conversion.
• Regenerate and review M11/M12 for the current source metadata while preserving the approved DEED, curve, router, nonce addresses, and 17-operation sequence.
• Obtain legal and compliance signoff for Stock Token distribution in intended jurisdictions.
• Deploy, verify, and publish production contract addresses only after all preflight checks pass.
• Set the frontend's canonical DEED address at build time to enable the Pons market link.
• Deploy the human-approved renderer, verify its runtime codehash, and obtain separate authorization before freezing it.
• Expand city exploration, transaction analytics, and protocol monitoring.

Each future step should produce verifiable artifacts: specifications, tests, audited code, deployment records, confirmed provider documentation, and public configuration. If target infrastructure changes, the roadmap should update without silently changing locked economics.

The following ideas are non-committed possibilities rather than roadmap promises: additional city maps, non-Genesis property systems, cosmetic architecture, auctions, richer visualization, governance, analytics, and additional districts. None is required for the current protocol lifecycle.

Any extension must preserve the original Genesis guarantee. No future collection, map, wrapper, cosmetic item, or governance decision may increase or dilute the 333 Genesis Property supply in the existing contract. New assets would require distinct naming, economics, and disclosures so users can distinguish them from permanent Genesis positions.

Extensions that affect rewards or fee routing require particular care. Adding districts, reward assets, cross-chain representations, lending, or delegated ownership can change accounting assumptions and marketplace behavior. Such work should use new reviewed interfaces or contracts rather than imply that current components already support it.

DEED turns a fixed token supply into a finite digital city. Three hundred and thirty-three Genesis Properties represent permanent onchain positions. Owners can transfer those positions or permanently progress them by burning the native asset. Reward Weight remains attached to each deed and determines relative participation when its district receives actual reward deposits.

Pons trading activity can create quote-denominated creator revenue for immutable DEEDFeeRouter. Its permissionless claim commits the exact 3333/6667 accounting and schedules the Genesis remainder; no caller can choose a different contribution. Stock Token delivery remains contingent on Pons sweep liveness, stream maturity, oracle freshness, liquidity, guarded processing, and asset availability.

The protocol's durable commitments are its Pons-created fixed supply, finite Genesis registry, immutable burn and progression schedules, relative reward accounting, launch-fixed 3% creator tax, and immutable district Stock Token addresses. Production addresses, operational roles, final metadata, audit results, RPC operations, and compliance approval remain to be finalized before launch.

This table summarizes the principal DEED economics and the Pons V2 launch configuration verified on the pinned Robinhood Chain fork. No public launch has occurred.