Amirmohammad Pasdar, Zhongli Dong, Young Choon Lee
Original: https://arxiv.org/abs/2106.09349

Why do we need oracles?

Smart contracts and blockchain do not have access to the information outside of their networks (i.e., off-chain data). The blockchain in fact is an enclosed system where interactions are limited to the data available on it. Hence, it is still an open practical problem referred to as the “oracle problem” that is defined as how real-world data can be transferred into/from the blockchain.

Voting- or reputation-based

Voting relies on participants’ stakes for outcome finalization while reputation considers reputation in conjunction with authenticity proof mechanisms for data correctness and integrity.

Data feed services

respond to queries and may consult with different sources (or a single source) to fetch the required information and return it to the smart contracts.

Computation oracles

perform user-defined computation-intensive tasks off-chain, providing computing power to the blockchains

Interface pattern

• request-response when the data space is huge and can be implemented as on-chain smart contracts and initiated on-chain, or off-chain oracles for monitoring, retrieving, and returning data
• publish-subscribe when the data is expected to change, e.g., RSS feeds, and
• immediate read when the data is required for an immediate decision.

Source - online, hardware or human

Oracle sources can be chosen from (a) software oracles where data comes from online sources (e.g., online servers), (b) hardware oracles where data comes from the physical world (e.g., sensors), and © human oracles that are also responsible for verifying the authenticity of information and its translation into smart contracts.

Direction - in or out

Information direction means the way information flows; from/to external resources, e.g., a smart lock is an outbound oracle that once the payment is received at the address, unlocks the lock in the physical world.

Trust model - centralised or decentralised (permissionless)

Centralized oracles are efficient but they can be risky because a single entity provides information, controls the oracles, and a failure makes the contracts less resilient to vulnerabilities and attacks. In contrast, decentralized oracles (i.e., consensus-based oracles) increase the reliability of the information provided to the smart contracts by querying multiple resources. It should be noted that an oracle is considered decentralized if it is permissionless- users can join or leave, and every user has an equal privilege.

Security

Consider integrity, confidentiality, and availability

Oracles are prone to be hacked; their process is vague, they can be bribed, and may not be stable [20]. Also, smart contracts lack direct network access, and the use of transport layer security (TLS) to fetch information while keeping data untampered during transmission is not enough Hence, mechanisms should exist to digitally sign the data for verification, and in this regard, oracles are neither tamper-resistant nor trustless.

Oracles do not mainly hold security properties of native blockchain protocols, however, the correctness of the data can be attested through authenticity proof mechanisms, e.g., software-based [21, 22] or hardware-based approaches [6, 23].

Voting-based

To mitigate the issue in terms of the data correctness, users can form a set of voters and/or certifiers who are involved in the process of data correctness approval that is shown in Figure 3. Each voter and certifier put stakes on responses to verify the data. If the outcomes are matched, rewards are distributed between them, otherwise, they are penalized. It may also inherit the game theory concept Nash Equilibrium (e.g., [25–27]) defined as the determination of the optimal solution in a non-cooperative game in which each player does not have any incentive to alter the initial strategy.

Drawbacks

Lazy equilibrium- a form of verifier’s dilemma- in which voters always return the same answer to questions to secure profits without performing works for correctness.
Sybil attacks: when attackers out-vote honest nodes on the network by creating multiple fake nodes to take over the network. A Sybil attacker can also employ mirroring that makes oracles to post individual responses based on a single data-source query.
Freeloading is another issue and defined as a cheating oracle obtains and copies the response of another oracle without paying per-query fees. This issue threatens the response time of oracles but can be addressed with commit and reveal strategy; sending cryptographic commitments to the responses and in the next round revealing the responses.

Prediction markets

Prediction markets are platforms where financial shares in outcomes or facts are created, shared, and exchanged by participants. These platforms enable users to bet on anything, e.g., political forecasting, and receive compensation or become penalized if they are correct or wrong.

They are resistant to manipulation but also are largely scalable, and can help with the aggregation and distribution of unlimited information. Data in the prediction markets depends on the number of participants to take part in because the more participants, the more data and consequently, the more effective the prediction markets are. Prediction markets can be based on distributed oracles, e.g., the Delphi-based prediction market called Omphalos [31], and markets should have a tradable market price at all times known as the market liquidity.

Prediction markets can also be multi-dimensional markets in which users not only trade on the state probabilities but also the relationship between dimensions.

Stake-based

Astraea [25] is a general-purpose decentralized oracle running on the public ledger that relies on a voting-based game strategy. This framework employs monetary and staking fees which assure the system is immune to Sybil attacks. This oracle has entities that may have one or more roles such as submitters, voters, and certifiers who may freely join or exit the system. Boolean propositions are submitted to the system based upon paying a fee by submitters, and voters play a low-risk/low-reward game by placing a small stake of their confidence on the truth of random propositions. In contrast, certifiers play a high-risk/high-reward game by placing a large stake in the outcome of the selected voting and certification process.

The outcome of voting and certification is the stakeweighted sum of votes or certifies, respectively, and due to the random nature, it is resistant to manipulation. In weighted votes, the weight (and reward) is affected by the level of the deposit made as the higher the deposit, the heavier the weight, and the higher rewards and penalties. If the outcome of voters and certifiers are matched, they are rewarded, otherwise, the players who take the opposite position are penalized. Hence, this oracle encourages players to place bet/vote on the propositions that have such a high level of confidence. The voting and certification deposit should be small or large relative to the total voting stake on the proposition as the former could not control the outcome and the latter could be penalized and could not tamper with the outcome.

Bonding Curves

Bonding curves are a way to dynamically set prices on assets with available in a limited quantity. Bonding curves set prices so each subsequent buyer will have to pay slightly more for it.

A bonding curve is a curve (equation) that connects two variables. For example, token prices change when the token supply changes. This is determined by math, coded in a smart contract. This is not determined by other factors like trading in the secondary market.

They are:
Continuously liquid - can be exchanged (or mint/burnt) at any time
Hard coded - according to a pre-set formula
Executed from smart contracts - giving them immutability, trust and predictability

For it to not be a Ponzi scheme, the tokens should allow users to claim on future cash-flow by the ecosystem. This could be earning via transaction fees or earning via future profits from the ecosystem.

Uses

Trading, fund-raising, curation markets

Trading

The most common use of bonding curves is with AMM (automated market makers) which is the main function of DEXs (decentralised exchanges).

An AMM is an alternative to a stock exchange, in that it provides a real-time vehicle for exchanging assets. Stock exchanges use an order book model, involving a separate class of “market makers” who continually adjust their buy/sell offers while watching the market bids. In AMMs this is replaced by a store of actual assets ready to be exchanged (called a “liquidity pool”) and the exchange rate between the two assets is set using a bonding curve formula.

