DEED
Whitepaper

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 can move through its official fee escrow into a measured WETH revenue pipeline. That revenue can acquire district-specific reward assets, which are then allocated among current property owners according to 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, operational integrations, and the property's ownership history. Real Robinhood Stock Token acquisition remains a later production milestone; Milestone 9 uses mock reward assets only.

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 the seller earned from what the buyer may earn 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, then links Pons V2 creator revenue to district rewards. Each transition is handled by a specialized contract. Pons deploys the canonical token and bonding curve; the NFT contract stores property state; the minter and manager apply fixed burn rules through IDEEDBurnable; and the revenue system measures WETH received before it can fund district accumulators.

1. 01Acquire DEED on Pons
2. 02Mint Genesis Property
3. 03DEED is burned
4. 04Own the NFT
5. 05Burn DEED to upgrade
6. 06Reward Weight increases
7. 07Pons trading creates fees
8. 08Creator revenue reaches escrow
9. 09WETH funds district reward pools
10. 10Owners claim deposited rewards

The two sides of this flow are related but not mechanically guaranteed to progress together. A user can burn DEED even if no reward assets have been deposited. Trading can produce fees without guaranteeing a particular conversion price or reward-asset output. Reward Weight only acts when a district receives a deposit. This separation avoids issuing new DEED as a reward and keeps 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, claimed as native ETH, wrapped to WETH, and deposited into RevenueVault. Reporting must not combine creator revenue with burned tokens or imply that ordinary trading automatically burns 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.

The one-primary-mint rule belongs to GenesisMinter and applies per calling wallet. It does not cap later ownership. A wallet that has already minted may acquire additional Genesis Properties through transfers or secondary markets, and a wallet that never used its primary mint 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 immutable start time. The minter checks its pause state, the wallet's prior mint status, the global 333 cap, and the selected district cap before burning DEED and requesting the ERC-721 mint.

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 one-mint-per-wallet gate, while later economic commitment is expressed through million-DEED upgrades. 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 current revenue allocation controller starts with an equal 25% quote allocation across four companies and allows the authorized allocation manager to replace all four values atomically before freezing them. The values must total 10,000 basis points. Revenue processing is blocked until allocations are permanently frozen. Equal allocation is the deployed default, not an assertion that future reward assets 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 can activate only after all 333 Genesis Properties exist and the NFT transfer hook and property upgrade hook both point to the same RewardDistributor. Activation is irreversible and permissionless once those conditions hold. Before activation, deposits and claims revert. After activation, deposits require REWARD_DEPOSITOR_ROLE and update only the selected district.

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.

Protocol revenue begins with quote-denominated creator revenue accrued by Pons trades. Fees first remain unswept on the bonding curve or the graduated V4 hook. A Pons sweep later credits the official Fee Escrow. PonsRevenueReceiver claims the amount available to its own address, measures the native ETH balance delta, wraps exactly that amount into canonical WETH, and deposits the measured WETH into RevenueVault.

1. 01Pons DEED trade
2. 02Unswept creator fees
3. 03Pons sweep
4. 04Pons Fee Escrow
5. 05PonsRevenueReceiver claim
6. 06ETH → WETH
7. 07RevenueVault
8. 08District reward assets

Sweep timing is asynchronous. Pre-graduation curve sweeps and post-graduation hook sweeps may depend on the Pons trusted operator, especially when an internal swap is involved. DEED accounting begins only when PonsRevenueReceiver actually receives ETH. The receiver has no generic withdrawal, no arbitrary recipient, and no configurable payout path.

This system funds rewards with external assets obtained from market-generated fees rather than newly minted DEED. Consequently, there is no DEED emission schedule to property owners. Reward volume depends on trade volume, fee collection, conversion output, revenue processing, allocations, and reward-asset acquisition. Any of these may be zero or unavailable during a period.

Production Pons revenue needs no DEED-to-quote conversion: creator revenue already arrives in native ETH from a native-quote launch. PonsRevenueReceiver performs the single deterministic ETH-to-WETH wrapping step. IStockAcquisitionAdapter remains the modular step from allocated WETH quote revenue to a district reward asset. RevenueVault and RewardDistributor handle accounting before and after that adapter.

For each processed revenue amount, RevenueVault reads the frozen four-district allocation, rounds the first three quote allocations down, and assigns the exact remainder to Meta so the total equals the requested amount. It gives the acquisition adapter an exact allowance for one district, clears that allowance, verifies quote spent, measures the reward asset received, and deposits that measured amount into the corresponding distributor pool.

Minimum-output parameters are operational protections rather than price guarantees. They allow a processor to reject conversion below an externally determined threshold, but the contracts do not supply an oracle or decide fair value. A production adapter must define venue validation, slippage policy, quote-asset assumptions, failure behavior, and asset custody. Those choices require review for the final Robinhood environment.

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 creating a contractual promise that one causes the other at a fixed rate. Pons trading can accrue creator revenue in ETH. After sweep and claim, measured WETH can acquire district reward assets. Deposits increase the utility of Reward Weight. Owners may then choose to burn DEED to increase future relative weight.

