Whitepaper

United States Secured Exchange (USSE)

Protocol Whitepaper, Version 1.0

September 2026

This document defines the technical architecture, economic invariants, governance structure, and risk factors of the USSE protocol. Sections 1 through 16 describe the system at a conceptual level. Appendices A through BF are per-contract technical annexes covering the deployed implementation, issued as a companion contract reference manual; references to them throughout this document identify where each mechanism is set out in full.

The deployed Smart Contract bytecode and on-chain execution state constitute the authoritative source of truth. In the event of any discrepancy between this document and deployed contract logic, the on-chain implementation governs.

Contents

• 1. Executive Summary
• 2. Definitions
• 3. Overview
• 4. Design Philosophy: 4.1 Constraint at the Configuration Surface; 4.2 Separation of Duties in Code; 4.3 Immutability of Core Economic Guarantees; 4.4 Deterministic Routing; 4.5 Integrity Anchoring Without Content Exposure; 4.6 Compliance-Aware Architecture; 4.7 Deployment Across Two Chains
• 5. System Flows: 5.1 Supply Flow; 5.2 Value Flow; 5.3 Governance Flow; 5.4 Liquidity Flow; 5.5 Messaging and Data Integrity Flow; 5.6 Cross-Chain Transfer Flow
• 6. Tokenomics: 6.1 Fixed Supply and Genesis Mint; 6.2 Circulating and Non-Circulating Supply; 6.3 Time-Based Issuance Model; 6.4 Allocation Categories and Funding Intent; 6.5 Allocation Vesting and Release Controls; 6.6 Reserve Custody and Isolation; 6.7 Deterministic Routing of Released Supply; 6.8 Tokenomics and Governance Boundary; 6.9 Incentive Program Contracts
• 7. Governance: 7.1 Governance Authority and Phases; 7.2 Scope and Limits of Governance Authority; 7.3 Governance Action Lifecycle; 7.4 Administrative Authority During the Transition Period; 7.5 Separation of Governance and Operations; 7.6 Governance Transition Guarantees
• 8. Treasury System and Financial Controls: 8.1 Separation of Custody, Authorization, and Accounting; 8.2 Deterministic Revenue Routing; 8.3 Auditability and Its Limits; 8.4 Immutable Fee Floor Enforcement and DEX Transition
• 9. Messaging and Data Integrity: 9.1 Confidential Messaging Architecture; 9.2 On-Chain Integrity Commitments; 9.3 Batched Anchoring and Permanence; 9.4 Policy and Governance Context
• 10. Identity and Social Infrastructure: 10.1 TheWall: Public Social Publishing; 10.2 ProfileRegistry: On-Chain Identity Presentation; 10.3 ContactRegistry: Contact Lists and Business Directories; 10.4 NameRegistration: Human-Readable Wallet Addressing; 10.5 OrganizationHierarchy: On-Chain Entity Structure
• 11. Digital Asset Infrastructure: 11.1 USSENFT: The ERC-721 Collection; 11.2 USSEEditions: The ERC-1155 Edition Collection; 11.3 NFTMarketplace: Listing and Settlement; 11.4 Minting and Content Infrastructure; 11.5 USSETicketing: Event Ticket Policy
• 12. Core System Invariants: 12.1 Fixed Supply Invariant; 12.2 Time-Based Issuance Model Invariant; 12.3 Governance Boundary Invariant; 12.4 Separation of Duties Invariant; 12.5 Immutability of Recorded Data; 12.6 Deterministic Enforcement Invariant
• 13. Real World Use Cases: 13.1 TheWall: Public Statements and Audience Control; 13.2 DEEP Mail: Encrypted Messaging, Payment and Files; 13.3 Media Marketplace: Mint, Buy, Sell and Play; 13.4 The Three Products Together
• 14. Risk Factors and Limitations: 14.1 Technical Risk; 14.2 Protocol and Governance Risk; 14.3 Economic and Market Risk; 14.4 Regulatory and Legal Risk; 14.5 Operational and Infrastructure Risk; 14.6 Privacy and Key Management Risk; 14.7 Adoption and Ecosystem Risk; 14.8 No Assurance of Performance; 14.9 Statements of Present Configuration
• 15. Regulatory and Legal Considerations: 15.1 Nature of This Document; 15.2 Separation of Protocol and Corporation; 15.3 Token Characterization; 15.4 Securities Offerings and Exemption; 15.5 Investor Eligibility and Verification; 15.6 Transfer Restrictions and Resale; 15.7 Jurisdictional Limitations; 15.8 Forward-Looking Statements; 15.9 Compliance-Aligned Configuration and Regulatory Development; 15.10 No Legal, Tax, or Investment Advice
• 16. Conclusion

The Smart Contract Appendices are issued as a companion contract reference manual. Each is listed there, with a one-line description, in the Appendix Index at its head.

1. Executive Summary

Digital coordination today is fragmented and discretionary. Messaging, social publishing, identity, and financial infrastructure are split across separate platforms, each governed by centralized operators who can alter terms, suspend access, or expose user data at will. Existing blockchain alternatives typically solve only one piece of this problem in isolation, leaving users to reassemble trust across disconnected systems, and few are built with enforceable supply discipline or compliance-aware architecture from inception.

United States Secured Exchange (USSE) addresses this by unifying confidential communication, social publishing, identity, and value transfer within a single deterministic protocol, where behavior is defined by code, subject to the administrative and upgrade authority described in the next paragraph and in §7.4, and a single governance regime covers all of them rather than one per layer. §5 states how supply, value, and authority move through it, and §13.4 shows what the three products look like used together.

Three things are enforced by Smart Contracts directly rather than by policy: a fixed token supply, treasury controls bounded by governance, and Integrity Commitments recorded through Anchoring Events. Those boundaries are architectural rather than already settled: until an upgradeable contract reaches Immutable Finalization its upgrade authority rests with its owner key, except that on five contracts (CEXListing, Farming, NFTMarketplace, USSEEditions and USSENFT) the address the contract names as governance may also authorize an upgrade, on TokenManager that authority rests with its administrator, and on the multi-signature wallet it rests with the wallet's own confirmed transactions. §7.4 and §14.1 set out the administrative and upgrade authority in force before that point.

The total token supply is created through the Genesis Mint and permanently constrained by the Fixed Supply Invariant; the token contract declares no other minting function. Circulating Supply expansion follows the Time-Based Issuance Model under the Triennial Unlock Cadence, enforced on-chain. Three qualifications belong with those two claims. Until the token contract reaches Immutable Finalization the code enforcing the cap remains replaceable by the owner key, and finalization closes that authority for every party rather than passing it to governance. The timing of the issuance schedule is not fixed. Before the first release, and while the vault remains un-finalized, the owner may move its anchor date later without any limit, though not so early that the first tranche would fall in the past; and the owner or the governance address may pause releases for ninety days at a time, a pause that may be renewed by a fresh call each time it lapses. Neither creates supply nor changes the size of a tranche. And the reserve's one exit off the schedule, a migration of the entire remaining reserve, is callable only by the address the vault holds as its governance address. The owner may set that address to any non-zero address, its own key included, until the vault is finalized, and a live read on 11 September 2026 returned it unset, so no party could make that transfer on that date. The exit remains subject to the Fixed Supply Invariant. Each of these is stated in full in §6.1, §6.3, §6.6 and §12.1.

Governance authority progresses through the Governance Transition from restricted deployment control to Executive Multi-Signature Authority and ultimately to DAO Governance, the decentralized autonomous organization phase, under enforced procedural safeguards. That progression is a design end-state rather than a present condition. The voting route is deployed but dormant until a stored activation date, so the administrative routes are the ones that operate until it arrives. §7.1 records that date.

Upon Immutable Finalization, upgrade authority over the finalized contract either closes or passes to governance alone, and no function of the finalized implementation reinstates the owner's authority. What finalization otherwise ends differs by contract: in a minority the configuration surface closes with it, while in most at least one capability remains reachable by the owner afterwards. Governance authority is limited in scope: no proposal or configuration function available to it can alter the core economic invariants, although where finalization passes a contract's upgrade authority to governance, as it does for the Reserve Vault, governance can replace that implementation. §7.6 describes the two forms finalization takes, and §12.3 what stands behind each invariant.

The Treasury System separates custody, authorization, and accounting functions, and records financial movement through immutable on-chain events. That separation is one of authority rather than of address, and the ledger measures what authorized sources report together with what the contract receives rather than serving as a custody record; §8.1 and §12.4 state both qualifications.

USSE also incorporates a native messaging and data integrity layer. Communications are encrypted on the sender's device and submitted on-chain in that form, while Integrity Commitments are recorded through Anchoring Events, creating tamper-evident records of existence and timing without disclosing message contents to anyone but the parties holding the keys. This enables authenticated coordination that preserves confidentiality while keeping the record verifiable. The recording contracts expose no path that alters a commitment. Everything described here is held on-chain (in contract storage, in emitted events, and in the transaction data itself), and the distinction that matters is not where a record sits but what a later upgrade can reach: the transaction log is fixed once written, while the values a contract's view functions return depend on the implementation deployed when they are called. Both are set out in §9.2.

Alongside these, the protocol provides a native digital asset marketplace. The non-fungible token (NFT) marketplace enables listing and settlement of both unique and edition-based digital assets, with minting and sale settlement denominated in ETH, the native currency of Ethereum, and deterministic fee routing through FeeManagement, as §11 sets out.

A public social record layer, on-chain identity profiles, human-readable wallet addressing, wallet-based contact management, and the organization structures built from those wallets complete the ecosystem's coordination infrastructure, keeping participant records on-chain and independently readable without reliance on centralized services. Three boundaries belong with that: message content is protected by the encryption applied to it rather than by being kept off the chain, profile presentation is performed by the applications reading the registry rather than enforced on-chain, and a published post cannot be altered by anyone once it is recorded. §9.1, §10.2 and §10.1 cover them in turn.

The protocol carries a compliance surface. A single registry holding account tiers and one sale stage are enforced by the token contract and by TokenSale, operating alongside the core economic guarantees and the data integrity constraints rather than over them. §4.6 states what it reaches and what it does not.

By prioritizing enforceable invariants over discretionary flexibility, USSE establishes a structurally bounded infrastructure intended for long-term operational reliability. The guarantees summarized above are formalized as invariants in §12, and the limitations and risks qualifying them are set out in §14.

This whitepaper is technical documentation. It contains no offering terms, subscription procedures, valuation, or financial projections, and it is not an offer to sell or a solicitation of an offer to buy any security. Any offer or sale of securities by United States Secured Exchange, Inc. is made solely through separate offering documents furnished to eligible investors, which govern in the event of any inconsistency with this document. See §15.

2. Definitions

For purposes of this document, the following terms have the meanings set forth below. Defined terms are capitalized when used in this whitepaper.

Anchoring Event

The recording of an Integrity Commitment to a blockchain. A recorded commitment is append-only: neither anchoring contract exposes a function that alters or deletes one, a batch root that has already been committed is refused as a duplicate, and a message receipt may be registered only once. Two properties bound what that last guarantee establishes. A receipt on the Layer 1 anchor may be registered by any address that pays the fee, the first to do so fixing it, and its fields are that registrant's assertion rather than values the contract checks against the Layer 2 record. And on the Layer 2 message bus a message identifier is unique per submitter rather than globally, so a later message posted by a different sender under the same identifier redirects the bus's lookup by identifier, and its inclusion check, to that later message, while leaving the earlier record itself unchanged. Two fields that sit alongside a commitment are not covered by that guarantee and should not be read as though they were: the metadata asserting that a batch was subsequently anchored to Ethereum may be written again by an approved submitter, as §9.4 states, and a batch's verified flag is set by an approved bridge. Because the commitment is a fingerprint of a message rather than the message itself, it establishes verifiable proof of existence and timing without revealing what was said. That is a property of the commitment rather than of the record as a whole: the encrypted message is carried on-chain alongside it, so the content is present in encrypted form and confidentiality rests on that encryption. §9.1 sets out where each part is held.

Automated Market Maker (AMM)

A decentralized protocol, meaning software running on a blockchain rather than a company, that lets anyone trade one token for another. The price comes from a formula applied to a liquidity pool, a shared holding of both tokens that anyone may deposit into. There is no order book, the list of standing buy and sell offers a conventional exchange matches against.

Centralized Exchange (CEX)

A trading platform run by a company that holds its customers' funds on their behalf, maintains the order book of standing buy and sell offers, and matches trades on its own internal systems.

Circulating Supply

Total token supply less the balance held in the Reserve Vault pending scheduled release, or the whole supply where no Reserve Vault address is set. That is how the token contract computes it. The figure measures supply held outside the vault rather than supply available to trade, so tokens an account cannot presently transfer, such as those under a lockup, are counted. §6.6 records what follows from that dependency, and §15.6 the position limit measured against it.

DAO Governance

The governance phase in which token holders exercise authority through the proposal and voting process, subject to Timelock Execution, the Governance Authority Matrix, and core system invariants. DAO abbreviates decentralized autonomous organization.

Decentralized Exchange (DEX)

A trading platform that runs entirely on a blockchain and lets users trade directly with one another, with no company in the middle, no one holding their funds, and no order book of standing offers to match against.

Deterministic Routing

The automated allocation and distribution of tokens or value according to predefined Smart Contract logic, without discretionary redistribution. What the term fixes is the split percentages and the destination addresses, which are held in the shared fee configuration rather than chosen per transaction. Not every fee path reaches that configuration: the content-upload registry forwards what it collects to a single configured address, and the per-action fee paid on Ethereum for a gasless action on Base is swept whole to a single owner-set treasury address rather than divided. Nor does the term mean that every component pays out at the instant value is received. §8.2, §6.4 and §14.5 state which paths and components those are and why.

Encrypted Payload

Message content encrypted for confidentiality between authorized participants by the sending application and submitted on-chain in that encrypted form; the contracts record what they are given and do not themselves check that it is encrypted. Confidentiality covers the content of a message rather than its context. §9.1 sets out what the context includes and where the boundary falls, and §14.6 the exposure following from it.

Epoch

A discrete time period used for accounting or reward emissions within the protocol. How each such period is bounded is determined by the mechanism that uses it rather than by a common rule: in the staking contract an Epoch runs from a start time written into a pool's schedule until the next start time in that schedule, at whatever spacing that schedule sets, the last running without end; and in the airdrop and referral contract an Epoch has no set length, ending only when an owner or governance call starts the next one.

ERC-20

The Ethereum standard for fungible tokens, meaning tokens whose units are interchangeable with one another as one dollar is with another. The standard fixes the functions a token must provide, so that any wallet or exchange supporting it can handle any such token.

Executive Multi-Signature Authority

The structured governance phase following initial deployment in which protocol authority is exercised collectively, under the Governance Authority Matrix, through a multi-signature mechanism requiring several named key holders to approve an action before it can execute. A live read on 11 September 2026 found the deployed multi-signature wallet configured with a single owner and a requirement of one confirmation, that owner being the key that holds the owner role on the core contracts, so the collective approval described here is a design end-state rather than a present configuration. §7.4 records the administrative routes that operate alongside that phase and admit an owner acting alone.

Fixed Supply Invariant

The permanent and immutable cap on total token supply established through the Genesis Mint: no configuration function or governance proposal can increase total supply beyond this amount. §6.1 states the mechanism that fixes it, and §12.1 the upgrade qualification that attaches to it.

Genesis Distribution

The allocation of the 1,000,000,000-token immediately-circulating portion of the Genesis Mint across eleven Program Wallets in fixed percentages, executed in the mint transaction itself. What is settled at that point is the split rather than the tokens themselves, which carry no vesting; §6.5 states what governs them afterwards. Distinct from the Reserve Vault's 6,000,000,000-token non-circulating portion, which the split does not reach. See §6.2 and Appendix A §3.2.

Genesis Mint

The single event, occurring upon protocol deployment, in which one hundred percent of total supply is created and allocated in accordance with contract logic.

Governance Authority Matrix

The defined framework governing which entities or mechanisms may exercise specific protocol authorities at each phase of Governance Transition, before and after DAO activation alike.

Governance Transition

The progression of protocol authority from initial deployment control to Executive Multi-Signature Authority and ultimately to DAO Governance. Its completion is a design end-state rather than a contract guarantee; §7.1 states what governs its timing and §7.6 what Immutable Finalization does settle irreversibly.

Immutable Finalization

The irreversible contract state, reached by on-chain execution, in which a contract's upgrade pathway is settled and the configuration functions gated on that state can no longer be called. Upgrade authority is settled in one of two patterns: it either closes for every party, or passes to the governance address and permanently excludes the owner. Which pattern applies is a property of the implementation in force when finalization occurs rather than one fixed at deployment, since that implementation may be replaced until then; LiquidityPool moved from the first pattern to the second by an upgrade in July 2026. What finalization settles is upgrade authority rather than administrative control generally, since a locked function that has a governance-gated counterpart commonly remains callable afterwards. Finalization reaches none of the four core economic invariants. §7.6 states the full effect, §12.3 the invariants, and §14.1 the exposure that upgradeability creates.

Integrity Commitment

A cryptographic commitment derived from an Encrypted Payload, meaning a short fingerprint computed from it that cannot be worked backwards to recover the message. It enables independent verification of message existence and timing without revealing content.

LP Token

A token issued to whoever deposits assets into an Automated Market Maker pool, representing their proportional share of that pool and redeemable for the assets underlying it. §6.9 describes the farming contract that accepts one as a deposit.

Oracle

A service that supplies a contract with information from outside the blockchain, which it has no way of fetching for itself, such as price data, performance metrics, or reference rates. This document refers to a configured oracle as a price feed, which is the term the sections below use. §14.1 states what a consuming contract does where the feed is stale and where no feed is configured at all.

Program Wallet

A purpose-specific wallet designated to receive protocol allocations under Deterministic Routing rules and governance-approved parameters. What is enforced on-chain is the routing that places value at such a wallet; moving value onward from one is an operational action rather than a code path, as §6.4 and §14.5 record.

Reserve Fund Wallet

A separate operational or emergency liquidity wallet, distinct from the Reserve Vault, maintained for treasury operations and contingency needs. It holds no part of the non-circulating reserve and releases no scheduled unlock; it is instead one of the eleven Program Wallets across which allocations are distributed (§6.3).

Reserve Vault

The time-locked custody contract that holds the 6,000,000,000-token non-circulating reserve established at genesis. Scheduled triennial unlocks under the Time-Based Issuance Model are the designed and default release path (§6.3), and §6.6 states the one exit off that schedule. Mechanically distinct from the operationally-separate Reserve Fund Wallet.

Smart Contract

Code deployed on a blockchain and running exactly as written, governing how protocol state changes, enforcing constraints, and executing transactions according to predefined logic rather than anyone's discretion. Most USSE contracts are deployed behind universal upgradeable proxy standard (UUPS) proxies and are therefore replaceable in place; a minority are not upgradeable at all. §14.1 states what each case means and the exposure it creates, and each Smart Contract Appendix's §12 states the upgrade pattern of the individual contract.

Time-Based Issuance Model

The deterministic mechanism by which non-circulating supply held in the Reserve Vault enters circulation through scheduled unlock events. Scheduled release is the designed and default path. The reserve has one exit off that schedule, described in §6.6, and it does not alter the Fixed Supply Invariant.

Timelock Execution

The delay mechanism applied to a governance proposal before it may execute, giving participants time to see it and respond before contract-level enforcement occurs. The delay is measured from the moment a proposal is created rather than from the moment it passes, so it does not describe an interval between approval and execution. See §7.3 and Appendix F §3.6.

Treasury System

The structured framework governing custody separation, accounting, and financial routing within the USSE protocol. That separation is one of authority rather than of address. §8.1 and §12.4 state what follows from that, and §8.3 the recovery powers that sit outside the routing.

Triennial Unlock Cadence

The three-year interval schedule governing release of predefined supply tranches from the Reserve Vault under the Time-Based Issuance Model. The tranche size and the interval are compile-time constants of the vault implementation. §6.3 states the limits on the schedule's anchor date and what may delay a release.

3. Overview

USSE is one token and three service layers, held together by two things they share. The token is an ERC-20 asset on Ethereum whose supply was created once, at genesis, and enters circulation on a published schedule, on the terms §6 states. The service layers are confidential messaging, public identity and social publishing, and a digital asset marketplace; each is a separate set of contracts with its own users and its own failure modes, and the sections below take them one at a time. What makes them a single protocol rather than three is the fee configuration and the governance authority they hold in common.

The layers converge on one fee configuration. The destination wallets and the split percentages a fee is divided against are held in one FeeManagement contract on each chain rather than in each contract, so a fee arising in one layer reaches the same destinations as one arising in another, where the contract taking it is wired to that configuration. The Ethereum and Base copies share no storage and are written separately; a live read on 11 September 2026 found them holding identical percentages and destinations, and that agreement is live state rather than a property of the code. §8 sets out what it governs, what falls outside it, and the recovery powers that reach funds after they arrive.

Authority converges in the same way. The deployed contracts answer to one governance regime rather than to a separate one per layer, and it is moving through a defined transition from deployment control toward decentralized governance; until that transition completes, the administrative routes rather than the voted one are the ones in use. §7 sets out the phases and what each admits. No governance function can create supply, enlarge a tranche or shorten the release interval, which §12 states as an invariant, although governance can migrate the reserve off the schedule and, once the Reserve Vault is finalized, replace its implementation, as §6.6 and §12.3 describe.

The protocol runs on two chains rather than one, and the layers are divided between them: the token, the reserve and the treasury on Ethereum, the digital asset layer on Base with its sale payments escrowed and settled on Ethereum, and the identity, social and messaging layers split across both. §4.7 states the principle behind that division, §5.6 the bridge mechanism for the token, which is deployed on Ethereum alone, and §11.3 how a marketplace sale crosses between the chains.

Two elements cut across all of it. A single registry records a compliance tier for each account and holds one sale stage; the token contract and the sale contract consult it, and it reaches none of the economic rules. And implementation detail for the deployed contracts, including addresses and per-contract limits, is set out in Appendix A through BF, issued as a companion contract reference manual, rather than in this document.

4. Design Philosophy

USSE is built on the principle that durable digital infrastructure requires enforceable constraints rather than discretionary flexibility. The protocol prioritizes structural invariants, bounded authority, and deterministic execution over adaptability that could compromise long-term predictability.

The system is engineered around the following doctrines:

4.1 Constraint at the Configuration Surface

Economic parameters, issuance mechanics, and governance authority are deliberately limited at the protocol level. Flexibility that could introduce discretionary supply expansion or opaque financial routing is excluded at the level of the configuration surface, which exposes no function that creates supply beyond the Genesis Mint and routes protocol fees to destinations fixed in advance rather than chosen per transaction. The exclusion of unilateral control is a design end-state rather than a present condition: §7.4 and §14.2 record the administrative authority in force during the transition period, and §14.1 the upgrade authority underlying it.

4.2 Separation of Duties in Code

Custody, authorization, and accounting functions are partitioned across distinct contracts and execution paths, so that policy definition, control of assets, and the recording of outcomes are held as separate authorities rather than merged in one component. That separation is one of authority rather than of address, and further qualifications belong with it: those §12.4 states, and one concerning a single destination: the Operations destination is fixed, by a constant compiled into both FeeManagement and TreasuryContract, to the same address that holds the owner role on the token contract, the Reserve Vault, FeeManagement and TreasuryContract, so the key that administers those contracts also receives directly the Operations genesis and triennial shares and the Operations share of each divided fee, which is 30% under the split configured on both chains on 11 September 2026. Authority boundaries are enforced programmatically rather than procedurally, which governs how an action executes rather than which parties may invoke one; on that see §7.4.

