Rare Protocol
Search
K
📄

$RARE Staking Whitepaper

RARE Staking: a Novel Mechanism for Reputation, Curation and Discovery
Charles Crain, John Crain, Rohit Kapoor, Zach Kolodny, Brennan Mulligan, Kyle Olney, Jonathan Perkins

Abstract

As part of the Rare Protocol, we propose a novel cryptoeconomic system in which users stake on each other to signal support, creating a peer-to-peer network similar to a web of trust. The statefulness of this network generates an open dataset for participant reputation at scale, without the use of verified credentials or centralized intermediaries. We anticipate that data generated by this network will aid users in discovering relevant and reputable content, resulting in powerful network effects that transcend any individual marketplace and promote visibility for emerging creators.
The purpose of this paper is to provide the conceptual framework necessary to understand the smart contract functionality, tokenomics, and mechanism design of the system described. It is intended primarily for technical audiences. However, it is our hope that it can serve as a reference for the generation of additional documentation that targets a broader audience in addition to any relevant governance discussions that may follow.

Specification

This network is primarily composed of individual smart contracts called rarity pools, that are deployed from a single smart contract factory. A smart contract called the RARE Staking Registry provides global and aggregated network information and maintains a registry of all rarity pools. Holders of RARE can stake the token to a rarity pool in exchange for a pool-specific synthetic token (xRARE), which is issued against a bonding curve using a square root function.
By staking in a rarity pool, users generate curation data that can be used by outside actors such as marketplaces, aggregators, or individuals. These outside actors can issue rewards to stakers as compensation for the valuable data they provide and encourage further engagement. If the rewards are denominated in RARE, they may be sent directly to a rarity pool, where they will be distributed among stakers based on the proportion of xRARE they own. However, rarity pools cannot account for and distribute rewards denominated in other currencies. To resolve this, specialized smart contracts called reward accumulators serve as intermediaries that can receive rewards denominated in any currency, perform reward swaps to convert those currencies into RARE, then transfer that RARE to the corresponding pool so that it can be distributed.

Rarity Pools

Rarity pools are modified ERC-20 contracts which allow users to stake RARE in exchange for a non-transferrable synthetic token that is issued against a bonding curve. In this paper we use the name xRARE to discuss these synthetic tokens in general terms, but in actuality the token for each pool will be named “xRARE_” followed by the target’s ENS name, if one exists, or an abbreviation of user’s address if one does not. By staking in a pool, users signal support for a given ethereum address. This address can be referred to as the pool’s target, and must be specified when a pool is created. Rarity pools may be created by any ethereum account, including their prospective target, by interacting with a smart contract factory that ensures only one rarity pool may be created per target.
There are four primary actions a user can take when interacting with a rarity pool: stake, unstake, claim, and add rewards. Stake allows users to lock RARE in a pool in exchange for xRARE. Unstake allows users to withdraw their RARE from the pool. Claim allows stakers to collect rewards, denominated in RARE, which have been sent to the pool as compensation for the curation data that its staker’s collectively generate. Add rewards transfers RARE to the pool and ensures that it can be distributed to stakers. Each of these will be discussed in detail within their own section.

Rounds and Snapshots

Rarity pools use periods of time, called rounds, to keep track of xRARE ownership and the amount of rewards flowing into the pool. When one round ends, the next round automatically begins. Rounds end when a fixed period of time called the round countdown is completed. The duration of the round countdown is the same for all pools and is a configurable value of the protocol. The round countdown begins in response to the first user action (stake, unstake, claim, or add rewards) that occurs in that round.
Additionally, before the action that triggers the round countdown is executed, a snapshot is taken of the pool’s xRARE distribution. At the conclusion of a round , each xRARE holder can claim a portion of rewards that were added to the pool during the round, proportional to their share of the pool’s xRARE supply captured during the snapshot.

Mechanics of the First Round

