[RFP] Develop a Keyper Incentive Mechanism and (delegated) Staking - Blockful

Shutter DAO DAO Proposals
1

TL;DR

This proposal aims to build a Staking mechanism, a delegate mechanism and a front-end for the end users and keypers of the Shutter delegate and Stake. It outlines the MVP and a V1 for future work.

Introduction

The staking mechanism will play an important role in guaranteeing the Shutter Network’s security and functionality. By enabling SHU staking, the Shutter validators, known as “keypers,” who are responsible for managing the cryptographic keys used in the protocol, will be incentivized and rewarded for their commitment to the network. When a keyper stakes their SHU tokens, they will earn a percentage of the fees generated by the protocol. Meanwhile, SHU holders can also earn rewards by delegating their staking tokens to keypers they trust. This creates more utility for SHU tokens, which can counteract sell pressure and increase the security of the Shutter network by creating a reputation mechanism for keypers.

Objectives

MVP Objectives:

  • Encourage Keyper Participation: Provide an incentive for keypers to participate in the network by staking SHU tokens and showcasing their commitment to the role.
  • Enable Community Support: SHU token holders can delegate their SHU tokens to support specific keypers, enhancing the network’s security and decentralization.
  • Reward Long-Term Commitment: Offer rewards to both keypers and SHU token holders who lock their tokens and support the network over time.
  • Counter Selling-Pressure: Periods with intense selling pressure can be solved with staking and lock periods.

V1 Objectives (to be approved by the Shutter DAO)

  • Layer-2 Governance: Allow users and keypers to vote on-chain by using layer-2 scalability, reducing fees and efficiency
  • Keypers approved by delegated amount: The smart contract will make this process seamless and less manual by approving keypers through delegating and DAO Governance.
  • Voting power by delegated and staked tokens: This allows keypers to increase their voting power on the DAO using their staked and delegated tokens.

Development process

At Blockful, we take security measures very seriously when developing smart contracts. Our team uses industry-leading tools and follows best practices to ensure that our code is flawless and bug-free. In order to achieve this, we are committed to implementing the following approaches across all smart contracts:

  1. During Smart Contract Development:

    1. Unit tests with 100% line coverage and 100% branch coverage, if possible
    2. Fuzzing tests on critical functions like stake and redeem.
    3. Integration tests running on mainnet fork to make sure that the Staking Contract, Delegate Staking Contract, and the SHU ERC20 contract operate seamlessly and bug-free.
    4. Run AST tools analyzers like Slither and Aderyn
    5. Throughout code review

  2. After code frozen

    1. Deploy all the contracts to L1 and L2 testnets and conduct thorough testing
    2. Internal audit

MVP Scope - Technical Specification

Blockful proposes creating two contracts for the MVP and deploying them to L1 and L2. The first contract is the Keyper staking contract, which allows Keypers to stake their SHU tokens and earn rewards. This will give them an opportunity to showcase their commitment to the project. The second contract is the Delegate Contract, which permits SHU holders to delegate their tokens to a Keyper they trust. This contract will also facilitate the community’s involvement in selecting and supporting a Keyper.

Scope

Staking contract

Currently Shutter AddrsSeq contract uses Arrays for store keypers. That makes integrating with the Staking contract really hard as we can’t easily retrieve whether a given address is a keyper or not to create restrictions on the stake function. Therefore, there a two options:

  1. Deploy a new contract that uses mapping instead of arrays (Deploy on both L1 and L2)

  2. Builtin the keyper whitelist functionality directly on the Staking’s contract (L1 and L2).

We recommend going with option two since there have been some conversations in the DAO about enforcing a minimum staking requirement for keypers. By selecting this option, we can easily switch to a new design in the future where to become a keyper, you must stake the minimum SHU threshold decided by the DAO. We could even take community participation to the next level by integrating the Staking Contract with the Delegation Contract and creating a system where becoming a keyper also requires a minimum threshold of delegation tokens.

