diff --git a/network-rfc/11_tokenomics_v2.1.md b/network-rfc/11_tokenomics_v2.1.md new file mode 100644 index 0000000..b4a05fd --- /dev/null +++ b/network-rfc/11_tokenomics_v2.1.md @@ -0,0 +1,78 @@ +# Tokenomics 2.1 + +## Overview + +Tokenomics 2.1 addresses the centralization issues of Tokenomics 2.0, namely: + +- That there is a single (de-facto centralized) pool for providing SQD for yield, which makes SQD a security +- The lack of dynamic pricing and many parameters that has to be hard-coded/adjusted in a centralized (or, at best, DAO-like) fashion. The subscription fee is not established by an open market and the marketplace. +- Removing the treasury-initiated buyback-and-burn mechanics which makes SQD a security +- Moving the reward token out of scope +- Introducing the fee switch to the Portals (to be activated in the future if necessary) +- Making it possible to register Portals on EVMs (in particular, Base) and Solana. For Solana users, it opens up the posibility to pay in USDC or SOL. + + +## The SQD Flows + +**Workers** +Workers serve the data and receive rewards in SQD. The reward depend on the number of served queries, the amount of delegated tokens and the uptime of the worker. The worker has to lock 100k SQD to participate in the network. The maximal amount of rewards distributed per worker and the delegators is controlled by a single parameter called `TARGET_APR`. The reward is then split abetween the worker and the delegators for the worker. + +**Delegators** +Delegators delegate SQD to workers to get a part of the worker reward. Both the amount of delegated tokens and the served queries affect the reward per query served. + +**Data consumers** +Data consumers query the network p2p using a Portal. The maximal bandwidth that can be consumed by a Portal is determined by the amount of SQD locked in the Portal contract. Thus, the data consumer either buys SQD on the open market and locks the desired amount themselves, or makes an _SQD Provision Offer_ to SQD holders willing to provide SQD in return to the fee. + +An SQD Provision Offer is an agreement to lock SQD for a specified amount of time for a fee, paid as continuosly during the whole lock period. The fee is locked by the consumer in advance and can be paid in any of the supported tokens. Special conditions apply for extending the provision offer and withdrwals. + +**SQD providers** +SQD providers hold SQD and fullfill the matching _SQD Provision Offers_. Active providers can advertise their target fees in advance to make the market and set the expectations for the data consumers. + +## Emission reduction + +The `TARGET_APR` currently set to 25% yearly, will be gradually reduced and replaced by the fees collected from the portals. + +## Portal Payments + +The are two options to get data through the portals: +- Lock SQD tokens (the existing flows) +- Pay a subscription fee in one of the supported tokens, so that the SQD is locked by one or multiple SQD providers. + +**The subscription flow** + +The user specifies: +- the required bandwidth (which translates into the required SQD to be locked) +- the terms (fix-term or auto-extension) +- the price (the dApp will provide the current quotes of the SQD providers to give a reasonable offer) + +The user: +- creates a Portal Registration Contract +- makes the fee deposits +- the willing SQD providers lock the SQD for the required term + +The fee is deducted every epoch and automatically split: +- 50% to the SQD providers +- 45% to the worker reward pool +- 5% gets burnt + +The fee parameters are adjustable. + +![image](https://gist.github.com/user-attachments/assets/9d3977ee-aa80-4a6f-a248-83656abc10e1) + + +## The fee switch + +Apart from the fees collected from the subscription fees, Tokenomics 2.1 introduces a fee switch directly to the portals. +The fee switch is initiall set to zero, but can be switched on at a later time. + +When it is on, the fee is deduced from SQD locked in every Portal contract, and distributed between burn and the reward pool. +That way even the users self-staking SQD will pay a usage tax. For SQD providers the tax may be compensated directly by the fee. + + +## Deployments to Solana and other networks + +The Poral Registration factories allow deployments on foreign networks, such as Base and Solana, assuming the two-way bridging is possible. In order to integrate a foreign chain one would need + +- Update the Worker nodes to listen to the registration events +- Establish a canonical "bridged" token on the target chain with minimal liqidity pools +- Implement bridging of the fees to be teleported to the host chain regularly, to top up the reward pool on the host chain \ No newline at end of file diff --git a/network-rfc/12_contracts_design.md b/network-rfc/12_contracts_design.md new file mode 100644 index 0000000..de17c1f --- /dev/null +++ b/network-rfc/12_contracts_design.md @@ -0,0 +1,74 @@ +# Portal System + + +### Portal Pool Creation and SQD Collection + +The Portal System begins when a Portal Operator creates a new portal pool through the PortalFactory by specifying key parameters including the maximum capacity (amount of SQD tokens), deposit deadline, payment token, and "budget". + +The portal operator allocation (contribution by the deployer) will be determined by the maximum capacity that the portal operator is seeking. + +The maximum capacity parameter defines the total amount of SQD that can be staked into the portal pool. This can be configured by the portal operator during creation and can be increased later if needed. The contract requires this amount to be higher than the minimum stake threshold (set by protocol governance/gateway registery contract) for portal registration. + +The factory deploys a single PortalPool contract, an upgradeable instance that combines both the core distribution logic and SQD vault functionality into one unified contract. +Once deployed, SQD token providers can stake their tokens directly into the PortalPool by calling the stake function with the portal pool address and desired amount. + +During this collection phase, the portal pool remains in a "Collecting" state where it accumulates SQD deposits from multiple providers until either the maximum capacity is reached or the deposit deadline passes. +If sufficient SQD is collected before the deadline (meeting the minimum threshold for portal registration), the portal operator can trigger the activate function to transition the portal pool to its active distribution phase. + +However, if the deadline expires without reaching the minimum threshold required for portal registration, the portal pool is marked as failed, triggering a full refund of both the operator's budget and all staked SQD tokens back to their respective owners. + +### Active Distribution and Fee Routing +Once activated, the portal pool enters its Active state where it begins distributing + +Throughout this active period, the portal operator can call the distribute function to inject tokens into the contract, which will be distributed across SQD providers etc. +This amount is distributed based on the FeeRouterModule, a separate admin-controlled contract responsible for splitting the fees according to configurable basis point allocations (configurable k% goes to the treasury and the rest goes to SQD providers). + +The FeeRouterModule holds the actual BPS. + During both the staking and distribution phases, the system can trigger external Hooks at key moments (before and after staking, distribution, and exits), allowing for customized behavior such as additional protocol token rewards layered on top of base distributions etc. + Similar to UniswapV4 Hooks. + + +The portal scales down its capacity as SQD is withdrawn but continues operating until the minimum threshold is breached. + + +**Two-Step Withdrawal Process:** + +1. **Portal Pool Exit Delay**: Exits are subject to a time-delay mechanism designed to prevent sudden liquidity shocks. The exit delay consists of a base period of 1 epoch plus a percentual delay calculated by the amount being withdrawn. The system allows a maximum of 1% of the total portal pool liquidity to exit per epoch, meaning if a provider wants to exit 5% of the liquidity, they must wait 1 epoch (base) plus 5 additional epochs (one epoch per 1% of liquidity), totaling 6 epochs before their full withdrawal is processed. Providers can withdraw unlocked portions incrementally (1% per epoch) rather than waiting for the full delay period to complete. + +2. **Liquid Unstaking from Registration**: Once the exit delay period completes and the withdrawal is processed by the portal pool contract, the Portal Registration Contract handles the actual unstaking. Since the registration contract supports liquid staking, the unstaking happens immediately without additional lock periods. The compute units allocated to the portal are reduced proportionally as SQD is unstaked. + +For example, if a provider holds 10% of the portal pool's total SQD and wants to exit their entire position, they would need to wait 1 base epoch + 10 epochs (for the 10% withdrawal) = 11 epochs total in the portal pool. + +**Importantly, once a provider requests an exit, they stop earning rewards on the requested exit amount during the entire waiting period** + +New SQD providers can enter the portal pool at any time, including when existing providers have requested exits. This allows for seamless replacement and maintains liquidity continuity in the pool. When new providers stake, the portal registration contract immediately increases the allocated compute units proportionally. + +Throughout this entire process, the system maintains upgradeability through the proxy pattern (allowing the factory admin to deploy improved implementations without affecting existing portal pools), adjustable fee distributions (admins can modify the FeeRouterModule configuration to change allocation percentages), and emergency controls (pausing functionality at both the factory and individual portal pool levels for security purposes). + +--- + +## State Transitions + +``` +Collecting → Active → Closed + ↓ + Failed +``` + +- **Collecting**: Portal pool accepting SQD deposits, waiting to reach minimum threshold before deadline +- **Active**: Minimum threshold met, portal registered and distributing tokens when injected. Portal continues operating as long as staked amount remains above minimum threshold, with compute units scaling proportionally. +- **Failed**: Deadline passed without reaching minimum threshold, full refunds enabled +- **Closed**: Portal pool closed? + + +### To Discuss + +1. **Liquid Stake Tokens (LST) vs NFTs**: + - SQD provider positions could be represented as Liquid Stake Tokens (fungible) or NFTs (non-fungible) + - Issue: LSTs would be tied to each portal pool (potentially 100+ different tokens if many portals exist) + + + +### Portal Registration Contract (V2) + +A new simplified Portal Registration Contract will be created to replace the current GatewayRegistry for portal pool operations. This contract is designed specifically for the portal pool system. diff --git a/network-rfc/13_frictionless_payments.md b/network-rfc/13_frictionless_payments.md new file mode 100644 index 0000000..254a76d --- /dev/null +++ b/network-rfc/13_frictionless_payments.md @@ -0,0 +1,99 @@ +# Frictionless Payments for Revenue Pools + +## Summary + +The goal of this initiative is to remove the biggest onboarding friction between Web2 users and Web3 participation in SQD Revenue Pools. + +Today, participating in a pool requires users to understand wallets, buy tokens, move assets onto the correct network, and complete an onchain action. +That flow is too complex for many first-time users and likely causes meaningful drop-off before users ever reach their first lock. + +The proposed solution is to introduce a frictionless onboarding flow using Wallet-as-a-Service and integrated on-ramping, +so a user can go from landing on a pool page to funding and locking into a pool through a familiar checkout-like experience. + +This does not only apply to Revenue Pools. +The same infrastructure can later support Portal usage payments and other Web2-to-Web3 payment flows inside the SQD ecosystem. + +## Problem +### Current situation + +The current user journey is too long and too technical for mainstream users. + +A new participant typically has to: + +1. Understand what SQD and Revenue Pools are. +2. Install or connect a browser wallet. +3. Buy SQD or buy another asset first. +4. Ensure funds are on the correct network. +5. Potentially bridge assets to Arbitrum. +6. Connect the wallet to the app. +7. Approve and lock SQD into the pool. + +This means users face multiple friction points before they experience any product value. + +## Why this matters + +Revenue Pools are not just a community feature. +If users drop before funding or locking, We lose: +- perceived product momentum +- conversion from interest to actual locked capital + +## Proposed solution + +Introduce a frictionless onboarding and payment flow using: + +- **Wallet-as-a-Service** +- **embedded wallet creation** +- **Apple Pay / card on-ramp** +- **one-click or near-one-click lock into a Revenue Pool** + +### Target user flow + +1. User lands on a Revenue Pool page. +2. User signs up with email, Google, or Apple. +3. Wallet is created automatically in the background. +4. User funds via Apple Pay or card. +5. Funds are routed to the correct chain and asset path. +6. User confirms and becomes an active pool participant. + +The key principle is simple: the user should reach their **first lock** before needing to learn wallet infrastructure. + +## Market examples +### Moonshot +Moonshot is one of the clearest examples of a crypto product using a familiar payment experience to reduce onboarding friction. +Its product messaging emphasizes that users can convert cash to crypto quickly, and its App Store listing shows 2M+ users. + +More importantly, Coinbase published a dedicated [Moonshot case study](https://www.coinbase.com/developer-platform/discover/case-studies/moonshot) stating that Moonshot **increased onramp conversion by over 25%** using Coinbase Onramp API. + +Coinbase also says Moonshot users could onboard funds **approximately 40% faster** with the new flow. + +**Why this matters for SQD:** it proves that a mainstream-feeling fiat-to-crypto flow can meaningfully reduce the psychological and operational barrier to first onchain action. + +### pump.fun + +[Privy’s pump.fun case study](https://privy.io/blog/token-creation-for-everyone-with-pump-fun) reports that since integrating Privy for wallet infrastructure, pump.fun has seen: + +- 2.5 million self-custodial wallets provisioned via Privy +- 8.5 million transactions since embedded wallets became the default + +**Why this matters for SQD:** when wallets become invisible and automatic, products can scale onboarding dramatically. + + +## Expected value +- Baymard reports that 19% of checkout abandonment comes from forced account creation, 18% from a long or complicated checkout, and 10% from not having enough preferred payment methods. +- Stripe reported that showing at least one additional relevant payment method increased conversion by 7.4% on average and revenue by 12%; +Apple Pay alone delivered an average 22.3% conversion uplift and 22.5% revenue uplift in Stripe’s study. +- Apple states that making Apple Pay prominent and default reduces abandonment and increases conversion. + +- **Baymard cart abandonment data**: [Baymard — Cart Abandonment Rate Statistics](https://baymard.com/lists/cart-abandonment-rate) +- **Baymard checkout usability research**: [Baymard — Checkout Usability Research](https://baymard.com/research/checkout-usability) +- **Stripe payment method conversion study**: [Stripe — Testing the conversion impact of 50+ global payment methods](https://stripe.com/blog/testing-the-conversion-impact-of-50-plus-global-payment-methods) + +Because the current SQD participation journey is more complex than a typical ecommerce checkout, these benchmarks should be treated as a conservative floor, not a ceiling. + +

+ Conversion benchmark chart +

+ +## One-line takeaway + +**Portal Pools do not need better wallet education first; they need a flow where users can reach their first lock before infrastructure friction makes them drop.**