See: https://finematics.com/bancor-v2-explained/

Value comes from the ease of liquidity, availability of liquidity and network of other tokens to interact and trade with.

Fund-raising

Value comes from the entitlement to future cash flow. Other than value increasing from more participants joining the ecosystem, the value can also increase from revenue generated from the ecosystem.

Price setting:

-Raising funds using a buy and sell function (e.g. Aragon fundraising function)
-Determining price in a closed economy (e.g. Nexus Mutual $NXM pricing)
-Curation market using tokens as a signal

Curation Markets

“Each topic/meme/idea/goal has an associated token of value that is used to curate information inside it.” - Simon de la Rouviere

With curation markets, tokens get allocated (or staked) on topics, which creates a collective signal. For example, if reddit upvotes required staking a token, or adding a restaurant to Tripadvisor required staking tokens which could be slashed if it wasn’t real. The value of the token creates a stronger incentive than a free expression, so can be designed to curate sets.

Value comes from the entitlement to future cash flow or accurately signal market sentiments.

Formulae

Play with the various functions and parameters: http://bit.ly/bondingcurve

Linear - favours early buyers too much
Exponential - encourages early holders at the cost of volatility later
Logarithmic - high volatility early but stability later
3D curves - adding a z-axis for “productivity level, technology adoption curve, users in the system, active users as a fraction of total users, etc.”

Augmented bonding curves - combines the general bonding curve with a funding pool, lock-up mechanism and inter-system feedback loops. Used to manage speculation and to align incentives to generate returns.

Dynamic bonding curves - prices of tokens are determined by the proportion of token owned. Used to incentivise early adopters, punish freeloaders and encourage active participation in the ecosystem.

Factors to consider

❏Incentivise early adopters
❏Price stabilisation at the end
❏Cost appreciation based on some factor of supply increasing (or productivity of platform or token)
❏Prevention of abuse or arbitrage
❏Growth of underlying product (s-curve, as a function z-axis)
❏Returns appropriately attractive across reasonable range or to focus more on early adopters

Practical Questions to get Started
❏What function is the bonding curve used for? Decentralised exchange (instant liquidity), fundraising, curation market or something else?
❏How many users can the project attract and sustain? (At the introduction stage, at the maturity state)
❏Are both early and late adopters adequately incentivised to participate? Do you want them to be equally incentivised?
❏Can I attract the amount of capital needed to take the project to an adequate level of adoption?

Token Design

Mechanism design focuses on the rules of the system. Rules and functions can be coded into the token itself, and the token usually serves as a focal point and incentive.

To work well, tokens need to:
●Define the token policy.
●Reward with financial incentives to encourage specific behaviours outlined in Mechanism Design.
●Design proper architecture of the token bearing in mind various aspects of the tokens including property rights, identity, payoffs.
●Mathematical proofs or models for necessary valuation, supply, etc.

Financial incentives

Platform activities
a.Transaction fees
b.Rewards for joining the network
c.Discount tokens (discussed in Chapter 14)
d.Referral links
e.Reward policies beyond mining
 
Returns on investment
a.Expected returns to tokens owned: via staking or changes in value of underlying asset
b.Arbitrage on exchange rates of token prices
c.Price level volatility of the tokens
d.Liquidity mechanisms: exchanges, liquidity function
e.Riskiness of token
Directing inflation to reward behaviour - eg. emissions towards users or stakers.
This becomes an interesting play between tokens locked up in stake and inflation rate of the ecosystem.

Instead of staking as a collateral, decentralised liquidity provider or as part of governance, Token Curated Registries (TCR) uses staking as a signal to rank preferences. Users are then rewarded for their participation via native tokens.

As financial securities:

the tokens could be an alternative to traditional financial assets and there is an opportunity cost to holding them.
In DeFi, this “returns to stake” mechanism is paired with a governance utility function to add to the value accrual of the native token. As a result, it mixes two asset classes in traditional finance: equities and fixed income.

Architecture

Currencies are a form of money with 3 main functions: a unit of account, medium of exchange and store of value.
 
Added advantages that digital currencies has over physical currencies include, but are not limited to:
 
Instantaneous transactions
Automatic update of accounting ledger
Cross-border transfer of ownership

Property rights
a.Economics of property rights: claim rights, ownership rights, rights to participate in governance decision making process
b.Harberger taxation
c.Representation of an identity and the rights of the identity (i.e. person, art, digital representation of something in physical form)
 
Distribution
a.Allocation and lock-up of tokens in various time periods
b.Conviction staked inflation funding: distribution of newly minted tokens as a function of number of tokens staked and duration of staking period

Token economics

Monetary policy
a.Supply of tokens, expected growth of money supply
b.Inflationary, dis-inflationary or deflationary tokens
c.Distribution of token allocation
d.Velocity: how often tokens change hands (if necessary)
e.Exchange rate regime: fixed-exchange (pegged), intermediate-exchange, floating-exchange
f.Zero-lower bound (ZLB) or effective-lower bound (ELB) for tokens with a monetary function
g.Negative interest rates or currency with an expiry date for specific type of token objective function
h.Reserve ratio or leverage given on collaterals

