Create an Open-Source Library of Audited Smart Contracts

Development
1

I propose creating an open-source library of audited smart contracts on NEAR - provided to the community for free.

Budget: 1 Million $NEAR

Who am I?

I’m Peter, the co-founder of Flux Protocol and one of the first founders to build on NEAR before testnet was live.

As a founder building on any new layer one, you face a chicken and the egg dilemma. Any DeFi lego that you would like to utilize within your product, you probably have to build yourself. At Flux, we open-sourced a flurry of repos which included the first NEAR native AMM optimized for prediction markets, the first indexer to allow frontends to display NEAR state, the first Oracle contracts, worked on the first token standards, and much more.

Why is this important?

In light of the recent Ref Finance Exploit, it’s clear the NEAR community must perform a deeper dive on core NEAR infrastructure like AMMs, Lending, Stablecoins, Oracles, Etc.

For developer adoption to go parabolic, we must invest in creating robust smart contract infrastructure developers can mix and match to create entirely new, innovative products on NEAR.

How should this work?

This DAO should contract RUST engineers that are familiar or built out NEAR core to perform audits of existing smart contracts and even build out missing contracts that would benefit NEAR’s core DeFi ecosystem.

Why not use existing smart contract audit companies?

RUST is a relatively new language when it comes to smart contract development. Many top audit firms have proficiency in Solidity, which means they can quickly identify common bugs and have had years to study and learn/create best practices.

However, NEAR is a new infrastructure – when we contracted a top audit firm to do a security review of our AMM, there were still a dozen critical bugs that we uncovered after receiving the high-level “green light.”

A similar experience happened with the NEAR Rainbow Bridge - NEAR Core engineers identified countless critical bugs after a few audit firms gave their stamp of approval.

NEAR core engineers will do a better job identifying bugs and creating best practices.

What contracts are a priority?

Any existing project building one of these use cases and would like to be the default for this audit must have their code open-source. The goal is not to have customized contracts or logic, just a stable base for developers to start.

Simple AMM

  • REF Finance can become the standard

Lending

  • A Compound Finance or Aave fork built in Rust

Stablecoin

  • A simple Maker Style stable coin with a standard collateralization ratio that utilizes NEAR, USDC, DAI as the underlying assets

NFT marketplace

  • An OpeaSea fork to facilitate simple ERC721 swaps (could be Mintbase or Paras for this audit)

Oracle

  • Flux Protocol can become the standard

Prediction Markets/Derivatives

  • Pulse can become the standard

How should this be displayed?

NEAR should market this library through its official channels and website, fully community-owned and curated. The DAO should vote to decide which new contracts are audited and added to the library. This library can have a documentation page on Gitbook with instructions on utilizing and deploying smart contracts.

How should this receive funding?

Initial funding should come from NEAR Foundation and initial donations from founders and community members.

Proposal:

There are six core DeFi primitives which are vital to replicate a flourishing DeFi Ecosystem on NEAR. Of those six, three already exist and are ready for an audit. For the existing code, I would propose a budget of $125k per project for audits. Projects not yet created on NEAR should receive $100k to seed the project’s development and an additional $125kk to audit the projects after completion.

The proposal will also include an amount to serve as a base foundation to begin auditing new primitives deemed to be beneficial to NEAR, also outside of DeFi.

Budget:

I propose initial funding of 1 million $NEAR to thoroughly audit the initial scope of contracts and provide a sufficient budget for the immediate future.

Future Funding

Projects that receive a free audit are encouraged to donate a portion of their native token (if applicable) to fund future open-source initiatives within the NEAR ecosystem.

If you would like to chat with me directly about this, feel free to send me a message @realpeter on telegram.

20 Likes
2

Thank you for this timely and necessary proposal. Absolutely agree that it is time for NEAR to be installing practices such as this, finetuning the overall ecosystem infra. I think with the security practices projects themselves will be implementing, the work of Proximity Labs, and such an initiative like this, users will be able to have more confidence in NEAR projects, and NEAR projects themselves will have nice safe rails to avoid worst case scenarios. Fully in support, and would love to help out in anyway, though I’m neither a developer nor a moneyman lol

