# OPEN10 Asset Specification v1 Status: FROZEN FOR IMPLEMENTATION Frozen at: 2026-08-10T23:58:42Z Asset: OPEN10 Chain: Base mainnet Issuer: Build In Public University thesis-asset program ## 1. Purpose OPEN10 is a fixed-supply research artifact recording a public investment thesis about Opendoor Technologies Inc. (NASDAQ: OPEN). It is designed to preserve the interval between an initial thesis and a defined public-market checkpoint. OPEN10 is not Opendoor stock, does not represent a claim on Opendoor, does not provide redemption rights, does not promise a payout, and does not grant ownership of any issuer asset. Token ownership is not required to read the thesis, evidence, or resolution record. ## 2. Frozen thesis checkpoint The market checkpoint is: > OPEN has an official Nasdaq regular-session closing price of at least USD 10.00 for five consecutive Nasdaq regular trading sessions. The checkpoint is satisfied only when all five sessions are consecutive trading sessions in the same listed equity record and each official close is >= USD 10.00. Intraday prints, pre-market prices, after-hours prices, options prices, VWAP, and unverified aggregators do not satisfy the checkpoint. The price is the split-adjusted official closing price reported by Nasdaq for the OPEN listing. The resolver must preserve the source URL or document identifier, session date, reported close, retrieval timestamp, and SHA-256 hash of the captured source artifact for every session. ## 3. Resolution states The registry has exactly three states: - OPEN: the checkpoint has not been verified and the thesis remains unresolved. - MATURED: the five-session checkpoint has been verified by the resolver quorum. - RETIRED: the checkpoint cannot reasonably resolve because the OPEN listing ceased through delisting, acquisition, or an equivalent corporate event before maturity. Retirement is not a success or failure claim. State transitions are one-way: OPEN -> MATURED or OPEN -> RETIRED. MATURED and RETIRED are terminal. The ERC-20 balance and transfer behavior do not change at resolution. ## 4. ERC-20 contract - Name: OPEN10 Thesis Asset - Symbol: OPEN10 - Decimals: 18 - Maximum supply: 1,000,000 OPEN10 - Initial supply: 1,000,000 OPEN10 minted once at deployment - Further minting: disabled - Burning: disabled in v1 - Transfer tax/fee: none - Rebasing: none - Pausing: none - Blacklist or allowlist: none - Upgradeability: none; implementation is immutable - Admin key after deployment: none for the ERC-20 - Contract ownership: none after constructor execution All initial supply is sent to a publicly disclosed issuer treasury address at deployment. No supply is reserved for an undisclosed team allocation. Any later distribution or liquidity activity must be disclosed separately; no distribution, sale, liquidity, or appreciation is promised by this specification. ## 5. Resolution registry The ERC-20 and resolution registry are separate contracts. The registry records the thesis metadata, state, session attestations, and terminal transition. The ERC-20 does not read the registry and cannot be frozen, clawed back, or altered when state changes. Registry requirements: - immutable asset identifier: OPEN10 - immutable token address after registration - immutable threshold: 1000 cents USD - immutable consecutive-session count: 5 - state getter returning OPEN, MATURED, or RETIRED - append-only daily session attestations - terminal state transition only - event emitted for every attestation and terminal transition - no token custody - no token transfer authority - no payout, redemption, or settlement function ## 6. Resolver quorum Resolution is an external-attestation process because the equity close is an offchain market datum. - Resolver set: three independently controlled public resolver addresses, disclosed before deployment. - Quorum: any two of three matching resolver attestations. - Each attestation identifies the session date, close in cents, source reference, retrieval timestamp, and source-artifact hash. - `sessionNumber` is a resolver-assigned monotonic trading-session index; a later session is not submitted until the prior session has reached its two-attestation quorum. - A resolver cannot alter or delete an attestation. - A quorum may only submit MATURED after five valid consecutive sessions are present. - A quorum may only submit RETIRED with a public reason and supporting source artifact. - Resolver addresses may be rotated only before the first state transition, by a two-of-three resolver quorum, with an onchain event. After a terminal transition, the set is immutable. The resolver is an evidence publisher, not a price oracle for trading and not a promise of token value. ## 7. Long backing-asset boundary Long may use the deployed OPEN10 ERC-20 address as a backing-asset input only if Long's own review accepts the asset. The Long integration is an adapter boundary, not part of the token contract. The Long adapter must not: - change token supply; - change the resolution state; - promise a payout based on OPEN; - represent OPEN10 as Opendoor equity; - use the registry state as a guaranteed price signal. The Long contract, configuration, or API integration must be documented in a separate receipt after its exact interface is known and independently verified. ## 8. Public evidence record The public page must link to: 1. this frozen specification; 2. the genesis thesis record and its date; 3. the original evidence snapshot, retained in private build records and not exposed on the public page; 4. all published session attestations; 5. the Base token and registry addresses after deployment; 6. the deployment and verification receipts. The local archive path is an internal provenance pointer, not a public URL. Public pages must use only verified public-safe evidence. ## 9. Explicit non-goals - No public sale is included in v1. - No promise of liquidity is included in v1. - No automatic marketing or influencer coordination is included in v1. - No outreach to Nate is included in the contract or deployment. - No financial return, yield, redemption, or stock exposure is included in v1. - No contract deployment occurs until the implementation passes source review, tests, Base Sepolia tests, static analysis, and a deployment receipt review. ## 10. Implementation gate The implementation is ready for deployment only when all of the following exist: - source-verified immutable ERC-20 contract; - source-verified resolution registry; - unit and invariant tests; - Base Sepolia deployment and readback; - three resolver addresses and quorum receipt; - public-safe metadata and spec URL; - legal/market-structure review of the proposed use and Long integration; - Base mainnet deployment receipt with token and registry addresses. Until then, OPEN10 remains a frozen specification and a public research page, not a live token.