KPI Options Resources

A Guide to Creating and Distributing Token Options for Defi Communities

Introduction So you've heard about the amazing piece of financial wizardry that is UMA KPI Option, maybe a proposal has been made, and your community is considering whether it would work for them

This guide to to help you navigate your way through the creation process. We have a lot of tools and a really supportive community that can make it easy for you to create KPI options without taking up precious dev. time.

Creating KPI Options - a step by step guide.

1.Define your metric

A KPI Option is redeemable for tokens at a defined future date, with the amount contingent on a particular metric. They are designed to incentivise the community into taking some action which maximises the chances of the indicator being met. The amount of protocol tokens that the option token is redeemable for depends on the performance of the Indicator that you want to optimise for.

Some potential KPIs might be the Total Value Locked (TVL) in the protocol, the number of tokenholders, or the number of participants in governance votes, but pretty much anything that you can measure and that is important for your growth can be used.

  1. Decide on your collateral type

The collateral is what is distributed to the KPI Options holders at the time of expiry If the protocol has more than one token, there will need to be a decision on which will be used as the collateral. If the collateral type chosen is not whitelisted for use in UMA contracts, you would have to submit an UMA Improvement Proposal (UMIP) to have the collateral type approved for use.

If you require support to write the UMIP, we have community members who are experienced in writing UMIPs, and we encourage them to post on the "talent available" board on the UMA Discourse. We also have an "Opportunities at UMA Collaborators" board, where you can post a bounty and wait for community members to respond, but you are welcome to submit an early draft and continue to edit.

  1. Add a price identifier for your KPI Option through the UMIP process

This is where you define how to determine the "price" of the KPI that you are tracking. Price in this context is a bit of a misnomer, but refers to the value of the metric that you are tracking (eg TVL, tokenholders, voters etc.). A template for a KPI Price Identifier UMIPs is available on our Discourse by opening a new topic, however again the "talent available" and "Opportunities" boards are useful for finding people who can turn this around quickly.

The deadline for UMIPs is 00.00UTC on a Thursday. All submitted UMIPs are then reviewed and proposers are encouraged to address any identified issues prior to the Community Call on the following Monday at 17.00UTC. At that meeting any outstanding issues are discussed and a decision on Go/NoGo/Go with contingencies is made. For UMIPs which are approved for GO, the vote begins that Thursday or Friday (alternating) at 00.00UTC. With the Price Identifier ready for implementation by the end of the weekend. An UMIIP takes a minimum of 10 days from submission to on-chain implementation. Deadlines can be seen clearly in our Protocol Calendar.

  1. Create the KPI Options contract

The next step is to create the KPI options contract. We have a basic token generator available for use which will create the contract by point and click. You will be asked to select the collateral, then select the price identifier, then set parameters (expiry, name, symbol, collateralisation and min sponsor tokens). We provide support for the Kovan network if you would like to deploy it to testnet first.

Once the contract is created, there is a form to fill in prior to deployment to give a general heads up to the team, a chance to look over the parameters chosen to catch any errors and an opportunity to be whitelisted for developer mining. The contract can then be deployed to mainnet.

  1. Design the Front End

There is a forkable basic front end available on our github. It is not particularly pretty, but it contains the basic functionality needed to create a user interface for minting. Unlike most of our other synths, KPI options do not require users to create the synths, only the team will do so, so a basic minting interface will suffice for the team to create the synths.

We do not currently have a forkable Dapp for claiming KPI tokens, so some form of claims mechanism or direct airdrop is required. It is probably desirable to have a more attractive front end for redeeming the options at expiry (although EMP tools would still work), but that would not have to be in place until near the expiry date.

  1. Mint and distribute the tokens.

Minting the tokens involves locking the collateral tokens into the smart contract and receiving KPI Options tokens in return. You simply need to decide how many you wish to mint and the maximum amount of protocol tokens that you would like distributed if the KPI is fully met.

We do not currently have a forkable Dapp for claiming KPI tokens, so some form of claims mechanism or direct airdrop is required. If that is something which would cause friction, we may be able to put you in touch with other teams who would be able to help with the distribution through their own claims dapp mechanisms.

7 (Optional) Set up a secondary market

Ideally you want the options in the hands of people who will work to achieve the KPI, setting up a secondary market on an AMM allows recipients to gain immediate value from the token, indicates to the community that the tokens are valuable and allows committed members of your community to maximise their options.

  1. Mobilise your community to achieve your KPI

Clearly communicating the success metric and providing some suggestions for your community on how to achieve it to maximise the value of the options they were airdropped will allow your community to pull together for the identified common goal.