Token valuation: variables that can allow tokens to have endogenous value
a.Endogenous factors
Backed by off-chain assets: fiat currency, gold assets, even the possibility of government bonds
Bonding curve (discussed further in Chapter 11:
Net present value
Expected value of funds
Dynamic price equilibrium
Demand growth of platform or demand of tokens
Savings function: Savings function depends on the (1) Growth rate of tokens
 
 (1) Growth rate of tokens
a.[Automated] Fixed token inflation increases tokens every specific time period
b.[Not automated] Token inflation with respect to tokens staked or locked-up
(2) Expectations of future price level (or utility) of tokens
c.E.g. holding the token longer increases the ranking of the token compared to newly minted tokens. This could result in shorter withdrawal times when the token is used to stake
d.E.g. the exchange rate of native tokens increases over time due to growth of the ecosystem, which means that the token-dominated price of products decreases. There is an incentive to save the native token, since the expected future prices of products is lower
Heterogeneity of user base: different risk appetites resulting in different demands of the token at different times, to smooth out the demand of tokens
Platform productivity: expectation of platform’s growth demand, efficiency at coordinating participants and achieving objectives
 
 
b.Market to dictate
Dutch auction: Dutch auction works in a similar way as Vickrey-Clarke-Groves auction, where this method generates the greatest social welfare. This works for similar goods and goods are priced by the market. E.g. government bonds or the launch of a new token.
Exchange rate of tokens to dollars reflects buyers’ willingness to buy in both a centralised order book way and a decentralised market maker method.
Scarcity of tokens affecting pricing choices cause buyer competition that reveals consumer values
Rational expectations of exchange rate in the next period
Value to users: the ecosystem or network effects that add value to users
Automated market maker using each token pool to dictate market prices, facilitated by arbitrage traders to achieve price equilibrium in various exchanges

Maker DAO Case Study

DAI is a stable-coin, loosely pegged to the USD.

DAI is a lending protocol, which lends DAI based on an over-collatoralised loan. (eg you stake $1000 of ETH, and you can mint $500 in DAI) You can stake a small range of coins as collateral: LINK, BAT, USDC…

MKR is the governance token for Maker DAO.

2 token system, to separate supply/demand pressure on governance token from the stablecoin.

Uses of DAI:

●Lending protocols like Aave, Compound, Celsius. They use $DAI as $DAI has less volatility in pricing and allows for more stable lending and borrowing.
●Decentralised exchanges like Uniswap, Curve, Balancer. $DAI is a common token pegged to USD, which allows for easy trade and demand.
●Derivative platforms like Chai use MakerDAO’s $DAI Saving Rates (DSR) to represent a claim on deposit in the DSR. And Opyn to long or short $DAI.

Users of MKR:

MKR holders have a say in the levers that keep DAI pegged. They can influence what types of collateral are accepted, and how to adjust the dials that keep DAI trading near $1.

Decision Making Protocol

Linked to the resolution mechanism, $MKR holders can reach consensus on an active proposal. The proposal is then empowered by a smart contract to modify internal variables on the platform.

MKR holders can make decisions on issues such as:
●Trigger an emergency shutdown
●Add new CDP type
●Modify existing CDP type
●Modify $DAI saving rate
●Choose a set of price oracles
●Choose a set of emergency oracles

The following risk parameters are governed by $MKR holders:
●Debt ceiling
●Liquidity ratio
●Savings rate
●Liquidation penalty
●Auction duration
●Auction step size

Resolution mechanisms

Safety mechanisms
There’s are automated safety mechanisms, one if CDP fails, and another emergency shutdown triggered by vote or oracle.

DAI savings rate adjustments
Prices deviate in the short run. To deal with this, the $DAI savings rate changes to reduce price instability. The $DAI savings rate is a global system parameter that affects how much $DAI holders can earn in return on their holding over time, and base borrowing costs for generating $DAI from CDPs.

Proposal Contracts
$MKR token holders will cast votes to elect a proposal as active. Proposals are executed once they have gained approval by $MKR voters. The changes are applied immediately to the internal governance variables, then the proposal contract wipes logic and is not re-used. Modifications are delayed for 24h until the proposal contract takes effect. This is to protect the platform against malicious governance proposals that harm the system.

Non-financial incentives

Voting protocol

1 .Time-limited poll - soft-check consensus
2. Continuous approval voting - on-chain, changes variables:

The policy of staked votes continuously challenges and reinforces the status quo of the system. Proposals are compared to the majority vote between the new desired proposal and the most recent successful proposal. Old proposals are deleted and wiped away, so changes to old successful proposals need to be submitted with changes. The system is continuously active, which requires continuous governance. New proposals can be submitted at any time by any $MKR token holder.

Allocation mechanism

Users mint DAI by depositing assets as collateral.

Maker’s fee comes from when users close that position, burning their DAI to get their collateral back. They call this their stability fee.

This is part of how the peg is maintained.

This risk parameter is used to manage supply and demand for $DAI during negative growth periods. When the demand for $DAI decreases, the savings rate associated with minting new $DAI increases. More users will want to repay the CDP (debt) and $DAI is burned. This reduces the $DAI available and increases the prices of $DAI. When the fees increase, it is also more expensive to create new $DAI, which increases the prices of $DAI once again.
 
The fee is calculated on a continuous basis using a continuous compound formula: . The collected fees are then burned.

Bargaining protocol

There are two types of auctions in MakerDAO when undergoing an emergency shutdown and liquidation:
●Debt auction: when CDP becomes under-collateralised, a reverse auction is created to sell $MKR for $DAI.
●Collateral auction: collateral from CDP is sold through an auction during liquidation. This is to ensure that the debt owned by the CDP is covered and to give the CDP owner the best price for their excess collateral refund.

The liquidation protocol used to function like so:

1. Defaulted CDP is closed by a Keeper. CDP assets are sent to a smart contract (LPC) and the CDP assets are for sale.
2. Liquidation penalty AND stability fee are applied to the $DAI-dominated loan.
3. LPC removes PETH collateral to satisfy the outstanding debt.
4. CDP owners can remove their remaining collateral. They receive the value of the leftover collateral minus debt, stability fee and liquidation fee.
5. The seized PETH is for sale.
6. The $DAI earned from PETH sale is burned and removed from the supply.
7. If there is insufficient $DAI from the sale, PETH is drawn from the pool and offered for sale. But this negatively impacts the ETH:PETH ratio.

Since it’s now multi-collateral, the CDP assets are auctioned off:

MakerDAO will buy collateral of a CDP and sell it in an automatic auction. The auction will determine the price of the CDP by market forces, since prices are unknown. The system will raise enough $DAI to cover the CDP debt. This is done by diluting the supply of $MKR tokens and sell it to bidders in an auction format.
 
Collateral of the CDP is sold, where proceeds up to the CDP debt amount plus liquidation penalty will be used to buy $MKR and remove it from the supply. This counteracts the $MKR dilution in the previous stage.
 
When enough $DAI is raised via the auction to cover the CDP debt and penalty, the auction switches to reverse auction to sell as little collateral as possible. Leftover collaterals will be returned to the original owners.

Community info

A set of trusted price oracles are chosen by $MKR voters. These provide real-time information about the prices of collateral assets.
 
Maker’s oracle uses two feeds, Light Feed and Dark Feed50. Light Feed comes from raw data from DeFi protocols. Dark Feed are anonymous individuals. The goal is to have a 1:1 ratio. Any protocol can apply to be a Light Feed to provide information to the Maker system. The governance then provides Data Models and tooling to calculate prices of digital assets.

Oracle governance:

An oracle governance framework is a proposal to define the rights and responsibilities of the governance mechanism. It includes:
●Defining criteria for selecting new feeds
●Defining criteria for selecting new oracles
●Adding and removing feeds
●Adding and removing oracles
●Identifying performance metrics for feeds and oracles
●Selecting the oracle price sensitivity parameters
●Selecting the Oracle Security Module (OSM) delay parameter

Maker DAO Case Study

DAI is a stable-coin, loosely pegged to the USD.

DAI is a lending protocol, which lends DAI based on an over-collatoralised loan. (eg you stake $1000 of ETH, and you can mint $500 in DAI) You can stake a small range of coins as collateral: LINK, BAT, USDC…

MKR is the governance token for Maker DAO.

2 token system, to separate supply/demand pressure on governance token from the stablecoin.

Uses of DAI:

●Lending protocols like Aave, Compound, Celsius. They use $DAI as $DAI has less volatility in pricing and allows for more stable lending and borrowing.
●Decentralised exchanges like Uniswap, Curve, Balancer. $DAI is a common token pegged to USD, which allows for easy trade and demand.
●Derivative platforms like Chai use MakerDAO’s $DAI Saving Rates (DSR) to represent a claim on deposit in the DSR. And Opyn to long or short $DAI.

Users of MKR:

MKR holders have a say in the levers that keep DAI pegged. They can influence what types of collateral are accepted, and how to adjust the dials that keep DAI trading near $1.

Decision Making Protocol

Linked to the resolution mechanism, $MKR holders can reach consensus on an active proposal. The proposal is then empowered by a smart contract to modify internal variables on the platform.

MKR holders can make decisions on issues such as:
●Trigger an emergency shutdown
●Add new CDP type
●Modify existing CDP type
●Modify $DAI saving rate
●Choose a set of price oracles
●Choose a set of emergency oracles

The following risk parameters are governed by $MKR holders:
●Debt ceiling
●Liquidity ratio
●Savings rate
●Liquidation penalty
●Auction duration
●Auction step size

Resolution mechanisms

Safety mechanisms
There’s are automated safety mechanisms, one if CDP fails, and another emergency shutdown triggered by vote or oracle.

DAI savings rate adjustments
Prices deviate in the short run. To deal with this, the $DAI savings rate changes to reduce price instability. The $DAI savings rate is a global system parameter that affects how much $DAI holders can earn in return on their holding over time, and base borrowing costs for generating $DAI from CDPs.

Proposal Contracts
$MKR token holders will cast votes to elect a proposal as active. Proposals are executed once they have gained approval by $MKR voters. The changes are applied immediately to the internal governance variables, then the proposal contract wipes logic and is not re-used. Modifications are delayed for 24h until the proposal contract takes effect. This is to protect the platform against malicious governance proposals that harm the system.

Non-financial incentives

Voting protocol

1 .Time-limited poll - soft-check consensus
2. Continuous approval voting - on-chain, changes variables:

The policy of staked votes continuously challenges and reinforces the status quo of the system. Proposals are compared to the majority vote between the new desired proposal and the most recent successful proposal. Old proposals are deleted and wiped away, so changes to old successful proposals need to be submitted with changes. The system is continuously active, which requires continuous governance. New proposals can be submitted at any time by any $MKR token holder.

Allocation mechanism

https://edennetwork.io/EDEN_Network___Whitepaper___2021_07.pdf

Network Objectives

1. Protect users from malicious MEV (frontrunning, sandwich attacks, etc.) and reduce the negative externalities MEV has on Ethereum
2. Improve earnings for block producers and increase consensus-level security against block reorganization
3. Tokenize access to MEV, and redistribute value to network stakeholders

How? Per EIP-1559:

Block producers are also allowed to accept transaction bundles. Bundles are be included after any priority queue transactions, but before transactions from regular Ethereum/Eden users.

Miners that participate in the Eden network and receive rewards for prioritising Eden transactions above all other transactions.

There are a set number (3) of “slots”, each with a unique index (i.e. slot 0, slot 1, etc.) that indicates their position within blocks
i. At any time, each slot is owned by exactly one account (the “slot tenant”), who has the right to set a “delegate address” for that slot.
ii. Transactions to (Ethereum transaction field to) the delegate address will be included in the slot
iii. The delegate address may be either an EOA (a regular account) or a smart contract
address
iv. Transactions submitted directly to the Eden Network relay that revert (fail) have the option of not being included in the block, saving the sender gas fees

Users reserve these slots via a continuous auction mechanism known as a Harberger tax
i. Slot tenants are taxed on a linear basis at some tax rate (3.3%
) per day on the initial principal of their stake. The taxed amount is burned, and the tenant loses their claim on the slot once their entire balance is depleted (301 days as per proposed tax rate)
ii. Any user may become a slot tenant by staking a minimum of 110%1
the EDEN staked by the existing slot tenant at the time the existing slot tenant bid for their slot
iii. In the event that another user outbids the current slot tenant, the original slot tenant is immediately eligible to claim any untaxed balance they have in the smart contract (or increase their stake to reclaim the slot). Being outbid is the only mechanism to recover an untaxed balance
iv. Once a slot tenant is outbid, they simply lose the slot instead of being pushed to the following slot

Block Producer Reward Procedure
For a given block producer that participated in Eden Network honestly over the course of an epoch, that block producer is “owed” some EDEN reward according to the emission schedule in proportion to their contribution to all produced Eden blocks. The exact calculation of owed balances is performed in a decentralized manner by a subgraph on The Graph.
To remit payments, an admin address generates a Merkle tree of these balances and posts the root of the tree to a distributor contract. Each new distribution mints a non-transferable ERC-721 NFT owned by the distributor contract whose metadata is an IPFS URI to the full set of Merkle proofs. Any block producer (or their delegated claimer account) can present the Merkle proof for their address to the distributor to claim their rewards.

Inflation/deflation mechanisms

Since the Harberger tax implementation creates perpetual deflationary pressure on the circulating supply of EDEN, and the network mints new tokens at an exponentially decreasing rate, we can counteract the implied scarcity through a net emissions mechanism. In a future release of the
protocol, the network will mint additional tokens equal to the minimum tokens burnt in a given day or 66,000 tokens as part of a net issuance mechanism.
Monthly inflation is distributed as follows:

1. Block producers: 60%
2. Liquidity Providers: 30%
3. EDEN Treasury: 10%

Hello @pitaj - were you having any trouble with the forum?

@Sertac said in Economics and Math of Token Engineering and Defi [Lisa Tan]:

I was super sad not-to-have participated in these events, this is a huge public service, thank you very much @saintsal

Async rocks! Would be a big benefit to everyone if you shared your notes and key excerpts from all the readings you’ve done too.

We all bring our own experience to notes, even if we just highlight and pick out key paragraphs. So just sharing them on a forum like this can help all ships rise. :)