Once a rarity pool has been deployed, the first round will start and rewards can be added to the pool. Because the pool was just created, there will be no stakers captured in the first round’s snapshot. However, the rarity pool will mint one xRARE to the address that deployed it. Granting this small allocation to the pool’s deployer offers the possibility of compensation in exchange for the effort and gas fees required to deploy the pool. In addition, the amount of xRARE granted to the deployer is small enough that it will not have a significant impact on reward allocation in future rounds, once other users have started supporting the pool.

Staking

Once a rarity pool has been deployed, users can stake on it by locking up their RARE tokens in exchange for a non-transferrable synthetic token (xRARE) specific to that pool. The amount of xRARE that a user receives (
xreceivedx_{received}
) when staking a given amount of RARE (
rstaker_{stake}
) can be roughly described by the following equation, where
XtotalX_{total}
is equal to the pool’s total supply of xRARE prior to their stake, and
aa
and
bb
are constants included to shape the bonding curve and avoid precision loss:
xreceived=rstake(arstake+Xtotal2Xtotal)bx_{received} = \frac{\sqrt{r_{stake}} * (\sqrt{a*r_{stake}+X_{total}^{2}}-X_{total})}{b}

Claiming

For each round, the amount of RARE claimable by a user (
rclaimr_{claim}
) is determined by the following equation, where
xuserx_{user}
is the amount of xRARE owned by the user during the round’s snapshot,
XtotalX_{total}
is the total supply of xRARE held by all stakers during the round’s snapshot, and
RtotalR_{total}
is the total amount of rewards accrued by the round at the end of the round countdown:
rclaim=RtotalxuserXtotalr_{claim} = \frac{R_{total} * x_{user}}{X_{total}}
For each user, the rarity pool stores the latest round id for which they have claimed (
iclaimedi_{claimed}
). If a user has not yet claimed any rewards, then
iclaimedi_{claimed}
is set to the id of the round during which they initially staked. In order to retrieve RARE allocated to them by the protocol, users specify the number of rounds from which they'd like to claim (
Δi\Delta i
). The protocol then transfers all of the RARE allocated to that user between round
iclaimedi_{claimed}
and round
irequestedi_{requested}
, where
irequested=iclaimed+Δii_{requested}=i_{claimed}+\Delta i
, and sets the new value of
iclaimedi_{claimed}
to
irequestedi_{requested}
. If
irequestedi_{requested}
is larger than the id of the pool's most recently completed round (
icurrenti_{current}
; i.e. if the user attempts to claim from a round which is still ongoing or has not occurred) then the user will receive all of the RARE allocated to them since their last claim, and
iclaimedi_{claimed}
will be set to
icurrenti_{current}
, rather than
irequestedi_{requested}
.

Unstaking

Unlike a traditional bonding curve, the amount of RARE a user can withdraw is not determined by the total supply of xRARE at time of withdrawal. This means that they will always be able to unstake roughly the same amount of RARE as they staked (
RAREinRAREoutRARE_{in} \approx RARE_{out}
). Users can withdraw RARE from the pool by specifying the amount of xRARE they would like to unstake (
xunstakedx_{unstaked}
). Using
xunstakedx_{unstaked}
, the rarity pool will calculate the amount of RARE to return to the user (
runstakedr_{unstaked}
) with the following equation, where
ff
is a percent-based fee (
0f10 \leq f \leq 1
) which burns a portion of the user’s RARE, and
xownedx_{owned}
is the total amount of xRARE the user owns prior to unstaking:
runstaked=(1f)rstakedxunstakedxownedr_{unstaked}=(1-f)*r_{staked}*\frac{x_{unstaked}}{x_{owned}}
The purpose of
ff
is to disincentivize freeloading on the curation data generated by other stakers. This could be done by staking into pools just before the round countdown ends and unstaking just after the next snapshot occurs, maximizing the number of pools from which rewards can be claimed while minimizing the opportunity cost invested in each pool. This phenomenon and the associated tradeoffs are discussed further in the Configurable Parameters section.

Adding Rewards

