This proposal introduces oStake, a novel staking contract that dynamically optimizes staking rewards based on Key Performance Indicators (KPIs). Overcoming the limitations of traditional staking models and UMA’s KPI options, oStake continuously adjusts rewards according to set KPIs to create a more dynamic, engaging, and efficient system for incentive mechanisms while maintaining the UX simplicity of traditional staking contracts.
Staking is one of the core mechanisms for incentivizing participation in protocols and governance with skin in the game. However, traditional staking models often provide fixed rewards, which does not adequately incentivize users to actively contribute to a project’s growth and success.
UMA KPI options provided a novel tool to tie key protocol success metrics to its incentive policies, which enables more sound and sustainable reward systems for projects aligned with protocol goals. To this date, around 20 projects have used KPI options to adjust their reward issuance to a wide variety of use cases, such as swap volume, borrow amounts, TVL, staked amount, market cap rank, protocol upgrades, and token price among others.
However, the KPI options model presents several challenges, including difficulties in individual deployment and integration, limitations in continuous deployment, the token distribution model, and incentive management issues. Additionally, with multiple KPI contracts, integrating with governance systems becomes increasingly difficult, highlighting the need for a more efficient and flexible solution.
In collaboration with UMA, we propose oStake as a dynamic staking contract template that can continuously issue KPI based rewards. With oStake, the amount of staking rewards paid out periodically adjusts to set KPIs. Similar to the staking contracts, we keep the general staking contract structure where there is a token staked, and staked token accrue a share of the rewarding pool that emits rewards over period. But rather than defined emission at each period, its emission rate in each defined period changes in accordance with KPIs. The periodic updates to rewards comes from UMA’s Optimistic Oracle.
Inverter is a modular protocol infrastructure for programmable workflows. Simply put, it offers the Inverter Open Library of Smart Contract Modules that can be customized and composed into automated workflows (in this context workflows refer to user journeys or use cases) that are executed on an Orchestrator Contract, which is a kind of conductor for linking and managing modules in a workflow. Each module acts as a specialized tool like in a carpenter’s kit that can be combined with others to build more extensive and more complex structures.
In the case of oStake, Inverter’s native modules work in tandem with UMA’s Optimistic Oracles to enable a dynamic staking contract template and widen the capabilities of standard staking contracts for protocol incentives. The proposed architecture not only facilitates continuous, dynamic reward payouts but also allows for long-term incentive policy management and modification without the need to deploy new contracts.
oStake can effectively address the major design limitations of KPI Options to scale the adoption of dynamic staking contracts. Let’s break them down one by one:
Discrete Reward Processing:
KPI Options model issues one-time reward payouts at the end of the contract period. In contrast, oStake allows for dynamic and continuous payout models to help maintain active user engagement and incentivize continued participation in the protocol.
KPI Options model distributes tokens in a single airdrop at the start of each incentive period, which rewards recipients irrespective of their actual contribution towards meeting the future KPI goals. The addresses receiving the KPI options are not held accountable if they contributed to the stated goal. oStake allows dynamic reward accrual over time, tied directly to KPI performance. This means that a community is incentivized to actively engage towards KPI metrics, as their rewards depend on it.
With the existing UMA model, new contracts and KPI tokens need to be deployed every time an incentive period restarts. This can be complex and time-consuming. oStake allows for long-term incentive policy management and modification without needing to deploy new contracts.
Periodic KPI token deployment creates governance issues, such as integrating and whitelisting new tokens into governance. oStake allows issuing rewards with a project’s native token or native staking token, without needing to introduce a new KPI token. Therefore, projects can seamlessly integrate oStake contracts into their governance framework.
Here is an example scenario of a protocol using oStake to deploy a dynamic staking contract: A protocol, called Optima, creates an oStake contract. It sets a TVL target to be provided in its native liquidity pool and sets the epoch intervals it wants the contract to check the TVL target with UMA Oracle (e.g. every 2 weeks), and how it wants to adjust staking rewards based on its TVL target. It then defines the maximum amount of staking rewards available for distribution and deposits tokens. Stakers stake their tokens in the oStake contract and start providing liquidity to the pool. The oStake contract monitors the total amount of liquidity in the pool on an epoch basis, comparing it against the predefined target for the TVL. As the total liquidity in the pool increases, the staking rewards for the next epoch distributed to stakers also increase proportionally up to a maximum limit set by the protocol to motivate users to add more liquidity to the pool. If the liquidity in the pool drops, the staking rewards for the next epoch are dynamically adjusted downwards in accordance with the decrease in participation to save funds. Optima can periodically update the liquidity target to align with its strategic objectives and market conditions, without needing to launch new contracts.
oStake offers a staking contract that can continuously optimize the distribution of staking rewards based on the performance of various on/off chain KPIs with the following set-up:
And below is a breakdown of each module component in the oStake:
|Module Category||Module Name||Module Function||Module Parameterization|
|Authorizer||ListAuthorizer||Determines who can set KPIs.||Only the Project is authorized|
|Logic Modules||UMA KPI Module||Checks KPIs with UMA oracles and generates PaymentOrders based on those KPIs.||The Project sets the KPIs and UMA oracle to validate them. Passing checks are sent to the PaymentProcessor as PaymentOrders|
|Funding Manager||Staking Funding Manager||Users stake and withdraw tokens.||Rewards from the PaymentProcessor accrue to all users equally|
|Payment Processor||SimplePaymentProcessor||Holds token supply and sends it to the staking contract.||Sends funds only to the FundingManager|
The user flow with the contract interactions The Project sets up an oStake contract and deposits the token supply into the PaymentProcessor. It also sets up the Logic Module with specific KPIs. Users stake tokens on FundingManager, and UMA oracles validate the KPIs. Once a KPI is validated, the Logic Module sends a PaymentOrder to the PaymentProcessor and rewards are sent to the FundingManager. Stakers accrue their rewards equally.
UMA has created the LSP(Long-Short Pair) contract template to showcase how UMA’s Optimistic Oracles can empower numerous financial products. Inverter’s modular architecture can advance and scale the adoption of use cases LSP contracts frontiered by leveraging UMA’s Optimistic Oracles with Inverter native modules.
At the heart of Inverter’s design is flexibility. Its modular architecture enables constructing complex systems using simple, interchangeable components. This plug-and-play approach allows building customizable and efficient solutions for specific use cases as easily deployable contract templates.
oStake leverages UMA’s Optimistic Oracles with Inverter native modules to enable a dynamic staking contract template that widens the capabilities of standard staking contracts for protocol incentives. Importantly, oStake is but one example of combining Inverter modules with UMA’s Optimistic Oracle as building blocks. Developers have the power to mix and match Inverter modules with Optimistic Oracles to create a plethora of contract templates for innovative financial products.
Even for the oStake, various Inverter modules can be composed to adapt to varying design needs. For instance, by eliminating the staking module, oStake morphs into a oRewarder, automating dynamic token rewards allocation to diverse addresses. Alternatively, by replacing the staking module with a token purchasing module, projects can sell tokens with a call option in the pool, like UMA’s Success Token. Projects can also fine-tune their payout or issuance policy as modules, ranging from straightforward payouts to periodic payments on longs, streams, and vesting schedules. Moreover, the management of the whole contract can be structured to fit the on-chain governance, as projects can easily structure the access controls and on-chain of their oStake contracts.
To conclude, Inverter <> UMA partnership to pilot oStake is not a proposition to build the next version of LSP contracts, but aligning on an infrastructure partnership that can support any future versions.
- Inverter will cover all the smart contract development and auditing costs.
- We are asking UMA to only stake a Public Bounty on Hats Finance.
- With the completion of each milestone, we ask $UMA for Inverter stake to participate in UMA’s governance and not sell for at least a year.
|Milestone||Objective||Deliverables||Estimated Timeline||Requested Stake|
|Milestone 1: oStake Specification||Align on a technical specification for starting the development of oStake.||Technical Specification to start 1. New module development 2. Integration with UMA Oracles||~2 weeks||NA|
|Milestone 2: oStake Development||Develop oStake||1. All the required modules are developed and documented 2. The oStake Workflow is set up 3. Code Review and Confirmation by the UMA team before Audit||~2 months.||10k $UMA|
|Milestone 3: Audit Complete||Audit oStake||1. Complete audit 2. Launch a public bug bounty competition on Hats Finance||~3 weeks||20k $UMA to be first staked on Hats Finance for bounty|
|Milestone 4: Pilot Case||Experiment with projects that has previously deployed KPI Options to analyze the improvements||1. Agree with a project that has previously used UMA KPI Options to launch a reward/incentive program with oStake 2. Work with the project to set up, implement, and run oStake 3. Write a case study report analyzing the observations and suggesting future improvements 4. Decide if more test cases or improvements are needed||Depends on the incentive period of the pilot project(s) that deploy oStake||20k UMA|
Risk Labs Multi-sig: 0x8180D59b7175d4064bDFA8138A58e9baBFFdA44a
Note: The on-chain vote will be to send the requested funding for the milestones to the Risk Labs foundation’s multi-sig, which will custody the total $UMA balance for this proposal and be responsible for confirming payouts at each milestone.
This proposal seeks a confirmation on the proposed roadmap and budgeting by the UMA Community, and delegating Risk Labs the decision making power over the completion of the milestones.
To ensure transparency and community participation, Inverter team will post an update to UMA community forum for every confirmed milestone.
|Alp Ergin||Cofounder||Gitcoin, Prime|
|Ataberk Casur||Cofounder||Curve Labs, Prime|
|Marvin Kruse||Protocol Architect||Byterocket|
|Pablo Carra||Smart Contracts||Token Engineering Commons|
|Felix Firscht||Smart Contracts||Byterocket|
|Baran Baloglu||Solutions Architect||Vodafone|
|Bora Baloglu||Full Stack/ Backend||Rapsodo|
Details on Inverter’s protocol architecture and smart contracts: GitHub - InverterNetwork/InverterProtocolArchitecture: The document for understanding Inverter Protocol's Technical Specifications