The staking contracts on L1 and L2 should be identical. The SHU token is assumed to have been deployed on both layers. It is worth noting that the proposal does not include bridging SHU tokens. If the DAO wants, Blockful can propose the development of SHU xERC20 token on Layer 2 in a separate scope.

  1. Contract design:

    • Upgreadeble: The DAO should be able to expand the contract in the future, which can be achieved through upgradeability. This will enable the DAO to develop additional features to the staking contract. For instance, the DAO may choose to make the staking contract compatible with ERC20, thereby creating a secondary market of staked tokens. This would enable staked SHU price discovery on AMMs, transfers, etc. Furthermore, it may also opt to make the staked contract compatible with ERC20Votes, which gives keypers the ability to use staked SHU as a voting power for the DAO. The contract’s upgradeability will ensure that the DAO can evolve and create a healthy ecosystem by implementing these enhancements.
    • Ownable:
      • The contract should inherit Open Zeppelin Ownable2Step
      • Owner should be the DAO multisig at MVP

  2. Immutable parameters:

    • Staking token: this should be the SHU token on both L1 and L2.
    • Lock period: The lock period refers to the minimum duration in seconds that must pass after a keyper stakes before they can withdraw their principal. We believe that this parameter should be immutable to ensure that keypers can trust that their SHU tokens will not be locked for longer than they expect.

  3. The following parameters are controlled by the DAO:

  • Rewards tokens: DAO can set as many rewards tokens as it wants
  • Reward rate per token: DAO can choose the reward to be paid per second to each token.
  • Stake minimum threshold: the minimum amount of SHU that the keyper must stake. This will be set to 0 at MVP time, and the DAO can vote to change this parameter later.
  • Keypers list: The DAO can add or remove keypers from its list, which will restrict the staking function only to those on the list at MVP. The contract can be upgraded in the future to allow anyone to become a keyper as long as they meet the minimum SHU staked and delegated threshold.

  1. Interface

    I) Called only by keypers:

    • stake: only addresses belonging to the keyper mappings are able to stake at MVP

    II) Permissionelees :

    • redeem: allow keyper to redeem staked SHU after the minimum X months and stop earning rewards
    • getAccumulatedRewards: allow keyper to get the amount of rewards they have accumulated until the current block.timestamp
    • collectRewards: allow keypers to collect SHU/ETH (or any other token the DAO decides) rewards accumulated over time
    • isKeyper: utility function that will be called on the Delegate Staking Contract to verify if an address is a keyper or not

    III) Called only by the Owner:

    • configureRewardToken: allow the DAO to configure the rewards token. Accept two parameters:

          1. Emissions per second

    2. The underlying reward token

    • configureRewardsToken: same as above but allows configuring multiple tokens in a single call.

    • updateKeypers: allow the DAO to update the keypers mapping, adding or removing keypers.

Delegate Staking Contract

The Delegate Staking Contract enables SHU holders to delegate their tokens to a trustworthy Keyper and earn a share of the fees generated by the Shutter ecosystem.

The Delegate Staking Contracts on L1 and L2 should be identical. The SHU token is assumed to have been deployed on both layers. It is worth noting that the proposal does not include bridging SHU tokens. If the DAO wants, Blockful can propose the development of SHU xERC20 token on Layer 2 in a separate scope.

  1. Contract design

    • Upgreadeble: The DAO should be able to expand the contract in the future, which can be achieved through upgradeability. This will enable the DAO to develop additional features to the Delegate Staking contract. For instance, the DAO may choose to make the Delegate staking contract compatible with ERC20, thereby creating a secondary market of delegated staked tokens. This would enable delegated staked SHU price discovery on AMMs, transfers, etc. Furthermore, it may also opt to make the staked contract compatible with ERC20Votes, which gives holders or keypers (using the delegated tokens) the ability to use the staked SHU as a voting power for the DAO. The contract’s upgradeability will ensure that the DAO can evolve and create a healthy ecosystem by implementing these enhancements.
    • Ownable:
      • The contract should inherit Open Zeppelin Ownable2Step
      • Owner should be the DAO multisig

  2. Immutable parameters:

    • Staking token: this should be the SHU token on both L1 and L2.

  3. The following parameters are controlled by the DAO:

    • Rewards tokens: DAO can set as many rewards tokens as it wants
    • Reward rate per token: DAO can choose the reward to be paid per second to each token.

  4. Interface

    I) Permissionelees:

    • delegate: It’s possible for anyone to delegate tokens to any keyper they choose. The function will then call the Keyper Staking contract and verify whether the delegated address belongs to a keyper or not.
    • redeemFrom: Users should be able to redeem their delegated staked SHU by entering the desired redemption amount and specifying the keyper they are redeeming from.
    • getAccumulatedRewards: allow users to get the amount of rewards they have accumulated until the current block.timestamp
    • collectRewards: allow users to collect SHU/ETH (or any other token the DAO decides) rewards accumulated over time
    • getDelegatedBalance: get the balance delegated for a given account

    II) Called only by the Owner:

    • configureRewardToken: allow the DAO to configure the rewards token. Accept two parameters:

          1. Emissions per second

    2. The underlying reward token

    • configureRewardsToken: same as above but allows configuring multiple tokens in a single call.

