Skip to content

Latest commit

 

History

History
124 lines (83 loc) · 4.84 KB

README.md

File metadata and controls

124 lines (83 loc) · 4.84 KB
Raw

curvance contracts

Main dependencies:

  • Rust: foundry compiler
    • Confirm you have rust with rustc --version
  • Foundry: compile and run the smart contracts on a local development network
    • Confirm you have Foundry with forge -V
  • Solhint: linter
    • Confirm you have the solidity plugin by Juan Blanco in VSCode -- Search settings in VSCode for Solidity: Linter, should be set to solhint
  • Prettier Plugin Solidity: code formatter
    • Confirm you have the solidity plugin by Juan Blanco in VSCode -- Search settings in VSCode for Solidity: Formatter, should be set to prettier

Code Disclaimer

While this code is now open source we highly recommend that viewers do not deploy this code on mainnet as it is actively being developed with multiple code refactors being done over the next few weeks, in parallel with audits. A finalized version of Curvance will be fully open sourced when it is "production ready".

Setup

  1. Copy .env.sample and fill it out with your own information
  2. Ensure you have forge installed, A guide can be found here
  3. Happy building, all dependencies are gitmodule linked & remapping can be found in remappings.txt which should be picked up automatically

Internal code guidelines

Smart contract order

  1. Types at the top of the contract
  2. Constants
  3. Storage
  4. Events
  5. Errors
  6. Constructor
  7. External
  8. Public
  9. Internal
  10. Private as the end of the contract

A/B state variables

Instead of booleans, we use 0, 1, 2 (0 for false, 1/2 for true) in hotpath areas to minimize runtime gas costs such as our Reentryguard implementation.

Precompiled selectors

In instances of 3 or more calls to a specific custom error, uint256 selectors are pre calculated and stored as documented constants with direct reversion to minimize runtime gas costs, while also decreasing smart contract size.

Permissioned function validation

Rather than modifiers we utilize internal functions with direct action control checks as we'd prefer an extra JUMP call than having to inline many instances of permissioning checks, this is to decrease smart contract size.

For adding new risk to the system (e.g. adding a new asset), elevated permissioning is required, while removing risk from the system (pausing a market function) has standard dao permissioning.

Linting

  • Prettier is set to have printWidth of 79 however comments sometimes do not take this, but are enforced in code review. Please ensure your commented lines do not exceed 79 characters.

Foundry tips

Build & compile

Compile all contracts

forge build

Run tests

Compile all smart contracts & run all tests in /tests

  • To run a specific test use --match-contract
  • For more details like console logs add -vv
forge test

Check coverage

Compile all smart contracts and check test coverage

forge coverage

Execute script

Execute a specific script using forge

forge script script/<something>.s.sol

Code Reviews

Reviews are a very important part of our development process. Two approvals are required to merge a pull request.

For certain topics, that come up several times during review discussions, this document is the source of truth if it covers the topic (e.g. best practices in Solidity).

If you think something needs to be changed in the code, please require changes. Often times reviewers just mention something they feel should maybe look different, but they approve anyways. Your input is important, and it is not a bad thing to discuss it with the pull request author before merging.

Assignment

Github will automatically assign 2 developers in round robin manner, counted against to how many pull request reviews they are already assigned to.

Branching strategy

For now we are using a simple feature -> develop -> main branching model.

Steps for working on a new feature

  • Branch feature branch off of develop
  • Branch name should be clickupIssueId-branch-name-based-on-task-title
  • Once your branch is ready, open a pull request and set develop as target branch

Release

For now, admins will merge develop with main to keep it up to date.

git checkout develop
git merge main // we prevent conflicts on main, resolve conflicts on develop
git checkout main
git merge development

This process will probably change later on.