Anyone can add rewards to a rarity pool by calling the addRewards function. This function does three important things when called:
  1. 1.
    Facilitate the transfer of RARE to the rarity pool.
  2. 2.
    Add that RARE to the pool’s current round.
  3. 3.
    Add any other RARE that is owned by the rarity pool but not included in any of its rounds to the pool’s current round.
As described in Rounds and Snapshots, once RARE has been added to the current round, it will become claimable to stakers as soon as the round ends. Note that if RARE is sent directly to a rarity pool contract without addRewards being called, then the rewards will not be included in the current round, but will eventually be included the next time that addRewards is called. Additionally, if any currencies other than RARE are sent to the rarity pool, they will not be distributable to stakers and will be inaccessible. Instead, all currencies other than RARE should be sent to the associated reward accumulator smart contract, discussed in the next section.

Reward Accumulators

Reward accumulators are specialized smart contracts that receive and process funds from outside parties who wish to incentivize staking activity. Anytime the smart contract factory deploys a rarity pool, it will also deploy a reward accumulator associated with that specific pool. Users can interact with reward accumulators to perform reward swaps, which convert non-RARE currencies owned by the accumulator into RARE. Reward swaps can only be performed for ETH or ERC-20 tokens with an ETH trading pair on Uniswap.
Reward accumulators are necessary because rarity pools can only account for and distribute rewards denominated in RARE. Any other currencies sent to rarity pools, such as USDC or other ERC20 tokens, will be inaccessible. Because of this, it is critical that users who wish to send currencies other than RARE to a pool send them to the corresponding reward accumulator first, so that they can be converted into RARE, added to a round, and distributed to stakers.

Reward Swaps

At any point a user may initiate a reward swap by specifying the contract address of the currency they would like to receive, the minimum amount of that currency they are willing to receive (
cminc_{min}
), and the amount of that RARE they would like to provide (
rswapr_{swap}
). The transaction will fail if
cminc_{min}
is greater than the reward accumulator’s balance of the specified currency, or if
rswapr_{swap}
is greater than the amount of RARE that the user owns.
The reward accumulator will then query Uniswap to determine the exchange rate (
ee
) between RARE and the specified currency. If the currency being swapped is ETH, then
ee
will be equal to the RARE / ETH price. If the targeted currency is some ERC-20 other than RARE, then
ee
will be equal to the RARE / ETH price multiplied by the inverse of the ERC-20 / ETH price. In either case, the exchange rate will be calculated using a 30 minute time weighted average to mitigate the risk of flash loan attacks.
The amount of currency the user will receive
cswapc_{swap}
is then calculated using the following equation, where
dd
is a percent-based discount (
0d10 \leq d \leq 1
) which incentivizes users to make the swap and compensates them for gas spent to perform the swap:
cswap=rswape(1d)c_{swap}=r_{swap}*e*(1-d)
Note that if the value returned for
cswapc_{swap}
is less than the value specified for
cminc_{min}
, the swap will fail. If the swap executes successfully, then
rswapr_{swap}
will be transferred from the user to the reward accumulator, and the reward accumulator will call the rarity pool’s addRewards function. This causes all RARE owned by the reward accumulator to be transferred to the rarity pool and included in the current round.

Discussion

Configurable Parameters

There are a number of configurable parameters within the protocol which can be controlled to produce optimal outcomes. These parameters, along with the tradeoffs which inform how the parameters should be tuned, are described below.

Round Countdown Duration