Frontend

Delegate and Stake button. Allow the display of keyper yield and amount of delegated tokens.

Estimation

Feature Time to Develop
i) Staking contract (L1 and L2) 3 weeks
ii) Delegate contract (L1 and L2) 3 weeks
iii) Testnets deployment and tests 2 week
iv) Internal audit 1 week
iv) Front-end 3 weeks
v) Design 1 week

Proposed Team

Ana Julia Bittencourt (Smart Contract Engineer)

Linkedin: https://www.linkedin.com/in/anajuliabit//

GitHub: anajuliabit (Ana ) · GitHub

Alexandre Vieira Souza (Full-stack Engineer)

Linkedin: Alexandre V. - alt.bank | LinkedIn

Github: AlexandreUser (Alexandre Vieira) · GitHub

Gabriel Novak (Project Manager)

Linkedin: https://www.linkedin.com/in/gabriel-novak/

Budget

We propose an additional allocation of 10.000 USDC to develop the staking and delegation contract specifically designed for Layer 2 solutions and an additional budget of 10,000 USDC for auditing the smart contract by an independent auditor.

Thus, the total proposal for MVP is as follows: 50,000 SHU tokens and 35,000 USDC + 10.000 USDC for a Blockful audit with an independent auditor of this MVP.

V1 Scope - Technical Specification and Estimation (To be approved by the DAO)

Although the following scope is not a part of Shutter DAO’s proposal requirements, we at Blockful are committed to ensuring the best possible experience for DAOs. To that end, we propose an improvement to the DAO governance process by expanding the current governance model to a cross-chain model. This would allow users to vote on both L1 and L2 and utilize staked and delegated tokens for voting. By doing so, we can increase stakeholder governance power. Additionally, we aim to automate the DAO process by making the Keyper selection process more streamlined, less manual, and more community-driven. We will use a holders delegation threshold to increase community power and a Keyper staking threshold to reduce the chance of malicious Keyper. By doing this, we can increase the SHU network security.

Scope

Staking contract upgrade

  • Make the Staking contract compatible with Open Zeppelin ERC20Votes.
  • Call Delegate Staking contract and approves staking based on the amount of delegated tokens the keyper has.
  • Keyper can decide whether they wish to distribute rewards among SHU holders who have delegated tokens to them and the amount of rewards they would like to distribute.

Delegate contract upgrade

  • Make the Staking contract compatible with Open Zeppelin ERC20Votes.
  • Remove isKeyper validation and allow delegation to anyone.
  • In addition to the rewards provided by the DAO, individuals who delegate to a keyper will also receive a portion of their rewards.

Cross-chain governance infrastructure

Creates a new governance infrastructure with the following architecture

  • Voting power is the sum of SHU staking tokens, SHU delegate staking tokens, and SHU tokens.
  • The system is designed to operate across both L1 and L2 chains.
  • Proposals can be created on either chain and once a new proposal is created, a cross-chain message is sent to the other chain as well. Voting can take place on both layers, but once the voting period ends, the votes must be emitted from the secondary chain to the one that originates the proposal. They are then tallied, and if the governance threshold is met, the status moves to succeed, and the proposal can be executed on the original chain.
  • Ownership Is transferred from the DAO multisig to the governance contract.

Estimation

Feature Time to Develop
i) Staking contract upgrade 3 weeks
ii) Delegation contract upgrade 3 weeks
iii) Cross-chain governance infrastructure 8 weeks
v) Updates on the Front-end 3 weeks

Budget

The budget for this implementation will come after the implementation of the MVP, as previously shown, Shutter DAO can have an idea of how much will cost the development of the overall application, MVP and V1.

Thus, the total proposal only for the V1 is as follows: 50,000 SHU tokens and 45,000 USDC + 15.000 USDC from a Blockful audit with an independent auditor.

About Blockful

Our expertise lies in crafting blockchain Public Goods solutions and applications for DAOs, offering tailor-made solutions to meet their unique need.

Twitter: https://twitter.com/blockful_io

Linkedin: Blockful | LinkedIn

Website: blockful.io

Github: Blockful · GitHub

Past services:

ENS Official Services Providers (check the proposal).

We received a grant to build and improve ENS:

  • User experience [UX]
  • Developer experience [DX]
  • Platform sustainability [PS]
  • Governance improvements [Gov]