5 Likes
3

I’ve also deployed a DAO for this project on Sputnik V2.

https://v2.sputnik.fund/?transactionHashes=3hG1ZJQn1embGmyV22Jr17PcE4c6HhkbttcxrnkVDFNB#/audit.sputnik-dao.near

2 Likes
4

I would love input from @erik.near, @illia, @kendall-near, and @evgenykuzyakov on this proposal.

5

Such a proposal takes the problem at the root. An analogy would be a company focusing on making its network impenetrable to malicious hackers. Building the most secure network won’t prevent a hack. Keeping the analogy, I think companies should take for granted that they will be hacked one day, and therefore spend more resources downstream. For example, how to make sure the data the hacker has access to is useless / unexploitable.

A forensics tool like Elliptic on NEAR would be a first step. The ability to identify and track any fraudulent or malicious wallet and share this information with on-chain and off-chain partners would make real world interactions close to impossible, ultimately making the risk / reward ratio unattractive for hackers.

Finally, I think we should emphasize the importance of basic software release management best practices. Taking the example of Uniswap, the team is mastering Github Issues. It’s not only about keeping track of tasks, enhancements, and bugs, but rather to make sure everything follows a safe lifecycle before deployment. Release Manager, Product Owner, Quality Manager are (almost) inexistant in the DeFi world. Dark launching and serious testing are also massively underestimated and often not even rewarded by the core teams. Yet, there are basic and extremely powerful phases / tools in any IT project.

1 Like
6

So far limitation has not been money but that availability and skill of the reviewers.
Even for us willing to spend money, we have been waiting for a period of time to get GitHub - near/core-contracts: Core contracts: reference staking pool, lockup, voting, whitelist, multisig. reviewed. It’s especially hard when new versions are keep coming.

I think having better practices around secure releases is for sure important part.
One of the important parts is figuring out how to rollout updates which are fixing other problems. Making sure there is still a rigorous review and testing process involved in that case.

Separately, I have suggested to create a sandbox environment that would prevent major issues via set of invariants maintained: [Discussion] Smart Contract Sandbox.
I think this can lower barriers of trying things when the risks are low. This can also be used for period of time after upgrade to limit potential issues that upgrade have brought.

Meantime, we are definitely looking for more reviewers to bring into the ecosystem.

Question to @peterflux is really who will be sourcing and coordinating reviewers in the proposed DAO? For example, for DeFi currently Proximity Labs already doing this.

Also if you are suggesting that it’s only reviewed by already existing core developers - they are already doing that. @evgenykuzyakov have been doing that for a long time now. And they are paid for that from the company they are working for. Creating extra incentive like this albeit theoretically may sound good, creates extra problems IMO. Also they are not professional reviewers and so resulting reviews are not as structured as one would expect from the audit firm.

So I would really prefer we are able to bring more reviewers into NEAR ecosystem with initiative like this. We have been exploring various ways to do this already.

5 Likes
7

I really like this idea as it will lower the barrier to entry while reducing risk for the entire ecosystem. This is also the goal we have with Cheddar as it is open source. @evgenykuzyakov has already provided one audit, but another one could only help further.

I do agree with @illia that the primary issue is having enough senior engineers trained in Rust. I would think this would be a key goal of this proposal; to recruit senior engineers and bring them into the NEAR Ecosystem. Without that, we will quickly run into bottlenecks with the review process that we have today. I recall that Mozilla downsized their Rust team a while back, have many of these engineers already found homes?

Perhaps a budget should be set for recruiting Rust engineers specifically. This recruitment would not necessarily be to put them in NEAR Core, but for them to join another organization like the one being proposed to support the ecosystem.

3 Likes
8

Actually, thinking about - how about we start Security Review Guild, which will actually hire and train people?

If there is someone who can run this, we can fund to train whitehat hackers and engineers who are interested in Rust and NEAR. And may be have interesting co-review practice sessions and other stuff.

The outcome for them will be to review indeed all these contracts.

