ERC-2212: Interest Earning Stakes

[PaulRBerg]

eip: 2212
title: ERC-2212 Interest Earning Stakes
author: Paul Razvan Berg (@PaulRBerg) <paul@sablier.finance>
discussions-to: https://github.com/ethereum/EIPs/issues/2212
status: Draft
type: Standards Track
category: ERC
created: 2019-07-26
requires: 20

Simple Summary

We propose a new way to monetise decentralised apps that involves users staking tokens in exchange for a product or a service and creators earning interest on the pooled stakes through a continuous lending protocol such as Compound.

Abstract

The advent of decentralised lending brought to the web3 ecosystem a new primitive for designing business models. We herein describe a smart contract interface that accepts deposits ("stakes") in ERC20 tokens. These deposits are immediately lent on the market to earn interest either for just the owner of the contract, or for both them and the user. We assume that users get access to a product or a service for as long as they keep staking tokens.

Motivation

While most web3 business models rely on paying a percentage fee on transfers, or committing to a monthly subscription, we aim to flip the model on its head. Users are their own banks now, so, instead of charging them, we make them stake tokens that can be claimed back, in full, at any point in time. We view this as a win-win-win scenario for users, dapp creators and lending protocols.

It is worth it to mention PoolTogether, a "no-loss lottery" that launched recently. It works by having participants deposit money in their contracts, locking it up for a while and earning interest through Compound. Ultimately, they choose a lucky winner and return the deposits back to all other players. PoolTogether takes a 10% commission on the prize.

We wrote this specification because interest earning stakes are a powerful financial instrument and a community-vetted standard and implementation will reduce the cost of replication.

Use Cases

• Software products and services
• Charity pools
• Games
• Gym memberships

Specification

Assigning an owner is mandatory for this spec to make sense, thus we assume that a proper implementation would use a well-known contract such as OpenZeppelin's Ownable. For brevity, we haven't included any method for assigning or transferring ownership.

Methods

owner

Returns the owner of the contract.

function owner() external view returns (address);

fee

Returns the fee as a percentage value scaled by 1e18.

function fee() external view returns (uint256);

balanceOf

Returns the stake that consists of the initial deposit plus the interest accrued over time.

SHOULD revert if staker doesn't have an active stake. SHOULD revert if tokenAddress doesn't match either the cToken or the underlying of the stake.

function balanceOf(address staker, address tokenAddress) external view returns (uint256);

depositOf

Returns the initial deposit.

SHOULD revert if staker doesn't have an active stake. SHOULD revert if tokenAddress doesn't match either the cToken or the underlying of the stake.

function depositOf(address staker, address tokenAddress) external view returns (uint256);

whitelistCToken

Whitelists a cToken to automatically convert its underlying when deposited.

MUST revert if msg.sender is not the owner.

Triggers Event: WhitelistCToken

function whitelistCToken(address cTokenAddress, address underlyingAddress) external;

discardCToken

Discards a cToken that has been whitelisted before.

MUST revert if msg.sender is not the owner.

Triggers Event: DiscardCToken

function discardCToken(address cTokenAddress) external

resetAllowance

Resets the allowance granted to the cToken contract to spend from the underlying contract to the maximum value possible in the EVM.

function resetAllowance(address cTokenAddress, address underlyingAddress);

stake

Creates a new stake object for msg.sender. Automatically converts an underlying to its cToken form so that the contract can earn interest.

MUST revert if msg.sender already has an active stake. MUST revert if the cToken/ underlying pair has not been whitelisted.

Triggers Event: Stake

function stake(address tokenAddress, uint256 amount) external;

redeem

Returns the deposit plus any accrued interest to the staker and levies the fee for the owner.

MUST revert if msg.sender is not the staker or the owner.

Triggers Event: Redeem

function redeem(address staker) external;

takeEarnings

Withdraws the earnings accrued over time.

MUST revert if msg.sender is not the owner.

Triggers Event: TakeEarnings

function takeEarnings(address tokenAddress, uint256 amount) external;

updateFee

Updates the fee practised by the contract. Has to be a percentage value scaled by 1e18. Can be anything between 0% and 100%.

MUST revert if msg.sender is not the owner.

Triggers Event: UpdateFee

function updateFee(uint256 newFee) external;

