> For the complete documentation index, see [llms.txt](https://ours-meme-1.gitbook.io/ours.meme-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ours-meme-1.gitbook.io/ours.meme-docs/impel/invitations.md). # Invitations The community invitation and referral framework serves as the primary network-scaling module across the OURS (`ours.meme`) ecosystem on the open, EVM-compatible Robinhood Chain (Chain ID: 4663). Grounded in the foundational principle that *"those who build the market, own it,"* the protocol rejects multi-level pyramid schemes, artificial clicker tasks, and speculative point farming. Instead, it permanently converts genuine referred liquidity, trading volume, and community expansion into protocol equity and real fee cash flows via on-chain, single-tier attribution. ### 1. Referral Binding & Architecture Rules The platform implements an immutable, anti-Sybil attribution framework where verified on-chain events and cryptographic proofs serve as the sole source of truth: * Single Immutable Binding: Each user wallet can bind exactly one referrer address throughout its lifecycle; once registered on-chain, this relationship cannot be altered, overwritten, or revoked. * Strictly Single-Tier Attribution: The protocol recognizes direct (Tier-1) referrals only. Multi-tiered structures, cascading downline splits, and pyramid kickbacks are permanently excluded by design. * Zero Trader Penalty: Binding an invite link or referrer address incurs no extra trading fees or slippage penalties. Referred traders enjoy the standard base fee and creator fee structures with full execution integrity. * On-Chain Activation Point: Attribution registers upon the user's first signed on-chain transaction after connecting via an invitation link. Transactions executed prior to wallet binding cannot be attributed retroactively. ### 2. Value Capture & Reward Sources Referral rewards are funded by real protocol mechanics and non-dilutable token reserves rather than unbacked inflationary emissions: Plaintext ``` Referrer Value Flow │ ┌────────────────────────────┴────────────────────────────┐ ▼ ▼ [ 50% Behavior & Content Mining Pool ] [ 16% Ecosystem Support & Rewards ] (Hardcoded in Total Platform Supply) (Funded via 30% Net Protocol Fees) │ │ Accrues shares from referred volume, Flywheel streams $OURS market buybacks onboarding, and graduation milestones into verified contributor reward pools │ │ └────────────────────────────┬────────────────────────────┘ ▼ [ User-Claimable Reward Vault ] (Non-Custodial FeeEscrow) ``` * 50% Behavior & Content Contribution Mining Pool: * 50% of the native $OURS platform token supply is hardcoded for verified ecosystem contributions. * Effective trading volume, swap turnover, and successful curve-to-Uniswap v4 graduations driven by referred wallets accumulate continuously toward the referrer's contribution balance. * Flywheel Ecosystem Support & Contributor Stream (from the 16% Allocation): * Across the transparent 48/16/16/20 platform fee flywheel, 16% is dedicated to Eligible Ecosystem Project Support and Contributor Rewards. * A dedicated portion of this leg executes open-market buybacks of $OURS to fund the active contributor reward budget (these tokens are distributed to builders and referrers rather than burned). * Epoch Distribution Framework: Eligible rewards accrue dynamically based on verified contribution shares: $$\text{User Epoch Reward} = \text{Allocated Epoch Budget} \times \frac{\text{User Valid Contribution Points}}{\text{Total Valid Points Across Eligible Users}} \quad \text{}$$ ### 3. Sybil Resistance & Contribution Verification To preserve long-term incentives for authentic community builders, the referral pipeline enforces rigorous verification standards: * Self-Referral & Linked-Wallet Exclusion: The platform actively identifies and filters circular self-referrals between affiliated wallets controlled by the same entity. * Wash Trading & Synthetic Volume Scrubbing: Artificially inflated volume generated through zero-slippage self-trades, circular cross-swaps, and automated ledger padding is excluded from reward calculations. * Protocol Action Exemption: Internal protocol operations—including automated buyback & burn calls, liquidity seeding (POL), and manual reward claims—do not generate referral points. * Reorg Reversal Protection: Reward attribution and contribution records settle exclusively upon final block confirmations. In the event of an underlying EVM reorganization, unconfirmed actions roll back automatically to maintain ledger consistency. ### 4. Non-Custodial Claims & Gas Responsibilities In full accordance with non-custodial smart contract standards, network gas fees are borne strictly by the transaction initiator without centralized subsidies: | **Interaction** | **Executing Actor** | **Asset Movement & Rights** | **Gas Fee Payer** | | ----------------------- | ----------------------------- | ---------------------------------------------------------- | ---------------------------------- | | Referral Binding | Referred User | Registers permanent on-chain Tier-1 link | Initiating User (Referred Address) | | Merkle Root Publication | Protocol Automation / Relayer | Submits verified contribution roots to the reward contract | Protocol Keeper / Execution Path | | Claiming Rewards | Referrer (Beneficiary) | Transfers unlocked $OURS directly into destination wallet | Claiming Referrer | * Zero Privilege Delegation: Platform operators and multi-sig signers possess no technical backdoors to alter, withhold, or redirect user-accrued rewards. * Self-Sovereign Gas Execution: Reward vaults holding assets cannot execute meta-transactions to cover gas on behalf of external EOAs. Users must maintain sufficient native Robinhood Chain ETH to execute claim transactions. ### 5. Specification & Implementation Status | **Parameter** | **Specification Standard** | **Implementation Status** | | ----------------------- | ------------------------------------- | ------------------------------------------------------------------------- | | Attribution Model | Strict Tier-1 (Direct Only) | Enforced on-chain; multi-level schemes excluded. | | Binding Limit | Exactly 1 referrer per wallet | Production standard; immutable once registered. | | Participant Cap | Uncapped invitee capacity | Open to community builders, KOLs, and volume drivers. | | Settlement Method | Dynamic epoch-based settlement | Settled relative to verified on-chain actions and reward budgets. | | Flywheel Protocol Share | 16% Ecosystem & Contributor Support | Funds regular open-market buybacks distributed to builders and referrers. | | Production Integration | Isolated Reward Distributor & Indexer | Non-custodial claiming via the My OURS dashboard. | > Launch Tokens. Fund Builders. Reward Culture. Grow the Market Together. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://ours-meme-1.gitbook.io/ours.meme-docs/impel/invitations.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.