The round countdown duration is currently set to 7 days. There are three primary trade-offs to navigate in setting the round countdown duration: gas efficiency, capital efficiency, and disincentivizing freeloading.
Decreasing round countdown duration is beneficial to the protocol in that it increases the resolution of reward allocation, ensuring that stakers may claim rewards soon after they are sent to the rarity pool. This increases the capital efficiency of the system, decreasing the opportunity cost users must absorb while waiting to claim their rewards. This also makes it less profitable to unstake immediately after a snapshot occurs, freeing up RARE to stake in another pool. With shorter rounds, this sort of freeloading as a user hops from pool to pool will be less profitable because the total amount of rewards allocated per snapshot may be significantly reduced.
However, as round countdown duration decreases, the number of rounds for which users must claim rewards will increase. This means they will need to specify more round IDs when claiming rewards, which decreases gas efficiency. Taken to its extreme, this may cause users who have not claimed for a long time to hit the gas limit when attempting to claim for all the rounds they missed. In this case, they would have to batch the rounds they’d like to claim across multiple transactions which may lead to frustration and could incur considerable design burden for front ends developed on top of the protocol.

Bonding Curve Equation

The square root function described in the Staking section was chosen because of its simplicity and because it balances increased compensation for early stakers with accessibility for later stakers. This function contains two coefficients which are meant to shape the bonding curve and prevent precision loss. Their current values are
a=21028a=2*10^{28}
and
b=1013b=10^{13}
.

Unstaking Burn Fee

The unstake burn fee (
ff
, described in Unstaking) is a percentage subtracted from the amount a user originally staked, and burned. Increasing the burn fee benefits the protocol by decreasing the behavior of freeloaders that frequently stake and unstake on pools in an attempt to time snapshots, as described in Round Countdown Duration. However, increasing the burn fee harms the protocol by disincentivizing users from unstaking even when the decision to do so is based on genuine curatorial intent and the desire to no longer support the pool’s target. We believe that the appropriate value would be one that is small enough to be tolerable by good actors, but significant enough that it would nullify any gains made by freeloaders. More robust modeling of this tradeoff is encouraged.
Note: Following forum feedback during the request for comment period, we have set the burn fee to 0% for initial mainnet deployment. More complex implementations which use a dynamic burn fee which decays over time are being evaluated and may be introduced as modifications to the protocol in subsequent proposals.

Reward Swap Discount

The reward swap function exists because it is not economical to perform individual swaps every time currencies other than RARE are added to a pool. As such, we must allow these funds to build up in the pool’s reward accumulator until it becomes economical for a third party to perform a reward swap. In order to offset the gas required to execute the swap, we must include a discount (
dd
) which provides an arbitrage opportunity to the swapper. The current value of
dd
is 0.1.
Recall the equation which determines how much RARE a user must provide in order to claim an amount of non-RARE currency
cswapc_{swap}
based on an exchange rate obtained from Uniswap (
ee
):
cswap=rswape(1d)c_{swap}=r_{swap}*e*(1-d)
In order for a swap to be profitable, the transaction fee must be less than
dcswapd*c_{swap}
. As such, increasing the value of
dd
decreases the value of
cswapc_{swap}
required for a profitable exchange, which also decreases the length of time over which currencies must accumulate before being swapped into RARE and distributed to stakers. However, increasing d also decreases the amount of RARE that ultimately gets distributed to stakers, decreasing the capital efficiency of the protocol as a whole.

Funding Rarity Pools

This protocol is designed to receive funding from arbitrary sources denominated in almost any digital currency. The intent behind this is to make rarity pools as extensible as possible. For example, rarity pools might receive rewards from NFT marketplaces, artwork aggregators, licensing revenue, or individual actors such as the target of the pool. For example, a marketplace could divert a portion of the platform fees it generates to the protocol to incentivize stakers to continue generating curation data. To do this, whenever the marketplace smart contract makes a sale, it would check the staking registry to see if the seller is targeted by a rarity pool. If they are, the marketplace contract could divert a portion of any fees generated by the sale to the reward accumulator associated with the seller’s rarity pool.

Incentive Alignment via
RAREinRAREoutRARE_{in} \approx RARE_{out}

In a traditional bonding curve, where the value of your position may increase or decrease based on the behavior of other stakers, there are two games which a user could win:
  1. 1.
    Accurately predicting whether a seller will generate value for the network
  2. 2.
    Accurately predicting whether other RARE holders will stake in the same pool