@jmah said in Economics and Math of Token Engineering and Defi [Lisa Tan]:

But typical insurance has actuary tables and forecasting. It sounded like the risk assessors just approved the claims if it met the criteria.

I understood that its more qualitative than the quantitative actuarial approach. A peer to peer marketplace that matches non-technical investors with technical assessors willing to stake their own funds that the contract they reviewed in sound.

Mechanism Design

●Aligning various objectives of different types of participants through incentives
●Revealing private information
●Affecting behaviours of users

Market design is akin to web2 marketplace engineering, dealing with the parameters of the market so that actors are able to find counter-parties and interact with them safely and proactively.

Mechanism design puts rules in place and figures out how the rules and game form can achieve the objectives of the ecosystem. This relies more on game theory and encoding rules.

Those rules can be encoded in on-chain code, or enforced off-chain.

Mechanism design seeks to understand which mechanisms are best for which type of participant.

There are many types of participants in an ecosystem, with different objectives and incentive mechanisms. We want to align them with rules or incentives, so that no one benefits at the expense of the other (e.g. Amy does not gain extra by Bobby losing something).

How? Provide a framework to analyse the ecosystem, market or institutions. It seeks to understand the problems associated with incentives and private information (assumptions, expectations).

In this way, we can consider that all games are just rules. So what are the rules we’ll set and how will they be enforced?