This is a feedback from Avsa (ENS co-founder) about our deliveries and work ethics.

6 Likes
2

The Blockful team does very good work. I’ve been exposed to some of their outputs for over two years. I have nothing but positive things to say about how the founder and his team conduct themselves.

If anyone wants additional details please just ask here in this thread or reach out to me privately. I’d be happy to share specific examples if it’s helpful.

3 Likes
3

@Novak Thank you for sharing this excellent proposal. Could you please provide a few more details on the following points?

  • Upgradeability: If Shutter is going to generate fees and intends to distribute them to stakers, would that be possible with the design you are proposing?
  • Parameters Controlled by the DAO: How flexible is the design in this area? Is it possible to add parameters if necessary?
  • Budget: What is your proposal regarding the disbursement schedule for both options? Perhaps it could be tied to specific deliverables.
  • SHU Disbursement: What vesting schedule are you proposing for the SHU allocation?

Regarding the proposed audit budget, I think this might warrant a separate RFP that the DAO should issue.

1 Like
4

Cool to see this proposal!

Have you thought about how this can be deployed and the front-end hosted for the next couple of months? Could you guys host it? Would that increase the budget needed? Or would the DAO need to do another proposal for this?

1 Like
5
  • Upgradeability: If Shutter is going to generate fees and intends to distribute them to stakers, would that be possible with the design you are proposing?

Totally. At MVP the DAO will need to fund the contract manually though

  • Parameters Controlled by the DAO: How flexible is the design in this area? Is it possible to add parameters if necessary?

Yes, as we are using Upgradeable Pattern, we can add new parameters later if needed

  • Budget: What is your proposal regarding the disbursement schedule for both options? Perhaps it could be tied to specific deliverables.

Milestones with disbursements

Feature Time to Develop SHU USDC
i) Design 1 week 2500 1500
ii) Staking contract (L1 and L2) 3 weeks 5000 4000
iii) Delegate contract (L1 and L2) 3 weeks 5000 4000
iv) Testnets deployment and tests 2 week 12500 8000
v) Internal audit 1 week 5000 2500
vi) Front-end 3 weeks 5000 5000
vii) MVP Delivery 1 week 15000 10000

This would be the ideal disbursement option, where we receive for each milestone we achieve and we receive the biggest disbursements on the most important milestones which are: iv) Testnet deploys; and vii) MVP Delivery. Those Milestones are the cornerstone to the building and proper delivery of the product.

  • SHU Disbursement: What vesting schedule are you proposing for the SHU allocation?

The vesting schedule could be the same as the lock-up period defined by the DAO (if I understood the question correctly).

1 Like
6
  • Have you thought about how this can be deployed and the front-end hosted for the next couple of months? Could you guys host it? Would that increase the budget needed? Or would the DAO need to do another proposal for this?

We can deploy and host the application using Vercel, which is a cloud platform ideal for hosting front-end applications with excellent performance and scalability features.

We can manage the deployment and hosting, including server maintenance and support. The cost of maintaining the server and providing support would be an additional $1,500/month. This fee would cover all the necessary aspects such as uptime guarantees, security updates, and customer support.

  • Regarding the proposed audit budget, I think this might warrant a separate RFP that the DAO should issue.

Ok, no problem at all.

1 Like
7

Regarding the proposed milestones and disbursements: Since each disbursement needs to be triggered through a vote, perhaps it would make sense to focus on 2-3 major milestones?

1 Like
8

Make sense @jul1an !

It could be as follows:

Milestones with disbursements

Feature Time to Develop SHU USDC
i) Design 1 week
ii) Staking contract (L1 and L2) 3 weeks
iii) Delegate contract (L1 and L2) 3 weeks
iv) Testnets deployment and tests 2 week 25000 17500
v) Internal audit 1 week
vi) Front-end 3 weeks
vii) MVP Delivery 1 week 25000 17500

The main milestones are: 1) Smart Contract Delivery and 2) Total application delivery.

2 Likes
9

Thanks, @Novak! Just to avoid any doubt, would option 2 (staking v1) have a similar disbursement schedule?

1 Like
10

Answer the question, yes, could be the same kind of disbursement and with 2 milestones.

But I want to highlight that the V1, was a rough estimate, just for Shutter DAO having a broader knowledge of the future scope, the approximate total amount for a final work instead of a formal commitment from us.

It may change depending on the evolution of the MVP. For the V1, we would rather make a new proposal by the end of the MVP, detailing it and receiving more feedback about the needs of the DAO, which could change the scope itself.

1 Like