---

Events

WhitelistCToken

MUST be triggered when whitelistCToken is successfully called.

event WhitelistCToken(address indexed cTokenAddress, address underlyingAddress);

DiscardCToken

MUST be triggered when discardCToken is successfully called.

event DiscardCToken(address indexed cTokenAddress);

Stake

MUST be triggered when stake is successfully called.

event Stake(address indexed staker, address indexed cTokenAddress, address indexed underlyingAddress, bool converted, uint256 cTokenDeposit, uint256 exchangeRate);

Redeem

MUST be triggered when redeem is successfully called.

event Redeem(address indexed staker, address indexed cTokenAddress, address indexed underlyingAddress, uint256 cTokenFee, uint256 cTokenWithdrawal, uint256 exchangeRate);

TakeEarnings

MUST be triggered when takeEarnings is successfully called.

event TakeEarnings(address indexed tokenAddress, uint256 indexed amount);

UpdateFee

MUST be triggered when updateFee is successfully called.

event UpdateFee(uint256 indexed fee);

Rationale

We designed these interest earning stakes with simplicity in mind, but we acknowledge that there are some missing features and obvious concerns which we discuss below.

---

Missing Features

Update

By and large, this is the most prominent missing feature. Dapp creators might want to update their staking requirements and the only way to achieve that would be to ask users to redeem their previous stake and put in the new amount.

We assume that most apps don't need this and the spec as it is now is sufficient for running the very first experiments. Yet, time will tell best. We are looking forward to making updates if need be.

Parallel Staking

Large enterprises have multiple sources of revenue, hence switching to a business model based on staking would require a smart contract that accepts multiple stakes per user.

However, the goal is to avoid writing an over-optimised standard. Parallel staking would require dapp creators to keep track of multiple stake ids, instead of only the user's account. Also, the user's interface would become more complex, as they would have to be aware of multiple stakes.

Beyond Compound

Some functions in the interface are highly specific to Compound, but the rationale behind that is simple. Compound is by far the best suited protocol for interest earning stakes. It is ultra-short term, which makes for frictionless business. We may update the interface when other continuous lending schemes, such as the Dai Savings Rate, will scale significantly.

---

Concerns

Loan Defaults

Lending never comes without risks, so interest earning stakes are not a good fit for the ultra-sensitive business applications. That said, dapp creators have an incentive to monitor the market for borrowers that go under the collateral requirements and liquidate them. By doing so, they secure the network for their own users and also earn a fee in the process.

Fluctuating Rates

The market rates for lending stablecoins hovered around 10% in early 2019, but this is not a given. Dapp creators can accommodate this issue by asking for a stake that generates interest reasonably above what they deem as an acceptable revenue stream.

Rent-Seeking

Interest earning stakes work best for products or services that are priced on time instead of quantity (imagine subscription-based SaaS). If a dapp is quota-based, its creators would be better off charging a fee on every transfer.

Implementation

Head to the Sablier organisation on GitHub for a WIP implementation.

Additional References

• Thread on cTokens
• Compound Protocol
• PoolTogether
• Pooled cDAI
• Lending Proxy by Luciano Bertenasco
• Web3 Revenue Primitives

Copyright

Copyright and related rights waived via CC0.

@PaulRBerg and @sablierhq ✌️

[bgits]

I think it would be helpful to also have a standard for interacting with lending contracts. It seems compound, dYdX, etc can and should expose the same interfaces so that developers can easily integrate multiple lending market places.

[PaulRBerg]

@bgits Interesting, although hard to implement. These protocols have very different interfaces and collateral requirements.

[bgits]

@bgits Interesting, although hard to implement. These protocols have very different interfaces to collateral requirements.

The different interfaces are the problem having a standard would fix. Collateral requirements, term structure and all components that compose a loan can be standardized into an expected interface just like they are for the traditional debt markets regardless of the thousands of different companies issuing different debt types.

[PaulRBerg]

What I meant is that coordinating all teams is hard, specifically because trade-offs would have to be made. Something like InstaDApp where each protocol is abstracted in the backend may be much easier to develop.

[hayesgm]

Big fan of this spec and the power behind this idea, as we've already see in a number of live projects. This specification can really open up that ecosystem to a new set of apps and teams.

