Partnership Proposal: oStake

[Ata]

Introducing oStake: Dynamic Staking Contract with KPI-based Varying Rewards

Name of the Project:

oStake

Proposer:

Inverter

Proposal Summary

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.

Project Description

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.

Value Add

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:

1. 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.

2. Non-Dynamic Distribution:
   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.

3. Repetitive Deployment:
   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.

4. Governance Friction:
   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.

Contract Set-up of oStake: Dynamic staking mechanism with KPI-based varying rewards

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.

Future

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.

Milestones & Deliverables

TLDR;

• 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

Total Budget Requested

50K $UMA

Project Treasury Address

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.

Core Team

Team member	Role	Past
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

Additional Information

Details on Inverter’s protocol architecture and smart contracts: GitHub - InverterNetwork/InverterProtocolArchitecture: The document for understanding Inverter Protocol's Technical Specifications

[Clayton]

A lot about this careful proposal makes sense to me personally, and I appreciate the time you put into crafting it!

My main hesitation is the actual business case. We had some amount of PMF with KPI Options, but not enough to keep it as a core product focus. So I worry about investing further in that direction.

What I think would move this proposal over the line for me is if you had a mid-or-large sized partner lined up who wanted to use it.

[Ata]

Hi Clayton, thank you for the kind words and questions! I’ll try to address them below:

You are right that even though KPI Options were a frontier idea in how projects can optimize their reward distribution, it didn’t find a grounded PMF. However, the details of why this was the case is important in understanding what were the pain points with projects that implemented KPI Options, and how they can be improved to open up a new scalable use case for UMA’s Oracle via one of the core incentive mechanisms of blockchain networks- staking.

We have done extensive research on the previous use cases of KPI Options (LSP Contracts that UMA introduced) and discussed them with core UMA team members. From this collaborative effort, our thesis emerged: KPI Options were a breakthrough tool in offering a novel incentive mechanism to projects, yet it had fundamental shortcomings in its architectural design to scale adoption, which limited its market reach and made it very difficult to continue even for projects that used this mechanism.

I can comment further on this thesis if you wish, perhaps some of the UMA team members who worked with KPI Options can provide their own thoughts here (for me, if you think about it, the core incentive mechanism of blockchains is KPI based: BTC started with rewarding miners per block produced, which is the key goal of Bitcoin blockchain: successfully producing new blocks), but I will focus on the issues you highlighted in this response.

We tried to elaborate on their shortcomings in the Value Add sections of our proposal, and I’ll try to further break them down here:

With KPI Options, a project that wanted to run a KPI-based incentive program faced significant limitations, such as how it could distribute the option tokens, distribute the rewards, modify the KPIs, integrate the tokens into governance processes, and the extra frictions Option tokens brought to its users. Moreover, it was all a manual process.

• Here is the process that a project would need to follow to set a KPI Option based incentive program:
  1. Decide a set KPI for a set time: e.g. 30 mil TVL after 3 months
  2. Decide and set up an airdrop method to set off addresses.
  3. Deploy the KPI contracts
  4. Deposit collateral tokens into KPI contracts
  5. Airdrop the KPI tokens.
  6. Whitelist new tokens into governance (if desired)
  7. Repeat the whole process again and deploy new contracts every time you want to repeat the incentive period
• Here is the process for the user:
  1. Receive KPI token
  2. Understand the whole process of being incentivized through KPI options
  3. After 3 months, claim the token rewards by interacting with the Option contract

Now, what were the pain points observed?

1. Discrete Reward Processing: The KPI Options model issues one-time reward payouts at the end of the contract period.

• As a user, my payout is not immediately tangible, I need to prepare for a payout that will happen far into the future, and somehow relate to this incentivization to decide on my present actions (e.g. working towards the KPI)
• As a project, my 3-month reward budget unlocks all at the same time. If I want to embed any vesting mechanism, I need to go through another deployment process.

