# Moment White Paper 0.1.1 Author: Mark ZHANG ## Table of Contents - [0. TL;DR](#0-tldr) - [0.1 What Is Moment?](#01-what-is-moment) - [0.2 For Creators](#02-for-creators) - [0.3 For Fans](#03-for-fans) - [Abstract](#abstract) - [1. Problem Definition](#1-problem-definition) - [2. Project Positioning and Vision](#2-project-positioning-and-vision) - [3. Core Roles](#3-core-roles) - [4. How the Product Operates](#4-how-the-product-operates) - [5. Why Moment Is Web2.5 Rather Than a Pure On-Chain Protocol](#5-why-moment-is-web25-rather-than-a-pure-on-chain-protocol) - [6. Technical Architecture](#6-technical-architecture) - [7. On-Chain Asset Model](#7-on-chain-asset-model) - [8. Core Mechanisms of the Current Contract](#8-core-mechanisms-of-the-current-contract) - [9. Anti-Arbitrage and Rule-Stability Design](#9-anti-arbitrage-and-rule-stability-design) - [10. Why Redeem Does Not Destroy the Asset](#10-why-redeem-does-not-destroy-the-asset) - [11. Market and Liquidity Design](#11-market-and-liquidity-design) - [12. Security Model and Trust Boundaries](#12-security-model-and-trust-boundaries) - [13. Asset Economics and Business Model](#13-asset-economics-and-business-model) - [14. Governance and Control](#14-governance-and-control) - [15. Compliance, Payments, and Real-World Interaction](#15-compliance-payments-and-real-world-interaction) - [16. Privacy and Data Handling](#16-privacy-and-data-handling) - [17. Roadmap](#17-roadmap) - [18. Risk Disclosure](#18-risk-disclosure) - [19. Conclusion](#19-conclusion) ## 0. TL;DR ### 0.1 What Is Moment? Creating Moment is a tentative answer to the question of meaning. I’m a passionate rock climber, a trained economist, a hacker, and an architecture lover. I am a firm supporter of Vitalik and his vision, a lover of Feynman and Louis Kahn, and my climbing hero is the late Canadian climber Marc-André Leclerc. In the first part of my life, I went through institutionalized training in school and office, worked for governments and corporations. and those experiences turned me into a firm individualist — a rebel against authoritarianism and monopolies. I want to build something that carries the spirit of individualism, heroism, and love: something healthy that cannot be controlled by any entities except for ourselves. The idea for this project was born during a climbing trip with my mom. I hadn’t seen her for a year since she moved to a remote village, and we decided to head to a nearby snow mountain together because she wasn't comfortable driving those roads alone. At one point during the journey, we were catching our breath in a small spot at the base of the mountain, and I watched her just sitting there, reading. In that single heartbeat, I knew I wanted to capture that moment — the simple presence of a mother and a son — and store it in a way that could last long after we are gone. A tiny, insignificant speck of a fleeting memory in the immensity of the universe, proving we ever existed. They say you should create something simply because you want it to exist. And that’s it. ### 0.2 What makes Moment different? #### 0.2.1 Data and True Ownership - **Data Control (Creator)** - **Traditional:** Centralized platforms own the data and user relationships; if the platform disappears, creators can lose access to the audience, records, and value they built there. - **Moment:** Ownership is anchored on-chain. Even if the company or platform no longer exists, the creator's issued assets, related records, and on-chain ownership history remain independently verifiable on the blockchain. - **Asset Durability (Fan)** - **Traditional:** Fragile physical merch or easily lost digital ticket stubs. - **Moment:** A lasting collectible with permanent ownership records and content references stored on-chain or anchored to blockchain-based infrastructure. Its value comes not just from being durable, but from remaining verifiable, ownable, and collectible over time regardless of whether the issuing company still exists. #### 0.2.2 Monetization and Revenue Structure - **Revenue Model (Creator)** - **Traditional:** One-time transaction (profits stop entirely after the initial sale). - **Moment:** Continuous long-tail revenue (profits from the primary sale + automated royalties on every secondary trade). - **Value of Purchase (Fan)** - **Traditional:** Sunk cost (physical merch depreciates the moment it's bought). - **Moment:** Asset-backed holding (potential to appreciate in value as the creator's influence grows). #### 0.2.3 Market Order and Anti-Scalping - **Scalper Defense (Creator & Fan)** - **Traditional:** Uncontrolled secondary pricing; scalpers capture all the premium profits. - **Moment:** Full-lifecycle tracking and smart price controls to fundamentally block malicious speculation. - **Secondary Market Experience (Fan)** - **Traditional:** High-friction, high-fraud risk on shady third-party resale sites. - **Moment:** Safe, one-click trading on an integrated, price-transparent official marketplace. #### 0.2.4 Fan Engagement and Identity - **Interaction Mode (Both)** - **Traditional:** One-way, passive consumption of content and goods. - **Moment:** Deep co-creation; fans actively participate and share in verifiable milestones. - **Proof of Fandom (Fan)** - **Traditional:** Scattered physical items; hard to aggregate and prove true loyalty. - **Moment:** A unique, instantly verifiable on-chain "Superfan Card." - **Perk Distribution (Creator & Fan)** - **Traditional:** Disconnected buyer data makes targeted rewards and follow-ups difficult. - **Moment:** The digital pass acts as a direct key for seamless, continuous perk airdrops. #### 0.2.5 Operations and Global Reach - **Operational Overhead (Creator)** - **Traditional:** Heavy logistics (upfront manufacturing costs, inventory management, shipping hassles). - **Moment:** Ultra-lightweight (zero physical inventory, fully automated digital issuance). - **Market Accessibility (Both)** - **Traditional:** Restricted by fragmented local ticketing systems and expensive cross-border shipping. - **Moment:** Borderless access; seamless, instant support from fans anywhere in the world. ### 0.3 For Creators **Own Your Data, Co-Create, and Build Long-Tail Revenue** Moment transforms your milestones and fan co-created events into sellable digital passes. Traditionally, centralized platforms own your data—if they shut down, your records and fan connections disappear forever. Moment stores your achievements on the blockchain, ensuring your data and fan network permanently belong to you. Beyond true ownership, Moment fixes the broken monetization model. Instead of only earning from initial sales and leaving secondary profits to scalpers, your passes are trackable and price-controllable. This curbs scalping and automatically earns you royalties on every legitimate peer-to-peer resale. **How It Works** Launch a milestone or co-creation campaign -> Issue exclusive blockchain-backed digital passes -> Let the platform handle the primary drop, anti-scalping price controls, and automated secondary market royalties. ### 0.4 For Fans **Ditch the Scalpers, Claim Your Ultimate Superfan Card** Moment is more than just a digital souvenir of the events you’ve joined and the creator milestones you’ve witnessed—it’s a superfan card packed with real-world utility. Supporting your favorite creators used to mean missing out on primary drops and risking scams from scalpers on shady resale sites. Moment offers fairer initial drops and keeps all trading within a secure, price-transparent ecosystem, completely eliminating cross-platform friction and fraud. **How It Works** Join a creator's co-creation campaign -> Get a digital card packed with exclusive perks -> Enjoy the utilities, or resell it to other true fans on a safe, price-transparent official marketplace. ## Abstract Moment is a Web2.5 real-world behavior assetization platform designed for independent creators, artists, musicians, extreme sports enthusiasts, and athletes. It is dedicated to transforming fleeting yet meaningful real-world achievements, relationships, and moments into verifiable, ownable, displayable, redeemable, and, in supported market flows, tradable on-chain assets. In the current creator and experience economy, attempts to build connections and monetize are constant. In real-world scenarios, fans enthusiastically collect early physical ticket stubs, creators issue offline meet-and-greet privileges or build exclusive membership programs, brands sell physical merchandise, and community leaders reward unique experiences through highly engaging groups. However, constrained by traditional physical mediums or Web2 centralized architectures, these "actions" create massive commercial friction. When scarce memorabilia or privileges enter the secondary market, the high value appreciation is often ruthlessly captured by scalpers; meanwhile, the friction costs of physical delivery or account-bound transfers are extremely high. More fatally, once an asset changes hands (e.g., a privately resold climbing gym ticket or event qualification), the issuer not only fails to capture any value from the secondary circulation but also bears significant operational and trust risks, such as counterfeit tickets and identity verification errors. These pain points are the fundamental reason why we must establish clear property rights for real-world behaviors and privileges. Powered by blockchain technology, all privileges can be transformed into unique, tamper-proof, and decentrally stored digital assets. This not only locks in genuine ownership and enables lower-friction circulation, but also creates the technical basis for royalty-aware settlement in supported trading paths. However, in the traditional, pure NFT ecosystem, a vast number of Web3 projects are entirely driven by speculation. They deliberately abandon any anchor to physical assets or real-world experience value, attempting to generate massive financial upside by manufacturing scarcity bubbles and Ponzi schemes. This reality-detached hype not only fails to close the loop on offline privilege redemption but also completely alienates the massive base of real consumers and creators due to the extremely high wallet barriers and associated risks. In stark contrast to this speculation-dominated narrative, Moment is not designed for hype or financial players. It is a tool tailor-made for real users who have zero knowledge of Web3, underlying technologies, or complex finance. It aims to provide an easy-to-use, trustworthy, and highly transparent infrastructure that helps the general public effortlessly upload, verify, store, and share this entirely new class of real-world assets. To achieve this, Moment has chosen a Web2.5 technical route: users can log in via email, phone number, or social accounts, authorizing the platform to execute on-chain operations. In a seamless, frictionless experience, they can accept challenges, submit proofs, earn Badges, and, when needed, complete privilege redemption or supported secondary circulation. Architecturally, Moment's centralized servers handle high-frequency interactions—such as auditing, public display, reporting, arbitration, and operations—while the on-chain system operates in the background, responsible for ultimate data storage, asset settlement, and maintaining the immutable record of rules, ownership, and redemption status. This "off-chain interaction, on-chain consensus" architecture not only guarantees a user-friendly experience but also fulfills the ultimate promise of decentralization: even if one day the Moment platform or its backing operating company ceases to exist, the media, achievement records, community interactions, and value consensus accumulated by users will not perish with it. They will completely break free from the capture of centralized entities, permanently surviving on the blockchain as digital assets that truly belong to the individual. **Moment's current core architecture includes:** - **Base** as the on-chain settlement network - **Privy** as the identity and embedded wallet infrastructure - **Relayer / Engine** as the gasless write execution layer - **A single ERC-1155 master contract** as the platform-wide Badge asset layer - **An off-chain state machine** as the business orchestration and risk control layer ## 1. Problem Definition ### 1.1 Real-World Achievements Are Difficult to Turn into Assets There are many behaviors in the real world that deserve to be recorded and owned. For example, completing a difficult climbing route, succeeding in a challenge with commemorative meaning, or reaching a milestone endorsed by a specific curator or community often carries achievement value, relationship value, community value, and may even later develop collectible value and circulation value. However, in the traditional internet environment, this value usually remains only at the content layer: a video, a screenshot, a post or a database record that weakens as the platform evolves and time passes. They can be viewed, but not truly owned; they can be shared, but not truly authenticated as owned; they can be remembered, but are hard to preserve over the long term as independent assets. ### 1.2 Traditional NFT Models Cannot Directly Solve This Problem a Non-Fungible Token (NFT) functions as an immutable digital certificate of authenticity recorded on a blockchain. It uses cryptography to prove that a specific digital item is unique, irreplicable, and unequivocally owned by a specific person. While NFTs successfully provide ownership and transferability for digital assets, they still have obvious shortcomings in real-world behavior scenarios: - High barrier to entry, requiring ordinary users to understand wallets, signatures, and gas - Product narratives often lean toward speculation rather than being built around real behavior and real context - Many projects only solve minting, not verification and redemption - Few place real-world benefits and collectible properties into the same closed loop This means that tokenizing real-world behavior does not automatically become valid simply because an image is put on-chain. ### 1.3 Moment's Core Answer The problem Moment wants to solve is not to build another NFT issuance platform, but rather: **How to transform real-world behaviors with rich context, strong emotion, and strong community value into a digital asset that can be acquired with low friction, verified on-chain, attached to benefits, continuously displayed, and seamlessly circulated—appreciating in value as the underlying community and reputation grow.** ## 2. Project Positioning and Vision Moment is positioned neither as a pure protocol, nor as a traditional membership points system, nor as a simple digital collectibles platform. Moment is a Web2.5 asset platform that takes real-world behavior as input, uses on-chain Badges as the final settlement result, and produces a dual output of redeemable benefits plus tradable collectibles. Moment's long-term vision is to build an on-chain layer for the accumulation of real-world achievement value. In this system, the effort, challenges, recognition, relationships, and rewards that exist in the real world will no longer be just statuses or content within a platform, but assets that users can truly hold. Moment uses Web3 in a restrained way. It does not pursue full decentralization of every process in the first stage. Instead, it clearly distinguishes which links must be proven on-chain and which are more suitable for platform governance. Moment believes that a sustainable ecosystem is not one that puts everything on-chain, but one that leverages the efficiency advantages of centralized coordination while preserving the tamper-resistant, individually owned, and independently verifiable character of on-chain assets, placing on-chain only the parts of truth that most need lasting trust. ## 3. Core Roles In an agent-driven world, individuals are no longer confined to a single fixed identity. The same person may, in different contexts, become a creator, organizer, fan, community leader, or sponsor. Roles are therefore defined not by profession or status, but by the function an individual performs within a specific scenario. Moment adopts this contextual view of participation. For this reason, its role design distinguishes between business roles and system roles. ### 3.1 Ecosystem Participants Ecosystem participants are the people and organizations that create, complete, verify, redeem, hold, and circulate Moments. These are not fixed identities. The same individual may, in different scenarios, act as an initiator, participant, verifier, sponsor, redeemer, collector, or community organizer. Moment therefore treats these as contextual functions within an interaction rather than permanent categories of personhood. **Initiator** Initiators define the challenges, configure the rewards, specify the verification mechanisms, and determine which Gallery or community context the challenge belongs to. For example, in a rock climbing scenario, the initiator might be a route setter issuing a digital badge for a 'First Ascent' achievement. For peer-to-peer challenges, the initiator could simply be an individual user; whereas in commercial contexts, the initiator might be a brand, a climbing gym, or an event organizer. **Participant** The participant accepts the challenge, performs the relevant real-world action, submits proof when required, and receives a Badge once the conditions are satisfied. In some contexts this role may correspond to a challenger, climber, attendee, supporter, or contributor. **Verifier** The verifier confirms whether the required behavior or achievement has in fact occurred. This role may be performed by the initiator, a designated witness, a curator, a merchant, a trusted community member, or a more structured verifier set depending on the scenario and the trust model. **Redeemer** The redeemer confirms that an attached benefit has actually been consumed or honored. This may be a friend confirming fulfillment of a promise, a venue confirming ticket usage, a merchant confirming benefit redemption, or another authorized party responsible for recognizing real-world consumption. **Collector** The collector may not be the original challenge completer, but can later purchase, hold, display, or trade certain Badges with cultural and commemorative significance. ### 3.2 Infrastructure Operators Infrastructure operators are the systems and privileged actors that keep the platform running, coordinate execution, and maintain operational safety. They do not define the meaning of a Moment by themselves, but provide the infrastructure through which ecosystem participation can be reviewed, settled, synchronized, and protected. **Backend workflow system** Handles the pipelines of review, disclosure, reporting, arbitration, retries, idempotency, event write-back, and database synchronization. **Relayer** Submits on-chain write operations on behalf of users and provides the execution layer required for a gasless experience. **Contract administrator** Configures challenges and Badges, maintains operational switches, and manages contract-level permissions. **Emergency pause role** Pauses critical on-chain write operations in exceptional circumstances to contain operational or security risk. ## 4. How the Product Operates Moment's business is not a one-time mint, but a complete asset lifecycle. ### 4.1 Create Challenges and Configure Rules The initiator creates a new challenge in the product, defining the challenge theme, time limit, badge designs, reward content, verification conditions, and redemption authority. For the on-chain system, the administrator then configures the challenge and its subordinate Badge types. A single challenge can have multiple Badge tokenIds. This allows the same event to have multiple asset types at the same time, such as standard edition, rare edition, commemorative edition, or special award edition. ### 4.2 Discover and Accept Challenges Users can discover a challenge through QR codes, social content, venue pages, or in-app feeds. After clicking to accept a challenge, the system records the user's intent state off-chain rather than immediately requiring an on-chain action. ### 4.3 Submit Proof and Perform Off-Chain Verification After completing the relevant real-world behavior, the participant submits proof materials to the platform, such as videos, photos, screenshots, location records, witness confirmations, or other supporting information. Moment does not treat these materials as an automatic trigger for minting. Instead, they enter an off-chain verification workflow designed to determine whether the claimed behavior actually occurred and whether the record is ready for final settlement. This workflow may include several distinct stages: - **Initial review**: the platform checks whether the submission is complete, legible, timely, and consistent with the basic challenge requirements. - **Verifier confirmation**: a designated verifier, witness, merchant, curator, or other authorized party confirms whether the claimed action or achievement should be recognized. - **Public disclosure window**: where appropriate, the record may enter a limited review period during which other relevant parties can see the pending result and raise objections. - **Reporting**: if a participant, witness, or third party believes the submission is false, misleading, duplicated, or otherwise invalid, they may submit a report for further review. - **Arbitration**: disputed cases are resolved through platform judgment or other predefined governance mechanisms, producing a final decision on whether the case should proceed to minting. Only after this workflow is completed and the case is considered settled does Moment treat the result as eligible for on-chain issuance. Moment believes that judging the authenticity of real-world behavior remains a contextual, evidence-sensitive, and operations-heavy process, and is therefore not suitable for full on-chain automation at the MVP stage. ### 4.4 Mint the Badge When the off-chain process is complete and the system confirms that the challenge record has reached a settleable state, the Relayer initiates the on-chain mint. At that point, the smart contract performs the final asset-level checks, including: - Whether the challenge and Badge have been configured - Whether the challenge and Badge are active - Whether the challenge has expired - Whether the Badge still has remaining supply - Whether the mint request has not been replayed - Whether the verification rules corresponding to the Badge are satisfied After the conditions are met, the Badge is minted to the user. ### 4.5 Hold, Display, and Redeem After the user receives the Badge, it can be displayed on the profile page. This Badge simultaneously has: - Achievement proof properties - Redeemable benefit properties - Circulation properties under suitable conditions When a Badge is associated with redeemable benefits, the way those benefits are exercised may vary by scenario. Some benefits may be one-time and settled through an on-chain redemption record, while others may be recurring, ongoing, or governed primarily by off-chain business rules. Moment therefore treats the Badge not simply as a consumable coupon, but as an asset whose ownership, status, and attached utility can be structured differently depending on the design of the specific challenge and benefit model. For benefits that are configured as one-time redemption in the current MVP flow, the platform does not destroy the Badge. Instead, it records the redeemed state on-chain. This preserves the Badge's collectible and proof-of-participation value while making the consumption status explicit. ### 4.6 Subsequent Circulation One of Moment's long-term goals is to make Badges more than a one-time rights distribution. They should continue to circulate in supported market flows as part of a user's achievement and community context. A Badge that has already been redeemed can still have commemorative value and collectible value. At the current stage, Moment has integrated the thirdweb Marketplace V3 contract as the current marketplace settlement layer for supported Badge circulation. Under this model, the Badge holder remains the asset owner, while Moment's controlled execution path coordinates the required marketplace approval, listing parameters, and purchase settlement inside the supported product flow. When a purchase is executed, the marketplace contract settles the trade on-chain by coordinating payment and transferring the Badge to the buyer in the same flow. Because the Badge itself remains the core asset and the redeemed state follows the asset, its collectible history and redemption status remain transparent after transfer. This integration allows Moment to connect secondary circulation quickly without first building a full proprietary exchange stack. In the current phase, it mainly provides marketplace settlement infrastructure within Moment's controlled product flow rather than an unrestricted user-directed trading environment. Over time, as Moment's trading volume, fee design, royalty convergence, redemption-aware display logic, and risk-control requirements become more mature, the project plans to develop its own app-native marketplace to provide a more tightly integrated and product-specific market experience. ```mermaid --- id: 0eccc14b-6ee7-47dd-8d88-64df9bb3f77f --- flowchart TD start([User Discovers Challenge]) --> accept[Accept Challenge] accept --> intent[Create Off-chain Intent Record] intent --> perform[Perform Real-world Action] perform --> submit[Submit Proof: Video / Photo / Screenshot / Data] submit --> review[Community Review] review --> verifier_check[Verifier Approval] verifier_check --> cooldown[Public Cooldown / Report Window] cooldown -->|No valid dispute| ready[Ready To Mint] cooldown -->|Reported or disputed| arbitration[Arbitration / Manual Resolution] arbitration -->|Approved| ready arbitration -->|Rejected| fail([Challenge Not Minted]) ready --> metadata[Generate Final Metadata URI] metadata --> mint[Relayer Calls adminMint / adminBatchMint] mint --> onchain_check[Contract Checks : Supply / Active / Expiry / Authorization] onchain_check --> minted[Badge Minted To User] minted --> profile[Show Badge In Profile] profile --> redeem_request[User Initiates Redemption] redeem_request --> authority_sign[Redemption Authority Signs Authorization] authority_sign --> redeem_tx[Relayer Calls redeem] redeem_tx --> redeemed[Badge Marked Redeemed On-chain] redeemed --> state_follow[Badge Retains Ownership, Redeemed State Follows Asset] profile --> market[Optional Listing On Marketplace] redeemed --> market market --> sale[Secondary Sale Executed] sale --> buyer_badge[Badge Transferred To Buyer] sale --> seller_proceeds[Sale Proceeds To Seller] sale -. Marketplace-specific royalty path .-> royalty[Royalty Routed If Supported] royalty --> recipient[Creator / Issuer Royalty Recipient] ``` *Figure 1: Complete Product Closed Loop* The diagram above shows Moment's complete product closed loop: evidence processing and review are completed off-chain, final mint and redeem settlement are completed on-chain, and after redemption the Badge still retains the ability to circulate and be displayed. It also highlights that, when a secondary sale occurs inside a supported trading route, asset transfer and payment settlement can happen together, while the royalty path depends on the rules supported by the marketplace route through which the trade is executed. ## 5. Why Moment Is Web2.5 Rather Than a Pure On-Chain Protocol The core of Moment's design is not to put as much as possible on-chain, but to put only what most needs to be proven on-chain. For consumer products, identity, review, reporting, arbitration, payments, customer service, and operations are not what blockchains handle best in the first place. If every process were forcibly pushed fully on-chain in the first stage, the system would immediately face extremely high complexity, cost, and user-experience burden. Moment therefore chooses: - **Off-chain for workflow and governance** - **On-chain for final state and key rules** ```mermaid --- id: 0e54b636-ba78-4bc6-bbb7-b840fc69f9c6 --- flowchart LR subgraph OFF[Off-chain Responsibility] oc1[Challenge Setup And Review] oc3[Proof Collection And Storage] oc4[Dispute Handling And Risk Control] oc5[Metadata Preparation] oc6[Relayer Orchestration And Retry] oc7[Customer Support And Operations] end subgraph ON[On-chain Responsibility] on1[Challenge And Badge Configuration] on2[Supply And Expiry Rules] on3[Mint And Redeem Authorization Checks] on4[Replay Protection] on5[Ownership State] on6[Redeemed State] on7[Final Settlement And Events] end oc1 -. finalized into .-> on1 oc1 -. bounded by .-> on2 oc3 -. proof reference supports .-> on7 oc5 -. prepared for .-> on1 oc6 -. executes .-> on7 oc1 -. approved result triggers .-> on3 ``` *Figure 2: Off-chain vs. On-chain Responsibility Boundaries* The diagram above is intentionally simplified. It highlights responsibility boundaries rather than implementation details: Moment keeps review, operations, and evidence handling primarily off-chain, while using the chain for rule enforcement, asset state, and final settlement. These boundaries are reflected as follows: ### 5.1 What Is Handled On-Chain - Basic challenge rules - Basic Badge rules - Maximum supply and minted quantity - Holder status - Redeemed status - Mint and redeem events - Verifier root and signature verification logic ### 5.2 What Is Handled Off-Chain - Proof upload and raw storage - Review state progression - Disclosure and reporting - Arbitration and exception handling - User identity risk control - Payment and customer service logic Moment's goal is not to prove that all behavior is executed automatically by the chain, but to prove that once a real-world behavior is recognized and settled by the platform, its asset result is real, verifiable, and independently existent. ## 6. Technical Architecture Moment's current technical architecture is composed of multiple layers with clear responsibilities. ```mermaid --- id: 3168904e-eb80-4928-b895-aac7152d9e52 --- flowchart LR subgraph U[User Layer] creator[Creator / Route Setter] challenger[Challenger / Climber] verifier[Verifier / Witness] merchant[Redemption Authority / Merchant] collector[Collector / Buyer] end subgraph F[Frontend App Layer] app[Moment App\nDiscovery / Challenge / Profile / Market] end subgraph I[Identity And Wallet Layer] privy[Privy\nLogin + Embedded Wallet] end subgraph B[Backend Workflow Layer] api[Moment Backend API] workflow[Review / Cooldown / Report / Arbitration] metadata[Metadata Builder] sync[Event Listener / DB Sync] end subgraph S[Storage Layer] db[Application Database] media[Proof Media Storage] ipfs[IPFS / Decentralized Metadata] end subgraph E[Execution Layer] relayer[Relayer / Engine\nGasless Transaction Execution] end subgraph C[Blockchain Layer - Base] badge[MomentBadge ERC-1155 Contract] market[Marketplace Infrastructure\nCurrent / Future Controlled Path] end creator --> app challenger --> app verifier --> app merchant --> app collector --> app app <--> privy app <--> api api --> workflow api --> metadata api --> db api --> media metadata --> ipfs sync <--> db badge --> sync market --> sync api --> relayer relayer --> badge relayer --> market badge --> ipfs app --> badge app --> market ``` *Figure 3: Technical System Architecture* The diagram above shows the system structure at the current stage: users enter the system through Moment App and Privy, the backend workflow handles review and state orchestration, the Relayer handles on-chain execution, and the main contract on Base ultimately settles the asset state. ### 6.1 Base: Settlement Network Moment chooses Base as its primary on-chain network because of its low cost, fast confirmation, and strong suitability for consumer-facing applications. As an Ethereum Layer 2 network within the Coinbase ecosystem, Base also offers a strong distribution and infrastructure context for consumer-facing on-chain products. For a product that requires a gasless experience, transaction cost and confirmation efficiency at the underlying network layer are critical prerequisites. ### 6.2 Privy: Identity and Wallet Layer Privy provides low-friction login and embedded wallet capabilities. Users can enter the system directly through email, phone number, or social accounts, without first learning mnemonic management, private key custody, or external wallet interaction. This allows Moment to keep the product entry point close to a Web2 experience while still ensuring that the assets ultimately land in the user's wallet. ### 6.3 User Wallet Ownership and Relayed Execution Moment separates user-linked asset ownership from platform-operated transaction execution. Users interact through a Web2-like product interface and are provisioned with embedded wallets through Privy, so the experience does not depend on traditional wallet setup or direct gas payment. In the current product stage, users do not independently export wallet keys or perform unrestricted third-party signing; instead, mint, redeem, and supported trading actions are executed through Moment's controlled flow. The resulting assets are still recorded in user-linked wallets rather than in a single omnibus platform wallet. In this sense, Moment is operationally centralized in workflow and execution, while preserving user-linked on-chain ownership of the final asset state. ### 6.4 Relayer / Engine: Execution Layer Moment uses a relayer to perform on-chain write operations on behalf of users. The result is: - Users do not need to pay gas themselves - Frontend interactions are not interrupted by native transaction flows - The platform can handle idempotency, retry logic, and execution ordering in a unified way The Relayer is the execution bridge between the user experience and the on-chain asset system. ### 6.5 Smart Contract: Asset Layer Moment currently uses a platform-level ERC-1155 main contract as the core asset layer. This contract is responsible for: - Recording challenges - Recording Badges - Controlling mint - Controlling redeem - Enforcing supply and expiry logic - Recording final ownership and redeemed state ### 6.6 Backend: Business State Machine Layer The backend is responsible for the actual orchestration of the entire workflow system, including proof submission, review progression, disclosure logic, reporting, arbitration, pre-mint checks, pre-redeem checks, event synchronization, and database write-back. ### 6.7 Storage: Content and Metadata Layer At the current stage, Moment recommends keeping raw evidence during the review period in centralized storage, while uploading final metadata and references to the necessary proof materials to IPFS. This preserves operational flexibility while providing long-term reference capability for the final asset. ## 7. On-Chain Asset Model ### 7.1 Why Use a Single ERC-1155 Contract Moment does not use a one-contract-per-challenge model. Instead, it uses a single platform-level ERC-1155 main contract to carry platform-wide Badges. The reasons are: - Lower deployment and maintenance complexity - A clearer role and permission system - A more unified event indexing and data write-back model - A more natural way for multiple tokenIds to coexist - Better support for batch minting ### 7.2 Challenge as the Parent Container In the on-chain model, challengeId corresponds to a challenge record. It is not the asset itself, but the parent container of a group of Badges. A challenge stores: - galleryId - expiryTimestamp - exists - active ### 7.3 Badge as the Actual Held Asset Each tokenId is the final on-chain asset that the user actually holds. It includes: - Its parent challenge - Supply cap and mintedSupply - Token URI - Reward, verification, and redemption related descriptions - Redemption authority - Royalty configuration - Verifier set configuration - Verification mode - Active status The same challenge can have multiple Badge tokenIds, allowing a single event to have a multi-tier asset structure at the same time, such as standard, rare, and limited editions. ## 8. Core Mechanisms of the Current Contract Moment's current on-chain implementation already includes a set of key constraints oriented toward consumer-grade asset scenarios. ### 8.1 Role and Permission Model The contract contains three key roles: - DEFAULT_ADMIN_ROLE - RELAYER_ROLE - PAUSER_ROLE This means ordinary users do not call mint and redeem directly. The platform is responsible for execution, but it still cannot bypass the constraints hardcoded in the contract, such as supply, expiry, and authorization. ### 8.2 Two Mint Modes The current contract supports two mint verification modes. **RELAYER_ONLY** In this mode, minting can proceed as long as the relayer calls it and the basic rules are satisfied. It is suitable for scenarios where the platform itself is the final approver. **THRESHOLD_SIGNERS** In this mode, the relayer must submit: - An EIP-712 signature from a verifier - The corresponding Merkle proof The contract verifies whether the signer belongs to the verifier set, whether the signer is duplicated, whether the quantity reaches the threshold, and supports either a fixed-number threshold or a ratio threshold. This allows different Badges to have trust models of different strengths. ```mermaid --- id: d8d1d742-1aef-4f39-a247-f3993833e5a9 --- flowchart TD start([Backend confirms eligibility]) --> prepare[Backend prepares the mint request] prepare --> mode{Which verification mode applies?} mode -->|RELAYER_ONLY| submit[Relayer submits the mint transaction] mode -->|THRESHOLD_SIGNERS| approvals[Collect verifier signatures and Merkle proofs] approvals --> submit submit --> basic_checks[Contract checks request validity, active status, replay protection, supply, and expiry] basic_checks --> verification{Signer-based verification required?} verification -->|No| settle[Mark request used, update supply, and mint badge] verification -->|Yes| signer_checks[Verify signer approvals and threshold] signer_checks --> settle settle --> finalize[Apply transfer rules and emit BadgeMinted] finalize --> done([Mint completed]) ``` *Figure 4: Mint Authorization Call Chain* The diagram above shows the mint call chain in the current contract. The externally exposed functions are adminMint and adminBatchMint, but the truly critical logic is unified inside _adminMintSingle, _validateMintApprovals, and _update. This is also the core source of mint security. ### 8.3 Authorization Model for Redeem Redeem is submitted by the relayer, but that does not mean the relayer can unilaterally decide that a benefit has been consumed. The contract requires an EIP-712 authorization signature signed by the redemptionAuthority. Only when the redemption authority has truly approved it can the redeem succeed. ```mermaid flowchart TD start([Holder wants to use a benefit]) --> backend[Backend checks the off-chain redemption conditions] backend --> auth[Redemption authority signs the redemption approval] auth --> relayer[Relayer prepares and submits the redeem transaction] relayer --> request_checks[Contract checks that the badge exists, the holder is valid, and the redemption request ID is valid] request_checks --> ownership_checks[Contract checks that the request has not been used, the holder owns the badge, and the badge has not already been redeemed] ownership_checks --> authority_checks[Contract checks that a redemption authority is configured and that the approval has not expired] authority_checks --> signature_check[Contract recovers the signer from the authorization message] signature_check --> signer{Does the signer match the configured redemption authority?} signer -->|No| revert[Transaction reverts] signer -->|Yes| state[Mark the redemption request as used and record the redeemed state] state --> event[Emit the BadgeRedeemed event] event --> done([Redemption completed]) ``` *Figure 5: Redeem Authorization Call Chain* The diagram above shows the redeem call chain. The Relayer is responsible for sending the transaction on-chain, but what truly determines whether the redemption is valid is the authorization message signed by the redemptionAuthority for the specific redeem request. Therefore, redeem is a combined process of off-chain business confirmation plus on-chain final authorization verification. ### 8.4 One Wallet, One Badge of the Same Type The current contract overrides ERC-1155's _update logic and enforces: - The amount transferred each time must be 1 - The same wallet cannot hold two copies of the same tokenId This makes the Badge closer to a credential-like asset rather than a stackable balance. ### 8.5 The Redeemed State Follows the Asset When It Moves If a Badge has already been redeemed and is later transferred to a new holder, the redeemed state transfers along with the asset. In this way, the system does not incorrectly bind whether it has been used to a historical address, but instead binds it to the current state of that asset. ## 9. Anti-Arbitrage and Rule-Stability Design For any asset-based system, the biggest risk is often not an obvious hack, but the quiet rewriting of rules after issuance. For this reason, Moment has introduced explicit anti-arbitrage constraints into the current contract. ### 9.1 A Challenge Expiry Can Only Be Tightened, Never Extended Once a challenge has been set with a non-zero expiry: - It cannot be extended to a later time - It cannot be changed back to 0 - An already expired challenge cannot be reactivated This prevents the platform from first using a limited-time narrative to attract users, then later extending the window and continuing to issue the same type of asset. ### 9.2 Key Badge Fields Freeze After the First Mint Once at least one copy of a given Badge has been issued, its key fields are frozen, including: - maxSupply - verificationMode - Verifier root and threshold configuration - redemptionAuthority - Royalty configuration - tokenURI - rewardDescription - verificationRule - redemptionDescription The main field that remains mutable at present is active, which is used for listing status and operational control. The result is that after asset distribution has begun, the platform can no longer rewrite the core terms, reducing the risk of selling expectations first and changing the rules later. ### 9.3 Replay Protection Every mint and redeem requires a unique ID: - mintRequestId - redemptionId Once successfully used, these IDs are permanently recorded as processed to prevent repeated execution and basic replay attacks. ## 10. Why Redeem Does Not Destroy the Asset A Badge carries two layers of value at the same time: - **Utility value**: before redemption it can be exchanged for a specific benefit - **Collectible value**: it still represents a real moment, relationship, or achievement that actually occurred Therefore, redeem does not burn the Badge. It only marks it as redeemed. This has three results: - The user still keeps their proof of achievement - A redeemed asset can still continue to be displayed and circulated - The frontend only needs to update its presentation according to the on-chain redeemed state, without rewriting the underlying metadata This makes Moment's Badge both a redeemable benefit credential and a digital collectible that preserves historical context. ## 11. Market and Liquidity Design One of Moment's long-term goals is to allow Badges to continue to be discovered, traded, and collected in appropriate supported market scenarios, rather than remaining only at the level of one-time benefit distribution. The current market-building direction includes: - The already integrated thirdweb Marketplace V3 as the current marketplace settlement infrastructure for supported trading flows - Privy embedded wallets as the low-friction entry point for holding and interacting - Payment and fiat on-ramp paths that are more friendly to Web2 users ### 11.1 Why There Is Currently No Enforced Royalty The current contract supports ERC-2981 royaltyInfo, and Moment has also already integrated thirdweb Marketplace V3 as a live settlement venue for supported trading flows. In the current product stage, however, trading actions are executed through Moment's controlled flow rather than through unrestricted user-side signing across arbitrary external marketplaces. This improves Moment's ability to converge fee and royalty logic within the supported product path, but it still does not mean royalty collection is universally enforceable across every possible transfer path. The reason is straightforward: ERC-2981 mainly provides a royalty declaration interface rather than a market-wide mandatory settlement capability, and third-party marketplace behavior cannot be treated as universally controllable by the token contract alone. Therefore, Moment's current white paper should not exaggerate this capability. A more accurate description is: - Royalty metadata is currently supported - thirdweb Marketplace V3 is currently integrated as the settlement layer for supported trading flows - In the current product stage, users do not have unrestricted user-side signing for arbitrary external marketplace transfers - Moment does not currently describe royalty enforcement as universally guaranteed across all uncontrolled marketplaces or transfer paths - If an app-native marketplace is established in the future, stronger fee, royalty, and trading-rule convergence mechanisms may then be considered ## 12. Security Model and Trust Boundaries Moment is not currently a pure protocol that requires trust in no outside party. It is a consumer-grade asset system with explicit trust boundaries. ### 12.1 What the Current Contract Already Protects - Mint requests cannot be replayed - Redeem requests cannot be replayed - Supply caps cannot be overissued - Expired challenges cannot continue minting - Threshold verifier rules can be validated on-chain - Duplicate verifiers will not be counted more than once - Key Badge terms freeze after the first mint - Expired challenges cannot be reactivated ### 12.2 What Still Depends on Platform Governance - Determination of the authenticity of real-world evidence - Reporting and arbitration - Sybil resistance and multi-wallet cheating control - Security of admin keys and relayer keys - Fairness of review standards and execution This boundary is not a flaw. It is an explicit design choice for Moment at the current stage: the chain guarantees the final truth of the asset, while the off-chain system governs the complexity of the real world. ## 13. Asset Economics and Business Model ### 13.1 Do Not Force a Platform Token into the Current Stage Moment's most important economic primitive at present is not a platform token, but the Badge itself. The Badge can already carry: - Proof value - Scarcity - Community context - Redeemable benefits - Secondary circulation potential Before the product and asset model are fully established, forcing a platform token into the system often causes the narrative to drift away from the product's real value. Therefore, Moment's more reasonable current path is to first make the Badge economy work, and only then decide whether a higher-layer token structure is needed. ### 13.2 Business Model Directions In the medium to long term, Moment's business model can come from: - Issuance and configuration service fees - Controlled marketplace transaction fees - Royalties or revenue sharing in controlled paths - Tooling and service subscriptions for venues, communities, and brands - Merchant redemption partnerships and event collaboration revenue sharing ### 13.3 Gasless Is a Strategic Investment Moment chooses to subsidize the cost of on-chain write operations for users. For consumer products, if users frequently feel wallet friction and gas costs in key flows, it is difficult for the product to grow beyond niche adoption barriers. ## 14. Governance and Control At the current stage, Moment remains a strongly operated and strongly product-governed model rather than a community-autonomous one. In practice, this means that the platform retains control over workflow orchestration, execution entry points, and operational response mechanisms, rather than delegating these functions to fully open or community-led governance. This currently includes the following areas of control: - The initial configuration of challenges and Badges is controlled by administrators - The execution of mint and redeem is controlled by the relayer - Emergency pause is controlled by the pauser - Review, disclosure, reporting, arbitration, and similar processes are mainly governed by the platform system and operations team At the same time, operational control should not be confused with universal custody of user assets. Moment's current model is designed so that assets ultimately reside in user-linked wallets, even though the platform controls key business workflows and the relayed execution path. This structure is reasonable in the MVP and Beta stages, because the system still needs frequent adjustment, strict operations, and rapid response to exceptional scenarios. If the system enters a larger-scale stage in the future, it can consider: - Having multisig take over key permissions - Finer-grained role separation - Introducing a committee or more formal governance process for handling high-dispute scenarios But at the current stage, Moment will not present itself as a system that is already fully decentralized. ## 15. Compliance, Payments, and Real-World Interaction Moment connects real-world behaviors, rewards, and transactions, so it naturally involves issues such as wallet custody, payments, merchant partnerships, and data governance. Moment's current compliance design principles should include: - The platform should avoid directly custodying fiat fund flows wherever possible - Payments, KYC/AML, and dispute handling should be handled as much as possible by compliant service providers - Badges represent proof and benefits, and should not automatically be treated as securities or yield-bearing financial instruments - User identity information, raw evidence, and sensitive business data should not simply be written on-chain ## 16. Privacy and Data Handling Moment will process a large amount of data with real-world context, such as account information, video proof, timestamps, scene information, and reward usage records. Therefore, the system must clearly define which data remains off-chain, which data enters IPFS, and which data should never go on-chain. The most reasonable current principles are: - Raw evidence and materials needed for arbitration remain off-chain - Final metadata and necessary proof references enter decentralized storage - The chain records only the minimum necessary information required for the asset and its state ## 17. Roadmap ### 17.1 Phase 1: MVP / Beta Infrastructure Completed - Single ERC-1155 main contract completed - Challenge and Badge model finalized - Basic mint / redeem mechanism completed - Relayer mode and gasless experience connected end to end - Testnet deployment and integration completed ### 17.2 Phase 2: Strengthen Verification and Redemption Mechanisms - Threshold verifier mode improved - Redemption authority authorized redemption further stabilized - Stronger management permissions and operational control - Audit and security review preparation ### 17.3 Phase 3: Market and Liquidity Build-Out - In-app Badge listing, browsing, and purchasing experience connected - App-native market path takes shape - Better integration with real-world payment systems ### 17.4 Phase 4: Ecosystem Expansion - Expansion to more challenge types and scenarios - A richer Gallery and curation system - A more mature reputation, collecting, and circulation mechanism - A clearer long-term governance model ## 18. Risk Disclosure Moment is still in a stage that requires continuous building and validation, and it must directly face the following risks: ### 18.1 Technical Risks - Smart contracts may still contain unknown vulnerabilities - Third-party infrastructure may be interrupted or fail - The relayer execution path may experience abnormalities ### 18.2 Operational Risks - Admin keys or relayer keys may be stolen - Review and arbitration standards may be inconsistent - User identity abuse and multi-wallet cheating may be difficult to fully eliminate ### 18.3 Market Risks - Some Badges may have insufficient liquidity - Collectible value and utility value may diverge - Uncontrolled marketplaces cannot fully realize the royalty logic the platform expects ### 18.4 Compliance Risks - Additional regulatory requirements may arise when real-world rewards, fiat payments, and cross-region operations are involved Moment's credibility does not come from claiming that there is no risk, but from being able to clearly explain which risks have already been significantly reduced by on-chain rules, and which risks still need to be addressed by platform governance and institutional design. ## 19. Conclusion What Moment is trying to solve is not an isolated technical problem, but the problem of how real-world value can be preserved over the long term in a digital system. Its central proposition is: **How can achievements, challenges, relationships, and rewards from the real world become assets that are not limited to the content layer, but are truly verifiable, ownable, redeemable, and transferable?** On this question, pure Web2 is not enough to provide asset ownership, while pure Web3 may not be suitable for real consumer scenarios. Moment therefore chooses a more realistic path: - Use Web2 capabilities to handle complex workflows, product experience, and real-world governance - Use Web3 capabilities to handle ownership, scarcity, settlement, and final-state proof If this path works, then a Badge will no longer be just an on-chain mapping of an image, but a new kind of digital asset that simultaneously connects real-world behavior, community context, benefit consumption, and long-term collecting.