In the presence of synthetic tokens which can be bought low and sold high, Game 2 is over-incentivized, which leads to a degenerative system (i.e. few winners, many losers). This is evident when looking at the system from the perspective of a bad actor, for whom the optimal strategy would be: stake on address 0x8cd7, shill that address’ rarity pool by paying influencers who get lots of other people to stake in the pool, then withdraw all of your xRARE in exchange for more RARE than you originally staked. This effectively rugs the other stakers, adds noise to the curation signal, and could stain the staking target’s reputation, even if they were not involved in the scheme.
However, the system becomes more regenerative (i.e. many winners, few losers) when we use the distribution of xRARE to determine what portion of rewards a user receives while keeping the amount of RARE they receive when unstaking roughly equal with the amount of RARE they staked
RAREinRAREoutRARE_{in} \approx RARE_{out}
. By preserving a 1:1 relationship between
RAREinRARE_{in}
and
RAREoutRARE_{out}
, the incentive shifts from getting other people to stake in a pool (Game 2) to getting other people to buy NFTs from or otherwise transact with the pool’s target (Game 1). This also keeps the motivations of stakers focused exclusively on generating accurate reputation data reflecting the degree to which the target contributes positively to the network.
By adopting the
RAREinRAREoutRARE_{in} \approx RARE_{out}
model, the system achieves far better incentive alignment. Collectors win, artists win, curators win, early stakers win, and even late stakers win – just not as much. Meanwhile, the only possible loss in this model is the opportunity cost of not staking your hard-earned RARE at all, or by staking in what ultimately becomes a less active rarity pool than your instincts had anticipated.

Reputation-Based Incentives

As the amount of stake and diversity of stakers in a rarity pool increases, the reputation generated by the pool creates a strong signal that the pool's target may be a valued member of the community and not a sybil. Through this protocol, each participant can have their reputation programmatically recognized by the DAO, enabling novel approaches to incentivization and distribution of governance power.
This could take the form of a commission paid in RARE on each transaction that goes to the pool’s target or a flat rate paid from the DAO treasury at regular intervals based on the reputation level they maintain. In order for this to be viable, a robust system of sybil defense and risk scoring for pool targets should be implemented. Considerable work in this area has already been done by Gitcoin’s Fraud Defense and Detection workstream, which could serve as a useful reference for any initiatives to develop reputation scores based on staking data within the Rare Protocol.

Peer-to-Peer Enforcement of Prosocial Behavior

Due to the current lack of any cross-platform reputation system that aligns incentives between artists, collectors, curators, and marketplaces, there is a multi-polar trap which incentivizes individual marketplaces to abandon royalties or make them optional. As soon as one marketplace allows collectors to avoid paying royalties, all other marketplaces are incentivized to make royalties optional or abandon them entirely in an effort to protect trading volumes. There is little that can be done to prevent marketplaces from succumbing to this race to the bottom, because the generation of fees through increased marketplace volume is fundamental to their business model.
rarity pools constitute a reputation system through which anti-social behavior, such as the bypassing of royalties, can be disincentivized through peer-to-peer enforcement of social norms without relying on profit-motivated, centralized intermediaries. This represents a revolutionary step towards the crypto community’s core values of decentralization and disintermediation.

Applications

Due to the open nature of on-chain data, this system provides a valuable dataset which can be used by any service integrated with the Rare Protocol. As such what we present here is not just a prediction game which improves RARE tokenomics and utility, but also a foundational piece of protocol architecture which can unlock other innovative systems over time. We see three primary areas in which staking data can provide significant value:

Reputation