2. Non-Dynamic Distribution: The 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.
• As you mentioned, “A shared payout among people can just encourage slacking and free riding – Sure, I can put in my effort, but everyone else will share in it. Or, I can not put in my effort, and I get to share in everyone else’s.

3. Repetitive Deployment: New contracts and KPI tokens have to be re-deployed every time an incentive period restarts. This creates a painful bottleneck for projects to monitor and re-deploy new contracts each one they want to renew an incentive program. It puts fundamental scalability limitations even in its implementation phase.

4. Governance Friction: Periodic KPI token deployment creates governance issues, such as integrating and whitelisting new tokens into governance.

• The reward tokens you distribute are different from your native token or a staking token. Anytime you want to integrate the KPI token into governance, you need to add new ones with each repetition since each KPI contract produces a different address for the KPI tokens.

5. Bad UX for every involved party: As a user, I don’t just stake and see the reflections of KPI on my rewards. I need to go through a learning curve and then also engage with another protocol with a completely new set of transactions with a new token. Compare that to staking, where I simply stake and earn rewards. As a project, I need to dedicate hours and brain space of multiple people inside my team to put out a deployment process and work on necessary integrations that periodically require re-deployment.

How does oStake address each of these problems and offer an alternative model for KPI based incentives that is effective and scalable?

1. Continous Reward Processing: oStake allows for dynamic and continuous payout models to help maintain active user engagement and incentivize continued participation in the protocol. Rewards don’t come in after 3 months, instead they are distributed over time. Rewards dynamically adjust, in an automated way, to the current KPI.
2. Dynamic Distribution: oStake allows dynamic reward accrual over time, tied directly to KPI performance. So the moment you leave staking, you will not have access to future rewards. The moment you are not eligible to receive rewards, you will not be eligible for rewards. So this addresses the problem you highlighted as well with KPI Options.
3. One-time Deployment: oStake allows for long-term incentive policy management and modification without needing to deploy new contracts. You can over time change your KPI goals and adjust your reward issuance rate. No-redeployment.
4. No Governance Friction: 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.
5. Simple UX: once configured, the staking contract automatically runs and adjust rewards based on KPIs. KPI goals can be changed over time without hassle. For the stakers, it is a simple staking experience like in traditional staking contracts.

• Here is how the user interaction scenarios look like with oStake contracts.
• Project wants to incentivize x metric and issue rewards to its stakers. It creates an oStake contract:
  1. Selects target metric
  2. Selects how it wants rewards to change in accordance with performance against the target metric
  3. Selects the time interval for the metric to be compared agaisnt performance.
  4. Deposits reward tokens to staking contract
  5. Selects the staking token it wants people to stake(gov token, lp token)
• For the staker:
  1. Stakes token.
  2. They receive staking rewards over time just like in normal staking. Within every period, the amount of staking rewards they receive depends on the KPIs the project sets.

For your point on lining up projects who want to use it, I agree that it is great to line up the initial set of users who are interested in piloting a contract’s implementation. And this is what our milestone 4 is all about. We ask for the %40 to unlock only when we bring a pilot case that the UMA community approves on. We prepared these milestones with the consultation of some of the UMA team members, and the feedback was around having a conversation with interested parties as we finish through the initial steps of exact module specifications, and receive a peer review to the code from the UMA core team before onboarding the pilot project for Milestone 4.

But we’ve still reached out to potential PoC partners and started to brainstorm to kickstart that process, some previously KPI Options users like BanklessDAO some none such as Push Protocol. We can start onboarding those partners with the initiation of milestone 1 and share them with the UMA community for the next milestones.

[Clayton]

Very thoughtful reply, a bit blown away by that! I guess I had overlooked the pilot adoption incentive piece.

I’m a YES on this proposal now myself.

[SlowChimera]

I really like this proposal, I think KPI options are significantly underexplored and this proposal addresses a lot of the practicalities that inhibited adoption.

