[Development] Staking and Delegate Mechanism - Blockful

[Novak]

Introduction and acknowledgments

We are thrilled to announce that Blockful has been selected to build the Staking and Delegate mechanism for Shutter DAO. We are grateful for the support and confidence shown by the Shutter DAO community in the recent voting proposal. Our team is eager to embark on this exciting project and contribute to the growth and success of Shutter DAO. Thank you for your trust and support!

We’ll use this thread as a public report for the DAO. Here, any member can give us an opinion, raise questions about our roadmap and achievements and stay up-to-date with the milestones and advancements of the project.

We are building in Public.

Project Management

Agile

We are using Agile to manage our product backlog with Sprints of 1 week each, the schedule we have right now is as follows:

• Planning - 1 hour on Monday
• Daily - 30 minutes on Wednesday
• Retro/Review - 1 hour on Friday

It can be changed anytime by the team, if necessary.

New Project Manager

We are putting Zeugh as the main PM of this project, he will be responsible for managing the sprints, information and main point of communication with the Shutter DAO Community for this project.

PS: I’ll keep here contributing to ShutterDAO as needed .

@zeugh - PM and partner on Blockful

Worked on several open-source projects, as JuiceBox, and Structured DAOs along the ecosystem.

Zeugh’s Twitter

Zeugh’s Warpcast

Telegram: @zeugh

Links to keep updated

We build in public, as our ethos is to keep all the development processes open to anyone who checks the progress and contributes to active development, below is the GitHub and repository of the development being made:

• GitHub Projects (Kanban): Shutter - Staking/Delegate · GitHub
• Repository: blockful-io/shutter-staking · GitHub

Roadmap

And here is our Roadmap in a table view and Gantt chart view.

We saw an improvement we could do to delivering the front-end fast and spread the milestones more equally on amount of weeks for each task.

This changed a little the disbursement from the proposal we did here. We propose a disbursement of 3 milestones, where we receive the main part on the final delivery, as follows.

Table View:

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

Gantt Chart:

We’ll ask the ShutterDAO to consider this new roadmap arrangement.

1st Milestone

Below is our 1st milestone where we’ll be working on the Design, Front-end and Staking Smart Contract on those weeks.

Table view:

Feature	Time to Develop	Milestones	SHU Disbursement	USDC Disbursement
i) Design	1 week
vi) Front-end	3 weeks
ii) Staking contract (L1 and L2)	3 weeks
iv) Testnets deployment and tests	1 week	Milestone 1	15000	10000

Gantt Chart view:

Again, we appreciate all the work of the Shutter DAO community and we’re very excited to make this happen.

Any questions let us know!

[zeugh]

Thank you @Novak for the informative post above and all the work done here so far, and thank you all voters for your trust in Blockful.

I’ve been in touch with some of you before and will use this thread to keep that contact going as we update our advances towards the milestones.

Feel free to reach out too if there’re any specifics of the project that are not clear or that you want to discuss further.

[zeugh]

Bringing a few updates on the project.

• Our team is advancing on the expected speed and the roadmap is being achieved as expected.
• We’ve found a few gaps in the scope that influenced the architecture, but already found solutions. Thanks Julian and Luis for the answers and call.
• We are going a bit beyond the agreed scope to make sure a future upgrade to integrate staked tokens to governance is easier to implement
• We’re currently evaluating the Figma prototype with our front-end team
• We’re currently developing the staking contract.

Request: We are interested in all developer feedback on the architecture planned, so feel free to reach me out on TG, comment here, or on our github repo or project.

A short quote from our architecture document to give an overview.

The architecture consists of two contracts:

1. Staking Contract: The main contract where keypers can stake SHU tokens and claim rewards.
2. Rewards Distribution Contract: A contract that distributes rewards to the staking contract.

The contracts are designed to be customizable, with adjustable parameters such as the lock period, minimum stake, and reward emission. Additionally, the contracts uses the Transparent Proxy pattern, where only the DAO has the permission to upgrade the contract and call the owner functions defined below.

Looking forward for any questions, feedback or to bring the next updates to you soon!

[zeugh]

Hey builders of Shutter, new update of the staking development.

Timeline

We are on track with the timeline for final delivery, but have made some changes on the planning of future sprints to better accommodate some changes to the front-end design that came once we had the final architecture in place.