Simple games in complex systems

The foundational principles stem from microeconomics mechanisms, which seek to understand why people behave the way they do. Complexity theory seeks to understand how decentralised systems work in nature.

Steps

1. Define the problem to be solved
2. Determine the social goal
3. Understand the constraints

Social choice functions

in an ecosystem, we want to make a collective decision to achieve a social goal that is good for everyone (social choice). We can analyse how good our decision or mechanism design is, with the social choice function.

• Pareto efficiency - can gains in one persons’s position not come from losses of another?
• Strategy-proof mechanisms - In an asymmetric game where players have private information, given no information about what the others do, you fare best or at least not worse by being truthful.
• Fairness
• Social welfare (see Bergson-Samuelson social welfare function ) which allows trade-offs between efficiency and equality

Collusion is inefficient from a systems perspective, so needs to be designed against.

Rules for governance, incentives, structure

How are decisions made? (What is the consensus protocol? What is the voting protocol?)
How are disputes resolved?
How are resources allocated?
How to participants bargain and transact with each other?
How does the community connect to off-chain information?

In the context of token ecosystems, mechanism design needs to:

1. Provide adequate governance – In the decentralised ecosystem, governance becomes of utmost importance to govern actions of participants in the ecosystem.
2. Include non-financial incentives – Financial incentives are discussed in the next pillar, token design. Other incentives need to be considered to account for preferences and asymmetric information.
3. Design structure of the mechanism – The mechanism is best to be Pareto efficient to protect the ecosystem, considering the main objective of the token ecosystem.

Governance

Governance can help to facilitate the transactions and activities within the ecosystem, making it safe for participation and preventing congestion when issues arise.

Governance is constraining, so useful to think about related to concerns like: centralisation, inflexible smart contracts, consensus protocols and regulation.

Non-financial incentives

Aligning the external and non-financial incentives can reduce information asymmetry or strengthen your mechanisms.

Reputation is also a noteworthy variable to reduce information asymmetry, incentivise participants to report their true information, and so reduce the hidden information (moral hazards) when transacting within the ecosystem.

Typical bad behaviours include vote buying, plutocracy, last-minute vote swings, participants simply not caring enough to cast their votes.

Non-financial incentives are very useful for minimising exposure to unknown unknowns:

Most ecosystems are continuous and dynamic. Hence, some situations are difficult to foresee or describe in advance. And even if they are, it can be a challenge to incorporate them into the design of the mechanism.

So it’s useful to think of how non-financial incentives can be used a catch-all to repel unforeseeable forms of bad behaviour.

Example - maintaining superhost status on AirBnB.

Instead of a steady state where mechanisms can be fixed, or statistical mathematics can be applied to analyse equilibriums, we have to look at how decentralised participants will adapt to the dynamic ecosystem by observing previous actions and possible future outcomes.

Structure

The structure of the mechanism helps us to design how the various pieces of information relate to one another in the ecosystem.

Two layers:

1. Immutable processes - written in code with fixed formats for input/output (typically resolution protocols) Consider: schelling points

2. Mutable processes - where the participants have a voice in changing the processes (typically decision-making protocols) Consider: staking systems, honesty motivators

DAO-related Economic factors

Economics of trust: we want to be able to trust the parties we are interacting with. This is done through smart contracts and skin in the game. Example: PieDAO
Economics of coordination: decision making with a small group of shareholders is tough. Decision making with a decentralised group is even harder. DAO helps with this coordination. Example: MolochDAO, MakerDao
Economics of allocation: like how the government collects tax revenue and decides where to allocate it, the DAO also gets to decide on the governance structure of the ecosystem. Example: KyberDAO, Dash, LAO

Voting protocols

Traditional voting: each person can vote based on the number of tokens they have, although this can lead to plutocracy and other attacks. (Example: governance tokens.)
Commit-reveal: Imagine you shout out your choice to everyone in the network. Then you reveal that choice, and everyone can verify if it is what you committed to. (Example: Ethereum smart contract.)
Quadratic voting: Instead of 1 person 1 vote, you can now place as many votes as you want on the issue. It shows the intensity of your preference. The cost of the votes are related to the number of votes you cast. It squares for every additional vote casted. The cost of influence is in the units of votes. (Example: Gitcoin grant.)
Quorum voting: minimum number of people to validate the vote. (Example: Balancer using Snapshot in its governance process by having enough votes staked on a proposal before it gets promoted to be voted upon in the governance vote.)
Delegated voting: users delegate votes to others, who can represent better democracy. (Example: Tezos.)
Partial-lock commit-reveal voting: token-weighted voting. Voters can participate in multiple polls simultaneously and tokens are not staked. (Example: Token Curated Registries.)
Politeia voting: tracking proposals to vote on. (Example: Dcred, Politeia.)
Conviction voting: continuous voting process where voters continuously stake their votes for a time period till the minimum threshold is passed to approve the proposal. (Example: Giveth.)

Allocation mechanisms

Reputation: to mitigate the moral hazard problems when transacting
Egalitarian: each participant in the ecosystem enjoys the returns in terms of transaction fee, be it online or offline nodes. (Example: Algorand.)

Bargaining protocols

Auction mechanisms: multi-attribute auctions, payment mechanisms, pace of auctions as solutions to congestion and safety issues.
Second highest price: The highest bidder will get the item. But instead of paying the price he/she bid, he/she will pay the second highest price instead. (Example: ENS domain.)
Fixed price: Price set by the system/project creator. Take it or leave it. (Example: prices of tokens on crypto exchanges.)
Vickrey-Clarke-Groves auction44: The person whose bid maximises the total social good of the network is chosen. (Example: Celer Network.)
Second highest price: The highest bidder will get the item. But instead of paying the price he/she bid, he/she will pay the second highest price instead. (Example: ENS domain.)
Reverse Dutch auction: Price drops as time goes. (Example: Gnosis, Algorand.)
All-pay: Everyone who participates has to pay. (Example: Augur.)
Dynamic pricing: Price set by the smart contract, depending on the liquidity of the pool. (Example: Automated market markets like Uniswap and Bancor.)

Community info

Software oracles: handle information available online. (Example: Chainlink)
Hardware oracles: Information available offline, via a client (i.e. RFID sensors, IoT devices). (Examples: VeChain, Weeve.)
Consensus-based oracles: Individuals provide input to the oracle system to inform/update the smart contract. (Examples: Augur, SchellingCoin, Witnet.)