The mechanism was a little unclear to me on first reading, but Ata clarified in the discord in response to my questions (@Ata it might be helpful to voters if you c&p’ed the simplified explanation of how it works and example to this forum) and it looks like a really neat way to allow protocols to adjust their incentives without the need to deploy multiple consecutive contracts, which was a sticking point in getting repeat users.

The one thing I’m still not clear on is what this particular proposal actually entails. In the proposal it says " The first milestone doesn’t seek funding but a community approval for the roadmap and budgeting."

So would the proposal be to set aside $50k $UMA in some kind of escrow where it would be unlocked in three tranches?

[Ata]

@SlowChimera

The one thing I’m still not clear on is what this particular proposal actually entails. In the proposal it says " The first milestone doesn’t seek funding but a community approval for the roadmap and budgeting."

So would the proposal be to set aside $50k $UMA in some kind of escrow where it would be unlocked in three tranches?

Hey @SlowChimera , Basically with every completion of the milestone we will make another proposal to unlock budget for the start of the next milestone, according to the roadmap we propose. Since we don’t seek funding in the initial milestone, the voting will be on initiating this project with the proposed roadmap and budgeting.

[Ata]

@SlowChimera

The mechanism was a little unclear to me on first reading, but Ata clarified in the discord in response to my questions (@Ata it might be helpful to voters if you c&p’ed the simplified explanation of how it works and example to this forum) and it looks like a really neat way to allow protocols to adjust their incentives without the need to deploy multiple consecutive contracts, which was a sticking point in getting repeat users.

That’s a great suggestion, thank you! Here is our Q&A chat on discord:

Q1
On a first read this seems designed for KPIs for liquidity provision. Is this its primary usecase or is there wider applicability?

Are additional KPI options distributed one the programme is in place or is the initial airdrop the only distribution?

A

1. KPIs can be any on/offchain metric that UMA oracle can support. These could be different things depending on what the project wants to encourage. Previous KPI Options use cases include swap volume, borrow amounts, TVL, staked amount, market cap rank, protocol upgrades, and token price. It is what the project wants to incentivize at that moment.
   Over time, what metric a project wants to incentivize can change. With oStake, they don’t need to redeploy the whole contract, but can simply update the module. They can also increase or decrease their KPI target as the project grows and they want to incentivize, say, higher TVL.

2. oStake doesn’t distribute KPI options. Instead, projects can give out rewards directly using their own token, without needing a secondary KPI token. The KPI determines how many rewards are given out in a period of time (like every 2 weeks) and automatically adjusts it every period based on the project’s performance. For a staker, it is a simple user journey like in traditional staking contracts- you stake, and you receive rewards as long as you stay in the staking contract. Behind it, however, how much rewards are issued in a given period is determined by how close or far the project is to their KPI.

Q2

If the module can be updated whats to stop the incentivising entity rugging the KPI holders. So say, there is a binary payout of 100 $token per option if liquidity reaches 100k, but then when it is 90k, the module is updated to make it so that the target is $200k, or is it a rolling thing, so that rewards are streamed rather than a distinct expiry date?

A

Yes, rewards are streamed rather than a distinct date. Think of it like how you would engage with a standard staking contract. You accrue rewards over time as you stay staking. When a KPI is changed it would affect the future streams. So if a project has 100k liquidity goal, and changes to goal to 200k after three months, as a staker who has staked since beginning i would have been earning rewards based on 100k for the first three months, and based on 200k after three months.

Q3
Is it that Coin DAO wants to incentivise x metric, so you stake $coin and get $stakedcoin which operates like a KPI option?

A
let’s walk through your example: Coindao wants to incentivize x metric and issue rewards to its stakers. It creates an ostake contract:

1. Selects target metric
2. Selects how it wants rewards to change in accordance with performance against the target metric
3. Selects the time interval for the metric to be compared agaisnt performance.
4. Deposits reward tokens to staking contract
5. Selects the staking token it wants people to stake(gov token, lp token)