We moved the front-end development forward to have more time to iterate on the design. The new timeline looks like this:

Design

Considering the MVP nature of the project we went back on the plan of a 3 dashboard app to one main screen and eliminated some redundant info to make the UX simpler to navigate.

We are organizing the UI for these goals:

• Stake and Unstake actions in the highlight
• Staking balance and unlocked balance in highlight
• Delegate action attached to Keypers list
• Wallet balance and rewards gained in the second level of priority
• Stakes shown individually, showing amount, delegate/Keyper, unlock date, and status

It is still a work in progress, aiming for final version early next week.

Architecture

We have finished architecture work for the Keyper stake contracts and are working on unit and integration tests for them.

It’d be of great value to have an extra pair of eyes and some feedback on the following documents for the Keyper stake contracts:

1. shutter-staking/README.md at main · blockful-io/shutter-staking · GitHub
2. shutter-staking/docs/staking-architecture.md at main · blockful-io/shutter-staking · GitHub
3. shutter-staking/docs/rewards-distributor.md at main · blockful-io/shutter-staking · GitHub

Tasks

We have updated our Github Project to manage all tasks related to the different Shutter 0x36 DAO + Blockful projects, so now the service provider projects will be in the same dashboard. You can filter by “Staking” to see only the issues related to this project. You can check the board here: Shutter · GitHub

[zeugh]

Hey Shutter Community, it’s my pleasure to bring one more update on our advances in the project:

tl;dr

At this point we have finished:

• the staking contracts
• most of the architecture for the delegate (non-keyper staking) contracts
• the components for the mock front-end

This finishes the Milestone I, with a good part of Milestone II already completed also. We’d like to move forward with creating the proposal for compensation on Milestone I and should have it live in the next few days, after a window for comments here.

Time-line

The current timeline, as posted on previous updates, still stands, and we are almost done with the Delegate Smart Contract development. We have some doubts on architecture decisions, so please read ahead if you can help us define that!

Deliverables Detailing:

Staking Contracts:

The staking contracts - both the Reward Distribution and the Staking - have been tested and deployed on testnet, we’d appreciate all feedback if anyone wants to explore them. We’re still going to have a round of internal audits before the final MVP delivery, as well as an audit by cducrest, but we are open to any feedback before that. The current version is already an upgrade from an initial exploration for optimizations.

We have made some changes to the contracts to fit the 24kb limit enforced by EVM. None of that affects the core usability of the system, but can change the experience and cost of managing those contracts in the long term. We evaluate that is fine for the MVP and still delivering inside the scope, but are adding an upgrade suggestion below for following versions. The changes are as follow:

• Ownable2Step replace for Ownable
  • Basically taking away an extra security layer we’d like to use, but is not necessary as long as the DAO manages the contracts with care.
• Removed a function that could call Unstake and Claim at same time.
  • Both functions are still available as core part of the contract, but will need to be called separately.
  • We’ll work around it on the UX to simplify the user journey, but the transactions will need to be signed individually.
• Removed a function that would “automatically unstake” a keypers mandatory 50k SHU upon removal from keypers list.
  • The forced unstake from the DAO side is still possible, but again, will need to be called separately as 2 transactions on the cases it is needed.
• Remove the setKeypers function, now it is needed to call setKeyper individually to each keyper the DAO wants to add/remove
  • This will not affect the ability to add keypers and the transactions can be bundled with multicall, but the transaction costs will be bigger as they will be individual transactions.

A future upgrade of the project could fit some of those features back if the keypers list was removed from the contract and the system leveraged Hats Protocol to keep track of keypers and their permissions on the contract. This would essentially externalize the Keypers list to a Hats tree and free some contract space for the features. Considering the MVP scope of this project, we’ll be leaving that option as a recommendation for future upgrades.

You can check the contracts at:

Staking

Rewards

You can check the code on github at:

Staking

Rewards

Delegate Contracts:

The delegate contract architecture has been mostly finished, except for some questions we have that are pending confirmation. For an overview, you can check the architecture description on github. The questions we have standing are:

• Should non-keypers also have a minimum lock time of 6 months?
  • We are assuming “yes”, but we would appreciate confirmation.
• Should non-keypers also have a minimum lock amount of 50k SHU?
  • We are assuming “no”, but we would appreciate confirmation.

