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.