User comes and stakes token. They receive staking rewards over time. Within every period, the amount of staking rewards they receive depends on the KPIs the project sets.

Q3-Follow up
maybe I’m getting a bit hungup on KPI options rather than this design. Under KPI options, at the expiry date you propose the value for the KPI metric, but I’m not clear how the contract knows what value the KPI is? User comes and stakes token. They receive staking rewards over time. Within every period, the amount of staking rewards they receive depends on the KPIs the project sets. So a project says stake your $coin and receive 10% staking rewards, but if the % of staked coins hits 25% by 1st Aug, then the staking rewards go up to 20% until 1st Sept when it changes again (by a KPI set on 1st Aug), and the proposal is made on 1st Aug, 1st Sept etc, so it appears that it is continuous, but in the background there is a proposal on the 1st Aug/1st Sept etc, which determines the staking value for the next month…is that how it works?

A
For the initial implementation based on our research, we plan to design it such that:

1. Project sets staking percentage as goal → %25.
2. It sets recurring periods it wants the KPI value to be received from UMA → every two weeks
3. Every two weeks the staking contract compares staking amount to set KPI by asking UMA Oracle ( i guess this is what you mean by “proposal”?)and informs the staking reward issuance for the next two weeks.
4. After three months, the project now wants to raise KPI to 40%. Now, every two weeks the KPI is checked against 40% target, and rewards are streamed accordingly.

[Alex]

I have had several calls with the Inverter team and I just want to emphasize the amount of time the team has spent working on the proposal and thinking through the design/user experience.

In my opinion, KPI Options have shown PMF for aligning incentives between projects and their communities. That being said, KPI Options require a lot of UMA resources during the implementation process and UMA has many competing priorities (optimistic governance, supporting prediction/insurance, etc).

Therefore, I am excited by the idea of having another implementation that focuses on improving some of the pain points of KPI Options while still using UMA’s Optimistic Oracle.

[Clayton]

A few questions in the leadup to the snapshot vote and community call:

1. The “requested stake” column of your table, is that meant to be paid before the ‘estimated timeline’ period, or after? You do mention it’s milestone-based payouts but I’m just not sure which milestone aligns to which payout exactly.

2. In milestone #2 it says there will be “Code Review and Confirmation by the UMA team.” How much UMA engineer time would you scope for this?

3. Each onchain payment from the treasury requires an onchain vote. Your proposal doesn’t open with any onchain votes. I might suggest delegating to the Risk Labs foundation this responsibility, where we custody the total $UMA balance for you and then make payments at each milestone. If you did this, the onchain vote would be to send the total amount requested to a Risk Labs wallet.

[Ata]

Hi @Clayton , thank you again for the questions and feedback! Below I tried to give answers to your points:

1. The requested payouts are for the initiation of the next milestone. To initiate the next milestone, the current milestone should be completed and the conditions for the next milestone should have been met.

2. For this, with Alex’s guidance, we have been engaging with Reinis as a lead dev from UMA for ostake, throughout the initial architectural review, writing of the specifications, and design decisions with regards to UMA Oracle integration. So far having one or two biweekly sessions has been very helpful, and we would need majority of the time when the KPIRewarder Module development will be completed.

3. Happy to do so! Let me check in with the Risk Labs team, and I will update this post with the Risk Labs multisig as the specified treasury address and add an explanation for that. Thank you for the suggestion!

Please let me know if you would like me to clarify further on any of these points, or if you have any other questions?

[SlowChimera]

If the proposal is to send the full amount to a RL custodial wallet, that passes the decision making power to release funds for each stage from the UMA DAO to Risk Labs, as tokenholders would not then have the ability to approve each tranche.

I dont have an issue with this, as I think its a good proposal, worth funding in its entirety, and Risk Labs is a trustworthy custodian, but I think its worth pointing that out for clarity.