I do agree with @bgits that the interface layer should probably be generic. That is, the interface for stake, redeem, takeEarnings, etc, should be as generic as possible so that a proper implementation could be backed by any protocol that is compatible with this spec. Then, the rest of the functions here (such as whitelistCToken) can be implementation details. Preferably, we can build a first-class implementation that integrates Compound, and then make sure the community has the resources to build further implementations.

I'd love to see this spec move forward and become widely utilized. We're already seeing projects build in this direction, and thus this spec can help keep the community and implementations fully compatible.

[PaulRBerg]

Hey @hayesgm happy to see you diving in!

Oh, absolutely, the standard should eventually become protocol agnostic. As mentioned in v1, I used Compound simply because it was easy to pick up. My take was that Barry suggested another ERC for accessing all lending protocols and I deemed that hard to accomplish. Sorry for any misunderstanding.

I made this HackMD document for everyone to leave their thoughts on v2.

What I did so far:

• Remove whitelistCToken, discardCToken and resetAllowance and their associated events
• Replace cTokenDeposit with deposit in the Stake event
• Replace cTokenFee with fee in the Redeem event
• Replace cTokenWithdrawal with withdrawal in the Redeem event

Also, the assumption is now that deposits and withdrawals are quantified in the underlying asset. That is, DAI instead of cDAI, because the former is the ubiquitous source of value (well, if you ask blockchain people).

Questions:

1. I personally like "stakes" more than "pools", as you can make a pool out of a group of stakes, but the reverse is not logically possible. But others said "Interest Earning Pools" sounds better, so I'm kinda sitting on the fence. What do you think?
2. Should there be a dead man's switch for withdrawing/ liquidating all stakes? That is, in case of a flash crash, the owner of the contract could call one method to redeem the underlying assets.

[hayesgm]

Cool @PaulRBerg added some comments to the HackMD doc. This is coming along, for sure. In regards to your two questions:

1. Yeah-- personally, I think of this as, for example, "Stake DAI to join the community" or "Stake USDC to donate" or whatever use cases people come up with. Collectively, we should think of this as Group Staking over a variety of underlying assets (that is, beyond just Eth staking). Personally, "Enter an Interest Earning Pool to join the community" doesn't have the same ring.
2. Liquidating each individual stake might be difficult code-wise. You could fully redeem this contract's balance from Compound and allow users to redeem directly from that balance. Holistically, though, I believe that users who stake this way are liable to any concerns in the underlying platform and adding this switch wouldn't truly insulate those users from those risks (plus, they could each redeem, themselves, in light of any concerns).

[AdvaithD]

This is amazing! I think it plays well into ethos as well. Using compound would be a great way to test this as an experiment. However, if this spec was protocol agnostic - we would have higher liquidity and better earnings.

This could be used as a membership mechanism for any dapp - "stake with us to get access, while we earn some interest off of your collateral"

[hayesgm]

In regards to agnostic, I believe the right implementation would be: many protocols will implement this same interface, however, each one would only implement staking via a single underlying lending protocol (e.g. Compound or dYdX). Different lending protocols have vastly different risk parameters, and it should be made clear to stakers ahead of time which protocol their funds are being staked to. The common interface, however, would make it easy to build common interfaces or second-layer solutions for interest-bearing protocol staking.

[PaulRBerg]

In regards to your two questions:

1. Awesome
2. Gotcha

Hey @AdvaithD glad to hear that! To follow up on Geoff's point: let's take an example of lending 100 DAI and two markets A and B which only allow up to 50 DAI each. Even if you may benefit from increased liquidity by lending on both A and B, you vastly *reduce* the security and significantly *increase* the overhead of the standard. Therefore, it is easier to cap the stake to 50 DAI, only lend on A and wait for the market to get larger.

[axic]

@PaulRBerg do you want to create a real EIP out of this (aka submit a PR)?

[PaulRBerg]

Hey @axic, thanks for the heads-up, will do. We're gonna set erc-1620 in stone soon and, when I make the PR for it, I'll make one for erc-2212 too.

[PaulRBerg]

As per the latest discussions in #2444, I'm going to close this discussion about ERC-2212.

There are two main reasons for this:

• The lack of a bespoke interface/ ERC for cTokens
• Me not having enough time to maintain, improve and promote this ERC