4.3 Immutability of Core Economic Guarantees

The Fixed Supply Invariant, Genesis Mint, Time-Based Issuance Model, and Triennial Unlock Cadence are structural conditions rather than governance parameters: none is held as one, and no configuration function reachable by governance writes any of them. Two qualifications belong alongside that. Upgrade authorization is a separate question and does not resolve the same way for all four, so what Immutable Finalization settles differs between the token contract and the Reserve Vault; §12.3 states the difference in full. And the issuance model fixes what may be released and in what amount rather than guaranteeing when, the anchor, pause, and off-schedule migration qualifications being set out in §6.3 and §6.6. Economic predictability is treated as a structural invariant rather than a governance variable.

4.4 Deterministic Routing

Value entering the ecosystem follows Deterministic Routing. The destination addresses and, except for token sale proceeds, the split percentages are fixed in the shared fee configuration rather than chosen per transaction; the sale contract divides its proceeds by percentages compiled into it. Two paths forward outside that split: the content-upload registry, as §11 records, and the per-action fee paid on Ethereum for a gasless action, which its collecting contract sweeps whole to a single owner-set treasury address. Key registration would be a third on a registry with no fee configuration set, which pays its fee whole to a single treasury wallet; the Base key registry was in that state until 30 September 2026, and both key registries have paid through the split since. Each allocation is recorded as it accrues rather than pooled for discretionary redistribution after collection. Payment is a separate question from accrual, and the components that settle later than the moment of receipt are stated where they arise: §8.2 states the token contract's trading fee and the fee taken by the protocol's own Automated Market Maker, and §6.4 and §14.5 the allocation categories funded by operator action rather than by a code path.

4.5 Integrity Anchoring Without Content Exposure

