HackMDDAO IMPLEMENTATION IN RUST FOR NEAR - PHASE 1
Reminder of Phase 1 - dev environment & team setup
We want to keep the project open and as collaborative as possible. That means that it should be quick and easy for someone to get up to speed and implement a package.
To get there, we need to have a team setup with a good documentation so that anyone can set it up locally and focus on the code, not configuring NEAR or any other part that might be needed to get to work.
The high levels deliverables here are:
- Setup so anyone can write the DAO TDD style similar to what has been done for the Solidity version
- Giving a tutorial / story about how to develop in NEAR for a solidity developer
- Giving feedback about the pain points to work with NEAR, with solutions if possible
- Giving a standard setup for anyone who wants to write smart contracts in NEAR
Approach
From our understanding after discussing with Nate from Mintbase and Matt from near, it seems like we need to setup a Rust project that uses NEAR SDK.
There are already a few examples we can inspire ourselves from but AFAIK none with NEAR simulator ready yet.
So we need to:
- Setup a dev environment with Rust, NEAR SDK using the simulator
- Document each step on how to set it all up (at least OSX, maybe Linux if it makes sense)
- Use a very basic DAO Registry & adapter as the first example
Tasks
Task 1 - setup and document dev environment
Create a repository with a working example of a NEAR project.
The project needs to contain:
- one smart contract
- At least two test suits with unit tests
- Documentation on how to set up your environment locally
- with IDE (Visual Studio Code)
- command line tools
- Documentation on how to test the smart contract and also how to deploy it on testnet (plus any prerequisit to do it)
In order to make the most out of this first phase, we should try to create a smart contract that will be useful for the next steps.
That's why I think that it should be a very simple version of DaoRegistry.
The logic of the smart contract should basically be a multisig
- the deployer of the smart contract should be the owner
- the owner can add or remove members
- each member can send tokens from the DAO
For each feature described here, we should have at least one unit test.
Test for task
David is going to use the documentation to setup the environment locally and see if everything is clear or if we need any fix / clarification in the document. He's also going to check that all the unit tests are executed and run successfully.
Task 2 - Using the simulator for multiple smart contracts
Once the setup is ready and is working well, it is time to use the simulator so we can do something more interesting.
We already have a simple DaoRegistry that works like a multisig.
The idea is to modify it so we can start working with adapters. The focus here is to get comfortable with the simulator so the current approach is simplifed.
- Modify the multisig to also have a registry of adapters (like in solidity)
- the owner can add / remove adapters
- Create a naive onchain voting adapter where the members can vote on a proposal
- Create an onboarding adapter where users create a proposal to join and the current members vote them in or out
- Wirte functional tests for them
- Documentation around the simulator, how does it work, how to set it up etc …
Tasks for NEAR
Now that we have defined the tasks that need to be done for phase 1, we still need to define the collaboration and what is still needed from NEAR to maximize our chances of success here.
NEAR technical support channel
We need to create a simple way of communicating between the people working on those tasks and key people at NEAR.
The goal is to avoid wasting time trying to fix things that more knowledgeable people would fix faster and better.