Case Study - Nexus Mutual

Decentralised insurance

$NXM is used for staking in the system in terms of buying insurance cover, participating in work to be done, or voting in the governance capacity.

Becoming a member requires KYC, which allows you to insure an asset for fixed period. Wrapped NXM is available to skip KYC.

Example:

Now for example let’s say insurance coverage price is 0.5 ETH and I want to cover 300,000 ETH. That is the amount I am adding on Aave.
 
That 0.5 ETH goes into Nexus Mutual, which is a big pot of funds. Part of the funds will be used to reward the risk and claim assessors.

Token pricing

The $NXM token price is determined by two main things – total $ETH in the capital pool and minimum capital requirement (MCR). This is determined via a bonding curve function.

Nexus Mutual includes three types of participants:
1)Insurance Cover Buyers: People who have paid for membership and can purchase insurance cover with $NXM.
2)Risk Assessors: Check the code, and general information on a project. They verify that the smart contract is well coded without any bugs.
3)Claims Assessors: Vote to accept or reject claims to pay the buyers, if something happens.

Risk assessors

1. They do a technical dive in Aave. They check the smart contract code for bugs. The code is secure and has no bugs.
2. Risk assessors put $NXM that they own in the Aave insurance coverage fund.
3. This fund is then used to provide the insurance coverage, if anyone wants insurance for their Aave transactions.

They stake $NXM because they can profit from their expert knowledge.

Assessors

Use typical oracle mechanisms aka Bayesian Incentive Compatibility (BIC)

Claim Assessors have to stake $NXM to assess claims. They stake $NXM with their vote, either yes or no to the claim. Since there is no objective “right” answer, the answer is determined by the majority claim assessors’ votes.

Market Design

market design defines the environment in which users and tokens co-exist so that markets can operate and be governed efficiently. We talked about network effects before, pointing out that market design is a prerequisite to achieve network effects. Successful market design (aka good ecosystem environment) will encourage more users to participate and increase the value of the ecosystem.

Congestion

Rate-limited on assessors to avoid spray-and-praying.

If I’m assessing the claim for Aave’s protocol, I can’t assess another protocol’s claim for 12 hours. This is quite important because you don’t want people to be assessing claims for a lot of different protocols at once and then they keep saying yes to everyone and they try to exploit the system, so there’s a 12-hour break between finishing the assessment of one contract and starting assessment of the next smart contract.

Safety

you can only purchase insurance cover when there are enough risk assessors staking their tokens to signal that the protocol is safe.

a different set of users, claim assessors, are deployed to determine the validity of the claim to award a pay-out. A minimum vote (70%) is required before the voting passes.

Token price

The price of $NXM is defined by the math in the bonding curve. This reduces speculation.
 
Not only so, the bonding curve embeds two main factors in the curve, the long term and short-term variables. Investors can view $NXM prices as a proxy to evaluate the short-term and long-term forecasts. This is done via the Total Capital and MCR variables.

Bonding curves: https://thegraph.academy/curators/introduction-to-bonding-curves/

KYC

KYC is a safety mechanism since it reduces regulatory risk, thus increasing participant confidence in their transactions

Get the book: https://book.economicsdesign.com/

I’ll start with some notes and excerpts from the first 8 chapters.

The framework:

General categories of token function:

1. If your token function is a currency to facilitate transactions within the ecosystem you can look into traditional monetary economics to understand the considerations and policy implementations for your token. A good place to start would be “monetary policy instruments” relating to how money is governed.
2. If your token is a currency that is very vulnerable to external forces (e.g. stable coin and the exchange rates between token and another currency like USD) you should look at the types of monetary policy that central banks use to govern their currency.
3. If your token represents a claim to certain assets on or off the chain, you can look into bonding curves that define token prices as a function of token supply. This requires a few concepts in monetary economics like reserve ratio and considers the impact of inflation. 4) If your token is a utility to access the network, the monetary policy here will really depend on the use-case and purpose. For example, if it works like airline miles, there isn’t much monetary policy to consider, probably just deflationary measures occasionally. So, it really depends.

Coordination

Firms exist because this arrangement makes it easier and cheaper to coordinate with buyers and sellers, compared to free markets. In free markets you have to:

• Discover what the market prices are
• Negotiate contract for each & every transaction
• Figure out of the seller or buyer is trustworthy if you trade at a later date

What makes a good ecosystem? More coordination. Because more coordination means more efficiency.

incentives vs governance

Free markets work when incentives are all aligned with the different participants (people and firms). Governance and regulations come in when incentives are not aligned and regulations exist to help realign them. This is because participants can find it challenging to coordinate amongst themselves. It can also get very costly in terms of time spent and opportunity cost.

Cooperation

There are 2 types of incentive compatibility.

1. Participants being truthful is the best response, irrespective of what other participants say or do. We call this Dominant Strategy Incentive Compatibility (DSIC).

aka truth produces the best option for you

2. Participants being truthful is the best response, given their expectation of other participants’ choices. We call this Bayesian Incentive Compatibility (BIC)

aka truth produces the best option for you, as long as everyone else is also truthful

https://handwiki.org/wiki/Incentive_compatibility

MolochDAO’s rageQuit - making it easy for people who don’t want to cooperate to leave, leaves only people willing to cooperate

Externalities

People behave based on their self-interest. It is important to understand why people do what they do. They do what they do because it is in their self-interest that the cost be borne by someone else1.
For example, upper management has a secure position and cannot be readily removed. They do not have to worry about job security and can focus on growing the business in the long run. But this incentive could create an externality, where they are shielded from the consequences of poor decision making and are not fired as a result of such decision making. For example, they focus on short-term profits at the expense of long-term losses. The losses will be borne by future management team, for they have long retired.
The solution is to align the interests of agents (upper management) and the principal (the company) so one does not win at the cost of the other.

Moral hazard occurs when someone increases their exposure to risk when insured, especially when a person takes more risks because someone else bears the cost of those risks.

Adverse selection is a result of ineffective price signalsthrough asymmetric information(one party having more information or different information compared to the other). eg. sellers have more information about the situation.

Outcomes and contraints

Defining the main objective of the token ecosystem is one of the most important factors in the design process. The objective determines the mechanisms in place, the governance structure, the policies, the protocols and everything in between. Without the objective1, the incentives and punishments do not mean anything because they do not affect the behaviour of participants in the token ecosystem in a useful way.
The objective is something the ecosystem is working towards. That means all the incentive mechanisms in place exist to achieve the objective.

7 Wonders