The messaging architecture separates Encrypted Payload handling from Integrity Commitments recorded through Anchoring Events. This allows confidentiality to coexist with durable proof of coordination, on the terms §9.2 and §9.4 state: the recording contracts expose no path that alters a commitment, a commitment is held on-chain in contract storage and, on the Layer 2 message bus and for batch roots on the Layer 1 anchor, in the emitted event as well (the Layer 1 anchor's per-message receipt stores its commitment without emitting it), and the metadata asserting that a batch was anchored to Ethereum is an assertion an approved submitter may write again.

4.6 Compliance-Aware Architecture

Compliance is held as a bounded capability in one contract rather than distributed across the system, and naming what enforces it is more useful than describing it in the abstract. A single registry classifies accounts by tier and holds one sale stage, and the token contract and TokenSale enforce against that classification rather than each keeping a policy of its own. What that surface reaches is bounded by design: no function it exposes writes the Fixed Supply Invariant, the Genesis Mint, the Time-Based Issuance Model, the Triennial Unlock Cadence, or a recorded Integrity Commitment, so regulatory alignment operates alongside the economic and integrity guarantees rather than over them. Enforcement is conditional on configuration rather than on deployment; §15.6 states those mechanics, and §15.4 and §15.5 the offering-side framing that sits alongside them.

4.7 Deployment Across Two Chains

The protocol is deployed across two chains rather than one, and what sits where follows the cost of the action it supports: the digital asset layer is on Base because transaction costs there are low enough to make on-chain metadata and media storage practical. §3 sets out which layer sits where. Two consequences belong with the choice. The chains share no storage, so a contract deployed on both maintains two independent records, which §10 states for names and for organizations. And every crossing between them is a mechanism rather than a property of the design: §5.6 states the bridge mechanism for the token, which is deployed on Ethereum alone and has no deployed counterpart on Base, §11.3 how a marketplace sale paid on Ethereum is delivered on Base, §9.3 how a record made on one is committed to the other, and §7.4 the relay through which governance authority reaches the Base side.

This philosophy reflects a deliberate preference for bounded authority, procedural governance, and immutable guarantees as prerequisites for long-term institutional credibility.

5. System Flows

The USSE ecosystem is designed around a small number of deterministic system flows that govern how supply, value, authority, liquidity, and data move through the protocol, and how the token itself is taken into and released from bridge custody, the token being deployed on Ethereum alone. These flows define the interaction between contracts and wallets without requiring investors to evaluate individual implementations. Each flow is enforced by contract logic at the point value or authority moves, and recorded on-chain for independent reconciliation. Some flows depend on an off-chain step, among them Encrypted Payload handling, message batching, and cross-chain anchoring. Where they do, the contracts enforce the integrity of what is submitted to them rather than that submission occurs, as §14.5 records.

Figure 1: USSE System Architecture Overview

GOVERNANCE LAYER

Executive Multi-Signature Authority DAO Governance Proposal → Vote → Timelock Execution → Execution

CORE PROTOCOL ENFORCEMENT LAYER

UnitedStatesSecuredExchange Token Contract Reserve Vault Treasury System Liquidity and Incentive Modules NFT Marketplace and Digital Asset Contracts Identity and Social Infrastructure Contracts Layer 1 and Layer 2 Anchoring and Cross-Chain Relay Contracts

PROGRAM EXECUTION WALLET LAYER

Staking Rewards Wallet Airdrop and Incentive Wallet Liquidity Wallet Treasury Operations Wallets

EXTERNAL INTERFACE LAYER

Users and Token Holders Institutions and Enterprises Liquidity Venues Off-Chain Encrypted Messaging Engine

This architecture illustrates structural separation between governance authorization, deterministic protocol enforcement, program-level execution, and external interaction. Governance defines policy within explicitly bounded authority. The proposal, vote and timelock sequence shown in the governance layer is the deployed route rather than the operating one, as §5.3 records. Core protocol contracts enforce supply constraints, reserve isolation, financial routing, and data integrity through deterministic logic that no participant can set aside on a case-by-case basis, other than through the governance-held reserve migration and treasury recovery functions named in §12.3 and §12.6; what stands behind that logic is the upgrade authority described in §14.1 and in the qualification opening §12. Program execution wallets receive allocations under those rules, and what leaves such a wallet afterwards is an operational action rather than a code path (§14.5). External interfaces interact with the system without direct control over enforcement mechanisms. Authority boundaries are enforced by Smart Contract architecture rather than discretionary intervention, consistent with the Core System Invariants set out in §12.

5.1 Supply Flow

USSE supply is created exclusively through the Genesis Mint and is permanently constrained by the Fixed Supply Invariant. The Genesis Distribution places a portion of that supply in immediate circulation, while the remainder is held in the Reserve Vault. Tokens held in the Reserve Vault enter circulation under the Time-Based Issuance Model and Triennial Unlock Cadence, subject to the qualifications set out in §6.3 and §6.6.

5.2 Value Flow

Economic value enters the ecosystem through the fees charged for use of the protocol, the proceeds of token sales, and other on-chain revenue sources. Each is allocated by contract logic to destinations fixed in advance rather than chosen per payment, on the terms §2 defines and §8.2 sets out. Custody of funds is held as an authority separate from accounting and reporting rather than at a separate address, and §12.4 states the qualification belonging with that. This value flow makes revenue traceable and purpose-bound under on-chain policy at each point a contract applies it.

5.3 Governance Flow

Governance authority progresses through the Governance Transition. Initial deployment and stabilization occur under restricted administrative control, followed by the Executive Multi-Signature Authority and ultimately DAO Governance. Actions taken through the proposal process follow a proposal, vote, delay, and execution lifecycle, with Timelock Execution and quorum requirements. That route is deployed but dormant: proposal creation and voting revert until the DAO activation date recorded in §7.1, so the administrative routes described in §7.4 are the only ones that operate at the date of this document. Once a contract has reached Immutable Finalization, upgrade authority over it is settled irreversibly in one of the two forms §7.6 states, while the spending policy held in the program wallet registry stays adjustable, through the owner's own setters and through governance mirrors, neither of which finalization closes. That policy covers the daily limit, the authorized-spender set, the approvals count, the per-wallet kill switch, and the pause, as §8.2 records. It binds only spending routed through that registry: a live read on 11 September 2026 found no wallet registered with it, and the eleven allocation destinations are externally-owned accounts whose own keys move their balances without reference to it.

5.4 Liquidity Flow

Liquidity allocation follows predefined routing and governance-constrained deployment parameters enforced on-chain. Tokens allocated for this purpose are deployed through decentralized and centralized venues under defined controls, with protocol-owned positions held separately from user liquidity and their cumulative deployment counted on-chain. Those counters measure deployment over the deploying contract's lifetime rather than an outstanding position, and no on-chain breakdown by purpose exists; Appendix U §3.1 states both. One of those decentralized venues is the protocol's own Automated Market Maker, deployed on Ethereum: non-upgradeable, charging a swap fee of 0.33%, and open to permissionless pair creation. §14.1 states the exposure its non-upgradeability creates. Separately from those positions, the protocol's Automated Market Maker can mint to a protocol fee recipient a share of approximately one sixth of the swap fees paid on each pair its factory created, whoever supplied that pair's liquidity; that share accrues as LP Tokens, settles when a collection call redeems them rather than on each trade, and is then distributed to the same destinations as other protocol revenue, as §8.2 records. It accrues only while the factory's fee recipient is set; that recipient has been the protocol's fee splitter since 12 September 2026, and nothing has yet accrued to it, the registered pair holding no liquidity. The fees earned by the protocol's own positions are not routed: they remain in the value of the LP Tokens the protocol holds.

5.5 Messaging and Data Integrity Flow

Encrypted Payloads are handled in scalable execution environments, while Integrity Commitments are recorded through Anchoring Events. This design provides tamper-evident verification of message integrity and timing without exposing message content. Authenticated wallet-to-wallet and group communication rely on this data integrity flow for durable, verifiable coordination. The dependency does not run the other way: no fee ledger, supply figure, governance tally, or compliance decision in the deployed system depends on a message having been sent. Governance's relationship to this layer is that it configures the operational parameters described in §9.4, not that it consumes what the layer records.

5.6 Cross-Chain Transfer Flow

USSE is deployed on Ethereum alone, and so is the bridge adapter through which it is bridged: no USSE token contract and no counterpart adapter is deployed on Base or on any other chain, so the mechanism described below takes tokens into, and releases them from, a single custody balance on Ethereum rather than moving them to a deployed representation elsewhere. An outbound transfer may be initiated by any holder while the bridge is unpaused: the tokens are taken into the custody of a dedicated treasury contract, and the transfer is assigned an identifier, derived from its parameters and a counter that rises with each transfer that sender makes, for an off-chain relayer to act on. A relayer is a service running outside the blockchain rather than a contract deployed on it. An inbound transfer is completed by releasing tokens from that same custody balance to a named recipient, on the authorization of an approved relayer or of the contract owner, and a given identifier can be completed only once. The flow is authorization-based rather than proof-based: no cryptographic proof of the source-chain event is verified on-chain, so a bridged position depends on the operational security of the relayer and owner keys rather than on contract logic. §14.1 states that trust model and its present bounds in full, and Appendices AD and AE set out the mechanism.

6. Tokenomics

USSE tokenomics are structured to provide long-term supply predictability, transparent issuance, and disciplined circulation growth under the Fixed Supply Invariant. The token supply is fixed through the Genesis Mint and governed exclusively through deterministic on-chain mechanisms. The deployed token contract exposes no discretionary minting authority at any stage of the protocol lifecycle; §6.1 states the upgrade qualification that attaches to that claim.

Supply movement and issuance timing are enforced by Smart Contracts and recorded through immutable on-chain events, supporting institutional planning horizons and independent verification. Allocation routing is enforced on-chain at the point a contract performs it: the triennial split described in §6.3 is applied by the Reserve Vault against percentages held in FeeManagement. Several allocation categories are nonetheless funded by operator transfer rather than by an automatic code path, as §6.4 and §14.5 record.

6.1 Fixed Supply and Genesis Mint

The total supply of USSE is permanently capped at 7,000,000,000 tokens through the Fixed Supply Invariant and created exclusively through the Genesis Mint. One hundred percent of total supply originates from the Genesis Mint: the genesis call is single-use and the token contract declares no other minting function. One qualification attaches to that guarantee, and §12.1 states it: until the token contract reaches Immutable Finalization it remains upgradeable by the owner key, and finalization closes that authority for every party rather than passing it to governance. Subject to that qualification, the design removes discretionary issuance as a source of inflation risk and provides a stable supply foundation for long-term valuation and governance.

6.2 Circulating and Non-Circulating Supply

The Genesis Distribution places 1,000,000,000 tokens, representing approximately 14.3% of total supply, in immediate circulation. The remaining 6,000,000,000 tokens are held in the Reserve Vault in a non-circulating state. Tokens held in reserve enter circulation through the scheduled releases described in §6.3, and are otherwise movable only by the extraordinary transfer described in §6.6.

Non-circulating supply remains visible on-chain at all times and is subject to the same auditability and reporting guarantees as circulating tokens. This distinction between circulating and non-circulating supply is intended to provide transparency while preventing premature or discretionary release.

6.3 Time-Based Issuance Model

Supply enters circulation through the Time-Based Issuance Model, which releases reserve tokens through scheduled unlocks under the Triennial Unlock Cadence. Each unlock releases 100,000,000 tokens at a fixed interval of 1,095 days, three years of 365 days each, enforced by Smart Contract logic. Sixty scheduled unlock events cover the complete reserve supply over an issuance schedule of approximately 180 years; because the interval ignores leap days, release dates drift earlier than calendar anniversaries, and under the present anchor the first falls on 4 July 2029 and the sixtieth on 23 May 2206.

The tranche size and the interval are compile-time constants that no configuration function or governance proposal can enlarge, and the release call is permissionless, so any party can trigger a release once it has come due. A due release completes only if the fee configuration contract the vault reads responds and the token contract accepts each of its transfers under the rules described in §15.6. Three qualifications belong alongside that guarantee. The schedule's anchor date may be re-set by the owner, but only while the contract remains un-finalized and no tranche has yet been released, and only to a date that keeps the first tranche in the future. Those limits bound the anchor in one direction only: the earliest anchor they admit lies one interval before the moment of the change, so the first tranche can be brought forward to no earlier than that moment, and they set no ceiling on how far it can be pushed back, so before the first release the owner may defer the whole schedule without limit and may later bring a deferred schedule forward again under the same rule. The vault may also be paused, which halts scheduled releases; a pause is bounded at ninety days per call and lapses of its own accord at expiry, so holding releases closed requires a fresh call every ninety days rather than a single indefinite halt. And the reserve has one exit off the schedule altogether, set out in §6.6. None of the three creates supply or alters the Fixed Supply Invariant, and Appendix C states each in full.

One further qualification is of a different kind and belongs with the constants rather than with the schedule: because the tranche size and the interval are compiled into the vault's implementation rather than held in storage, they are bounded by that contract's upgrade authority, which passes to the governance address at Immutable Finalization rather than closing. See §12.3 and §14.1.

This approach fixes the size of each release and the interval between them, so circulation grows in known increments rather than through discretionary issuance decisions. What the qualifications above reach is when those increments begin and whether one is delayed. The size of an increment can change only through an upgrade of the Reserve Vault or a replacement fee configuration contract whose percentages total less than one hundred, since the vault checks only that a release does not exceed a tranche.

The schedule's long horizon aligns token availability with measured ecosystem growth and sustained operational funding rather than short-term market dynamics.

Each tranche of 100,000,000 tokens is routed through the following allocation categories at the time of release, as enforced by the FeeManagement Smart Contract:

Those eleven shares are stored values in FeeManagement rather than constants compiled into it, and the distinction matters to anyone modelling a future tranche. Before Immutable Finalization the owner may rewrite all eleven in a single call, and afterwards a mirror gated to the governance address alone may still do so, that mirror carrying no finalization gate. Any rewrite must total one hundred percent and must leave the Founder share at or above 2%, the Advisor share at or above 1%, and the Operations share at or above 1%, those three floors being constants compiled into that contract. They bind a rewrite of FeeManagement's own values rather than the split a tranche follows: the vault reads its percentages from whichever FeeManagement its pointer names, a pointer §6.5 describes, and itself enforces only that no tranche pays out more than the tranche. The remaining eight shares, the 45% Treasury share among them, carry no floor. The genesis percentages in §6.4 are of the other kind: they are compiled into the token contract and were applied once, in the mint transaction itself.

6.4 Allocation Categories and Funding Intent

Tokens entering circulation are routed through designated Program Wallets that correspond to defined allocation categories. These categories support protocol operations, liquidity provisioning, ecosystem incentives, governance functions, and long-term sustainability initiatives.

The initial allocation of the 1,000,000,000-token circulating genesis supply across designated Program Wallets is as follows:

Allocation categories and routing rules are enforced on-chain and are designed to separate custody, execution, and accounting responsibilities. This separation enables transparent reconciliation and reporting. It separates responsibilities between contracts rather than between parties: during the transition period one owner address controls the contracts concerned, as §7.4 records.

Detailed wallet addresses and routing logic are specified in the Smart Contract Appendices rather than duplicated here; §4 sets out the principles and constraints under which those allocations operate.

An allocation category names a destination and a share. It does not name a Smart Contract, and three categories share a name with a contract whose relationship to the allocation is worth stating precisely, because the shared name invites an assumption the deployment does not make.

• CEX Listing. CEXListing (Appendix Y) registers exchange listings and pays vested USSE and ETH allocations to whitelisted exchange deposit addresses from balances transferred to it, under an aggregate cap of 50,000,000 USSE across every listing. That cap bounds what may be allocated to listings, not everything the contract may pay out: a separate recovery function, reachable by the governance address and, until Immutable Finalization, by the owner, transfers any token the contract holds, USSE included, to any address in any amount, outside the cap, the allowlist and the allocation timelock. Nor is the cap the size of the allocation category. Whether the destination FeeManagement holds for the CEX Listing share is this contract or a CEX Listing Program Wallet is a deployed configuration value rather than a property of the design, and the two should not be assumed identical.
• Airdrop. The Genesis Distribution's Airdrop share and the Triennial Airdrop share are both paid to the Airdrop Program Wallet. AirdropAndReferral (Appendix AC) sits at a different address and receives neither automatically: its claim budgets are set directly by owner or governance, and its distribution pool arrives only by transfer from an outside holder. Funding that contract from the Airdrop Program Wallet is an operational action rather than a code path, and the contract's spending capacity is bounded by the balance it has actually been sent.
• Staking Rewards. This share funds incentive emissions from the Staking Rewards Wallet. Staking (Appendix AA) additionally determines what governance measures: once GovernanceContract is pointed at it, total staked principal is the basis every proposal under the open-participation model is measured against, and a voter's staked principal is their weight, as described in §7.3; while no stake exists, no such proposal can be created. At the date of this document GovernanceContract holds no staking reference, so staking has no effect on governance until one is configured. Where it is configured, staking participation bears on governance weight as well as on reward accrual, and the two effects are not separable.

One destination appears in the two tables under different names. The genesis Token Sale share and the triennial Treasury share are both paid to the address FeeManagement holds as its treasury destination, the token contract minting the first to it and the Reserve Vault sending the second to it, so the two tables address the same eleven destinations and differ in the percentages and, for that row, in the name. Whether that address holds a token-sale wallet or the treasury is a deployed configuration value, on the same basis as the CEX Listing share above.

6.5 Allocation Vesting and Release Controls

The Genesis Distribution is executed by the Genesis Mint directly to the Program Wallet destinations recorded in FeeManagement. No contractual vesting is applied at that moment: the table in §6.4 records where tokens are placed, not a schedule under which they become transferable. Three separate controls govern what happens afterwards.

Destination locking. The Founder, Advisor, and Operations destination addresses are fixed to compile-time constants and cannot be changed by any administrative call. TreasuryContract and FeeManagement each reject a wallet update that does not preserve those three addresses. That settles the recipients within those two contracts, but not for the triennial tranches: the Reserve Vault reads every destination from whichever FeeManagement contract its own pointer names, and that pointer may be replaced by the owner until the vault reaches Immutable Finalization and by the governance address alone at any time. A replaced pointer names all eleven destinations, the three locked ones included, and the floors described in §6.3 do not bind it. The lock binds the configuration surface rather than the constants themselves, which are bounded by each contract's upgrade authority, and the two resolve differently: TreasuryContract's closes at Immutable Finalization for every party, while FeeManagement's passes to the governance address instead of closing. §8.4 records the same limit on the allocation floors.

Contractual vesting. TokenVesting (Appendix T) provides per-beneficiary schedules on Ethereum, each carrying a cliff, a linear vesting duration, and a single named beneficiary who alone may claim against it. Schedules are written by the registered multi-signature address and are funded by escrow rather than by draw: USSE must already be held by the contract, and a schedule may be created only where the contract's uncommitted balance covers it in full, which prevents one schedule being backed by tokens already committed to another. A schedule created as revocable may be ended by that same multi-signature address, paying the beneficiary whatever has vested at that moment and returning the remainder to the treasury address the contract holds. Creating and revoking a schedule both close at the contract's Immutable Finalization, while a beneficiary's claim does not.

Present state. Whether a schedule exists is readable on-chain rather than inferred from this document. nextScheduleId counts the schedules ever created and is incremented only when one is created, so it returns zero while none has been created; the contract's USSE balance shows what has been transferred in to back them. As at the date of this document neither has moved from zero. While that remains so, on-chain vesting is a capability of the deployed architecture rather than a constraint binding any allocation category, and what binds a specific allocation is the lockup the applicable offering documents impose rather than this contract. Any restriction on resale arising under applicable securities law is separate again, addressed in §15.6.

6.6 Reserve Custody and Isolation

The Reserve Vault functions as a constrained issuance vault: it is visible on-chain at all times, does not conduct market operations, and does not fund programs outside of enforced release logic.

The reserve leaves the vault by exactly two routes. The first is the scheduled release described in §6.3. The second is a migration function that transfers the entire remaining reserve in a single call to an address the caller names; it is reachable only by the governance address, expressly excluding the contract owner, and it validates that destination only against the zero address. A recovery function for foreign tokens sent to the vault in error exists alongside these, but it refuses the reserve token itself and so is not a third route. Both routes are properties of the deployed implementation rather than of the address: until the vault reaches Immutable Finalization the owner may replace that implementation in a single call, without a vote or a delay, and afterwards the governance address may, so the migration route's exclusion of the owner does not extend to the upgrade route before finalization (§12.3, §14.1). Whether the migration route is presently reachable turns on whether a governance address has been configured on that contract, which is live state rather than a property of the code; Appendix C's §3.4 and §11 set out both the mechanism and that dependency. One consequence is worth naming: the token contract computes Circulating Supply as total supply less the balance standing at the Reserve Vault address it points at, so a migration that moved the reserve without also repointing that address would count the whole remaining reserve as circulating from the moment it completed.

6.7 Deterministic Routing of Released Supply

Each scheduled release follows the predefined routing rules enforced on-chain and set out in §6.3. Released tokens are directed through designated Program Wallets before being utilized for operational, liquidity, or incentive purposes, so newly circulating supply enters the ecosystem through controlled and auditable pathways rather than through direct reserve injection into markets. What is enforced on-chain is the routing that places tokens at those wallets; moving them onward is an operational action, bound by the program-wallet registry's policy only where a wallet is registered and the movement is routed through it, and otherwise by the key that controls the wallet, as §8.2, §6.4 and §14.5 record. All release events and subsequent transfers are recorded as immutable on-chain events, preserving continuous transparency into supply movement.

6.8 Tokenomics and Governance Boundary

Tokenomics mechanics operate within clearly defined governance boundaries. The Fixed Supply Invariant, Genesis Mint, Time-Based Issuance Model, and Triennial Unlock Cadence are not governance parameters, so no configuration function or proposal governance may execute can create new supply, accelerate issuance, move the release schedule, or expand tranche size. Within governance's reach, the bounded pause described in §6.3, which governance shares with the owner, can hold a due release closed for up to ninety days per call without moving the dates of later tranches. Three further functions bear on timing without that bound: replacing the fee configuration contract the vault reads, placing a lockup on the vault address through the compliance registry, and the reserve migration described in §6.6, after which no scheduled release can be made. The tranche size and the interval are compile-time constants of the Reserve Vault implementation rather than stored values. Those bounds are properties of the deployed implementations, and the upgrade authority standing behind them differs by contract; §12.3 states which of those invariants it closes to governance and which it does not. Any extraordinary Reserve Vault transfer can be made only by the vault's governance address, which the vault does not require to act through a proposal, vote or delay; such a transfer does not alter the Fixed Supply Invariant, but the Triennial Unlock Cadence no longer applies to the tokens it moves.

Governance processes may adjust certain policy-level parameters related to allocation usage and program behavior. §7 describes the governance structure, the authority transitions, and the routes by which such an adjustment may be made.

That separation keeps supply creation and tranche size off the configuration and proposal surface governance operates on, leaves the timing of releases and the custody of the reserve within reach of the functions described above, and leaves governance to guide ecosystem evolution within it.

6.9 Incentive Program Contracts

The allocation categories in §6.3 and §6.4 name destinations and shares. Three deployed contracts hold the incentive programs those categories are intended to support, and this subsection describes what each contract is and what it holds. All three are deployed on Ethereum alone. None of them draws on an allocation through a code path of its own: the staking contract publishes a funding call gated to a configured wallet, the farming contract pays from whatever reward-token balance it holds, and the airdrop and referral contract distributes from a balance sent to it by an outside holder, as §6.4 records. What each program can pay is therefore bounded by what it has been sent, not by the percentage beside its name in the tables above.

Staking. The staking contract (Appendix AA) holds a registry of pools rather than a single program. On the deployed contract that registry is presently empty: no pool has been created and the reinitializer that seeds the first has not been run, so staking, claiming and the funding call described below all revert until a pool exists. Each pool carries its own reward rate expressed in tokens per second, an optional lock period, an early-withdrawal fee, an optional ceiling on the annualized reward rate, and separate flags for whether the pool is active and whether it is paused. While a position remains within its lock period its rewards cannot be claimed, and leaving early forfeits every reward it has accrued in addition to paying the fee on principal. A pool may also carry a schedule of dated Epochs, and where one is set the rate of the active Epoch replaces the pool's flat rate for accrual. Two compiled constants bound what any of those values may be set to: the early-withdrawal fee cannot exceed 20%, and the annualized rate ceiling cannot be set above 500%. The rate ceiling is one of the optional limits §14.1 describes, and it is bypassed rather than enforced both where it reads zero and where it reads the largest value its field can hold, which is the value every pool created through the pool-creation functions starts with; a ceiling binds only once one is set explicitly.

Reward tokens reach the contract through a funding call that accepts them from the address held in stakingRewardsWallet, although that gate governs the call rather than the reward balance: rewards are paid from whatever USSE the contract holds beyond staked principal, so a plain transfer from any holder funds them equally. No initializer, the setup call a contract runs when it is first deployed, writes that address. While it is unset the contract owner alone may deposit, and that remains true after Immutable Finalization; once a wallet is configured, finalization makes that wallet the only source. A wallet has been configured on the deployed contract since 30 September 2026.

The contract additionally holds three values described as bearing on governance rather than on rewards: a minimum continuous lock duration, a bonus to voting power earned by stake locked for at least that long, with the bonus itself bounded at 50% by a compiled constant, and a minimum staked amount below which the contract's own eligibility view reports an address as not qualifying as a governance participant. All three are written by a reinitializer, the equivalent call an upgraded contract runs, which substitutes documented defaults where it is passed zero, and by their own setters; that reinitializer has not been run on the deployed contract, where all three read zero. They are published through the contract's view functions, but no deployed contract consults them: GovernanceContract measures a voter by raw staked principal, without the bonus, and applies a minimum of its own, as §7.3 sets out.

Farming. The farming contract (Appendix AB) is a single pool that accepts one configured LP Token as a deposit and pays a distinct reward token at a per-block rate. Its accrual window is a block range whose start is set at initialization and remains re-settable, and whose end is optional: an end block of zero means the program does not close on its own. A lock period of zero means deposits are not locked, and where a lock is configured the compiled ceilings are 3,650 days on the lock and 20% on the early-withdrawal fee that an early exit pays; no reward can be claimed while the lock runs, and an early exit also forfeits every reward the deposit has accrued. One property belongs with any description of the program and is a matter of the contract rather than of its configuration: where the reward balance held by the contract is smaller than the amount a claim has accrued, the transfer pays out the balance that is there rather than reverting, and the unpaid remainder is recorded as owed to that depositor and claimable through a separate call once the balance is replenished, so an underfunded pool defers payment rather than failing visibly.

Airdrop and referral. One contract (Appendix AC) carries two distinct programs. The first is a one-time claim per address, which the owner or the governance address may reset to admit a further claim, optionally naming a referrer who is paid a separate amount at the same time. The second is a referral-code program in which a code is committed to chain as a hash, then redeemed by another address against a fee denominated in United States cents. That figure is converted to ETH through a price feed where one is configured, as one has been since 30 September 2026, and at a fixed rate compiled into the contract where none is, which is the case §14.1 describes; where the fee itself is unset, as it is at the date of this document, the amount required is zero and redemption is free. Fees collected on the second path are routed through FeeManagement on the same basis as other protocol fees, the contract having pointed at it since 30 September 2026, falling back to a configured treasury address where FeeManagement is unset and remaining in the contract, recoverable by a governance sweep, where neither is set. The referee payment, the redemption fee, and the price feed are written by a reinitializer and by their own setters, and by no earlier initializer.

Two properties of that contract are worth stating precisely, because each is easy to read as its opposite. The first is that its Epoch budgets are accounting ceilings and not balances. Raising a budget authorizes further spending and moves no tokens; the tokens themselves arrive only by transfer to the contract address, so a funded budget and a funded contract are separate conditions and either can exist without the other. The second is that the two programs hold separate budgets whose zero values read in opposite directions. The claim path tests its budget on every payment, so a budget of zero blocks any claim that would pay a non-zero amount. The redemption path tests its budget only where the budget is non-zero, so a budget of zero leaves redemptions uncapped. §14.1 records the second of those among the limits that ship unwritten.

Properties the three share. Each is upgradeable behind a UUPS proxy, subject to §14.1. Each publishes governance-gated mirrors of its configuration, and no mirror on any of the three carries a finalization gate, so the governance route to the parameters those mirrors cover outlives the owner route, which finalization does close. The governance address itself is the exception on the farming contract: its only appointment function is governance-gated but closes at finalization, so from that point the farming contract's governance address is fixed. Not every owner-side function is mirrored, and the owner surface does not close uniformly either: the staking contract and the airdrop and referral contract gate every owner-side setter they publish on finalization except one reinitializer each, which carries no finalization gate and remains callable by the owner until it has been run once, and on the deployed contracts neither has been run; the farming contract keeps its pause, its unpause, its token recovery, and its treasury-reporter setter owner-callable afterwards. On all three the governance gate admits the contract owner as well as the governance address, so the mirrors are not exclusive to governance while both addresses are held by the same party; the one exception is the staking contract's own governance-appointment mirror, which admits the governance address alone. That exclusion does not reach the staking contract's unrun reinitializer, which also writes the governance address, admits the owner alone and carries no finalization gate, so while it remains unrun the owner could use it after finalization to appoint itself governance and thereby hold the upgrade authority described below as passing to governance. All three refuse to renounce ownership. One property does not hold uniformly and §12.3 governs it: upgrade authority over the staking and farming contracts passes to the governance address at Immutable Finalization, while upgrade authority over the airdrop and referral contract closes at that point for every party rather than passing to anyone.

7. Governance

Governance within the USSE ecosystem is designed to provide clear authority boundaries, enforceable constraints, and a defined Governance Transition from centralized deployment control to DAO Governance. The framework prioritizes system stability during early phases, and the passage of control to token holders is a design end-state rather than a contract guarantee: as §7.1 records, the activation date that opens the voting route is a stored parameter the owner may reset without bound in either direction until GovernanceContract is finalized, and §7.4 sets out the authority that operates until then.

Governance authority is intentionally limited in scope. Certain core economic and structural parameters sit outside that authority and cannot be modified through a proposal or a configuration call; §7.2 states that boundary, and §12.3 the separate question of upgrade authority over the contracts enforcing it. Within those limits governance functions as a policy and coordination mechanism rather than a source of discretionary control over supply or protocol fundamentals.

7.1 Governance Authority and Phases

During initial deployment and stabilization, governance authority is exercised under restricted administrative control. This phase exists to support secure contract deployment, system configuration, and early operational oversight. Authority during this period is intended for actions necessary to initialize and stabilize the protocol; no contract confines it to those actions, and until the contracts concerned reach Immutable Finalization it includes the upgrade authority that stands behind the fixed economic constraints, as §6.1, §12.1 and §12.3 state.

Following initial deployment, governance authority is designed to transition to an Executive Multi-Signature Authority; as of 11 September 2026 that transition had not begun, and no deployed contract named the multi-signature wallet as its governance address. This phase introduces collective oversight through a defined decision-making body operating under multi-signature controls and procedural safeguards. Executive governance is responsible for supervising protocol operations, enforcing policy constraints, and preparing the system for decentralized governance.

The final phase of governance transfers authority to DAO Governance. In this phase, governance decisions are made through token-based voting, subject to quorum requirements and execution delays, once the open-participation model described in §7.3 has been armed; until it is, the voted route admits only the contract's signer set. DAO activation and Immutable Finalization are distinct events with distinct effects: activation opens the voting route, while finalization is what irreversibly settles upgrade authority over a given contract. Once decentralized governance is active and the relevant contracts have reached Immutable Finalization, upgrade authority over each of those contracts either closes altogether or is exercisable only through the address holding governance authority, according to that contract's implementation, and in neither case can the deployer or any successor reinstate it through the finalized implementation. Whether that amounts to the exclusion of unilateral control depends on what that address is; §7.4 and §14.2 record the cases in which it resolves to a contract directed by a single owner. What finalization does to configuration authority is a separate question that does not resolve the same way everywhere: where a locked owner function has a governance-gated counterpart whose gate admits the owner as well as the governance address, the capability returns to the owner, as §2 states. §7.4 describes the position before that point and §7.6 describes what finalization does and does not end.

The DAO activation date is enforced on-chain by GovernanceContract's daoActivationDate parameter, set at genesis to July 4, 2029, and updatable pre-finalization by the owner (setDaoActivationDate) or post-finalization by governance itself (governanceSetDaoActivationDate); see Appendix F §6. Until that date arrives, proposal creation and voting both revert, so no proposal can be created, voted on, or executed through GovernanceContract at all, and the administrative routes described in §7.4 are the only ones that operate in the meantime. The two events also interact in one direction: the post-finalization setter for the activation date executes only as the payload of a proposal that has itself passed, and no proposal can exist before the date arrives, so finalizing GovernanceContract ahead of that date would fix the date until it arrives, after which only a passed proposal could change it.

7.2 Scope and Limits of Governance Authority

Governance authority is explicitly constrained. The Fixed Supply Invariant, Genesis Mint, Time-Based Issuance Model, and Triennial Unlock Cadence cannot be changed through governance proposals or voting outcomes: none of the four is exposed as a parameter any proposal can write. That constraint operates on the configuration and proposal surface; the separate question of upgrade authority over the contracts enforcing each invariant is addressed in §12.3.

Governance may adjust certain policy-level parameters related to allocation usage, incentive programs, operational configuration, and protocol-level settings, provided such adjustments remain within predefined contractual constraints. Governance actions taken through the proposal process are subject to the formal requirements described in §7.3 and are enforced through on-chain execution logic. The limits on what governance may change are enforced by contract logic irrespective of the route by which an action is initiated; the routes themselves are described in §7.3 and §7.4.

7.3 Governance Action Lifecycle

Governance actions taken through the proposal process follow a structured lifecycle designed to introduce transparency, deliberation, and delay between decision and execution. Each such action originates as a formal proposal that defines the intended policy change or action. This lifecycle governs the proposal route, which becomes available on the DAO activation date recorded in §7.1; §7.4 sets out the administrative routes that operate before then.

The form a proposal may take is constrained by the entry point through which it is raised. The governance facade publishes 108 proposal entry points, of which 106 encode a specific function and argument shape, so a proposal created through one of those can only ever call the function that entry point names. The remaining two are general-purpose and carry both the target and the encoded call from the proposer. In every case the address a proposal will act on is supplied when the proposal is created rather than fixed by the entry point, so the constraint operates on what may be called and not on where. A proposal raised through the facade is created in the name of the address that called it: the facade passes its caller to GovernanceContract, which accepts that call only from the facade address configured on it, applies to the caller the eligibility test a direct proposal meets, and records the caller as the proposer. That has been so since 18 September 2026; before then the facade proposed in its own name and, holding neither a signer place nor stake, could create no proposal. An eligible address may therefore propose either through the facade or by a direct call on GovernanceContract, once proposal creation opens on the DAO activation date recorded in §7.1.

A proposal is open to votes from the moment it is created until it is executed or cancelled. The contract sets no closing time for an individual vote, and the optional submission and voting windows it implements are switched off. Under the open-participation model, standard proposals require a participation quorum of 10% of the governance basis and an approval threshold of 50% of votes cast. Actions that modify governance structure or other structurally significant protocol parameters are intended to carry a supermajority approval threshold of 73%, but the tier is chosen when a proposal is created rather than derived from what it does: each specific entry point on the governance facade fixes one, while a proposal raised through a general-purpose entry point, or directly on GovernanceContract, carries whichever tier its proposer names. A minimum holding of 0.02% of that same basis is required both to submit a formal governance proposal and to vote on one, and no single voter may contribute more than 5% of the basis to any tally.

Those five figures describe the open-participation model, which is armed by a single owner call. That call sets the token and staking references, sets the quorum to 10%, and writes 0.02% and 5% in place of any zero it is passed; it can be made once, and it carries no finalization gate. A separate owner setter writes the same references and the two proportions without touching the quorum, and it will accept a zero minimum holding, in which case no minimum applies. Neither route can leave the per-voter cap at zero, which the contract would read as no cap. The model's state is readable on-chain, and the contract reports it directly: openParticipationArmed() returns true only where a token is configured and the per-voter cap is non-zero. A live read on 11 September 2026 returned false. On that date no token or staking contract was configured, both proportions read zero, the stored quorum read 50% rather than the 10% the model applies, and the approval and supermajority thresholds read 50% and 73%. Before Immutable Finalization each of these values can also be written by owner setters; afterwards the thresholds, the minimum holding and the per-voter cap remain writable by a passed proposal, which cannot set any of them to zero, and, while the arming call has not been made, by that single owner call, which carries no finalization gate. The figures above should therefore be read as the model this contract is configured to run rather than as the values standing in its storage, and anyone relying on a particular figure should resolve it from the contract. Appendix F §3.3 and §3.5 set out both configurations, and the activation-date gate described in §7.1 means none of this is operative before the date recorded there.

While the model is unarmed, which is its state at the date of this document, the proposal route is not open to token holders. Eligibility to create a proposal and to vote on one falls back to the contract's signer set, each signer's vote counts once, and quorum is measured against the number of signers rather than against any supply figure. The signer set is a stored list, written by the owner before Immutable Finalization and by a passed proposal afterwards, and it has no minimum size. On 11 September 2026 it held one address, the owner's own. Were the activation date to arrive in that state, the voted route would be exercisable by that one key: a single signer's vote is complete turnout, and it meets both the quorum and the supermajority threshold.

Under the open-participation model the governance basis is total staked principal. A proposal can be created only while a staking contract is configured and holds a non-zero balance, and the contract refuses to create one otherwise, so no proposal under this model is measured against Circulating Supply or against wallet balances, and until stake exists the proposal route is unavailable. The staked total is frozen when a proposal is created, so the quorum, eligibility and per-voter figures above are proportions of that total at that moment rather than of total supply, while a voter's own weight is the principal they have staked, read at the time they vote.

Proposals are subject to Timelock Execution. The delay is set for the proposal's tier and is measured from the moment a proposal is created rather than from the moment it passes, and quorum and threshold are evaluated when execution is attempted rather than at a vote close, so voting remains open while the delay runs and no separate interval between approval and execution is guaranteed; §2 defines the term on those terms and Appendix F §3.6 states the execution gate. Execution of a proposal occurs only after all procedural requirements have been satisfied and is performed through contract-enforced mechanisms. Two conditions attach to that step. Execution is reserved to the contract's signer set under every model, so a proposal that has carried takes effect only when a signer calls it. And a proposal not executed within fourteen days after its delay has elapsed expires and can no longer be executed, so a passed proposal depends on a signer acting within that window. Governance does not directly execute actions but authorizes execution paths that are carried out by protocol contracts.

7.4 Administrative Authority During the Transition Period

The lifecycle described in §7.3 governs actions taken through the proposal process. Until Immutable Finalization, it is not the only route by which a protocol parameter may be changed. This section states expressly what else exists, because the distinction is material to how governance authority should be understood at the date of this document.

Several contracts admit their own owner address as a sufficient caller on functions that a governance proposal would otherwise reach. Where a contract's governance gate accepts either the governance address or the owner, an action available to governance is equally available to the owner acting alone, without proposal, quorum, or timelock. Separately, the Governance facade carries an owner-operated execution path that sits outside the quorum, threshold, and timelock protections enforced by GovernanceContract. For the contracts governed through that facade, that owner-operated path is the route presently available rather than a fallback to the voted one; the facade's action counter read zero on 11 September 2026, so no action had been queued through it since that counter was introduced.

On Base, governance authority for several deployments resolves to a relay contract that executes arbitrary calldata, meaning any instruction its owner chooses to send, under its own identity. A contract naming that relay as its governance address treats a relayed call as a governance action, so the authority held by the relay's owner over those contracts is equivalent to governance authority itself. Separating the relay owner's keys from the governed contracts' owner keys is an operational control rather than one enforced by contract logic.

On a further set of deployments the governance address is neither a facade nor a relay but an externally-owned account, and it is the same account that holds the contract's own owner role. Seven deployments across both chains are in that state at the date of this document: TheWall, both messaging contracts, the organization registry and the message bus on Base, and the message bus and the Layer 1 anchor on Ethereum. Where a contract is in it, governance and ownership are not two authorities held by one party but one address recorded twice, so a governance-gated function and an owner-gated function are reachable by the same key on the same terms, and the qualification that a governance gate "admits the owner as well" describes no additional party. Which contracts are in that state is live configuration rather than a property of the code, and §14.9 records it.

A third route is specific to the token contract. The token exposes twenty-four privileged functions behind a TokenManager gate, TokenManager being deployed on Ethereum alone as the token itself is. They include opening trading, the buy-side fee rate, the maximum wallet and transaction limits, registration of Automated Market Maker pairs, the fee and limit exclusion lists, the settlement threshold and chunk size described in §8.2, the pointers to FeeManagement, the Reserve Vault, ComplianceRegistry, TokenSale, and the Automated Market Maker router and pair the token's own fee settlement trades through, and a per-address list that blocks both sending and receiving.

That routing is conditional rather than absolute. Where the token's one-time TokenManager pointer has been set, these operations admit that contract alone and exclude the token's own owner; where it has not been set, they admit the owner directly. Whether it is set is live chain state rather than a property of the code, readable as isTokenManagerAddressSet, and the call that sets it is owner-only and may be made once. Through TokenManager each operation runs as a three-call sequence: the administrator signals it, authorized signers sign it, and the administrator executes it once the signatures meet a configured minimum. That minimum constrains any single signer without being an independent check on the administrator, because the same key sets the signer set, sets the minimum, and performs both the signal and the execution.

Twenty-three of the twenty-four have a matching operation on TokenManager, and both mismatches are inert. The token carries two swap-enable functions with identical bodies, of which only one is routed, so the unrouted duplicate is unreachable and nothing is lost with it. TokenManager, for its part, publishes an operation named for minting for which the token implements no counterpart, so that operation cannot execute, which is §6.1's position seen from the other side. Immutable Finalization closes all twenty-three for every party, on the token contract directly and on TokenManager through its own administrator and signer gates; on TokenManager it moves upgrade authorization to the governance address rather than ending it. Appendix I sets out the operations individually.

The practical consequence is that, during the transition period, the constraint on administrative action is the security and discipline of the key holders rather than the voting mechanism described in §7.3. That mechanism is deployed but dormant: as §7.1 records, proposal creation and voting revert until the DAO activation date, so the routes described in this section are not alternatives to the voted route at the date of this document: they are the only routes that operate. §14.2 addresses the risks arising from this, and each Smart Contract Appendix identifies the authority model and finalization behavior of the individual contract in its §3 and §12.

7.5 Separation of Governance and Operations

Governance and operational execution are intentionally separated. Governance defines policy and authorizes actions, while operational contracts and wallets execute those actions within fixed constraints. Governance does not directly custody user funds or operational balances.

This separation reduces operational risk and limits the impact of governance errors. It is a separation of function between contracts, and it is not by itself a constraint on which parties may invoke a given function; that question is addressed in §7.4.

7.6 Governance Transition Guarantees

The transition from centralized deployment control to decentralized governance is carried out through contract functions, and until the contracts concerned reach Immutable Finalization its timing and configuration rest on owner decisions, as §7.1 and §7.4 record. Transition conditions and authority changes are enforced through contract logic and cannot be silently altered.

Immutable Finalization is applied per contract, and its effect is determined by that contract's own implementation. Where it occurs, upgrade authority over that contract is settled by its finalized implementation, which provides no way to return it to any party, including the original deployer, the Executive Multi-Signature Authority, or any successor entity. That settlement takes one of two forms: in some contracts upgrade authorization closes altogether, and in others it passes to the governance address alone, so the implementation remains replaceable by the address holding governance authority and by no other party. In both cases no function of the finalized implementation reopens the owner branch that finalization closed. Where authority passes to governance, governance can still install an implementation with different rules, including one that admits another party, so what finalization guarantees is that the next upgrade can be made only through the governance route, not that any particular address is excluded from that route or from what a later implementation permits, since governance may name the address that exercises it, including the former owner's. §14.1 records the same point.

The extent to which finalization also retires owner-level configuration authority differs by contract. In some contracts the configuration surface closes entirely; in others, a locked function has a governance-gated counterpart that admits the owner, so upgrade authorization is the only authority that finalization genuinely settles. Fifty-two deployed contracts implement Immutable Finalization, counted as distinct contracts rather than deployments, eleven of them being deployed on both chains. In most of them at least one configuration capability remains reachable by the owner afterward, through a function that never carried the lock, through a governance-gated counterpart that admits the owner, or through both; only a minority close their owner-level configuration surface completely. That distribution concerns configuration authority and not the separate ability to transfer ownership or to pause, neither of which the lock governs. §2 describes the two patterns, and each Smart Contract Appendix's §12 states which pattern that contract implements and which capabilities it actually loses. Finalization of a given contract should therefore be read as an irreversible settlement of upgrade authority rather than as a uniform termination of all administrative control. As at the date of this document no contract has reached Immutable Finalization, so what this section describes is prospective in every case; the test on each contract is immutableFinalized, and §14.9 records the position as present configuration to be confirmed on-chain.

The governance framework is designed to balance early-stage operational security with long-term decentralization, providing investors and participants with clear visibility into how authority is exercised and constrained over time.

8. Treasury System and Financial Controls

The USSE Treasury System is designed to provide transparent, auditable financial control without centralizing custody or discretionary authority. It establishes a clear separation between value custody, accounting, authorization, and reporting, and routes protocol revenue on-chain under Deterministic Routing rather than by discretionary instruction. Where settlement is deferred rather than immediate, where the ledger records less than the movement it describes, or where a recovery power sits outside the routing, §8.2 and §8.3 state the qualification at the point it applies.

8.1 Separation of Custody, Authorization, and Accounting

At a system level, the Treasury System does not function as a single wallet or pooled account. Instead, it operates as an accounting layer that records the financial movements designated Program Wallets and protocol components report to it; the ledger accepts a report from an authorized source without verifying it against any movement of value, and reporting to it is best-effort, as §8.3 records. This separation holds control of funds, authorization of spending, and the recording of outcomes as distinct authorities rather than merging them in one module, subject to the qualification §12.4 states: the treasury contract both holds balances it distributes and maintains the ecosystem value-movement ledger, so that ledger measures reported plus received value rather than serving as a custody record.

8.2 Deterministic Revenue Routing

Value entering the ecosystem, including protocol fees, messaging fees, liquidity-related proceeds, and other on-chain revenue sources, follows Deterministic Routing enforced by Smart Contracts: the destinations and the split percentages are drawn from the shared fee configuration rather than chosen for each payment, and no party selects a recipient at the moment value arrives. Not every path reaches that configuration. The content-upload registry forwards what it collects to a single configured address instead, as §11 records. The per-action fee paid on Ethereum for an action a relayer submits on a user's behalf, described in §10, likewise does not reach it: the Layer 1 fee collector, and the Ethereum payment escrow for the per-action payments it accepts, accumulate that fee and release it through a sweep that any address may call to one owner-set treasury address, and a read on 11 September 2026 found both pointing at the address the configuration names as its treasury destination. Because a contract called through a configured forwarder waives its own on-chain fee on that path, as §10 records, a waived write fee never reaches the split, and the relay fee paid in its place reaches the treasury destination alone. On the paths that do reach it, what varies is when the split is paid out, not who receives it. On most fee paths the division and payment complete inside the transaction that triggered the fee. On the two paths described below the fee is booked to the protocol's own account first and paid out later, so an audit trail assembled from payments alone will not align with the fees that gave rise to them until settlement runs.

That routing is shared rather than reimplemented contract by contract. Seventeen contracts in the deployed system read the same fee configuration at the moment they divide a fee, a sale's proceeds, or a reserve release, three of them shared fee libraries reading it on behalf of the contracts that link or inline them, and one of them the Ethereum payment escrow through which marketplace settlement now divides its platform fee. The Base marketplace contract is not among them: its purchase functions now revert, and the fee-division routine it retains is called by no function. The destination wallets and the split percentages are held in that configuration rather than copied into each contract, so a fee arising from a marketplace sale draws its destinations from the same set as one arising from a name registration or an ordinary token transfer. The configuration is deployed once on each chain, contracts on Ethereum reading the Ethereum instance and contracts on Base the Base instance, and the two hold separate state that is kept aligned by operation rather than by code; a read on 11 September 2026 found them identical in every split percentage and every destination address. Concentrating the parameters is what allows the routing to be verified from a single source, and it is equally why an incorrect value there would reach every fee at once, which is the exposure the floors described in §8.4 bound.

The contracts reach that configuration through a pointer each holds, so this routing is conditional on that pointer being set rather than on the contract being deployed. Where it is unset there is no split to fall back to, and the outcome is then a property of that contract rather than of the shared configuration: a single destination the contract holds separately, retention for a later sweep, or a reverted call. Which pointers are presently set is configuration rather than a property of the code, and a reader relying on the split reaching a particular fee should confirm that contract's pointer on-chain.

Two things follow that a reader assembling the protocol's finances should not have to infer. The first is that the value reaching those destinations arises from use of the protocol rather than from the sale of tokens. It is collected as the trading fee on registered pairs, the fee taken by the protocol's own Automated Market Maker, the write fees on the identity and social layers, the fee on a value transfer carried alongside a message, and the mint and marketplace fees on the digital asset layer, with the content-upload registry forwarding outside the split as §11 records. Proceeds of any token offering are raised under the separate offering materials §15.4 describes, so the two inflows are distinct in origin. They are not distinct in destination: the sale contract pays its proceeds to wallet addresses drawn from this same configuration, under a separate schedule of percentages compiled into that contract rather than the one applied to fees. The second is that neither inflow creates an entitlement for a token holder: no fee path distributes to holders in proportion to their holdings, and §15.2 states that ownership of tokens conveys no dividend entitlement and no claim on corporate assets or revenues. What this configuration fixes is where value goes when it arrives rather than what volume arrives, which depends on the level of activity the products described in §13 attract and is not projected in this document.

A wallet registry is available to organize disbursement of program funds. It holds a daily spending limit and an active flag for each registered wallet, while the set of addresses authorized to spend and the number of approvals a request must gather are held once for the registry as a whole and apply to every wallet in it, and the owner is admitted as an authorized spender in its own right. On the registry's ordinary path a request is raised, approved, and executed by authorized spenders, and execution reverts where it would take the wallet past its daily limit for the day. Three qualifications belong with it. First, the registry binds only movements executed through it: it draws tokens from a registered wallet under an allowance that wallet has granted and pays ether from the registry's own balance, so the key controlling a registered wallet can move that wallet's holdings directly without reference to the registry. Second, the owner key holds a direct transfer that bypasses the approval process and is never refused for exceeding the daily limit, although it is recorded against that limit and so consumes the day's remaining routine budget; it has no governance counterpart and is not closed by Immutable Finalization. Third, the policy setters survive finalization by design, so that a compromised wallet can still be disabled after the upgrade path has closed; governance mirrors the daily limit, the authorized-spender set, the approvals count, the per-wallet kill switch, and the pause, but not the direct transfer. Whether the registry governs any wallet is live state rather than a property of the code: a read on 11 September 2026 found no wallet registered in it, an approvals requirement of one, and no governance address set, while every destination the fee configuration names on either chain was an externally owned account. Onward movement from a Program Wallet is therefore bound by the registry's policy only where that wallet is registered and the movement is routed through it, and otherwise by the key that controls the wallet, which is the qualification §6.4 and §14.5 record.

Two revenue components reach their destinations by a different mechanism and are worth stating separately. The first, and the larger, is the trading fee the token contract takes on transfers where one side is a registered Automated Market Maker pair. That fee is moved to the token contract and booked into nine per-category counters as it is taken, and it is not paid out then. Settlement waits for a later qualifying transfer, and runs only while a settlement switch routed through TokenManager is on, once the token contract's own balance has reached a configurable threshold and the pair holds liquidity; it then sells the accrued tokens through the Automated Market Maker with no minimum output, and a configurable chunk size can further cap how much any single settlement releases, so a large accrued balance may take several transfers to clear. Where the pair holds no liquidity at all, a later qualifying transfer made while that switch is on distributes a queued balance of five hundred thousand tokens or more directly in token form instead, and a token-manager call can trigger that direct distribution outright rather than waiting for a transfer to carry it. A read on 11 September 2026 found the switch off, trading not yet opened, the registered pair holding no liquidity, and all nine counters at zero. The second is the protocol's share of the trading fee taken by its own Automated Market Maker. That share is approximately one-sixth of what the 0.33% swap fee adds to a pair, the remainder staying with the liquidity providers, and the pair realizes it by minting LP Tokens to the factory's fee recipient only when liquidity is next added to or removed from that pair, not on each trade. Those LP Tokens stay in that form until a collection call on the protocol's fee splitter redeems them for the pair's two underlying assets, unwraps the wrapped-ether side to ETH, and distributes both, the USSE side in token form, to eight destinations drawn from the same fee configuration, the treasury destination also receiving the share the configuration assigns to liquidity. That call is open to any address while the splitter is unpaused, and it is not triggered automatically by trading, so this component accumulates between collections rather than settling on each trade. Two conditions stand in front of it, and both are live state rather than properties of the fee logic. The accrual occurs only where the factory's fee recipient is set; where it is unset the swap fee stays whole with the liquidity providers and the protocol takes no share of it. And the splitter accepts only pairs created by the factory address it records, which its owner may change until the splitter is finalized. A read on 13 September 2026 found the deployed factory's fee recipient set to the protocol's fee splitter, and found that splitter recording the factory that created the token's registered pair, so both sides of the arrangement are in place; no share has accrued yet, because accrual is minted only when liquidity is next added to or removed from a pair and the registered pair holds none while trading is not open. Until the splitter is finalized, its owner can also transfer any token it holds, accrued LP Tokens included, to an address of the owner's choosing.

The rates those two components charge rest on different bases, and the token contract's are worth stating because its own interface does not report them consistently. A sale into a registered pair is charged on a schedule compiled into the implementation: 5% for approximately the first six months after the contract's recorded deployment timestamp, 3% to approximately twelve months, and 1% thereafter. No configuration function writes that schedule; it changes only with the implementation, on the terms §14.1 states. A purchase from a registered pair is charged at a stored rate instead, one of the operations routed through TokenManager described in §7.4, and that rate's setter carries no ceiling. The floors described in §8.4 bound how a fee is divided once it has been taken; nothing in the token contract bounds this rate before it is taken.

That is not particular to the fee. The token sets no ceiling on the position limit, the transaction limit, or the settlement parameters described above either. What it does compile in are the supply figures, the direct-distribution threshold named above, a signature typehash (the fixed template a signed message is checked against), and a floor of five percent of Circulating Supply on the position limit of a holder that ComplianceRegistry reports as Reg D verified, none of which bounds a setter, so what constrains all of these values is that same authorization process rather than a limit fixed in the code.

Two things follow for a reader resolving either figure on-chain. The live sell rate is returned by currentSellFeeBps(), while the similarly named feeTotalSell() holds a deprecated value that no code path reads and that should not be taken for the fee. And the decay is measured from deploymentTimestamp, which is public, so which tier applies is readable rather than inferred from the date on this document; that value is written at deployment and may be written once more by a one-shot owner reinitializer, which where that second call remains unmade would restart the schedule at its highest tier, and which Immutable Finalization does not close. A read on 11 September 2026 returned a deploymentTimestamp of 4 July 2026 at 01:07:47 UTC, which on the contract's own arithmetic places the 5% tier until 2 January 2027 at 16:07:47 UTC and the 3% tier until 4 July 2027 at 07:07:47 UTC; the same read returned 500 from currentSellFeeBps(), 1000 from feeTotalSell(), a stored purchase rate of 50 basis points, and showed the reinitializer not yet called.

8.3 Auditability and Its Limits

The Treasury System maintains an on-chain ledger of the value movements reported to it, and every entry it accepts is written as an immutable event naming the source, the amount, and a classification of that source. Two limits on that ledger belong here rather than in an appendix. It carries no reference to the authority under which a movement occurred: no ledger event carries a proposal identifier, a role, or any other pointer to the authorization the movement was made under, so an entry establishes what moved and from where rather than on whose authority. And reporting is best-effort rather than guaranteed. Eleven deployed contracts carry a shared reporting component for token movements, and eight of them contain a call to it; the token contract and the two LP Token treasuries carry it without calling it. Its calls are wrapped so that an unset ledger address, a caller the treasury has not authorized, or any revert inside the treasury does not stop the movement: an unset address is skipped without any notice, a refused or reverted call causes the reporting contract to emit a skip notice of its own, and in either case the movement completes with no ledger entry behind it. Ether fees divided through the shared fee library are reported to the same ledger by a second wrapper of the same kind, whose failure handler emits nothing. Whether a reporting address is set is live state rather than a property of the code: all eleven have named the treasury contract since 29 September 2026, and a read on 30 September 2026 found the token-movement side of the ledger still holding no entry. The allowlist naming which contracts may write to the ledger is owner-controlled and finalization-gated with no governance counterpart, and the treasury contract's own upgrade authority closes outright at Immutable Finalization rather than passing to governance, so that set is fixed from that point with no party able to extend it. Within those limits the records enable independent verification of financial activity without reliance on off-chain statements or discretionary disclosures.

Financial controls within the Treasury System are designed to prevent commingling, unauthorized redirection, and opaque fund movement, and the routing, custody and accounting separations described above are what deliver that. One authority sits outside them and should be read alongside. The treasury contract exposes an ETH sweep and an ERC-20 rescue, each callable by the governance address to a destination and for an amount of its choosing, and neither is closed by Immutable Finalization; the contract's own documentation describes the token rescue as governance discretion and does not exclude the managed token. These are recovery powers rather than routing paths, and they are why the guarantee that holds concerns how a fee is divided at the moment it is taken, and not what may subsequently be done with funds the treasury already holds.

Together, these controls make ecosystem fund handling predictable and auditable within the bounds §8.2 and this section state: the destinations of a fee split are fixed in the shared configuration rather than chosen per payment, the ledger records what is successfully reported to it, and the discretionary powers that remain are named rather than implicit. Before Immutable Finalization all of this stands behind the treasury contract's upgrade authority, as §14.1 describes; finalization closes that authority outright rather than moving it to governance, so from that point the arrangement above is settled.

8.4 Immutable Fee Floor Enforcement and DEX Transition

FeeManagement enforces minimum allocation percentages for key fee recipients. These minimums are compiled into the contract as constants rather than held in storage, and the owner update path and the governance update path both check against them, so neither the owner nor a passed governance proposal can set one of those shares below its floor. The wallet addresses designated for founder, advisor, and operations distributions are locked on the same basis: TreasuryContract and FeeManagement each reject a wallet update that does not preserve all three.

That protection is a protection against FeeManagement's own configuration functions, and it should be read as exactly that. FeeManagement sits behind a UUPS proxy, and Immutable Finalization moves upgrade authority to the governance address rather than ending it, so a replacement implementation could carry different constants. Nor do the floors and locks bind the contracts that read FeeManagement. Each of those contracts reaches it through a pointer of its own, and a setter on that contract can repoint it to any other contract that answers the same read functions; the reading contract checks the address it is given, at most, against the zero address, and does not check the percentages or destinations it then reads against the floors or the locked wallets. The Reserve Vault, for example, takes all eleven destinations and percentages of a tranche release from whichever contract its pointer names and bounds only the total. On most of the contracts that divide fees, the governance-gated pointer setter admits the owner and is not closed by Immutable Finalization; on the Reserve Vault it admits the governance address alone. What the floors and locks guarantee is therefore that no FeeManagement setter can starve those categories or redirect those wallets; what stands behind them across the system is the custody of each reading contract's pointer, and what stands behind the constants themselves is the upgrade authority described in §14.1 and in Appendix L §12.

FeeManagement also carries a one-time shift from the pre-DEX to the post-DEX fee split. It is applied by a single transaction rather than automatically on any external event, through either of two functions that share one body: an owner function that closes at Immutable Finalization, and a governance counterpart that admits the governance address alone, excludes the owner, and is not closed by finalization. Whichever runs first consumes the shift, which is guarded by a flag it sets and that no function can reset. Applying it overwrites the nine runtime fee splits in one call and permanently raises the operations floor from 30% to 38%, so the floor steps up as a consequence of the shift rather than alongside it. Finalizing before the shift is applied therefore does not fix the pre-DEX profile permanently: the shift remains available afterward as an action of the governance address, and finalization itself cannot proceed until a governance address has been set. Which profile governs is readable on-chain rather than inferred: postDexShiftApplied returns false while the pre-DEX profile is in force and true once the shift has been applied. A live read on 11 September 2026 returned false on both chains, with no governance address set on either instance, so that the shift was then available to the owner alone.

9. Messaging and Data Integrity

USSE incorporates a native messaging and data integrity framework designed to enable authenticated coordination between participants while preserving confidentiality and verifiable proof of communication. This system operates alongside economic and governance functions to support use cases where privacy, integrity, and auditability are required simultaneously. It is the layer beneath DEEP Mail, the encrypted messaging product described in §13.2.

The messaging architecture separates confidential payload handling from integrity anchoring. This separation allows the protocol to preserve message privacy while providing durable proof that communication occurred at a defined point in time; §9.2 and §9.4 state what that durability rests on and where it stops.

9.1 Confidential Messaging Architecture

Message content is handled through Encrypted Payload structures designed to preserve confidentiality between authorized participants. An Encrypted Payload is produced on the sender's device and submitted on-chain in the transaction that records the message, so what protects the content is the encryption applied to it rather than its absence from a public settlement layer.

Confidentiality is maintained at the content level, and the boundary of that guarantee is worth stating precisely. The encrypted message body is submitted on-chain, and where it comes to rest differs by contract. The messaging contract retains in its own storage the Integrity Commitment over that body, the encrypted key, and routing metadata, while the body itself remains in the data of the transaction that submitted it, which is where a recipient retrieves it from. The Layer 2 message bus records a field its interface names the ciphertext, but the messaging contracts fill that field with the message's Integrity Commitment rather than the encrypted body, and every record on either chain's bus at the date of this document was posted that way, so the bus holds a further copy of the commitment and of the encrypted key rather than the content. In neither case is the body absent from the chain. The consequence runs in both directions and both halves belong in the statement: no function the contract exposes returns the body and no later transaction can alter what was submitted, but the ciphertext forms part of the permanent public record and can be retrieved by anyone at any time. Confidentiality therefore rests entirely on the encryption, and rests on it indefinitely; §14.6 states the exposure that follows. Not all of the accompanying metadata is hidden. The sender and recipient addresses, the timestamp, the fee, and the attachment hash are stored and emitted, and a message's topic is stored as a plaintext string rather than encrypted. Confidentiality therefore covers the content of a message and not its context. The same distinction applies to group messaging, where group names and group topics are likewise held in the clear.

9.2 On-Chain Integrity Commitments

Each message produces an Integrity Commitment that binds the encrypted content to a specific sender context and timestamp. These commitments are recorded on-chain, and are stated below as records the recording contracts expose no means of changing.

A commitment allows independent verification that a message existed at a defined moment and has not been altered. Verification can occur without disclosure of the underlying encrypted content. This mechanism provides integrity guarantees comparable to notarization while preserving confidentiality.

Once recorded, a commitment cannot be modified or removed through any function these contracts expose. Neither the messaging contracts nor the anchoring contracts declare an update path, a deletion path, or an administrative override over a recorded commitment at any privilege level. A group host's ability to delete a group reaches that group's membership and metadata rather than the messages sent within it, and the key lifecycle functions a participant holds over their own registered key reach the key rather than anything already recorded under it. Two qualifications belong with the guarantee. The first is the general one stated in §12.5, and it is a point about mutability rather than about location: every record described here is on-chain, but what no later transaction can reach is the transaction log (the calldata a message was submitted in, and the events emitted alongside it), while the values a contract's view functions return are a property of whichever implementation is deployed when they are called. Where a commitment sits differs by contract, and the difference is worth stating rather than generalizing: the messaging contracts store the commitment and do not emit it, so it is recoverable from storage and from the submitting transaction; the Layer 2 bus stores it and emits a hash derived from it; and the Layer 1 anchor stores the per-message receipts registered with it, emitting the batch root each receipt cites but not the receipt's commitment. The second bounds that exposure, and here it is narrower than it is elsewhere in the system. Upgrade authorization over the messaging and anchoring contracts is held by the owner key, carries no governance mirror, and closes at Immutable Finalization for every party rather than passing to the governance address as it does in the contracts §12.3 describes. The period in which a replacement implementation could alter what a stored commitment returns is therefore the period before finalization, and it ends at it. See §14.1; Appendix AL §12 and Appendix AM §12 state each contract in full.

9.3 Batched Anchoring and Permanence

Each message's Integrity Commitment is recorded on the chain that message is sent on, at the moment of sending. That record is what makes message existence, ordering, and timing independently verifiable on the terms §9.2 states, and it does not depend on any subsequent step.

A separate batching layer can aggregate commitments and anchor them onward to Ethereum Layer 1, reducing redundant data overhead while retaining an inclusion proof for an individual message. The strength of that proof is worth stating precisely. The Layer 1 contract's verification function establishes that a nominated leaf, the entry standing for a single message, sits within the batch a receipt names; it does not itself recompute that leaf from the message, so binding a proof to a particular message is a step the verifying party performs off-chain against the receipt rather than a check the contract completes. Group messages sit outside that path altogether, their per-recipient records entering neither of the mappings the lookup and proof functions read. Appendix AF §11 and Appendix AG §11 set out both limits. This cross-layer anchoring is an optional extension, activated through administrative configuration (by the owner or governance on the messaging contracts, and by the owner alone on the anchoring contracts), rather than a precondition of the guarantees above; where it is not activated, commitments remain recorded and independently verifiable on their originating chain. At the date of this document the messaging contracts on Base post to the Layer 2 bus and those on Ethereum do not, and neither bus has yet committed a batch, so no message has been anchored to Ethereum.

9.4 Policy and Governance Context

The messaging system supports both permissionless participation and defined compliance boundaries. On the messaging contracts, governance may set operational parameters: the message, registration and relay fees, the transfer fee charged on a payment sent with a message, the authorized relayer set, the public key registry against which a send is checked, the verifier contract against which each send's proof is checked, the trusted forwarder that determines whom a forwarded message is attributed to, the registration cooldown, and the batch-size ceiling that bounds how widely a single call may write. Each of those parameters has a governance-gated setter that Immutable Finalization does not close, and each such setter also admits the owner. The relayer allowlist held by the direct messaging contract is written by those setters but read by no code path, so the relayer set that takes effect is the key registry's. On the anchoring contracts the comparable parameters are held by the owner rather than by governance and end at Immutable Finalization for every party. What governance retains there is narrow and is not the same on both: on the Layer 2 bus it may reassign itself, finalize, and install the trusted forwarder, and only the last of those survives finalization; on the Layer 1 anchor it may reassign itself and finalize, and neither survives. Appendix AF §6 and Appendix AG §6 give each census. No contract in this layer exposes a content policy, a moderation control, or a blocklist at any privilege level. It does expose a stop: while the messaging contracts post each message to the Layer 2 bus, as they do on Base, the owner's pause over that bus halts every message send on that chain, and that pause is not closed by Immutable Finalization. The moderator roles that exist in group messaging are assigned by a group's own host rather than by governance, and reach that group alone.

Governance authority does not extend to retroactive modification, deletion, or invalidation of previously recorded commitments, and in this layer that holds with unusual strength: upgrade authorization over the messaging and anchoring contracts never passes to the governance address at any stage, closing outright at Immutable Finalization instead, so governance acquires no route to a recorded commitment even after the owner's own authority has ended. One record in the chain is weaker than that and should not be read as covered by it. The metadata recording that a batch was anchored to Ethereum, meaning the Layer 1 transaction a batch commitment cites, is an assertion by an approved submitter that nothing on-chain verifies, and it may be written again over the same batch; that submitter set is itself frozen at finalization while the function writing the anchor stays open to it. The commitments within a batch are unaffected by this, and Appendix AG §11 states the limit in full. Subject to that, recorded integrity records remain intact regardless of future policy changes.

This boundary preserves trust in historical records while allowing forward-looking policy refinement.

10. Identity and Social Infrastructure

USSE also provides a native identity and social infrastructure layer, distinct from the confidential messaging system described in §9. Where messaging keeps content private and records only Integrity Commitments, this layer is public by design, covering a permanent posting record, on-chain identity presentation, human-readable wallet addressing, personal contact management, and the structure of organizations formed from those wallets.

Fees in this layer, and in the messaging system described in §9, are charged on the chain the action occurs on, with one systematic exception that applies across both. A trusted-forwarder path runs through these contracts, allowing a relayer to submit a user's action so that the user pays no gas, the charge the network itself makes for executing a transaction, on the chain where the action executes; the payment that meters the action is itself an Ethereum transaction. Where a forwarder is configured on the contract being called, the on-chain fee on that path is waived in full rather than reduced. At the date of this document a forwarder is configured on these contracts on Base only; none of them has one on Ethereum, where every action pays its fee on-chain. Such actions are metered on Ethereum instead: USSEFeeCollector (Appendix BA) records a per-action payment in ETH keyed to the hash of the user's signed request, and the relayer submits the corresponding action only once the recorded payment meets its own quote. The two halves are not bound together on-chain: neither contract holds the other's address, and no on-chain record links a waived action to the payment that covered it. The metering of gasless activity therefore rests on the relayer enforcing its quote rather than on contract logic. Value an action itself carries is treated differently. Where a forwarded message carries an ETH payment, the payment and the transfer fee on it must still accompany the call while both the message fee and the relay fee are waived, and a payment in an ERC-20 token cannot be forwarded at all. A marketplace purchase is not a forwarded action: the purchase functions on Base refuse every caller, and the price is paid on Ethereum to USSEPaymentEscrow and the token delivered on Base by an authorized settler, or by anyone once an hour has passed since the purchase was bound to the listing, as §11.3 describes. §14.1 addresses the risks arising from this.

10.1 TheWall: Public Social Publishing

TheWall is the public on-chain social layer of the USSE ecosystem. It enables wallet holders to publish text posts and media uploads directly on-chain, on both Ethereum and Base, creating a permanent public record of each submission. The two deployments are independent, and each chain holds its own posts and its own social graph. What the contract keeps in its own storage is a post's metadata and a hash of its content. Since version 2.7.0, published on 11 September 2026, the text of a post submitted directly is also written to a separate content store, which holds it as contract code, and is carried in the event log as before, so a reader can recover it from either and check it against the stored hash. A post created through the authenticated or prepaid upload pathway described below is refused unless its text was written to that store first. Every post on either chain at the date of this document was submitted directly.

Unlike conventional social platforms that apply algorithmic content ranking, administrative moderation, or retroactive deletion, TheWall enforces strict chronological ordering at the contract level and contains no administrative removal mechanism: across the contract's whole function surface there is no path at any privilege level that deletes, hides, or bans a post or an author. Content published to TheWall is written to an on-chain content store and emitted in the event log, so it remains readable from contract state as long as the network persists, whether or not nodes continue to serve historical logs. Content curation is managed entirely by participants, through on-chain follow and block controls and a permissionless report signal that records a flag and emits an event while carrying no on-chain consequence for the post, with no algorithmic ranking layer between a user and the chronological record.

A post submitted directly carries a protocol fee calculated as the greater of 10% of a fixed gas estimate priced at the current gas price and a $0.03 USD minimum; that figure is a minimum rather than an exact charge, since the contract routes the whole amount attached to a post, a like or an unlike as fee and refunds no excess. A post submitted through the forwarder carries none, on the basis set out above. Both of those figures are values written at deployment rather than constants. Where a Chainlink price feed is configured, the USD floor is converted at the rate that feed reports and an answer older than a day halts the call; where none is configured, the conversion falls back to a fixed rate compiled into the contract, which does not track the market. The fee therefore tracks prevailing network conditions rather than the gas the individual transaction consumes. Fees that are charged are routed through FeeManagement under Deterministic Routing.

Posts are immutable once published. Post editing was removed in TheWall v2.6.0, and the contract exposes no function that alters a published post at any privilege level. The fifteen-minute edit window earlier versions carried, and the governance-adjustable duration that bounded it, no longer exist: the storage slot that held that duration and the per-post field that recorded an edit are retained only because removing a state variable would shift every variable declared after it, and neither is read by anything.

Media uploads are stored on-chain through a chunked submission system, in one of two forms. On TheWall's own upload path each chunk is emitted as an event, and integrity rests on a declared content hash, which consumers verify when reassembling the payload from those events. On the authenticated pathway described next, which is the one in use, UploadRegistryV2 deploys each chunk as the code of its own contract, checks it on submission against a Merkle root the uploading wallet committed to, and serves it back as that contract's code rather than as an event; the whole-payload hash the upload declares is recorded but not checked on-chain. An authenticated upload pathway extends this capability by enabling applications to submit upload proofs signed by the originating wallet, linking verified media to public posts through an on-chain authorization record. A further prepayment pathway allows users to commit fee escrow in a single signed transaction; a relayer may then finalize the associated post within a defined settlement window without requiring a second on-chain signature from the originating wallet. Where a relayer stalls, any party may trigger a refund of the unused balance to the user once 24 hours have passed without progress on the upload, where progress means submitting a batch of chunks, finalizing the upload, the relayer drawing a gas reimbursement, or anyone topping the escrow up; starting the session and creating the post do not restart that period.

Governance-adjustable parameters, including fee rates and content size limits, are subject to the Governance Authority Matrix. Timelock Execution applies to changes made through a governance proposal rather than being enforced by the contract itself. At Immutable Finalization these parameters pass from the pre-finalization setters to the governance-gated mirrors, which remain callable; because this contract's governance gate admits the owner as well as the governance address, the capability returns to the owner rather than leaving it. Upgrade authority is what finalization ends here, and it ends outright: this contract's upgrade gate carries no governance branch, so finalization closes it for every party rather than passing it to the governance address.

TheWall complements the encrypted messaging infrastructure by providing an open and publicly verifiable coordination layer. Where messaging protects the content of a conversation, TheWall exposes an irrevocable public record of statements and coordination that no administrative action can remove and that no party can alter, its own author included.

10.2 ProfileRegistry: On-Chain Identity Presentation

ProfileRegistry provides the on-chain identity layer for the USSE ecosystem. Each wallet address may register a persistent profile containing a display name, a biography, and a collection of up to twenty avatar entries. An avatar entry is held in contract storage, but what it holds is not always the image: the contract accepts a data uniform resource identifier (URI), in which case the image itself is on-chain and bounded at roughly thirty-seven kilobytes; a short identifier naming one of the client's default avatars; or an InterPlanetary File System (IPFS) content identifier, in which case the image is held off-chain and the entry records only where to find it. Once registered, profile data is readable by any client directly from the chain, without reliance on centralized identity services. Profile content is self-asserted rather than verified, display names are not unique, and a profile establishes no identity beyond the wallet that registered it.

Display names and avatars registered through ProfileRegistry are intended to be presented across platform surfaces where wallet identity appears, including encrypted messaging, public posts on TheWall, governance actions, and integrated applications. That presentation is performed by the applications reading the registry rather than enforced on-chain: no protocol contract reads a profile's contents, and the registry exists on Base alone. ProfileRegistry functions as the visual identity complement to NameRegistration, which maps human-readable names to wallet addresses.

Base, the Ethereum Layer 2 network, was chosen because lower transaction costs make direct on-chain image storage practical. Creating a profile, updating its name or biography, and adding an avatar each carry a protocol fee calculated on the same basis as TheWall's, being the greater of 10% of a fixed gas estimate priced at the current gas price and a USD floor, and routed through FeeManagement under Deterministic Routing; switching or removing an avatar and deleting one's own profile carry none. Governance-controlled parameters, including fee rates and contract address references, are subject to the Governance Authority Matrix. Timelock Execution applies to changes made through a governance proposal rather than being enforced by the contract itself. At Immutable Finalization these parameters pass from owner control to the governance-gated mirrors, which remain callable; upgrade authority is what finalization ends. A profile can also be deleted without its holder's consent, and that capability survives finalization on both sides: the contract owner holds a dedicated administrative delete and governance holds a mirror of it, neither of them finalization-gated. It is moderation tooling, and it persists for the life of the deployment. Its reach is narrower than the word suggests: deletion, whether administrative or by the holder, clears the display name, biography and active selection but not the avatar collection, which stays in contract storage, remains readable through the registry's avatar listing function, and is reattached, with the first entry of that list selected, if the wallet registers a profile again; because removing an avatar moves the last entry into the removed position, that first entry is the oldest only where no earlier removal has moved a later one into it. Two further capabilities survive finalization in the same way: the owner and governance may each pause every profile write, and governance may transfer the contract's ownership, and with it the administrative delete.

10.3 ContactRegistry: Contact Lists and Business Directories

ContactRegistry provides each wallet with a persistent contact list stored on-chain. The contract is deployed on Ethereum and on Base and each deployment holds a separate list, but the application reads and writes contacts on Ethereum alone, so a wallet's contact list and the business directories are Ethereum records in practice and the Base deployment holds none of them. Users assign display labels to wallet addresses and manage per-contact access controls, with all data recoverable from any device without reliance on centralized storage. ContactRegistry extends the identity infrastructure of the ecosystem by enabling participants to curate and label the wallet networks with which they interact.

Beyond the contact list itself, the contract allows a wallet to register as a Personal or Business profile, publishes enumerable directories of registered businesses, and supports a mutual-consent invite flow. Two ways of recording a contact coexist and they differ in exactly this respect. An invite must be accepted by its recipient, and acceptance writes the pair to both parties' lists, so a reciprocal connection is recorded only where both have agreed. A direct add writes a one-sided entry to the caller's own list alone, requires nothing of the address being added, and is the path a wallet uses to label a counterparty it has dealt with. Neither path places an entry on another wallet's list without that wallet acting.

Write operations within ContactRegistry are fee-gated and routed through FeeManagement under Deterministic Routing. The fee is calculated on the same basis as TheWall's and ProfileRegistry's, being the greater of 10% of a fixed gas estimate priced at the current gas price and a USD floor. It resolves that floor the same way: where a Chainlink price feed is configured the floor is converted at the rate that feed reports and an answer older than a day halts the call, and where none is configured the conversion falls back to a fixed rate compiled into the contract, which does not track the market. On Ethereum, the deployment the application uses, a price feed has been configured since 30 September 2026, so the floor there now tracks the market: a read that day returned an estimated fee of 0.0000112 ETH, the three-cent floor at the feed's rate of about $2,668. Until then no feed was configured and the floor was the compiled fallback of 0.00003 ETH whatever the price of ETH, roughly seven cents at the rate read on 11 September 2026. Declining or cancelling an invite carries no fee. Governance-controlled parameters, including fee rates and the maximum contacts permitted per wallet, are subject to the Governance Authority Matrix. Timelock Execution applies to changes made through a governance proposal rather than being enforced by the contract itself. At Immutable Finalization these parameters pass from the owner-gated setters to the governance-gated mirrors, which remain callable; because this contract's governance gate admits the owner as well as the governance address, the capability returns to the owner rather than leaving it, and upgrade authority is what finalization ends.

10.4 NameRegistration: Human-Readable Wallet Addressing

NameRegistration is the on-chain identity naming layer of the USSE ecosystem. It maps human-readable names to wallet addresses, enabling users and applications to address wallets by name rather than by hexadecimal identifier across all ecosystem surfaces including TheWall, encrypted messaging, and integrated applications. It is deployed on both Ethereum and Base, and each chain maintains its own independent set of names. On Base an authorized relayer may also register a name on a wallet's behalf, paying the fee itself, a path the contract describes as intended for cross-chain synchronization; a name registered that way needs nothing of the wallet it is assigned to and counts against that wallet's one-name allowance.

A name registered without an expiry is permanent: expiresAt of zero means the name never lapses, and the eight names reserved for the protocol's own identities are held on that basis. Whether a name carries an expiry is chosen at registration rather than imposed by the contract: the basic registration function records none, so a name registered through it is permanent on the same terms, while the two registration functions that accept an expiry take any future date the caller supplies, the application supplying one year. A name registered with an expiry behaves differently, and since v3.7.0 that expiry is enforced. It is enforced in exactly one place, the availability test a new registration runs, and the narrowness of that is the substance of the guarantee. A name whose expiry has passed is not taken away and does not stop working: it stays owned by its holder and keeps resolving. What changes is that, once a further ninety-day grace period has also elapsed, the name becomes registrable by anyone, and the first party to register it takes it. A holder may extend their own expiry by a year at a time through renew(), paying the registration fee. The contract exposes no reclaim, no auction, and no automatic transfer: absent administrative action, the only way a lapsed name changes hands is another party registering it after the grace period.

Registration is first-come, and holders cannot transfer a name between themselves, but administrative action can move one: the reservation function and its governance mirror assign a name to a nominated wallet, force-transferring it where it is already registered to someone else, and the ban function and its mirror delete a registration outright. The contract owner can additionally release any name not held under a reservation, the release path treating the contract owner as though they were the name's holder, and the owner or governance may rewrite any name's expiry to any value, including one already past, which for a name not held under a reservation makes it registrable by anyone once the grace period measured from that value has run. Immutable Finalization ends none of these powers, though for two different reasons: the reservation and ban functions are finalization-gated on the owner side but carry governance mirrors that are not, and those mirrors admit the owner as well as the governance address; the release path carries no mirror, the expiry setter is itself governance-gated, and neither was ever finalization-gated. A holder's continued control therefore rests on those powers not being exercised rather than on a contract guarantee.

A wallet may hold one name. The cap is a stored parameter rather than a constant, presently set to one on both chains, and a registration that would take a wallet past it is refused. Two qualifications belong with it. An exemption list allows a nominated wallet to hold more; no wallet is exempt at the date of this document, the eight reserved identities each holding a single name on a wallet of its own rather than depending on it. And the cap binds registration only: lowering it never strips a name already held, because the check runs nowhere except in the registration path. There is no cooldown between registrations. A separate ban list refuses specific names outright; it is administered by the owner and by governance, and when the one-name cap was introduced in v3.8.0 it was populated with eighty-six names, covering regulators and government bodies, platform authority and support roles, company officers, security and wallet terms, financial-action lures such as airdrop and refund, and reserved infrastructure words. Where a Chainlink price feed is configured and a USD price is set, registration fees are denominated in USD and computed in ETH at the moment of transaction, so that registration costs remain consistent in real-world value terms independent of ETH price fluctuations. Where either is absent, a flat fee denominated directly in ETH applies instead.

All registration fees are routed through FeeManagement under Deterministic Routing. Governance-controlled parameters, including pricing, authorized relayers, banned names, and name reservations, are subject to the Governance Authority Matrix, with Timelock Execution applying to changes made through a governance proposal rather than being enforced by the contract itself. Where ProfileRegistry defines how a wallet identity is presented and ContactRegistry organizes personal networks, NameRegistration establishes how a wallet is addressed, completing the three-part wallet identity infrastructure.

10.5 OrganizationHierarchy: On-Chain Entity Structure

Where the three registries above describe an individual wallet, OrganizationHierarchy describes a structure built from them. It is deployed on Ethereum and Base, each chain holding its own organizations, and it records entities of any kind: companies, departments, teams, committees, and the delegated-authority structures found within governance-driven ecosystems. An organization is a tree of nodes, each created either at the organization's root or under an existing node, as one of four types: department, sub-department, team, or role; the type is a label, and the contract does not constrain which type may sit under which. Each member holds one of five organizational roles, being Owner, Admin, Manager, Employee, or Associate, and it is the role that determines what that member may do. A job title may be set alongside it by an administrator; the title is a descriptive label rather than a permission, and it is a member attribute that survives a move between nodes but not the member's own removal. An organization is marked public or private, and the ceilings on nodes per organization, members per node, and outstanding invitations are configurable parameters rather than fixed constants.

Membership is written by two paths that differ in what they require of the member, and the distinction governs what an entry evidences. An invitation must be accepted by its recipient, and may be declined by them or cancelled by the organization, so a wallet recorded that way has acted itself. A Manager or above may instead add a member directly, which requires nothing of the address being added. A member may leave of their own accord. Most write operations carry a protocol fee on the same basis as the registries above, being the greater of 10% of a fixed gas estimate priced at the current gas price and a USD floor, routed through FeeManagement under Deterministic Routing. Seven do not: removing, moving, or renaming a node, changing an organization's visibility, deactivating it, leaving one, and declining an invitation.

Membership, role, and hierarchy changes are recorded on-chain and the record of them is permanent, with one exception: where a role change transfers ownership, only the incoming owner's change is emitted, and the outgoing owner's demotion to Admin is written to storage without an event of its own, so it has to be inferred. The current-state view is not permanent either: the contract exposes paths to remove a member, remove a node, and deactivate an organization, so what accountability rests on here is the event history rather than the standing state, as §13.2 sets out and §12.5 states generally. Governance-controlled parameters, including fee rates and the structural ceilings, are subject to the Governance Authority Matrix. Timelock Execution applies to changes made through a governance proposal rather than being enforced by the contract itself. At Immutable Finalization these parameters pass from the owner-gated setters to the governance-gated mirrors, which remain callable; because this contract's governance gate admits the owner as well as the governance address, the capability returns to the owner rather than leaving it, and upgrade authority is what finalization ends.

11. Digital Asset Infrastructure

The protocol operates a native digital asset layer on Base Mainnet, the layer beneath the Media Marketplace product described in §13.3. It comprises two token collections, a settlement marketplace, an event-ticketing policy contract, and the minting and content-storage infrastructure supporting them; of these, only the content-upload registry described in §11.4 is also deployed on Ethereum. The buyer's payment for a marketplace purchase never reaches Base: it is paid and settled on Ethereum through a separate payment escrow, USSEPaymentEscrow, which §11.3 describes. The two collections follow the ERC-721 and ERC-1155 standards, the first for tokens that are each unique and the second for editions issued in multiple copies. Base was selected for the same reason it hosts the identity layer described in §10: transaction costs low enough to make on-chain metadata and media storage practical. Value in this layer is denominated in ETH. Mint fees on the two collections and the marketplace's platform fee are routed through FeeManagement under Deterministic Routing, so that activity funds the same Treasury System destinations as the protocol's other fee-bearing flows; the platform fee is divided on Ethereum, by the payment escrow, through the FeeManagement deployment there. A mint called on either collection directly through the trusted forwarder is the exception to the first half: both collections waive their own fee for such a call, the relay's per-action fee paid on Ethereum taking its place, and that fee reaches a single treasury address rather than the FeeManagement split. A mint completed through the mint escrow is not a forwarded call at that point and pays the collection's fee in full. The upload registry is the exception: it forwards what it collects as a single undivided transfer to one configured address rather than through the FeeManagement split.

11.1 USSENFT: The ERC-721 Collection

USSENFT is the protocol's ERC-721 collection, implementing the Enumerable, URIStorage, and Royalty extensions across five distinct minting entry points, with extended on-chain metadata and creator attribution recorded per token. Minting carries a dynamic ETH fee, priced against prevailing network conditions rather than fixed in advance, which is distributed across nine of FeeManagement's ten wallet categories at the moment of collection.

The collection's supply ceiling follows the convention §14.1 describes: a stored maximum that no mint may exceed, which the contract reads as no ceiling at all when it holds zero, and which reads zero on the deployed collection, so no ceiling is in force at the date of this document. It is an adjustable parameter rather than a compile-time constant. It may be raised, lowered subject only to not falling below the number already minted, or set to zero to remove the ceiling entirely, and a governance mirror carries that capability past Immutable Finalization. What a holder can rely on is therefore the number minted at the moment they read it rather than a bounded eventual total.

What a token resolves to is a separate matter, and the two collections differ on it. A token may be minted against content stored on-chain through the upload registry described in §11.4, or against a conventional off-chain metadata reference, and which of the two applies is settled when it is minted. The contract owner can additionally repoint any token's metadata reference at any time. That path carries no governance mirror and was deliberately never finalization-gated, its stated purpose being the correction of broken metadata, so it persists for the life of the deployment. §11.2 records that the edition collection has no equivalent, and §14.2 the governance risk that administrative authority of this kind creates.

Creator royalties follow the ERC-2981 standard and are capped at 10% per token, a ceiling enforced by the contract rather than left to convention; §11.3 states what that standard does and does not collect. Immutable Finalization is narrower here than in the core economic contracts. Ten functions are finalization-gated and seven of them have an ungated governance mirror admitting the owner as well as the governance address, so what finalization ends is upgrade authorization and the ability to rotate the governance address. Fee, royalty, supply, and integration settings all remain changeable afterwards, as do the pause controls. Upgrade authority ends outright here rather than passing to the governance address, which is the reverse of the edition collection and is stated at §11.2. Appendix AS §12 states which capabilities finalization actually removes.

11.2 USSEEditions: The ERC-1155 Edition Collection

USSEEditions is the protocol's ERC-1155 collection, supporting creator-defined editions whose supply is settled at creation. A creator either sets a maximum number of copies, which the contract enforces on every mint into that edition and which no function can subsequently raise, or sets that maximum to zero, which the contract reads as uncapped and which leaves the edition open to further copies without a supply limit. Which of the two applies is fixed when the edition is created, so an edition's scarcity, or the deliberate absence of it, is a property of its creation rather than a parameter under continuing administrative control. Royalties are again ERC-2981 and again capped at 10%, the ceiling being enforced at each of the three paths that create an edition, and the dynamic ETH mint fee is split nine ways through FeeManagement on the same basis as the ERC-721 collection.

An edition's metadata reference is written by those same three creation paths and by nothing else. No administrative path repoints it, which is where this collection differs from the ERC-721 one described in §11.1.

Two administrative powers belong with that. An edition can be deactivated, which stops further minting into it while leaving every copy already issued and every onward transfer untouched, and it can be reactivated afterwards. Its creator holds both, the contract owner holds both, and governance holds a mirror of each that Immutable Finalization does not close. A creator's continued ability to mint into their own edition therefore rests on those powers not being exercised rather than on a contract guarantee, in the same form §10.2 and §10.4 record for the identity registries.

Upgrade authority resolves the opposite way from the ERC-721 collection. Before finalization the owner or the governance address may authorize an upgrade; after it, the check admits the governance address alone and excludes the owner. Finalization therefore transfers upgrade authority here rather than ending it, which is the general position §14.1 sets out, while on USSENFT it closes for every party. Finalizing is itself refused while the governance address is unset, so the transfer cannot leave the contract with no party able to authorize an upgrade.

11.3 NFTMarketplace: Listing and Settlement

NFTMarketplace holds fixed-price listings for both ERC-721 tokens and ERC-1155 edition copies. There is no auction or bidding mechanism: a listing states a price, and a buyer either meets it or does not. The listing is held on Base; the money is not. Payment and settlement were moved to Ethereum, and the marketplace's own purchase functions were retired: both revert, and a caller reaching them receives a named PurchaseRetired error rather than an obscure failure.

A purchase is therefore a sequence across two chains. The buyer pays the full amount in ETH to USSEPaymentEscrow (Appendix BF), a payment escrow on Ethereum, against terms naming the listing, the buyer, the payee, the price, the royalty, the platform fee and the settlement charges. An authorized settler binds the listing on Base to that buyer and that payment, a step the marketplace refuses unless it holds the item and the agreed total matches the quantity taken. The settler then settles the terms on the escrow, which credits the seller, the royalty recipient and the settler, divides the platform fee across nine FeeManagement destinations, and in the same transaction sends a message through the OP Stack bridge recording on Base that Ethereum has confirmed the payment. The token is then delivered on Base, and the marketplace releases it only to the bound buyer, only against that confirmation, and only where the confirmed price covers the quantity taken and the confirmed payee is the listing's own seller or, for a listing held by the configured edition pipeline, the creator the token itself names as its royalty receiver. The settler delivers in the first instance, and once an hour has passed since the binding anyone may complete the delivery. Three consequences belong with that shape and none of them is visible from the Base contract alone. Proceeds are credited rather than paid: a seller collects by calling the escrow's withdraw function on Ethereum, and until they do their proceeds sit in that contract. The buyer holds a refund against the escrow until settlement completes, callable once a delay measured from their own payment has passed, presently fifteen minutes. Settlement closes it, and settlement precedes delivery, so from that point the buyer's only remedy is delivery on Base: a settled purchase that governance force-delists, or an edition purchase whose buyer is a contract unable to accept the transfer, leaves that buyer with neither the item nor an on-chain refund. And settlement depends on an authorized settler acting, so a purchase is not atomic and the whole flow rests on the escrow being correctly wired to the marketplace it is settling for.

The fee model is a buyer premium, and three amounts are charged on top of the listed price rather than deducted from the seller's proceeds: the platform fee, a relay fee that pays the settler for the work it performs on Base, and, for a piece sold by the edition pipeline, a top-up that funds the pipeline's minting of the next piece. The platform fee reaches the destinations described below; the other two are credited to the settler, so they are a cost of settling the purchase rather than protocol revenue. A creator royalty under ERC-2981 is the one deduction a seller does bear, and it is conditional rather than automatic. No contract queries the standard at settlement: the royalty is read from the token when the platform prepares the purchase terms, and the escrow credits whatever royalty those terms name. The escrow itself enforces two limits only, refusing terms whose royalty exceeds the price and leaving with the seller a royalty that names no recipient. The remaining conditions are applied by the platform when it prepares the terms, which carry no royalty where the query reverts, names no recipient, or returns more than the price, and a royalty naming the seller is credited back to the seller in any case. In each of those cases the seller receives the full listed price. For a piece listed by the edition pipeline the platform's terms name the creator as the payee, paid once with no separate royalty, and the marketplace accepts that payee for a listing held by the edition pipeline it is configured with. The platform fee is distributed across nine FeeManagement destinations at settlement, and since that division now happens on Ethereum, this layer's fee revenue reaches the same destinations as the protocol's other flows without crossing a chain to do it. Each of the nine transfers is attempted with a bounded gas allowance and never blocks the sale: a transfer that fails, together with rounding dust, stays in the escrow until it is swept to a single treasury address.

Both listing types are held by the marketplace while a listing is open. ERC-1155 copies are escrowed into the marketplace when the listing is created, and so is an ERC-721 token, which the marketplace takes into its own custody at listing and returns to the seller only on delisting. A purchase can be bound only to a listing whose item the marketplace itself holds, so an active listing is assurance that the item is there to deliver. A multi-copy edition listing may be bought in part. A buyer takes the quantity they want, that quantity alone is delivered, and the remaining copies stay listed and available at the same price, still held by the marketplace. Only one purchase may be bound to a listing at a time, so while one buyer's purchase is in progress the remaining copies cannot be bought by another until that purchase is delivered or released.

Trading can be suspended. The owner and the governance address each hold a pause, neither route gated by Immutable Finalization, and while it is engaged new listings, the binding of a listing to a buyer, and delivery all revert on Base; the retired purchase functions revert in every state. Delisting is deliberately left outside the pause, so a seller may recover a listed token or listed edition copies while trading is suspended, provided no purchase is bound to the listing. Where one is, the seller may reclaim the item only if Ethereum has not confirmed the buyer's payment and the binding is more than a day old; otherwise there are two governance-gated releases: a reservation release, which refuses once a settlement has been recorded and after which the seller may delist, and the force-delist, which returns the item to its seller even where the buyer has already paid. The payment escrow on Ethereum carries no pause of its own, so a buyer whose payment has not yet been settled keeps the refund described above throughout, while a buyer whose purchase has already been settled can neither refund it nor receive delivery until the pause is lifted. The pause carries no expiry of its own, unlike the Reserve Vault's, which §6.3 records as bounded at ninety days per call.

One property of the collections bears directly on holders and belongs here rather than in an appendix. Both USSENFT and USSEEditions treat a single governance-configured marketplace address as approved to transfer every holder's tokens, and that approval takes precedence over the standard per-holder approval record. A holder who revokes approval for that address does not thereby withdraw it. This is a deliberate integration between the collections and the marketplace, and its consequence is that holding a USSE-issued token includes standing transfer authority held by whatever address governance or the owner has configured. §14.2 addresses the governance risk this creates.

11.4 Minting and Content Infrastructure

Four supporting contracts complete the layer, and the event-ticketing policy contract they work alongside is described in §11.5.

PlatformMintRegistry maintains a platform-wide sequential mint number, allocating one number to each mint event that a whitelisted minting contract reports to it, so that issuance across the collections and the edition pipeline can share a single ordering. Numbering requires configuration on both sides: the minting contract must point at the registry, and the registry must list that contract as an allocator. Both halves are readable on-chain. On the live reads of 13 September 2026 all three carried them: both collections and the edition pipeline point at the registry and are listed there as allocators, so mints on either collection are numbered from that point on; a read on 30 September 2026 returned thirteen from the registry's totalAllocated(). A number is assigned when a token is minted, so any token minted before its collection was wired carries none, and no later call gives it one. The number is an index rather than a permission, since no token or fee calculation depends on one, so a mint that goes unnumbered is unaffected in every other respect. The one exception is a half-configured collection: one that points at the registry without being listed there as an allocator has the mints that consult the registry refused, because its refusal is not caught. On the editions collection those are the two calls that create and mint in one step, and on the single-token collection every mint except one made by the edition pipeline, which is exempted. That exemption applies only while the single-token collection names the edition pipeline, which it has done since 30 September 2026; six pieces the pipeline minted there on 17 September 2026 took numbers of their own and keep them.

MintEscrow allows a mint fee and a capped relayer gas reimbursement to be committed in one ETH transaction, with the funds held by the contract rather than by the relayer and reclaimable by the user once the deadline and a short grace period have passed without settlement. It is also the escrow through which every ticket is issued. For a ticket paid on Base it claims the seat, holds the ticket price, and pays the organizer only once the ticket has been minted; it issues the organizer's complimentary tickets; and for a ticket paid on Ethereum it lets the authorized relayer hold the seat for the buyer, accepting confirmation of the Ethereum settlement only from the payment escrow through the OP Stack bridge.

EditionPipelineManager supports sequential ERC-721 editions in which a creator pre-pays for a small buffer of pieces and each sale funds the mint of the next, so that a long edition does not require the creator to fund it in full at the outset.

UploadRegistryV2 stores content on-chain in chunks, each chunk deployed as its own immutable contract, with each upload session authorized by the content's author rather than by whoever submits the transaction, either by their signature or, where the author has prepaid for the upload, by that prepayment. It is deployed on both Ethereum and Base and serves TheWall as well as this layer.

11.5 USSETicketing: Event Ticket Policy

USSETicketing holds event-ticket policy on behalf of the collections. It records what a ticket is: the event it admits to, the seat it names, the tier and price it was sold under, and the ceiling it may be resold at. It takes custody of no token, moves no funds, and issues nothing, the token itself being minted by one of the two collections described above; its only external calls to those collections are view reads, it names the primary-sale payee but never pays it, and its only payable entrypoint is the upgrade mechanism inherited from its proxy base, restricted to the upgrade authority.

Creating an event is permissionless, and the wallet that creates one becomes its organizer. That organizer is thereafter the only party who may reconfigure it: no owner or governance function writes an event's payee, sale cutoff, resale cap, tier prices, or cancelled flag directly. An event also carries the artwork its tickets are minted against, set by the organizer and refused if empty. It is a precondition of a public sale paid on Base rather than of the event's existence: an event may be created and configured without it, and the organizer's own complimentary tickets carry their own mint data, while a purchase paid on Base reads the event's artwork and fails without it. A purchase paid on Ethereum is completed differently: the authorized relayer holds the seat on Base and supplies the mint data itself, so on that route the contracts neither read the artwork nor require it, and the binding of the ticket to the organizer's artwork and royalty rests on the relayer rather than on the escrow. The relayer may also complete that mint before Ethereum's confirmation arrives, a step open to anyone else only once it has. Three qualifications follow from the administrative surface that does exist. Where an organizer leaves an event's resale cap at zero, the ceiling applied to tickets minted thereafter is set by the platform default described below, an owner or governance parameter; a cap already frozen onto an issued ticket is unaffected. The mint-escrow and trusted-forwarder pointers are administrator-controlled and are trusted to assert caller identity, so an administrator who repoints either can act as an organizer. And the contract is upgradeable, so before Immutable Finalization the owner, and after it governance, can replace the logic entirely; organizer exclusivity is a property of the current implementation and its correctly-set pointers, not a guarantee against the administrator. What the protocol's own administrators hold directly at this contract is the pause control, the integration pointers, the governance pointer, and one economic parameter: the platform default resale cap just described, which may itself be set to request no ceiling at all. The governance-gated functions also admit the owner, other than the setter for the governance pointer itself, which admits the governance address alone, and the governance-side mirrors of the pointer and resale-cap setters are not closed by Immutable Finalization.

Two event-level terms govern resale. A sale cutoff refuses sales from the time it names, both the primary sale of a new ticket, a complimentary one included, and any later resale through this platform's own marketplace, and does not restrict transfer outside it; it is inactive until an organizer sets it, and a cutoff of zero means the sale window never closes. A resale ceiling is expressed in basis points of the ticket's own original price and, when an organizer sets one, is bounded at five times that price. Unlike the sale cutoff, a resale ceiling is not inactive until set: an event that names none falls back to a platform default of 110% of the ticket's original price, resolved and frozen onto each ticket at the moment it is recorded. A distinct sentinel value exists in the contract to request no ceiling at all. The bound the event-level setters enforce rejects it, so an organizer cannot name it for an event, but the platform default is not bounded the same way: the owner or governance may set the default itself to that sentinel, and every event left at zero would then issue uncapped tickets. Nor does a stored ceiling always bind. It is a multiple of the ticket's recorded price, and a ticket sold in a tier priced at zero is recorded at zero and is therefore uncapped whatever its basis points, so an organizer who wants a bounded resale for such a tier must price it. Each ticket captures its resale basis when it is minted rather than reading the event's setting at the moment of resale, so a ticket already sold keeps the ceiling it was sold under, and a later change, to either the event's setting or the platform default, does not re-base it.

A third class of ticket sits alongside the sold ones. An organizer may issue complimentary tickets free of charge; a comp carries no price and cannot be requested by a buyer, the only routes to one being two escrow entry points that admit the event's own organizer and nobody else. A comp takes one of two forms. A seatless comp must first be enabled by setting a comp face value. That face value is the basis the resale ceiling is computed from rather than a charge, and setting it to zero both disables seatless comps and is refused at issue, since a ticket recorded at a price of zero would be uncapped for resale. A seatless comp carries a reserved tier that no section name a buyer supplies can ever reach, and that tier is refused sale outright on this platform's own marketplace: a refusal unrelated to redemption, and one that reaches only sales conducted through this platform's marketplace, so a holder may still transfer a comp directly or list it on a venue outside this system. A seated comp needs no face value and is issued through the same path as a purchased seat, under that section's tier and recorded at that section's configured price, so it is not refused sale and resells on this platform's marketplace under the same ceiling as a purchased ticket for the same section. Both forms remain subject to the event's cancellation and sale cutoff.

Redemption is recorded on chain, and the record is enforced only against re-use, not against transfer or resale. A holder, or a redeemer the organizer has authorized, may mark a ticket redeemed; the contract deliberately does not consult that flag when deciding whether a sale is permitted, so redemption alone never blocks a transfer or a resale, and a redeemed ticket remains transferable and remains sellable on this platform's marketplace provided the sale is otherwise permitted. The record exists so that an application can display the state rather than so that the contract can act on it.

Enforcement reaches only the contracts configured to consult this one, and the two integrations fail in opposite directions: an escrow whose pointer is unset refuses to sell tickets, while a marketplace whose pointer is unset sells them without enforcing the sale cutoff or the resale ceiling. Whether each pointer is set is live chain state rather than a property of the source; both were read as set on 9 August 2026 and were re-confirmed set on 9 September 2026 on Base, the only chain where either contract is deployed, and §14.9 records the event that would make that false. The pause control is held by governance and by the owner and is not ended by Immutable Finalization; on this contract governance is presently unset, so in practice only the owner holds it, a gap §14.9 also records. It suspends event creation and most configuration, seat claims and redemption, while leaving the sale check answering, leaving ticket recording open, and leaving the escrow's own seat release open so that a paused contract cannot strand a buyer's committed funds; an organizer may still cancel an event and authorize door redeemers. It does not suspend settlement on the mint escrow, so a ticket committed before the pause is still minted and its organizer still paid while the pause stands; and because version 1.11.0, published on 11 September 2026, no longer suspends recording, that ticket is recorded with its resale ceiling and its seat, and becomes redeemable when the pause is lifted.

Detailed mechanics for every contract in this section are set out in Appendices AS, AT, AV, AW, AX, AY, AZ, BE and BF.

12. Core System Invariants

The preceding sections describe USSE's economic, governance, and data-integrity mechanisms in full. This section formalizes the subset of those mechanisms that function as permanent, non-discretionary guarantees, meaning architectural constraints enforced at the contract level rather than by policy. Each invariant below is a compressed, load-bearing restatement; see the cross-referenced section for the complete mechanism.

One qualification governs the whole section. Each invariant is enforced by the implementation deployed at the address that holds it, and most contracts in this system remain upgradeable behind UUPS proxies. An invariant is therefore a property of the current implementation rather than of the address, for as long as an upgrade path to that implementation remains open. Immutable Finalization settles that authority, and it does not settle it the same way everywhere: in some contracts upgrade authorization closes altogether, and in others it passes to the governance address and the implementation remains replaceable by that address. §14.1 states that exposure in full. The difference between the two forms is material to §12.1 and §12.3, and each Smart Contract Appendix identifies its own contract's upgrade pattern in its §12.

12.1 Fixed Supply Invariant

The total token supply is permanently capped and created exclusively through the Genesis Mint, with no mechanism to create additional supply beyond that cap. The genesis call is single-use and the token contract declares no other minting function. Upgrade authorization over that contract is held by the owner before Immutable Finalization and closes at it for every party, rather than passing to the governance address, so this invariant is not subject to governance modification at any stage. Until that contract is finalized, it rests on the owner key that holds the upgrade authorization, on which see §14.1. See §6.1.

12.2 Time-Based Issuance Model Invariant

Circulating Supply growth follows the Time-Based Issuance Model and Triennial Unlock Cadence. Tranche size and interval are fixed constants that no configuration function or governance proposal can enlarge, and no mechanism creates supply beyond the Genesis Mint. Release timing is subject to the anchor, pause, and off-schedule migration qualifications stated in §6.3 and §6.6. The Circulating Supply the token reports also depends on the Reserve Vault address the token stores, which the token's manager can repoint until the token is finalized, as §2 and §7.4 note. See also §6.7.

12.3 Governance Boundary Invariant

Governance may adjust policy-level parameters within predefined contractual constraints. None of the Fixed Supply Invariant, Genesis Mint, Time-Based Issuance Model, or Triennial Unlock Cadence is held as a governance parameter, and no configuration function reachable by governance writes any of them. Upgrade authorization is a separate question and does not resolve the same way for all four. On the token contract, which enforces the Fixed Supply Invariant and the Genesis Mint, it closes at Immutable Finalization for every party. On the Reserve Vault, which is where unlock timing and tranche amount are enforced, it passes to the governance address at finalization instead of closing, and the tranche size and the interval are compile-time constants of that implementation rather than stored parameters. The Time-Based Issuance Model and the Triennial Unlock Cadence are therefore bounded after finalization by the custody of the governance address rather than closed to it, which is the general position §14.1 records and the reason the Governance Authority Matrix's custody of that address is load-bearing. That custody matters before finalization as well: the Reserve Vault's migration function, reachable by the governance address alone and not closed by finalization, transfers the entire remaining reserve to an address the caller names, so the schedule binds the reserve only while that function goes unexercised (§6.6). A read on 11 September 2026 found no governance address set on the Reserve Vault, so that function was then reachable by no party. See §6.8, §7.2.

12.4 Separation of Duties Invariant

Custody, authorization, accounting, and execution functions are separated so that no single module both defines the policy governing a movement of value and holds discretion over its execution: allocation percentages and destination addresses are set through the configuration surface and applied by contracts that compute against them without the ability to vary them. The separation is one of authority rather than of address, and two qualifications belong alongside it. The first is that the treasury contract both holds balances it distributes and maintains the ecosystem value-movement ledger, and on its ether side reported entries and received value increment the same counters, so that ledger measures reported plus received value rather than serving as a custody record and should not be reconciled against the contract's balance; Appendix M §11 states this in full. The second is that the separation is not complete within every module: the treasury contract's governance address both sets that contract's allocation percentages and holds the sweep and rescue powers §8.3 names, each exercised to a destination and for an amount of its choosing, and the program-wallet registry's owner both sets its spending policy and holds the direct transfer outside it that §8.2 describes. This invariant concerns the separation of function; it does not by itself constrain which parties may invoke a given function, on which see §7.4. See also §7.5, §8.1.

12.5 Immutability of Recorded Data

Once recorded, Integrity Commitments, governance actions, issuance events, and treasury entries cannot be retroactively altered or deleted through any function the recording contracts expose. The governance audit log is append-only and declares no delete or update path at any privilege level, the owner included, and the treasury ledger declares no correction or reversal function, so an erroneous entry there cannot be withdrawn, and only a token entry, which records whether it is an inflow or an outflow, can be offset by a further entry; Appendix J §11 and Appendix M §11 state each in full. Policy may evolve prospectively, and recorded entries remain intact. The durability of that guarantee rests on the transaction log rather than on what a contract reports, and the distinction is one of mutability rather than of location: both are on-chain, but events and calldata are written into the chain's history, which no upgrade can reach, while the values a contract's view functions return are a property of whichever implementation is deployed when they are called, under the qualification stated at the head of this section. A party verifying a historical record should therefore treat the event stream as authoritative and the view functions as a convenience. See §8.3, §9.2, §14.1.

12.6 Deterministic Enforcement Invariant

System behavior is governed by deterministic Smart Contract logic rather than discretionary intervention across supply movement, financial routing, and Integrity Commitments: amounts, destinations, and eligibility conditions are computed by contract logic at the moment of execution and are not open to case-by-case adjustment. The recovery powers and the direct program-wallet transfer named in §8.2 and §8.3, each exercised to a destination and for an amount the caller chooses, and the reserve migration described in §6.6, sit outside that description; they are bounded by who may call them rather than by computation. Determinism governs how an action executes, and it does not by itself make every action unconditional or automatic. Scheduled supply movement carries the anchor, pause, and off-schedule migration qualifications §12.2 records, and the release call is permissionless rather than automatic, so a tranche that has come due is released when some party pays the gas to call it. The execution of an authorized governance action is likewise deterministic; which parties may authorize one is qualified during the transition period by §7.4. See §5, §9.1.

13. Real World Use Cases

Three products carry the coordination, communication and digital asset capabilities described above to users, each serving both organizations and individuals. TheWall is the public social platform described in §10.1. DEEP Mail is the encrypted messaging system described in §9, carrying payments and files alongside a message. The Media Marketplace is the digital asset layer described in §11, covering music, art, and event ticketing. Token acquisition, trading, staking and incentive participation are separate surfaces, described in §6, §8.4 and §15.4 rather than here. The sectors named below are illustrations of where these capabilities apply, not representations that the protocol satisfies any sector's regulatory requirements.

Each subsection states what the activity described costs the party undertaking it and where that value goes, since use is what connects these products to the economics §6 and §8 describe. Almost every write across the three is fee-bearing, and those fees are routed through FeeManagement under Deterministic Routing to the destinations §8.2 states rather than to an account chosen when the payment arrives. Each subsection names the actions in its own product that carry no fee, and three exceptions to the routing are stated where they arise: an action submitted through the trusted forwarder is metered off-chain instead, on the basis §10 sets out; the content-upload path forwards what it collects to a single configured address; and a key registration paid directly on Base goes whole to a single treasury wallet, because the key registry on that chain has no FeeManagement address configured. What volume of activity these products will attract is not projected here.

Identity beneath all three. NameRegistration allows a wallet to be addressed by a chosen name rather than by a hexadecimal identifier, and ProfileRegistry and ContactRegistry allow a persistent on-chain identity and a curated contact network without reliance on a centralized platform. The same identity carries across all three products. Two limits belong with that control, and Immutable Finalization ends neither: a profile can be deleted without its holder's consent by the contract owner or by governance, and administrative action can reassign or delete a name registration. §10.2 and §10.4 record both, and a holder's continued control rests on those powers not being exercised rather than on a contract guarantee. Profile content is self-asserted rather than verified and establishes no identity beyond the wallet that registered it.

13.1 TheWall: Public Statements and Audience Control

TheWall is a public record rather than a feed. What it stands in for is a publishing arrangement in which the platform carrying a statement also decides whether it stays visible, and it removes that decision from every party including the protocol's own: posts are ordered chronologically at the contract level, no administrative path deletes or hides one, and the text of a post is written to an on-chain content store and carried in the event log, where any party can recover it, a post created through an upload pathway being refused unless its text was stored first, as §10.1 sets out.

Corporate statements and public attestations. An organization can publish a statement to a durable public record without relying on a centralized intermediary, and a reader can establish what was said and when without trusting the publisher's own archive. This suits corporate announcements, editorial and journalistic provenance where the question is whether a published piece was later altered, and any disclosure whose value depends on it being demonstrably unedited. Each post is permanent in the event log and alterable by nobody, its own author included, as §10.1 records.

Personal statements of record. For an individual the same properties give a tamper-proof record of personal assertions that no administrative action can remove and that no party can alter, its own author included. Where the publishing wallet has registered a name and a profile, successive statements accumulate against one persistent identity rather than against a hexadecimal address, so a reader can follow an author across time without a platform account mediating the connection.

Work that must outlive the platform carrying it. Media uploaded through TheWall is stored on-chain in chunks, each checked on submission against a Merkle root the author committed to, so a published work does not depend on a server or a hosting account remaining available; the whole-payload hash the upload declares is recorded rather than checked on-chain, as §10.1 sets out. An author whose archive would otherwise sit behind a platform account instead holds the work itself on the same terms as the post announcing it, which is what an archive, a journalistic record, or a body of creative work needs when the question is whether it survives the service that hosted it.

Audience control that no intermediary can override. Following, unfollowing, blocking, and unblocking are actions a reader takes over their own view, and each is free of the protocol fee that publishing and engagement carry. The report signal is free on the same basis and records a flag against a post without changing that post's standing, emitting an event and carrying no on-chain consequence. Because §10.1 establishes that no path at any privilege level deletes, hides, or bans, and that no ranking layer sits between a reader and the chronological record, there is no intermediate power to suppress a post short of removing it, and no power to remove it either. For a publisher whose concern is being quietly buried rather than being taken down, that absence is the substance of what the layer offers.

What it costs and where that goes. A post submitted directly carries a protocol fee of the greater of 10% of a fixed gas estimate priced at the current gas price and a $0.03 USD minimum, routed through FeeManagement under Deterministic Routing to the destinations §8.2 states. A post submitted through the trusted forwarder carries no on-chain fee and is metered off-chain instead. Reading, following, blocking and reporting cost nothing at any time. §10.1 states how the USD floor is resolved and what governs it where no price feed is configured.

What it does not establish. TheWall establishes that a wallet published a statement at a time, and that the statement has not been altered since: the contract exposes no function that edits a published post, so there is no window during which an author or anyone else may revise one, on the terms §10.1 records. It establishes nothing about whether a statement is true. The two deployments are independent, so neither a post nor the social graph around it crosses chains. And permanence rests on the event log rather than on what the contract reports, which here is also a statement about where the text is: a post's text is not a struct field at all, so it is written to the content store as contract code and carried in the PostContentStored log, both of them beyond the reach of any later transaction or upgrade, while the stored hash and the index a contract reports are a property of whichever implementation is deployed, as §12.5 states generally and §14.1 records as an exposure. A post created through the authenticated or prepaid upload pathway emits no such log, and is refused unless its text was written to the store first.

13.2 DEEP Mail: Encrypted Messaging, Payment and Files

DEEP Mail carries an encrypted message with either a reference to a file or a payment in a single transaction, and carries both together on the group transfer path; of a file itself the contract keeps only a hash. What it stands in for is an arrangement in which the correspondence, the document and the payment sit in three separate systems and have to be reconciled afterwards by whoever disputes them. Message content is encrypted before it is sent and travels on-chain in that form; what the contract retains is an Integrity Commitment together with routing metadata, so the record proves that a specific message existed at a specific time between specific parties while what it said stays readable only to the parties holding the keys. §9.1 states what that metadata includes and where confidentiality stops.

Private payment with an authenticated record. A payment and the message describing it share a transaction context rather than living in separate systems, which reduces ambiguity about what a payment was for without exposing its contents.

Payroll and coordinated disbursement. An organization can execute payroll, revenue sharing, or a coordinated disbursement as a single atomic on-chain operation, alongside the encrypted message that documents it. GroupTransferHelper takes one amount and divides it evenly among a message's recipients; CustomSplitHelper takes a list of recipients with a requested amount for each. One property governs how the figures should be read, and it matters wherever they are contractual: the protocol fee is charged on top of the amount being distributed rather than deducted from it, so on CustomSplitHelper each recipient receives exactly the amount named for them, and on GroupTransferHelper the whole total the caller names is divided evenly among recipients, any remainder too small to divide being returned to the caller. The paying party therefore supplies the distributed amount, the fee on it and the messaging fee, and any excess over those is refunded to it. Earlier CustomSplitHelper deployments that deducted the fee and scaled each payment down in proportion remain on-chain and callable, so this arithmetic holds for the current deployments only. On both helpers the message is recorded on-chain against the helper contract rather than against the paying organization.

Milestone and contract execution records. Counterparties can associate a payment with an authenticated confirmation, a milestone acknowledgment, or a record of contractual execution, without a centralized intermediary holding the evidence. This suits shipping and logistics, where chain-of-custody and delivery acceptance are disputed after the fact; professional services, where an engagement record and its associated billing need to be tied together; construction and other staged work, where release of funds follows an acknowledged milestone; and healthcare administration, where supplier, billing and authorization traffic must be both confidential and auditable.

Recording who was authorized to act. An organization coordinating through DEEP Mail can hold a persistent representation of its own authority structure, so that who could authorize a given step, and when, is recoverable from the same chain as the messages and payments themselves rather than from an internal system the counterparty cannot see. OrganizationHierarchy accommodates entities of any kind: companies, departments, teams, committees, working groups, and delegated-authority structures. It records node types, role assignments, member enrollment, and per-member job titles. A job title is a descriptive label held alongside a member's role rather than a substitute for it, since permissions are determined by the role alone, and it is membership context that does not survive its holder's removal.

Program and policy coordination. An organization that makes decisions collectively can use this infrastructure to coordinate and document them. Funding allocations and program-level actions can be agreed through authenticated messaging, settled through the payment paths above, and left as an on-chain record a third party can reconstruct independently. The organization's own authorization happens outside these contracts: USSE's governance contracts govern the USSE protocol itself, as §7 describes, and are not a governance service for other entities.

What it costs and where that goes. A payment sent with a message carries a protocol fee of 0.33%, charged on top of the amount its recipients receive rather than deducted from it; that holds for a payment to a single recipient through the messaging contract, in ETH or in an ERC-20 token, and for both disbursement helpers. On CustomSplitHelper that rate is fixed at deployment and no function can change it; on GroupTransferHelper, and for the messaging contract's own transfer fee, it is a stored value an owner or governance setter may rewrite up to a compiled ceiling of 10%, and §14.9 records the GroupTransferHelper rate in force and the authority over it. Sending a message and writing to an organization's structure each carry a protocol fee routed through FeeManagement under Deterministic Routing to the destinations §8.2 states, a group message being charged once for each recipient, with seven organizational operations exempt as §10.5 sets out. Registering a key carries a flat fee of 0.001 ETH on both chains, the key registry's gas-based pricing being switched off, and whatever is sent with a registration beyond any relay fee is kept as fee rather than refunded; paid directly it is divided across the FeeManagement destinations on either chain, the Base key registry having been pointed at its FeeManagement instance on 30 September 2026; until then it sent the whole fee on Base to a single treasury wallet. Declining an organization invitation carries no fee, but cancelling one does, and in group messaging declining an invitation, withdrawing one, and leaving a group each carry the standard fee.

What it does not establish. The structure provides evidentiary material rather than a compliance determination: whether it satisfies the recordkeeping, supervision, or audit obligations applying to a particular institution is a question for that institution and its advisors, and the protocol makes neither that determination nor any attestation of compliance. Two limits belong with it. Confidentiality covers a message's content and not its context, the participating addresses, the timestamp, the fee, the attachment hash and the topic all being recorded in the clear, as §9.1 states. It is also durable rather than permanent, each message's encrypted key being held in contract storage for the life of the deployment, so a party who separately holds the encrypted body could read it at any later date if that encryption were broken; §14.6 records both as risks. And membership, role and hierarchy changes are permanent in the event history while the current-state view is not, since the contract exposes paths to remove a member, remove a node, and deactivate an organization; accountability therefore rests on that history, the distinction §12.5 draws elsewhere.

13.3 Media Marketplace: Mint, Buy, Sell and Play

The Media Marketplace is where music, visual art, and event tickets are issued, sold, and traded on. It runs on the digital asset layer described in §11, deployed on Base. Three parties meet in it, and what each of them can rely on differs.

The creator: terms that are settled at issuance rather than administered afterwards. A creator issues a unique work as an ERC-721 token or a multi-copy edition as an ERC-1155, and that choice is also the choice about scarcity: an edition is created either with a copy ceiling no later function can raise, or with none at all, and §11.2 states how each behaves. Scarcity, or its deliberate absence, is therefore a property of how an edition was created rather than a parameter under continuing administrative control, which is what a creator cannot obtain from a platform retaining the ability to reissue. A royalty of up to 10% per token can be attached, a ceiling both collections enforce, and the edition pipeline lets a creator pre-pay for a small buffer of pieces and have each sale fund the mint of the next, so a long edition need not be funded in full before it begins. Content uploaded on the authenticated path is stored on-chain in chunks and authorized by a signature from the work's author rather than by whoever submits the transaction. Both collections also accept a conventional off-chain metadata reference, so whether a work carries its own content or points at a file held elsewhere is settled by how it was minted.

Royalty is a claim recorded, not a charge collected. A creator relying on the 10% ceiling should read what the standard does. Royalties follow ERC-2981, which records who should receive a royalty rather than charging it, so one is paid where the venue handling a sale honors it and is not paid where the venue does not. The protocol's own marketplace honors it conditionally, and §11.3 states when it pays none and which of those conditions the contracts themselves enforce. A royalty attached at issuance is therefore a term other venues may observe rather than a guarantee of collection.

The collector: what buying here does and does not secure. A collector buys at a stated price, and the record of issuance and every subsequent transfer is public. There is no auction or bidding mechanism: a listing states a price, and a buyer either meets it or does not. What a buyer pays is the listed price plus the platform fee and the cost of settling the purchase across the two chains, and what a seller receives is the listed price less any royalty owed, those charges being a premium on the buyer rather than a deduction from proceeds. Where the payment is made is worth knowing before making one: the listing sits on Base but the money is paid on Ethereum, into a payment escrow, and the token is delivered on Base once that payment has been settled across. A seller is credited rather than paid, and collects by withdrawing on Ethereum. A buyer whose payment has not yet been settled holds a refund against that escrow, callable once a short delay has passed; settlement closes it, and because settlement precedes delivery, a purchase that has been settled but not yet delivered can be completed only by delivery on Base. §11.3 sets out the sequence and what each step depends on. Three properties bear directly on what holding means here. A listing takes hold of the work it offers: a unique work, like an edition copy, is held by the marketplace from the moment it is listed until it is delivered or delisted, so an open listing is assurance that the asset is there to be bought. And both collections treat a marketplace address configured by governance or by the owner as approved to move every holder's tokens, whether or not that holder has listed anything, and a holder who revokes that approval does not thereby withdraw it. Trading can also be suspended, by the owner or by governance and on terms Immutable Finalization does not end, and while a suspension stands no new listing, binding of a purchase or delivery completes on Base. Delisting remains open, so a seller can recover a listed work that no purchase is bound to, but a buyer whose purchase has already been settled on Ethereum waits for delivery until the suspension is lifted. §11.3 states the listing paths and the pause, and §14.2 the risk that standing approval creates.

Playing what you own. A buyer of an album, a film or a book holds it as a token rather than as a licence a platform can revoke, and plays, watches or reads it from the application at no protocol fee and under no subscription, retrieval being a read of chain data rather than a transaction. Owned media, minted or bought, is presented together there. Media listed for sale is held separately, a listed work of either kind having been escrowed to the marketplace while its listing stands. A work whose content was stored on-chain remains retrievable for as long as the network persists, with no hosting account or subscription standing between a holder and what they bought; a work minted against an off-chain reference depends on that content remaining hosted. One further limit belongs with the first case: on the ERC-721 collection the contract owner can repoint a token's metadata at any time, a path that carries no governance mirror and that Immutable Finalization does not end, its stated purpose being the correction of broken metadata. The edition collection has no equivalent, an edition's reference being written only when it is created.

The event organizer: resale terms that travel with the ticket rather than with the venue. An event organizer issues tickets as tokens, and the ticket's own terms are fixed by contract rather than by the policy of whichever platform handles the resale. USSETicketing holds the authoritative record of what a ticket is: the event it admits to, the seat it names, the tier it was sold under, the price it was sold at, and the ceiling it may be resold at. It answers two questions for the contracts that consult it, whether a seat may be claimed and whether a ticket may be sold at a given price, and it takes custody of no token and no funds. Each ticket captures its own resale basis when it is minted rather than reading the event's setting at the moment of resale, so a ticket already sold keeps the ceiling it was sold under and changing an event's default later does not re-base it. Each event also carries a sale cutoff, which refuses marketplace sales from that time and does not restrict transfer, and the organizer is the only party that may configure either.

What it costs and where that goes. Minting on either collection carries a dynamic ETH fee, priced against prevailing network conditions rather than fixed in advance, and the marketplace's platform fee is a proportion of the sale added to the buyer's payment. Both are distributed across nine of FeeManagement's ten wallet categories, the mint fee when it is collected and the platform fee when the purchase settles on Ethereum, reaching the same Treasury System destinations as the protocol's other fee-bearing flows. The content-upload path is the exception recorded in §11: it forwards what it collects as a single undivided transfer to one configured address rather than through that split. A marketplace purchase is not submitted through the trusted forwarder at all: the buyer pays on Ethereum and the marketplace's own purchase functions are retired, so the forwarder fee waiver §10 describes for the identity and publishing actions never reaches a purchase. A mint called on either collection directly through the trusted forwarder is, by contrast, exempt from that collection's mint fee, as §11 records.

What it does not establish. Enforcement of a ticket's terms depends on the contracts around it being configured to consult USSETicketing, and the two integrations fail in opposite directions: an escrow whose pointer is unset refuses to sell tickets, while a marketplace whose pointer is unset sells them without enforcing the sale cutoff or the resale ceiling. Whether each pointer is set is live chain state rather than a property of the source; §11.5 records the reading and its date, §14.9 the event that would make it false, and Appendix BE states the dependency in full. Nothing in this layer reaches a sale conducted on a venue outside it. Within it, the cutoff binds only where an organizer has set one, while the ceiling applies by default, at 110% of a ticket's recorded price unless the organizer names another; both bind only where the pointer above is in place and only for a ticket the contract has recorded, and a ticket in a tier priced at zero carries no effective ceiling. The royalty is a claim this marketplace honors conditionally rather than a term any venue enforces. All three travel to another venue only as terms it may choose to observe.

13.4 The Three Products Together

Each product stands alone, and an organization may use one without the others. Used together they work from a single wallet identity: a company registers a name and a profile, publishes an announcement to TheWall under it, contracts and settles through DEEP Mail with the payment carried in the same transaction as the message documenting it, holds its own authority structure on-chain so that who could authorize a given step remains recoverable afterwards, and issues the resulting work or ticket through the Media Marketplace under that same wallet. Every step leaves a record a third party can reconstruct without the company's cooperation, and none of them rests on a platform account another party can withdraw. Which chains carry which registry differs, as §10 records, and the digital asset layer is deployed on Base, with its content-upload registry also on Ethereum and every marketplace purchase paid and settled on Ethereum through the payment escrow §11.3 describes. What the composition adds is not a capability unique to any one of the three but a single identity and a single reconstructible record across all of them.

14. Risk Factors and Limitations

Participation in the USSE ecosystem involves risks inherent to decentralized systems, cryptographic infrastructure, evolving regulatory frameworks, and market conditions. The following factors are presented to provide transparency into material considerations that may affect the protocol, its operation, and its adoption. The list is not exhaustive, and further risks may arise over time.

14.1 Technical Risk

USSE relies on Smart Contracts and cryptographic systems that, although built with security controls, have not been externally audited as at the date of this document and may contain undiscovered vulnerabilities. Software defects, integration errors, or unforeseen interactions between protocol components could result in unintended behavior, temporary disruption, loss of functionality, or loss of value. Although deterministic execution, separation of duties, and immutable recordkeeping reduce operational exposure, no complex software system can be guaranteed to be free of defects.

Five specific characteristics of this deployment warrant separate statement.

Most contracts are upgradeable. The majority of USSE contracts are deployed behind UUPS proxies, which means the code executing at a given address can be replaced while the address itself, together with every balance and record held at it, remains unchanged. The behavior described in this document and its appendices is therefore the behavior of the implementation deployed at the date of writing, not a permanent property of the address. Immutable Finalization settles upgrade authority rather than uniformly ending it: in some contracts it closes upgrade authorization altogether, and in others it transfers that authorization to the governance address and excludes the owner permanently, so that the implementation remains replaceable by governance after finalization. What finalization settles in that second form is the exclusion of the owner, not the identity of the address that succeeds it: finalization does not freeze the governance slot, and where a contract exposes a governance-gated function that rewrites it, whoever holds the slot can move that authority to another address without a further upgrade. Each appendix's §12 states which upgrade pattern that contract follows and what finalization does and does not end. A minority of contracts are not upgradeable at all, among them the shared libraries, the AMM contracts, and the gas-abstraction forwarders described below. These carry the converse exposure, that a defect in them cannot be corrected in place.

Certain functions depend on an external price feed. Many of the contracts that charge fees express a minimum in USD and read a Chainlink-compatible aggregator to convert that figure to ETH. Two distinct failure modes follow. Where a feed address is configured and its answer is unavailable, non-positive, or older than the staleness bound that contract applies, being one day compiled in for most and a stored parameter in at least one, the read reverts and the action halts rather than settling at a wrong price; not every affected contract has a pause through which such a condition could be managed, and in several the fee is computed before the gasless path is tested, so relayed calls that owe no on-chain fee revert alongside paid ones. Where no feed address is configured at all, the conversion does not halt but falls back to a fixed rate compiled into the contract, which does not track the market; the appendices identify the contracts in which that fallback rate is itself inaccurate. The dependency is one of availability as well as accuracy.

Cross-chain transfer relies on relayer authorization rather than proof. The bridging contracts take USSE into custody when a transfer is initiated and release it when a transfer is reported complete, on the authorization of an approved relayer or of the contract owner. No cryptographic proof of the source-chain event is verified on-chain, no destination chain is checked against an allowlist, and the bridge adapter is deployed on Ethereum alone, so both halves of a transfer act on the same custody balance rather than on a counterpart contract elsewhere. The per-call release bound that would limit a compromised key is maxReleaseAmount, which the contract reads as no cap when it holds zero rather than as a bound of nothing; a live read on 14 September 2026 returned zero for it on the deployed adapter, so no such bound was in force on that date. It is written by setReleaseLimit before Immutable Finalization and by a governance mirror that finalization does not close, so the bound can be established at any time by either party. That bound sits on the adapter alone. The custody contract also releases its balance, in any amount and to any destination, on a direct call by its own owner, a path that the adapter's release bound, its replay protection and its pause do not reach and that Immutable Finalization does not close; the custody contract held no USSE at a live read on 11 September 2026. Relayer and owner authorization is therefore the whole of the trust model for bridged transfers, and the security of a bridged position depends on the operational security of those keys rather than on contract logic. Appendices AD and AE set this out in full.

Gas abstraction concentrates on a single contract. Gasless interaction on Base depends on a trusted forwarder contract that is non-upgradeable and that submits only on behalf of an owner-approved relayer set. An empty or stale relayer allowlist suspends gasless submission for every contract trusting that forwarder at once. Failure here degrades convenience rather than custody, since every affected contract remains reachable directly. The user-facing experience of the protocol nonetheless depends on infrastructure that cannot be patched in place and can only be replaced by re-pointing each dependent contract individually. The forwarder is also the fee-bypass path described in §10: an action it submits pays no on-chain fee on the contracts whose fees are charges rather than payments, and is metered instead by an off-chain relayer against a payment recorded on Ethereum, with nothing on-chain binding the two together. Control of the forwarder is therefore control of a route that transacts on those contracts without paying them. Appendix BD describes the forwarder presently in production.

Several optional limits are inactive until configured, and a zero value does not mean the same thing throughout the system. A number of contracts express a bound as a parameter that the deployment left unset, so the deployed state is whatever that parameter holds in contract storage before an operator sets it, which is zero for each contract named below, with one qualification for the staking emission ceiling: a staking pool created now records an explicit uncapped value rather than zero, which the contract treats the same way. In most of those contracts a zero is read as "no limit" and the check is skipped in full: the bridge's per-call release bound described above, the referral programme's Epoch budget, and a staking emission ceiling all behave that way, so each ships permissive and becomes restrictive only once a configuration transaction is sent. The treasury is not among them, and its case is the stronger one: there is no withdrawal cap to configure. Its outward paths are an ETH sweep and an ERC-20 rescue, each unbounded in amount and in destination, and what stands in front of them is who holds the governance address rather than any parameter, as §8.3 records. In at least one contract the same value is read the opposite way: the contact registry's outstanding-invite limit is tested such that zero rejects every invite, and that deployment was consequently blocked on both chains until the value was set in August 2026. The consequence for a reader is that an unconfigured parameter cannot be interpreted without reading the contract that holds it, since the safe default is permissive in some places and prohibitive in others, and the deployed behaviour of a limit is a matter of live chain state rather than of the source. Each appendix states which convention its contract follows and what the parameter's shipped value was at the date of the live reads recorded in §1 of that appendix.

14.2 Protocol and Governance Risk

The protocol incorporates governance mechanisms intended to balance decentralization with operational stability. Governance decisions may affect policy parameters, funding priorities, or operational configurations within defined constraints. Critically, no proposal or configuration function available to governance can alter the Fixed Supply Invariant, Genesis Mint, Time-Based Issuance Model, or Triennial Unlock Cadence, none of which is exposed as a governance parameter. That constraint operates on the configuration surface rather than on the upgrade path described in §14.1, and the two do not resolve identically for all four of those invariants; §12.3 states the difference. Governance outcomes may not align with the preferences of all participants, and participation levels, coordination dynamics, or concentration of voting power could affect governance efficiency or responsiveness over time.

Six characteristics of the present governance configuration are material. They qualify the proposal lifecycle described in §7.3, and §7.4 sets out the administrative routes in full.

Administrative authority is broader than the voting process during the transition period. §7.4 sets out the routes that operate alongside the proposal process and the contracts each one reaches. What follows from them for a holder is that the protections described in §7.3, being deliberation, a participation threshold, and a delay between decision and execution, are not in force at the date of this document, because no proposal can exist to be subject to them: proposal creation and voting revert until the DAO activation date recorded in §7.1. A parameter a holder might expect a vote to govern can therefore be changed by a single key without proposal, quorum, or timelock. Until Immutable Finalization the constraint on that is the security and discipline of the key holders rather than contract logic, and the separation of those keys is an operational practice that no contract enforces.

Governance authority on Base resolves through a relay contract. As described in §7.4, the address holding governance authority for several Base deployments is a relay contract that acts at its owner's direction. For a holder, the consequence is that governance authority over those contracts reduces to control of a single address: whoever directs that relay exercises governance authority over them, and separating that party from the governed contracts' own owner keys is an operational control rather than one enforced by contract logic. The governed contract holds only the address it names as governance, so identifying the arrangement requires inspecting that address rather than the contract relying on it. Appendix AH describes the mechanism.

Governance-configured addresses can carry standing authority over user assets. As described in §11.3, the NFT collections treat a governance-configured marketplace address as approved to move any holder's tokens, and a holder cannot withdraw that approval. Rotating that address is a governance action whose effect reaches every holder simultaneously, and the gate guarding it admits the owner as well as the governance address, so the owner may take it alone. Immutable Finalization does not close that power: the setter carries the governance gate and no finalization gate, so it remains available to both parties afterwards.

A contract whose governance address is unset cannot be governed through the voted route. Where a deployment holds a zero governance address, no party can act as governance: the functions behind the strict governance gate are unreachable until an address is configured, while those behind the gate that also admits the owner remain reachable by the owner alone. The contract is therefore administrable only through its owner. Whether a given contract is in that state is a live property of the deployment rather than of its source code.

Governance can move pooled assets directly, and Immutable Finalization closes neither route. The Reserve Vault exposes a migration that transfers its entire remaining balance to an address the caller names, gated to the governance address alone and expressly excluding the owner, and validating that destination only against the zero address; §6.6 describes it as the second of the reserve's two exits. The treasury contract separately exposes an ETH sweep and an ERC-20 rescue, each to a destination and for an amount of governance's choosing and neither excluding the managed token, as §8.3 records. None of the three carries a finalization gate. What follows for a holder is that the reserve and the balances the treasury holds are reachable in a single transaction by whoever holds the governance address on those contracts, which is the question the characteristics above and §7.4 address.

Voting weight is measured against staked principal, and until the model is armed the vote rests with the signer set. Under the open-participation model GovernanceContract measures every proposal against total staked principal and refuses to create one while no stake exists, as §7.3 records. A small staked total therefore produces a small denominator, and the absolute holding required to meet the proposal threshold, to contribute the maximum permitted share of a tally, and to reach quorum falls with it. The per-voter cap described in §7.3 is itself a proportion of that same basis, so it bounds any single voter's share of a tally without offsetting the effect; neither route that arms the model can leave that cap at zero, which the contract would read as no cap. The basis is fixed when a proposal is created, so this varies proposal by proposal. Until the model is armed, eligibility to create and to vote on a proposal rests with the contract's signer set, one vote per signer, and at the date of this document that set holds the owner's key alone, so once the activation date arrives the voted route would be exercisable by that key.

14.3 Economic and Market Risk

The value and utility of USSE may be influenced by broader digital asset market conditions, liquidity availability, adoption rates, and macroeconomic factors. Token price fluctuations may occur independently of protocol performance or system integrity.

Liquidity conditions may vary across venues and over time, potentially affecting execution costs, market depth, or accessibility. Third-party venues are outside the protocol's control, and nothing in this document is an assurance that a market for the token will exist, continue, or be accessible from a given jurisdiction.

Protocol activity and holder return are separate things, and a reader assessing the token on the strength of the fee model should hold them apart. The fee-bearing flows described in §8.2 route to the Treasury System destinations named there, and no contract path pays anything to a holder in that capacity, so growth in fee-bearing activity increases what those destinations receive rather than what a holder receives. §15.2 records the corresponding corporate position, that ownership of tokens conveys no claim on the revenues of United States Secured Exchange, Inc.

Which fee profile governs the token's fee routing is not fixed for all time either. §8.4 describes a one-time change that takes effect when a single owner transaction is sent, and §14.9 records the present state of that flag as a matter to be confirmed on-chain rather than inferred from the date on this document.

Circulating Supply is constrained by the Time-Based Issuance Model, but the genesis allocation is not itself subject to a contractual release schedule enforced on-chain. As §6.5 records, the on-chain vesting mechanism is deployed but has not been used to create a schedule, and whether that remains so is readable on-chain. While no schedule exists, allocations distributed at genesis are constrained by whatever lockup the applicable offering documents impose and by any restriction on resale arising under applicable securities law, rather than by a vesting contract. The destination locking described in that section fixes where three of those allocations are sent; it does not restrict onward transfer from the addresses that receive them. Participants evaluating potential sell-side pressure should assess those instruments rather than infer a schedule from the allocation table.

14.4 Regulatory and Legal Risk

Regulatory treatment of digital assets continues to evolve across jurisdictions. Changes in laws, regulations, or enforcement priorities may affect how USSE can be used, distributed, or accessed in certain regions, and may introduce new identity verification, reporting, or transfer-restriction requirements over time.

The positions this document takes on those questions are the company's own rather than determinations any authority has made for it. §15.4 records that no securities regulator has registered, approved, or passed upon the offering or this document, and §15.3 that this document characterizes the token for no regulatory purpose, the characterization of a digital asset depending on the facts and circumstances of its offer, sale, and distribution. A regulator, a court, or a jurisdiction reaching a different conclusion later could affect how the token may be offered, transferred, held, or listed, and what would follow for the offering and for its purchasers in that event is determined by applicable law rather than by anything stated here.

The compliance conditions applying to a holder are administrative settings rather than fixed terms, and a holder is exposed to whoever holds the authority to write them. The sale stage, the lockup duration, and an individual account's lockup expiry are each rewritable by that authority at any time, and Immutable Finalization does not end it; §15.5 and §15.6 state the mechanism and who holds it, and §15.9 the resulting position that the rules freeze in code while the values they enforce against stay adjustable. A restriction can therefore be released early, or applied where none applied before, without a proposal, a quorum, or a timelock.

Nor does enforcement reach uniformly. §15.5 records that the sale contract's compliance check cannot be disabled by leaving it unconfigured, while §15.6 records that the token contract's transfer check is skipped where its registry address is unset. The protections described in §15 are conditional on configuration, which §14.9 collects as present state to be confirmed on-chain rather than assumed from this document.

One further limit belongs with all of it, and §15.6 states it in full: these on-chain restrictions are protocol mechanics rather than legal conditions, and their expiry or non-enforcement satisfies nothing under applicable law. A holder whose on-chain lockup has lapsed may remain restricted, and remains responsible for confirming that a transfer is permitted before making it.

See §15 for the full discussion of USSE's regulatory and legal posture, including the separation between protocol-level operations and corporate securities activities.

14.5 Operational and Infrastructure Risk

USSE depends on underlying blockchain networks, execution environments, and external infrastructure components. Network congestion, protocol-level upgrades, outages, or disruptions affecting these dependencies could impair performance, delay transactions, or limit availability.

While the system is designed to preserve integrity during disruptions, availability and uninterrupted execution cannot be guaranteed at all times.

A substantial part of the deployment runs on Base. The identity presentation and digital asset layers are deployed there alone, apart from the content-upload registry, and the messaging, social, naming, contact and organization layers each have a Base deployment alongside their Ethereum one, together with the Base side of governance relay and message transport. Base is an Ethereum layer-2 network whose sequencing and data availability are provided by infrastructure the protocol does not operate, and a disruption there affects the Base deployments without affecting the Ethereum ones; for a layer deployed on both chains it is the record held on Base that is affected, the two records being separate as §14.7 records.

Two dependencies are operational rather than contractual and should not be read as enforced by code. Several contracts share a name with an allocation category without holding any automatic funding relationship to it, as set out in §6.4: moving value from a Program Wallet into such a contract is an action taken by an operator, and a contract that has not been funded cannot pay, irrespective of the allocation reserved for that purpose. Separately, message batching and cross-chain anchoring depend on off-chain relayer processes to submit what the contracts record; the contracts enforce the integrity of what is submitted to them, not that submission occurs.

External price data is a further dependency, and unlike the two above it is enforced in code rather than operationally. Messaging fees and the fees on several identity and registry operations are computed against a minimum expressed in United States dollars and converted to the native asset through an external price feed at the time of the call. The contracts reject a stale answer, on the bound §14.1 describes. Where a feed stops updating, the affected calls revert rather than falling back to a stale or default price, and the consequence differs by contract: where the fee is computed on every fee-bearing call, the contract's write surface stops with the feed, while a contract that reads the feed only to display a quotation continues to settle.

14.6 Privacy and Key Management Risk

Although USSE is designed to preserve message confidentiality and data integrity, participants remain responsible for managing their own cryptographic keys and credentials. Loss, compromise, or misuse of keys may result in unauthorized access, or in the irrecoverable loss of control over the assets and records held under them.

While encrypted message contents are protected, the fact of a message is not, and neither is all of its context: the participating addresses, the timing, the fee paid, and the attachment hash are recorded in the event log, the message's topic is held in the message record the messaging contract stores and in the data of the submitting transaction, and group names and group topics are recorded in the event log, so all of them are permanently public. The topic is stored as a plaintext string rather than encrypted. Interaction patterns may also be observable at the network level. Message bodies are committed to chain in encrypted form. The messaging contract stores a hash of the encrypted message rather than the message itself, leaving the body in the data of the submitting transaction, while the Layer 2 message bus records a field its interface names the ciphertext, which the messaging contracts fill with the message's hash rather than the encrypted body, as §9.1 records. On either path the encrypted body is permanently public alongside the metadata above and is retrievable by anyone.

The key is another matter, and it is the reason confidentiality has a long horizon rather than a permanent one. Each message carries its encrypted symmetric key in contract storage, permanently and in encrypted form, and the encrypted body sits alongside it in the permanent transaction record, so both halves of what is needed to read a message are already publicly available and would yield its contents at any future point if the encryption protecting them were broken. Confidentiality therefore rests on the continued strength of the encryption applied at the time of writing, and any future weakness would apply retroactively to everything already recorded.

Content published to TheWall is committed to chain on a different basis again: it is public by design and is not encrypted at all, as §10.1 describes. The permanence that makes the record tamper-evident also makes it unrecallable: no contract in this layer declares a path that deletes a message or a public post once published. One qualification belongs with that guarantee, and it turns on the difference between contract state and the event log. A group's host may delete the group, which wipes its stored metadata, including its name and topic, along with its membership records. What is unrecallable there is the event stream, which no upgrade or later call can reach, rather than the values the contracts' view functions return; §12.5 states that distinction generally, and Appendix AU's §3.1 and §11, together with Appendix AM §3.2, set out each mechanism.

14.7 Adoption and Ecosystem Risk

The long-term viability of the ecosystem depends on sustained participation by users, developers, institutions, and counterparties. Failure to achieve meaningful adoption or integration could limit utility and network effects, and competitive technologies or alternative platforms may reduce demand for USSE-based systems.

Adoption is also divided between the two chains the protocol runs on, and the division is a property of the deployment rather than of a user's choice. The social, naming, contact and organization layers are deployed on both Ethereum and Base and share no storage between them, so a name, a posting history, a contact list or an organization established on one chain does not exist on the other and has to be established again to be used there. Deployment and use are not the same thing here: contacts are written by the application on Ethereum alone, as §10.3 records, so that layer's Base deployment holds nothing a participant put there. Identity presentation runs on Base alone, as does the digital asset layer apart from its content-upload registry. A participant's record is therefore per-chain, and network effects accumulate per chain rather than across the protocol as a whole; §4.7 states the principle behind the division, and §10 and §11 record which layer sits where.

14.8 No Assurance of Performance

To the maximum extent permitted by applicable law, the protocol is provided on an "as is" basis, without representations or warranties regarding performance, availability, or suitability for any particular purpose. Participation in decentralized systems involves inherent uncertainty, and participants should evaluate their own risk tolerance and compliance obligations before engaging with the protocol.

14.9 Statements of Present Configuration

Most of this document describes how the deployed contracts behave, which is a property of the code they run. A smaller set of statements describes what those contracts hold at a particular moment, and each of those is true as at the live reads recorded beside it rather than as a permanent property of the system. They are collected here with the event that would make each false, so that a reader relying on one can confirm it on-chain rather than infer it from the date on the cover.

Twenty-six statements are listed. None of them is a guarantee of continued state, and a reader relying on any of them should read the named value on-chain rather than rely on the figure recorded here.

15. Regulatory and Legal Considerations

This section sets out the regulatory and legal posture of the protocol and of United States Secured Exchange, Inc. One distinction runs through all of it and is easier to state once than to repeat: the protocol's on-chain compliance mechanics and the conditions of a securities offering are separate things. The contracts enforce access rules of their own, and a transfer those contracts permit is not thereby a transfer applicable law permits; a condition imposed by the offering documents binds whether or not any contract checks it.

The mechanics described below are configuration held by the deployed contracts rather than terms of an offering, and several of them are administrative settings that can be changed. Where a statement in this section describes what a contract holds at a particular moment rather than how it behaves, §14.9 collects those statements with the event that would make each one false. Nothing here is legal, tax, or investment advice, and §15.10 states that in full.

15.1 Nature of This Document

This whitepaper is technical documentation describing the USSE protocol as deployed. It is not an offer to sell, or a solicitation of an offer to buy, any security or other financial instrument, and it contains no offering terms, subscription procedures, offering price, valuation, or financial projections. Where the appendices set out the pricing mechanism a deployed contract implements, they describe contract behavior and state no offering price.

Any offer or sale of securities by United States Secured Exchange, Inc. is made exclusively through separate offering documents furnished directly to eligible investors; §15.5 states what eligibility requires. Those documents govern and control in the event of any inconsistency with this whitepaper. No person should rely on this document in connection with an investment decision, and nothing in it forms part of or is incorporated into any offering document unless expressly stated in that document.

15.2 Separation of Protocol and Corporation

The protocol operates as software governed by deterministic Smart Contract logic deployed to public blockchain networks. Once deployed, protocol behavior is determined by that code within the authority boundaries described in this document, and remains subject to the upgrade and administrative authority set out in §14.1 and §14.2.

United States Secured Exchange, Inc. is a separate legal entity. Its corporate activities, including any securities offering, equity issuance, or regulated financial activity, are distinct from protocol-level operations, are governed by applicable federal and state securities laws, and are conducted pursuant to separate offering materials and formal filings where required. Ownership of tokens does not constitute an equity interest in United States Secured Exchange, Inc., and conveys no shareholder rights, dividend entitlement, liquidation preference, or claim on corporate assets or revenues.

15.3 Token Characterization

Within the protocol, the USSE token functions as the unit of value transfer, as the asset on whose exchange trades the protocol's trading fee accrues, and as the basis for governance participation where governance is active. It is not the denomination in which the protocol's service fees are charged: the identity, messaging, social, and digital asset layers charge their fees in ETH and route them to the Treasury System destinations described in §8.2. Those fees are not a USD price throughout. On most of those paths the amount charged is the greater of a percentage of a fixed gas estimate priced at the current gas price and a USD floor; name registration is priced in USD where a price feed and a USD price are both set, and is a flat ETH amount where either is absent; the marketplace platform fee is set as a percentage of the ETH listing price when the purchase terms are prepared, and the settlement contract credits the amount those terms name; and the content-upload registry requires at least the ETH amount named in the author's signed upload intent. §10.1, §10.4 and §11 state each basis. Where a USD floor is applied, it is converted at the rate a configured price feed reports, and where no feed is configured at a fixed rate compiled into the contract that does not track the market.

Two qualifications belong with that description. The content-upload registry has no integration with the shared fee configuration: it forwards what it collects as a single undivided transfer to one configured address rather than through the split described in §8.2, as §11 states. And a message may carry an asset transfer alongside it, on which the messaging contract takes a proportional fee denominated in the asset attached rather than in ETH, so that fee is taken in USSE where USSE is the asset attached. That is a charge on a value transfer rather than a service fee, and its denomination follows the caller's choice of asset rather than being fixed by the contract.

The legal characterization of a digital asset depends on the facts and circumstances of its offer, sale, and distribution, and may differ across jurisdictions and change over time. This document does not characterize the token for any regulatory purpose. The value flows bearing on that question are described elsewhere in this document rather than summarized here: the Genesis Distribution and issuance model in §6, Deterministic Routing of protocol revenue in §8, and the immutable fee floors and DEX transition in §8.4, each with the corresponding appendix. Persons acquiring tokens through an offering conducted by United States Secured Exchange, Inc. should refer to the applicable offering documents and consult their own advisors.

15.4 Securities Offerings and Exemption

Token sales conducted by United States Secured Exchange, Inc. are made in reliance on the exemption from registration provided by Rule 506(c) of Regulation D promulgated under the Securities Act of 1933, as amended. Securities offered and sold in reliance on that exemption have not been registered under the Securities Act or under any state securities law, and have not been approved, disapproved, or passed upon by the Securities and Exchange Commission, any state securities regulator, or any other regulatory authority. No such authority has confirmed the accuracy or adequacy of this document or of any offering document.

Rule 506(c) permits general solicitation and general advertising. It requires that every purchaser be an accredited investor and that the issuer take reasonable steps to verify accredited status. United States Secured Exchange, Inc. verifies accredited status before accepting a subscription, and the applicable offering documents describe the procedures used.

ComplianceRegistry implements four sale stages, being Paused, Reg D, Reg A+, and Open, and holds one of them at a time. No offering is being made under any stage other than the Rule 506(c) offering described above, and the presence of a stage in a contract is not a representation that an offering under it is planned, qualified, or available. Which stage is in force is a value held in that contract rather than a term of the offering, and §14.9 records it as a statement of present configuration to be confirmed on-chain.

15.5 Investor Eligibility and Verification

Eligibility and accredited status are not separate conditions in the offering described in §15.4. That offering is made in reliance on Rule 506(c), which requires every purchaser to be an accredited investor, so accreditation is a necessary condition of eligibility: a person who is not accredited is not an eligible investor for it, and references to eligible investors in this document should be read on that basis. Accreditation is necessary rather than sufficient: participation additionally requires completion of identity verification, and verification of accredited status through documentation or third-party confirmation. Self-certification alone is not sufficient.

The distinction is carried in the contracts rather than left to the offering documents alone. ComplianceRegistry classifies an account into one of three tiers: the Reg D tier records an account verified for both identity and accreditation, the Reg A+ tier records one verified for identity alone, and an account in neither is unclassified. During the Reg D sale stage only the Reg D tier may purchase; during the Reg A+ stage either verified tier may, an accredited account satisfying the lesser requirement as well.

Those determinations are recorded on-chain, and the registry governs sale-stage eligibility, purchase permission, and lockup application from them (Appendix B). TokenSale evaluates eligibility against that registry before every purchase, on the single purchase path it exposes and without the conditional that qualifies the token contract's transfer check in §15.6: its registry pointer cannot be set to the zero address, so the check cannot be disabled by leaving it unconfigured (Appendix S). The registry records the outcome of a verification as a tier and an attestation hash, written by the contract owner or by an authorized compliance officer; the verification itself is performed off-chain, so the chain holds evidence that a determination was made rather than the basis on which it was made. The set of parties who may write a determination is bounded and readable on-chain: the contract owner, up to three officers held in a managed set, one further officer slot retained for compatibility, and, through the finalization-surviving mirror of the write function, the registry's governance address once one is configured, which on the deployed registry it presently is not. The officer set is not fixed at deployment: the owner may add or remove officers before Immutable Finalization, and governance-gated mirrors that also admit the owner may do so afterwards. That authority is not ended by Immutable Finalization, because the mirror of the write function carries no finalization gate and admits any authorized officer as well as the governance address, so an account's tier remains writable by those parties for the life of the deployment. These mechanisms enforce the protocol's own access conditions; they operate alongside, and do not replace, the offering conditions established in the applicable offering documents.

15.6 Transfer Restrictions and Resale

Securities acquired in an exempt offering are restricted securities. They may not be resold, transferred, or otherwise disposed of except pursuant to an effective registration statement or an available exemption from registration, and any resale is subject to holding-period and other conditions imposed by applicable securities law.

The protocol separately enforces contract-level transfer restrictions during defined sale stages, including a lockup applied to accounts that purchase during the Reg D stage (Appendix B §3.3 and §3.5). That lockup runs for a configurable period defaulting to 365 days, and while the registry sits in the Paused, Reg D, or Reg A+ stage an account whose lockup has not expired can send only to TokenSale, and the lockup does not stop it receiving tokens. It is evaluated only in those stages: once the Open stage is set neither the transfer check nor the purchase check restricts anything, and any lockup still outstanding ceases to block transfers before its term has run.

An account's tier also governs the largest position the token contract will let it hold. That limit is measured against Circulating Supply and stands at a configured default of 2%, raised to at least 5% for an account the registry reports as verified at the Reg D tier. It is a market-stability control rather than a condition of the offering, and §8.2 records that nothing in the contract bounds the figure a setter may write.

Whether these restrictions are enforced at all depends on configuration rather than on deployment. The transfer check runs in the token contract, which consults the registry on every transfer where a registry address is configured on it and no fee settlement is in progress; where that address is unset the check is skipped rather than failing closed, and where the registry call reverts the position limit falls back to its default. The sale stage, the lockup duration, and an individual account's lockup expiry are administrative settings rather than terms of the offering, and each remains writable through a governance-gated function that Immutable Finalization does not close. The token contract also applies a restriction of its own that does not consult the registry: while its limits are in effect and its trading flag is unset, a transfer of a non-zero amount reverts unless either party is the token's owner or is excluded from fees, the transfer is to the burn address, or it is made during the contract's own fee settlement, whatever the sale stage and whether or not a lockup applies, and the position limit described above is enforced only while those limits are in effect. Both settings are changed through the token's manager, and neither can be changed after the token's own Immutable Finalization; §14.9 records their present state.

These on-chain restrictions are protocol mechanics. They are not a substitute for, and their expiration, lifting, or non-enforcement does not satisfy, any legal condition on resale. A holder whose on-chain lockup has lapsed or has ceased to be enforced may remain subject to restrictions under applicable securities law, and remains responsible for confirming that any transfer is permitted before initiating it.

15.7 Jurisdictional Limitations

Regulatory treatment of digital assets, decentralized systems, and cryptographic communication technologies varies by jurisdiction. This document is not directed at any person in any jurisdiction where its publication or availability would be contrary to applicable law, and no offering is made in any such jurisdiction. Participants are responsible for determining and complying with the laws applicable to them, including any restriction on acquisition, holding, transfer, or use of digital assets.

15.8 Forward-Looking Statements

This document contains statements regarding intended architecture, planned functionality, governance progression, and anticipated protocol development. Such statements reflect present expectations, are subject to the risks described in §14, and are not guarantees of future outcomes. Deployment schedules, governance transitions, feature availability, and ecosystem participation may differ materially from what is described. United States Secured Exchange, Inc. undertakes no obligation to update any forward-looking statement except as required by law.

15.9 Compliance-Aligned Configuration and Regulatory Development

The protocol permits compliance-aligned configuration where necessary, including compliance tiers, sale-stage boundaries, transfer gating, and the access controls surrounding them. These are configuration settings rather than governance outcomes: §15.5 records who may write them and that the authority to do so survives Immutable Finalization, and the governance-gated mirrors of those setters admit the owner as well, so the administrative authority described in §7.4 applies here as it does elsewhere in the system. Such configurations do not alter core protocol guarantees relating to supply integrity, issuance enforcement, or immutability of recorded data.

Immutable Finalization moves the two contracts carrying this surface in opposite directions, and the asymmetry is worth stating. On both ComplianceRegistry and TokenSale, upgrade authorization is gated to the owner before finalization and carries no governance branch, so finalization closes the ability to replace that code outright rather than passing it to the governance address. The configuration mirrors carry no finalization gate and survive. From that point the rules these two contracts enforce are fixed in code no party can replace, while the values they enforce against remain adjustable through those mirrors.

Future legal or regulatory developments may affect how the protocol is accessed, distributed, or integrated in particular jurisdictions. Such developments could impose additional compliance obligations, restrict participation, or limit specific use cases without altering the underlying technical architecture.

15.10 No Legal, Tax, or Investment Advice

Neither this document nor any communication from United States Secured Exchange, Inc. constitutes legal, tax, accounting, regulatory, or investment advice. Acquisition, holding, transfer, or use of digital assets may carry legal and tax consequences that depend on individual circumstances. Prospective participants should consult their own qualified legal, tax, and financial advisors before engaging with the protocol or participating in any offering.

16. Conclusion

USSE is designed as a deterministic protocol that integrates value transfer, governance, financial controls, and secure coordination within a single enforceable framework. Throughout this document, emphasis has been placed on constrained authority, structural predictability, and verifiable execution rather than discretionary control.

The Fixed Supply Invariant, Reserve Vault enforcement under the Time-Based Issuance Model, and bounded governance architecture establish long-term economic discipline. Treasury separation and deterministic revenue routing provide financial transparency without pooling custody under a single discretionary authority, though that separation is one of authority rather than of address. Integrity Commitments recorded through Anchoring Events enable authenticated coordination while preserving the confidentiality of message content. §12 and §9.1 record the invariants and what that confidentiality covers.

System behavior is defined by code. Authority is limited by design. A recorded Integrity Commitment cannot be altered through any function the recording contracts expose, while the metadata asserting that a batch was anchored to Layer 1 may be written again by an approved submitter, as §9.4 states. Governance operates within explicit contractual boundaries; which parties may exercise governance authority before Immutable Finalization is qualified by §7.4.

USSE is structured to function as infrastructure, and participation depends on informed evaluation of its guarantees, limitations, and associated risks. §14 sets out those risks and limitations, and §15 the regulatory and legal position.

By anchoring economic rules, governance boundaries, and data integrity to deterministic execution, the protocol treats reliability, auditability, and long-horizon structural stability as foundations rather than aspirations.