1. 01Pons trading activity
2. 02Creator revenue
3. 03Escrow claim
4. 04WETH revenue
5. 05District deposits
6. 06Property utility
7. 07Permanent DEED burns
8. 08Lower remaining supply

The loop is reflexive but not self-executing in every environment. Conversion and revenue processing require authorized operators and viable integrations. Reward assets require availability. Property progression requires voluntary owners with sufficient DEED and allowance. Trading requires liquidity and users. A failure or pause at one point can reduce later activity without corrupting the deterministic ownership and burn state already recorded.

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. Milestone 9 verifies chain ID 4663, ETH as the native currency, the official Blockscout explorer, canonical WETH, the current Pons V2 stack, and Pons graduation into locked Uniswap V4 liquidity. It does not deploy DEED publicly or integrate Robinhood Stock Tokens.

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 Genesis mint burn and one primary mint 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.
• Deploy the WETH RevenueVault and PonsRevenueReceiver.
• Choose a CREATE2 salt and predict the exact token and curve addresses.
• Deploy GenesisMinter and PropertyManager against the predicted token through IDEEDBurnable.
• Configure Genesis hooks and revenue roles.
• Launch through the official Pons factory with the receiver as creatorFeeRecipient.
• Assert predicted and actual token and curve addresses are identical 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 only token surface required by GenesisMinter and PropertyManager. IStockAcquisitionAdapter abstracts WETH-to-district-reward execution. Transfer and upgrade hook interfaces connect settlement to ERC-721 transfers and property progression. PonsRevenueReceiver has immutable escrow, WETH, and vault references and exposes no arbitrary withdrawal.

PropertyMetadataRenderer is presentation-only and emits onchain metadata from canonical state supplied by GenesisProperty. Mock quote and stock contracts support deterministic development tests and are not production assets. Production launch and revenue contracts use narrow interfaces for the verified Pons V2 token, fee escrow, canonical WETH, and RevenueVault.

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.

AccessControl roles divide operations across DEED contracts. GenesisMinter and PropertyManager have pauser roles. RewardDistributor has a reward depositor role. RevenueVault separates revenue depositors, revenue processors, and pausers, while StockAllocationController has an allocation manager role. Pons V2 separately governs its factory, fee policy, trusted sweep operator, graduation components, and time-delayed creator-recipient recovery paths.

Authorized DEED accounts can grant and revoke subordinate roles according to OpenZeppelin AccessControl administration, pause or unpause the components that implement Pausable, process measured WETH revenue through immutable adapters, configure allocations before freeze, and set the metadata renderer through the immutable GenesisProperty metadata manager. Pons sweeps remain an external operational dependency; the DEED receiver cannot redirect or withdraw claimed revenue.

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 revenue from PonsRevenueReceiver or redirect its RevenueVault deposit.
• 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 revenue deposits and processing. These controls can limit new state transitions while an incident is investigated without creating a method to rewrite completed burns or property progression.

The current RewardDistributor does not implement a general pause switch for deposits or claims, and PonsRevenueReceiver is intentionally permissionless and non-configurable. Their sensitive inputs are instead limited by depositor roles, immutable dependencies, and measured receipt, while user claims remain governed by ownership and checkpoint accounting. Standard DEED wallet transfers and GenesisProperty secondary transfers are not globally pausable in the current architecture.

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 debt owed by the protocol, a right to company equity, a guaranteed conversion path, or a fixed fiat value. Development mock tokens are not securities, shares, or redeemable financial assets.

Risk controls should include independent audits, reproducible deployments, role separation, multisignature or equivalent key management where appropriate, verified adapters, monitored accounting, conservative slippage limits, incident disclosure, and staged launch testing. 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.
• Timed one-wallet Genesis mint with 100,000-DEED burn.
• Sequential property progression and immutable Reward Weight schedule.
• Accumulator-based rewards, transfer checkpoints, and upgrade checkpoints.
• Launch-fixed 3% Pons creator tax with untaxed wallet transfers.
• Pons Fee Escrow → measured ETH → WETH → RevenueVault integration.
• 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.
• Select and verify the production Robinhood Stock Token acquisition integration in Milestone 10.
• Confirm final Pons metadata, CREATE2 salt, deployer, sweep operations, and multisig or equivalent role holders.
• 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.
• Finalize production NFT artwork and metadata operations.
• 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, and measured WETH processing can turn that revenue into district reward assets. This creates a path from market activity to property utility without minting new DEED rewards. The path remains contingent on Pons liquidity, fee sweeping, escrow claims, asset availability, operator actions, and production integrations.

The protocol's durable commitments are its Pons-created fixed supply, finite Genesis registry, immutable burn and progression schedules, relative reward accounting, and launch-fixed 3% creator tax. Production addresses, operational roles, final metadata, audit results, and the reward-asset provider remain to be finalized and verified 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.