• network effects
• signalling
  • Be innovative so that big publications pick up on your project. These are signals to the public that your company is so innovative that these big publishers are interested to report on them. That’s how you can win the trust of the public.
  • Pay money for your project/article to be published on Forbes, Techcrunch, Mashable, etc.
  • Whitepapers that are peer-reviewed by academics.
  • Frequently updated Github.
  • Having a wide variety of experts with domain knowledge in your team (computer scientists, entrepreneurs, economists, academics).
  • An active community of real and non-bot users on social platforms like Twitter, Telegram, Discord.
  • (If MVP4is out) Total value locked in the protocol and ratio to the price of token.
  • In addition to whitepapers, publish token economics papers, technical papers, yellow papers
• Monetary policy
  • eg ampleforth
• Property rights
• Lock in
• Principal-agent theory
  • Your behaviour changes depending on whether the utility bills are included in the rent or excluded from the rent. When they are part of rent, you think less about your usage. When they are excluded from rent and you have to pay for the amount that you use, you are more likely to be conscious about your usage.
  • aka charge for time vs results?
• Schelling points

Market design

• Solving problems in existing marketplaces through incentives
• Making individual strategic decisions through interactions (behaviours)
• Organising and understanding markets through rules
• Considering behavioural economics in the interactions of users (behaviours)

Instead of observing how markets behave, we can design how markets should behave.

Design for:

• thickness (available liquidity)
• throughput / congestion
• safety

https://docs.keep3r.network/

Registering a Job via Governance
If you prefer, you can register as a job by simply submitting a proposal via Governance, to include the contract as a job. If governance approves, no further steps are required.
Registering a Job via Contract Interface
You can register as a job by calling addLiquidityToJob(address,uint) on the Keep3r contract. You must not have any current active jobs associated with this account. Calling addLiquidityToJob(address,uint) will create a pending Governance vote for the job specified by address in the function arguments. You are limited to submit a new job request via this address every 14 days.

https://docs.cow.fi/overview/coincidence-of-wants

Coincidence Of Wants (what makes bartering work) is being used here to create a peer-to-peer settlement layer using a batch auction mechanism. This avoids MEV (loss to arbitrage/sniping) in AMMs because it uses signed messages for orders instead of an on-chain transaction, but then settles on-chain in batches.

It uses signatures to keep the off-chain messages trustable, and link them back to on-chain settlement. It’s an application of an interdependence architecture and is maybe an interesting mechanic for multiple, simultaneous use too.

There’s also a fun play on decentralisation here. Ethereum is architecturally and politically decentralised (assuming enough distribution in mining power) but not logically decentralised since it is the single source of truth.

This logical centralisation leaves a weakness: the lag in the consensus mechanism. Sniping on AMMs takes advantage of this centralisation weakness. CoWSwap decentralises that, creating an off-chain consensus layer in each auction batch. It feels like it’s moving in the direction of BitTorrent or ScuttleBot to me.

https://integral.link/

Delays a transaction for a fixed time, then executing based on a time-weighted average of the prices over that delay.

From their docs:

This is what happens when we deal with most traders: a few come in for some LINK soup and take out some ETH soup; and the next few do the opposite. Yes, of course, sometimes you have more LINK soup and sometimes more ETH soup, but these are all fair conversions. This is called “Cyclical Imbalance”. Oh don’t forget, you get to charge a fee for providing this conversion service.

The problem here is with toxic traders: they steal soup from you, period. And as more and more of them come through, you have less and less soup. They do that by “front-running”. The key pillar of “front-running” is that they know what you don’t 100 milliseconds ahead of time. It’s almost entirely about a time advantage. So our counter-move also has to do with time: anyone who wants to buy soup, place your order now, but you must WAIT 5 minutes before you get your soup. They lose their time advantage, they lose their edge, and our soup pot is safe again. This is why we have a 5-min TWAP.

Gitcoin Quadratic Lands

A few practical next steps

(both are waiting on Polygon approvals due to various dependencies)

This is a generalised scoring rubric for grants, which creates evaluation and operational consistency, and makes it easier and faster to give actionable feedback on unaccepted applications. It should be appended with more specific criteria for each stream.

Eligibility

Binary score. If any are not true, the application is considered ineligible.

Evaluation

Each of the 3 categories is rated 0-3, giving a total score of 0-9.

Concept - is it viable and aligned with the funding goals?

• Greatly progresses the Polygon ecosystem
• Takes advantage of unique Polygon characteristics, and/or creates unique advantages for Polygon users

Outcomes - Will it achieve impact?

• Attracts engaged Polygon users
• Realistic plans to validate the effectiveness of the outcomes

Capability - can they do it?

• Core team has adequate experience (and advisors) to see the funded project to completion
• All core competencies required to achieve the milestones are executed by the core team. (No core competancy is outsourced.)
• The action plan is reasonable, and the amount requested is congruent to the work necessary and team skill

Scoring

For each of each of the 3 above criteria, provide a score (half points allowed)

0 - Poor :x:
Some basic criteria are not addressed
1 - Weak :star:
The proposal addresses the criteria, but there are fundamental gaps or weaknesses
2 - Good :star: :star:
The proposal addresses the criterion well, but shortcomings may be present
3 - Excellent :star: :star: :star:
The proposal successfully addresses all relevant aspects of the criterion, with only minor shortcomings

Appending criteria for different streams

To illustrate how this rubric should be extended to include more specific criteria, these would be the additional criteria for Season 0:

Note: these criteria are in addition to the general criteria above.

Eligibility

Concept

• Demonstrates demand (TVL, unique addresses, community size)
• Proof-of-concept reveals which aspects work and which need attention

Outcomes

• Specifically targets number of polygon users at each milestone
• Impact ROI (Targeted users per $1000 granted) is on-par or better than currently accepted grants
• Demonstrates momentum towards next milestones

Capability

• The team will execute this project with or without the grant
• The team is capable of articulating their challenges in a timely and concise fashion

Or, for a grant stream specific to retrospective acknowledgement:

Eligibility

Concept

• Demonstrates demand (TVL, unique addresses, community size)

Outcomes

• Has social media reach > 1000 users
• Has 50+ Polygon users with a Polyscore of 40+.

Capability

• The team has skin-in-the-game to continue the project for the next 3-6 months

Living documents

These rubrics (the general and stream-specific) are intended to be living documents, changed based on some form of active governance and management.

This allows the grant program to be adaptive to externalities and to real-time learning that can improve performance.

When combined with cohort-based measurements, we can all see how they change various results, as we can separate performance of cohorts based on differing versions. When committed on-chain, they provide an immutable, trustable history and open possibilities to compose grants operation with other useful governance functionality.

too much back and forth
more aligned - double work
can’t take all nft related project
10-15 /
can take 1-2
we’re a small team
3 people in marketing team
help in some projects

we’ll send all projects to ecodao
extremely good

everything new
Studios interested well-established projects

basic marketing push - retweets
amas, deep dive

polygon isn’t throwing money at projects like solana. wants to have a higher bar on selection (to focus resources on better projects, not just volume)