We just got 70 people trained in Ukraine in Rust + NEAR. We can bring them up to speed on reviewing via some form of internship program with this Guild. Also having some kind of security experts who have done it on other chains to train will be useful as well.

5 Likes
9

Yes, this is exactly the idea of this DAO – to fund new engineers that are entering the NEAR Ecosystem to create a guild of engineers that are specialized in RUST, rather than moonlighting from Solidity.

I appreciate the work that has been put into the Github Core library, but this is a bit different. The Core Library is focused on more “base operations” like vesting, voting, multisig, etc. Instead, I’m proposing a guild of engineers that are paid to audit existing core DeFi Protocols and also create missing contracts such as lending, stablecoins, etc. that are money legos that are necessary to bootstrap NEAR.

In my opinion, NEAR’s ecosystem is developing at a slow pace and this isn’t caused by a lack of effort, it’s that all builders are creating from scratch.

The goal of this proposal and DAO is to ensure in 9-12 months’ time any new developer entering the NEAR ecosystem has a robust audited set of open-source money legos which can be combined to make products.

Think products like:

  • PoolTogether
  • Alchemix
  • YEARN
  • IDLE
  • etc.

This will not only help to create a healthy developer and project ecosystem, but it will also make users feel safer when interacting with NEAR projects in the future.

2 Likes
10

Yes, this is exactly the idea of this DAO – to fund new engineers that are entering the NEAR Ecosystem to create a guild of engineers that are specialized in RUST, rather than moonlighting from Solidity.

I appreciate the work that has been put into the Github Core library, but this is a bit different. The Core Library is focused on more “base operations” like vesting, voting, multisig, etc. Instead, I’m proposing a guild of engineers that are paid to audit existing core DeFi Protocols and also create missing contracts such as lending, stablecoins, etc. that are money legos that are necessary to bootstrap NEAR.

In my opinion, NEAR’s ecosystem is developing at a slow pace and this isn’t caused by a lack of effort, it’s that all builders are creating from scratch.

The goal of this proposal and DAO is to ensure in 9-12 months’ time any new developer entering the NEAR ecosystem has a robust audited set of open-source money legos which can be combined to make products.

Think products like:

  • PoolTogether
  • Alchemix
  • YEARN
  • IDLE
  • etc.

This will not only help to create a healthy developer and project ecosystem, but it will also make users feel safer when interacting with NEAR projects in the future.

2 Likes
11

After the NEAR Wiki, this one has to be the most important proposal for the overall NEAR ecosystem. Peter, I can confidently speak for everyone in the NEAR community when I say this library will be a cornerstone for future engagement and development on NEAR, as both developers and everday community members would use it as a reference hub. This calls for unanimous support by every participant in our ecosystem. Rolling this proposal out as a medium post will also be a good idea to seek general feedback. Very timely and well thought out, developments like these take care of both the trees and the forest!

1 Like
12

In addition to the underlying contract, in order to promote the Web3.0 process, web components may be required, similar to WordPress. Can bring Web2.0 development experience.

13

I think this is a great idea, a library of such contracts would be invaluable, especially for new entrants in the ecosystem looking to build for Hackathons ect. Just looking at the traffic for docs.openzeppelin.com, for example:
Peak periods were during April, July and August when two Key hackathons were live. This shows that developers (specifically, new developers) rely heavily on these libraries during their first precious moments building on a new platform. This may be because it gives them a sense of ‘security’, that the product they launch contains tried and tested code that will be safe for end users.
Awesome Idea and I will be watching eagerly.

2 Likes
14

Would like to circle back on this. This is definitely important and should contribute to near-sdk-rs standard contracts. I would suggest some architecture design first as well, to figure out what are a more composable components will look like.

Let’s have next set of things to move this forward:

  • Specify who is going to be the “chair” of this DAO. So they can present weekly/bi-weekly updates.
  • Expand the council to at least 3 independent parties, including this chair.
  • For the operation of this DAO, the proposal description should be posted here on gov.near.org. Defining this format will be chair’s job as well.
  • We can then fund it with first 50k $NEAR to start development and quickly expand from there as this DAO shows results.

What do you think @peterflux ?

3 Likes
15