[Ata]

Hi everyone, a quick update on the proposal:

1. With @Clayton suggestion, I spoke to Alex for setting Risk Labs’ multi-sig to take custody of the total $UMA balance for this proposal and be responsible for confirming payouts at each milestone. I added the Risk Labs multi-sig address to the proposal as the recipient address.

2. I tried to clarify what this means for the milestone checks and how we want to ensure transparency and participation by the UMA community based on @SlowChimera 's feedback.

Hope it is all clear? We will also have a UMA community call later today (08.08.2023), happy to go over the proposal in more detail and answer any question there as well!

[Ata]

The oStake proposal is up again for vote on UMA snapshot after a month of community discussion and feedback: Snapshot

We have republished the proposal after missing the quorum in the previous vote by just 1% with participation from UMA Stakers voting 32 YES (3.27m) and 0 NO. Therefore, if you can, please take a look at the proposal and participate in voting as early as possible! Thank you!

[kevin]

Hi @Ata - Thanks for writing the proposal and answering all the questions. Apologies for joining in the discussion late. I believe I was on vacation during the community call. I have a few questions related to the team and how these tokens will be used:

1. How is the Inverter team funded now?
2. If the Inverter team does not receive this grant would this oStake product still be a priority? Would it still be built?
3. When the Inverter team receives these UMA tokens will they all be sold for stables to fund your team?
4. For milestone 4, do you require only one project to deploy? And how meaningful would this TVL be to qualify? The milestone seemed pretty loose and wide for interpretation.
   Thanks
   Kevin

[Ata]

Hi @kevin , thanks for the questions. No need for apologies; however late, it is always welcome

1. Inverter is currently raising for pre-seed. We’ve been bootstrapping Inverter team internally for couple months also and have some grant funding. We also started generating revenue from projects deploying through Inverter.

2. If the team doesn’t receive this grant, oStake will still be a priority. In fact, since the governance process lasted a bit longer than we envisioned, we already started with Milestone 1 We chose to build oStake with UMA as the oracle of choice rather than the others, since we believe in its value proposition as a generalized truth machine and we want to be a long term contributor and participant in its future.

3. As stated in the proposal, no UMA tokens will be sold for at least a year. We will stake UMA and participate in the oracle verification process for the use cases we will be enabling. Only for the public audit competition, we will stake UMA for bounties, as described in the audit milestone to elevate the security standards of oStake contract. This, however, incentivizes us to deliver a good code- so we retain a larger UMA in Inverter treasury!

4. For milestone 4, we require at least one project to deploy a real time pilot, but we will be inviting a lot of projects to test it. We already started reaching out to projects interested in using oStake for different means. Our incentive is to build and populate use cases of oStake as much as possible, since we are not building it for nothing; we are also investing a lot of resources to make oStake one of Inverter’s flagship PoCs. The goal is to establish a solid case study, formulate documentation and use cases as a reference to reach out to more projects.

Hope it was all clear? Please reach out if you have more questions you are curious about! Thank you

[Ata]

Hello everyone,

I wanted to give a status update on oStake. We have completed milestone 1 with the specifications completed for oStake and have kicked off milestone 2.

First of all, we would like to acknowledge that we are submitting this milestone completion report a bit later than we planned for. One big learning point for us was improving the communication and coordination with the UMA team to achieve a faster progress over the milestones. Since the completion of the milestones depends on the getting a sign-off from the UMA team with the review, we will do better in planning and communicating the review needs beforehand!

Here, you can find the document for oStake workflow specifications, which is still open to comment if anyone has a question: oStake Workflow Specifications - Google Docs

This document also outlines the implementation requirements for Milestone 2, which we have already begun and we are working towards submitting it for code review soon!

With the completion of the first milestone, we are looking forward to becoming an active governance participant in UMA!

Thank you