• call - what does the project want. lauchpad? copalaunch, auditing? certik,
  lists and releationships
  when is the launch date
  marketing support call
  basic marketing push
  be on call to answer things

team, concept, if they can deliver
do they have community
good backers

concept is cool but team can’t do it, then give them a small grant

Sharing my outline for the Season 1 grants program here, so anyone interested can follow along, give feedback or contribute.

The goal here is to move us to something state-of-the-art quickly, so it deals with a number of factors that other grants programs are working on as well. So I’d love broad input from in and out of Polygon.

Goals and parameters

The goals of this design are:

• Pipeline yield - treat the talent pipeline as the primary asset to Polygon, aligning with them to maximise their growth and achievement
• Decentralised-first - wherever possible, the process should be politically and architecturally decentralised from the outset. When that’s not possible, use proxies for decentralised primitives to allow for a later transition to on-chain.
• Simple process - we want this to be understandable to all stakeholders, allowing for easier engagement, especially for grantees. “Simplicity is complexity resolved.” The simpler we can make our interfaces to each other, the easier the process will be to understand and improve.

To this end, the design has several guiding principles:

1. Impartial - increasing perceived fairness and thus, the programs reputation, and setting it up with democratic mechanisms consistent with self-government.
2. Transparent - increasing community agency and allowing for a strong feedback and improvement loop.
3. Consistent - consistent growth outperforms sporadic growth since it allows for the support organisation to grow in concert with the grant program, and a more repeatable system less dependent on the performance of individual actors.

Multiple Streams

• the process needs to support a changing set of grant streams. For example, smaller grants to endorse dApps that need a little market boost, larger grants to transition running projects onto Polygon, NFT-specific grants, etc.
• Streams are explicitly defined based on:
  • amount requested
  • targets such as success metric or type of milestone/achievement
  • type of support needed
  • qualification parameters such as past achievements, metrics, team composition, endorsements…

This creates a decentralised and permissionless architecture. Various Polygon and Polygon-related grants programs can participate int the process, using the DAO grant infrastructure and resources as their backend or platform.

It also creates cooperation incentives among the grantors, such as pooling non-monetary support resources to accelerate selected projects, and more diverse and available pools of grant evaluators to improve throughput, feedback and scruteny.

GX - Grantee experience

For the program to attract a higher-calibre of applicants, we want to provide great GX. Our feedback tells us grantees want fast feedback, but that’s the tip of the iceberg. If we consider the talent pipeline to be a strategic asset, then we need to develop and support it regardless of whether they qualify for a particular grant within a particular funding window. These are motivated builders ready to work on Polygon, and this design aims to deliver value to them regardless of if their application was accepted.

Response time

To this end, we aim to respond as quickly as possible, when possible, which in turn requires operational optimisations:

• Obvious rejections are processed in real-time, reducing the pipeline volume for the evaluation team
• The process aims to return applications quickly, with feedback, giving the applicant more time to re-apply with improvements. We remove ambiguity by returning (rejecting) any application which requires additional information, but inviting reapplication.

Focus on application improvement

• Application are either returned with:
  • Specific reasons and questions, with reference to documentation such as the relevant rubrics and application examples, and
  • in cases of strong applications or projects, a dedicated champion to assist them in reapplying

Post-application GX

• easy review process
• automated payments
• megaphone support (twitter, community call shoutouts with results, AMAs)

Operational process

Note that the process optimises for fast response via fast rejections. This entails a supporting process for real-time improvement of public-facing documentation. For example, quickly updating the website with a clearer example application. The strategy here is to use rejections as input for improving our scalable resources like website content.

When there are good applications that don’t technically qualify, we assign them a personal support champion so they can reapply and be accepted as conveniently as possible. This also allows the evaluators to better understand decificiencies in the process, to amend the criteria or adjust the available policy levers accordingly.

Performance measurement

This design looks at performance measurement from twi perspectives:

• Absolute performance: for any given funding stream, what has the portfolio achieved and at what cost?
• Iterative performance: is the funding stream improving it’s performance over time? Time-based and policy-based cohorts allow us to adapt and improve the performance of the fund as funds are being deployed
• Operational performance: how effective and efficient is the operation on a weekly basis? This looks at measures such as response time, throughput rate, throughput volume, and efficacy measures such as accepted applications and milestone success rate.

Cohort-based

To this end, we need to measure ourselves on a using weekly cohorts. This has the additional benefit of planning support operations like announcements and payments on a recurring weekly schedule.

Over time, weekly-cohorts can be compared against each other for long-term performance, revealing which policies, marketing channels and partners produce the best performers.

Policy Levers

The process is designed with several policy levers, allowing for real-time adaptation of the grant faucet to external and internal factors:

• max total grant capital allocated per week – capital deployment rate
• selection bar - top X or top X% – for balancing capital effectiveness vs capital deployment
• automatic rejection bar - score – for managing the operational processing rate (a higher bar means faster processing of applications overall, with a trade-off of more false negatives)

Due Diligence

Due Diligence is weak across the blockchain grants landscape, and if we’re being honest, it’s even underused in conventional government, charity and corporate application processes. Nonetheless, weak or no due diligence wastes funds on ineffective projects and signals attracts the fraudulent and inept.

Each stream must define certain measurable or observable qualifiers, and these need to be checked by evaluators before final approval.

Milestones and tranching

For larger grants, it’s recommended that a minimum bar of target success metrics is also required for each application, and payments tranched in milestones measured by those metrics.

This approach protects the funds from abuse, and improves our visibility of what works and doesn’t, thus allowing us to improve or adjust as necessary.

Evaluators

• Self-selection bias - Optimism’s first round of retrospective grants revealed the group biased heavily to projects they were already familiar with. This reveals 2 weaknesses in typical blockchain grants programs:
  • They favour community insiders, taking opportunities away from the nascent and diverse projects the grant endowments are meant to support
  • They crystalise around known categories of expertise, rejecting emerging categories by omission
• Lack of oversight - granting bodies tend be structured in ways that conflate operational responsibilities with oversight, and as such there is usually almost no oversight. Do the grant programs actually work? Do they achieve results beyond allocating capital and enabling early milestones? And, how do the token-holders and other stakeholders have governance influence over the process?

The answers to these will come from a combination of factors:

• Long-term success metrics
• Decision-making transparency, ideally on-chain
• Separate oversight bodies, elected quadratically
• Separating operational responsibilities from evaluation responsibilities, allowing for easier independent evaluation by community members
• Operational visibility of difficult-to-assess application categories, revealing when broader domain experience is needed in the evaluator group

To simplify this for the moment, organising the evaluators and evaluation process like TCRs would align it to the most well-used on-chain primitive that applies. Though, as a community, we’ll need to develop more primitives for grant and resource distribution generally.