Delegate contract architecture:

https://github.com/blockful-io/shutter-staking/blob/main/docs/delegate-architecture.md

Front-End:

The necessary components for the MVP have all been created, and you can see their first mock application below and a bit of the usability in the video linked:

https://drive.google.com/file/d/15220CymFx_ALgKiJBRdlNBjoUoxwhEMG/view?usp=sharing

You can check the code at the separate front-end repo (shutter staking dapp): https://github.com/blockful-io/shutter-staking-dapp

The integration of the front-end to the contracts will happen on the end of the second milestone, and we are working in making this component library easy to work with, so any future development on top of this MVP can be easier to execute.

Feedback and Comments

For now that’s the updates we have, we’d love to have some feedback from you and confirm the answer for the questions on Delegate Contracts section.

[zeugh]

New update time: We have finished Milestone II and are on the way to finishing deliveries in time for the August 20th timeline!

We have deployed the Delegate Staking contract on Sepolia, which you can also check on our github.

With that, we’ve started internal audits, and should have everything ready for the external audits to begin as soon as we’re done with it!

Looking forward to bring you our final updates next week!

[zeugh]

Milestones 3 delivery, aka “it’s alive!”

Happy to announce that we are done with the development of the staking and delegate mechanism.

Contract development:

Since the last update - delivery of milestone 2 - we have finished our internal audit, and after a few adaptations for gas optimization, we have our final version of the contracts ready for the external audit!

The commit to be used for reference is this one.

The latest testnet deploy is defined on the Constant.sol file

Front-end:

We have finished the main structure of the front-end, but as discussed in a recent call with @jul1an @luis and @AnthonyCaravello there are some needs to make the interface available for members for which the delivery will go beyond the initial scope of this project. Mainly the hosting of the front-end which was rejected as part of the initial proposal. Those new scope needs have been defined and will be coming in a proposal later today.

The current development is available on github and covers most of the requirements of the original proposal scope, but the contract size limitations of the EVM brought a new need for an indexer of the keyper’s authorized by the DAO and the need of that indexer adds the need of a backend to support it.

The hosting of the current proposed front-end, the next indexer development scope and the hosting of it’s backend support are all included in the new proposal which we are finalizing reviews and will edit here soon.

Next steps:

The new scope proposal will be on the forum soon, and depending on the speed of it’s approval the whole structure can be available as soon as the 3rd of September.

We’ll leave this update up for review and commenting before moving forward to a proposal for compensation, but given the completion of the internal audit, this is a green sign from our side for the work on the external audit to start.

[zeugh]

The contracts have been deployed to ETH Mainnet.

We are finishing the adjusts on the interface from testnet to mainnet and will bring the official link and the proposal transaction to fill and start them over the next few days.

RewardsDistributor - RewardsDistributor | Address 0xfad7db6b2ebe2cb586dd08dc6a9d07d4a0fbef49 | Etherscan

Staking - Staking | Address 0xe48858d552b77cc953b79d0c162ecfabd7244b50 | Etherscan

TransparentUpgradeableProxy - TransparentUpgradeableProxy | Address 0xc643fd3107799d5eef411e936323a3975bc105aa | Etherscan

ProxyAdmin - ProxyAdmin | Address 0x02aceedc8da5145e2f7d9e1614b533300df844d9 | Etherscan

DelegateStaking - DelegateStaking | Address 0x48adfe2bb4813831f5a3ac5300e57c8a931c556c | Etherscan

TransparentUpgradeableProxy - TransparentUpgradeableProxy | Address 0xf0dd9e28577d7ef943d574af35f1aa1c0d6446a7 | Etherscan

ProxyAdmin - ProxyAdmin | Address 0x164dbadbecac8d7986677d410c0f225d2721a08d | Etherscan

For the proposal to fill the contracts, we are still pending the decision of the emission rate for each contract, I’ll explain a bit:

There are 2 staking contracts, one for keypers and one for non-keypers.

There’s 1 Distributor contract.

We need to register the Keypers on the correct contract, fill the system with SHU and set the SHU/second of each contract.

The contract to be filled with SHU is the Distributor. The Distributor also needs to be configured with how many SHU/second it will be giving as rewards for each of the the staking contracts.

I’ll have the transactions built and presented to the DAO soon.