Rarity pools introduce an open system to the Rare Protocol that establishes a web of trust, allowing RARE holders to collectively identify which marketplace participants are trustworthy and likely to generate positive economic activities. However, this web of trust is only useful if the underlying data is easily readable.
A quantifiable reputation score could be made available through an off-chain API which processes curation data from rarity pools in order to provide an easy to understand and independently verifiable metric. Such a score could be calculated using a model similar to quadratic funding, which imposes a cost of conviction such that 100 people staking 1 RARE would generate a larger signal than 1 person staking 100 RARE. Additionally, mechanisms such as conviction voting could be used to amplify the signal generated by a staker the longer they maintain their stake on a given pool. Stakers with high reputation scores could even have an increased influence over the reputation score of the pools they stake on, creating a natural incentive to accumulate positive reputation in order to gain influence in the network. Making reputation scores sybil resistant should be a top priority, as employing these mechanisms creates the opportunity for disingenuous pool targets to stake on themselves using many accounts in order to boost their score.
By incorporating reputation scores or similar metrics into an app which collates data on collectors, artists, and curators across the cryptoart ecosystem, this web of trust could become an invaluable public resource - significantly derisking economic activity in marketplaces where a seller's reputation may be difficult to discern. For example, the absence of a legitimate rarity pool may immediately identify bad actors attempting to impersonate prominent artists or collectors.

Curation & Discovery

In addition to assuring buyers that the counterparty they are about to purchase from is reputable, rarity pool data can also be used to help them find good art to buy in the first place. This improved discovery happens in two ways: discovering sellers via the seller’s own rarity pool data (e.g. a reputation score leaderboard), or discovering sellers by exploring the list of rarity pools on which prominent network participants have staked.
These staked lists are essentially curated registries of the ethereum addresses a given user supports, and cross-referencing these lists can foster powerful data-analysis similar to the PageRank centrality models that fueled early search engines. In our case, such models could increase the opportunities for emerging talent to gain visibility organically and generate powerful network effects.
These and other data insights will become critical as the web3 creator economy continues to grow. In the future, staked lists, reputation scores, and other constructs built on top of staking data could be used to augment search results, change how content displays in a user’s feed, or power decentralized recommendation engines across a multitude of UIs.

Community

When a user stakes in a rarity pool, they receive a non-transferable xRARE token specific to that pool which could be easily referenced by token gates. Communities with token gates targeting xRARE ownership for a particular pool, which may be called staking-gated communities, create interesting possibilities for the self-organization of the network based on their preference in art. This highlights the social aspects of staking in somebody’s rarity pool. Stakers are not just saying “I think this person makes, collects, or curates good art and will generate economic activity”, they are also joining a community of people who share the same interests, philosophies or opinions as the pool’s target.
All of the cryptoeconomics described in this paper are merely a substrate for the genuine expression of trust and preference between network participants. The ability to harness this social data for the development of community tools represents an incredible opportunity to strengthen the interpersonal relationships that the web3 creator economy is built upon.

Conclusion

By adopting this system, Rare Protocol will further entrench its place as the leader of innovation in the web3 creator economy. In addition to improving tokenomics by increasing RARE utility, rarity pools will further align incentives between artists, collectors, and curators. The on-chain information made available across rarity pools will provide a scalable dataset that is trustlessly verifiable and openly accessible. As the Rare Protocol continues to grow, rarity pools could eventually power a number of interoperable, community developed tools which increase trust and economic activity across the ecosystem. In this way, the RARE Staking protocol revolutionizes the economics of human creativity for all members of our community by introducing a powerful crypto-economic primitive which will change the way art is curated and sold forever.

Acknowledgements

Special thanks to the many people who have contributed to our thinking and provided valuable feedback on the protocol, its mechanism design, and this whitepaper: Mike Deal, Keegan Ead, Emilio Cazares, Zack Yanger, Gordon Berger, Luke Whyte, Phil Readman, Savaş Özay, Juan Pablo Bermani, Renat Khasanshyn, Patrick Gerbes, hex6c, disruptionjoe.eth, Paulius Uza, Kevin Seagraves (@captnseagraves), Aaron Harburg, Chikai Ohazama, Kyle Smith (bestape.eth), Simon Hudson, 0xZakk, Cooper Turley, collab+currency, Nick Tomaino (1confirmation)