Foundry is a blazing fast, portable and modular toolkit for Ethereum application development written in Rust.

Overview

foundry

Github Actions Telegram Chat Crates.io

Foundry is a blazing fast, portable and modular toolkit for Ethereum application development written in Rust.

Foundry consists of:

  • Forge: Ethereum testing framework (like Truffle, Hardhat and Dapptools).
  • Cast: Swiss army knife for interacting with EVM smart contracts, sending transactions and getting chain data.

demo

Forge

cargo install --git https://github.com/gakonst/foundry --bin forge --locked

If you are on a x86/x86_64 Unix machine, you can also use --features=solc-asm to enable Sha2 Assembly instructions, which further speedup the compilation pipeline cache.

We also recommend using forgeup for managing various versions of Forge, so that you can easily test out bleeding edge changes in open pull requests or forks from contributors.

More documentation can be found in the forge package and in the CLI README.

Features

  1. Fast & flexible compilation pipeline:
    1. Automatic Solidity compiler version detection & installation (under ~/.svm)
    2. Incremental compilation & caching: Only changed files are re-compiled
    3. Parallel compilation
    4. Non-standard directory structures support (e.g. can build Hardhat repos)
  2. Tests are written in Solidity (like in DappTools)
  3. Fast fuzz Tests with shrinking of inputs & printing of counter-examples
  4. Fast remote RPC forking mode leveraging Rust's async infrastructure like tokio
  5. Flexible debug logging:
    1. Dapptools-style, using DsTest's emitted logs
    2. Hardhat-style, using the popular console.sol contract
  6. Portable (5-10MB) & easy to install statically linked binary without requiring Nix or any other package manager
  7. Abstracted over EVM implementations (currently supported: Sputnik, EvmOdin)

How Fast?

Forge is quite fast at both compiling (leveraging the ethers-solc package) and testing.

Some benchmarks below:

Project Forge DappTools Speedup
guni-lev 28.6s 2m36s 5.45x
solmate 6s 46s 7.66x
geb 11s 40s 3.63x
vaults 1.4s 5.5s 3.9x

It also works with "non-standard" directory structures (i.e. contracts not in src/, libraries not in lib/). When tested with openzeppelin-contracts, Hardhat compilation took 15.244s, whereas Forge took 9.449 (~4s cached)

Cast

Cast is a swiss army knife for interacting with Ethereum applications from the command line.

">
cargo install --git https://github.com/gakonst/foundry --bin cast
// Get USDC's total supply
cast call 0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48 "totalSupply()(uint256)" --rpc-url <..your node url>

More documentation can be found in the cast package.

Contributing

Directory structure

This repository contains several Rust crates:

  • forge: Library for building and testing a Solidity repository.
  • cast: Library for interacting with a live Ethereum JSON-RPC compatible node, or for parsing data.
  • cli: Command line interfaces to cast and forge.
  • evm-adapters: Unified layer of abstraction over multiple EVM types. Currently supported EVMs: Sputnik, Evmodin.
  • utils: Utilities for parsing ABI data, will eventually be upstreamed to ethers-rs.

Rust Toolchain

We use the stable Rust toolchain. Install by running: curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh.

Minimum Supported Rust Version

The current minimum supported Rust version is rustc 1.54.0 (a178d0322 2021-07-26).

Testing

cargo check
cargo test
cargo doc --open

Formatting

We use the nightly toolchain for formatting and linting.

cargo +nightly fmt
cargo +nightly clippy --all-features -- -D warnings

Getting Help

First, see if the answer to your question can be found in the API documentation. If the answer is not there, try opening an issue with the question.

Join the foundry telegram to chat with the community!

Acknowledgements

  • Foundry is a clean-room rewrite of the testing framework dapptools. None of this would have been possible without the DappHub team's work over the years.
  • Matthias Seitz: Created ethers-solc which is the backbone of our compilation pipeline, as well as countless contributions to ethers, in particular the abigen macros.
  • Rohit Narurkar: Created the Rust Solidity version manager svm-rs which we use to auto-detect and manage multiple Solidity versions.
  • Brock Elmore: For extending the VM's cheatcodes and implementing structured call tracing, a critical feature for debugging smart contract calls.
  • All the other contributors to the ethers-rs & foundry repositories and chatrooms.
Comments
  • forge fails with `GLIBC_2.33' not found (required by forge) in github action CI

    forge fails with `GLIBC_2.33' not found (required by forge) in github action CI

    Component

    Forge

    Have you ensured that all of these are up to date?

    • [X] Foundry
    • [ ] Foundryup

    What version of Foundry are you on?

    nightly-2e99f7fdaef6a7aaeb426b02ef87e052cc14f68b

    What command(s) is the bug in?

    No response

    Operating System

    Linux

    Describe the bug

    We use the foundry-toolchain github action in our CI and it started failing in the last few hours with failures like this:

    forge: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by forge)
    forge: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by forge)
    forge: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by forge)
    

    Is there a problem with the nightly release?

    I didn't include the proper forge --version string, because forge can't even run that in our CI. It started failing after the latest release:

    • latest release broken: https://github.com/foundry-rs/foundry/releases/tag/nightly-2e99f7fdaef6a7aaeb426b02ef87e052cc14f68b
    • previous one is fine: https://github.com/foundry-rs/foundry/tree/nightly-f6361e6ddb6af62bbf6e122d0d8b27d2f5f6b42d
    T-bug A-releases 
    opened by KholdStare 51
  • Lazily iterate over tests instead of collecting

    Lazily iterate over tests instead of collecting

    Instead of collecting here and here, it’d be nice if we could have an iterator which we can stream over

    That'd allow us to then iterate in parallel here for nicer UX & speed

    good first issue 
    opened by gakonst 39
  • feat(forge): Better deployment

    feat(forge): Better deployment

    Add the ability for forge to use a solidity file to create a contract on mainnet and arbitrary deploy scripts by adding a cheatcode. You could do something like:

    contract t {
        function deployMyContract() {
            uint256 input1 = dep.someFunc();
            vm.mainnetDeploy();
            MyContract t = new MyContract(input1);
        }
    }
    T-feature C-forge D-hard 
    opened by brockelmore 38
  • feat: support environment variables in `foundry.toml`

    feat: support environment variables in `foundry.toml`

    Component

    Forge

    Describe the feature you would like

    A common use case is configuring test params with environment variables, with the RPC URL used for forking tests being a popular example. Right now there is now way to specify in the config file to use a certain environment variable for fork URLs, and instead you'd have to pass this in to the test command, e.g. forge test --fork-url $MY_RPC_URL

    Additional context

    No response

    T-feature C-forge P-low 
    opened by mds1 32
  • feat: fmt config

    feat: fmt config

    Component

    Forge

    Describe the feature you would like

    The formatter uses a configuration with hardcoded values. The goal is to define the input format for the configuration (i.e. whether the configuration will be defined in a separate file like fmt.toml or it will become a part of foundry config) and, potentially, expand the options.

    Currently, the supported configuration values are:

    • line_length - maximum line length where formatter will try to wrap the line
    • tab_width - number of spaces per indentation level
    • bracket_spacing - print spaces between brackets

    Additional context

    No response

    T-feature C-forge Cmd-forge-fmt 
    opened by rkrasiuk 31
  • Foundry crashes with `arithmetic operation overflow`

    Foundry crashes with `arithmetic operation overflow`

    Component

    Forge

    Have you ensured that all of these are up to date?

    • [X] Foundry
    • [X] Foundryup

    What version of Foundry are you on?

    forge 0.2.0 (70f4fb5 2022-11-02T00:05:06.592613Z)

    What command(s) is the bug in?

    forge test

    Operating System

    Linux

    Describe the bug

    Hello, after updating forge-std dependency foundry started crashing with arithmetic operation overflow error. The issue is occuring locally on my M1 Macbook as well as in a linux docker container in CI. Here is the code and here is the log of a failing CI pipeline.

    Update

    The bug is not related to forge-std (the forge-std update simply made it occur more frequently). The bug is caused by overflow in smart contract execution.

    T-bug Cmd-forge-test C-forge 
    opened by benesjan 29
  • forge build fails with solc 0.6.12

    forge build fails with solc 0.6.12

    Component

    Forge

    Have you ensured that all of these are up to date?

    • [X] Foundry
    • [X] Foundryup

    What version of Foundry are you on?

    forge 0.2.0 (b951f65 2022-03-26T04:46:06.407207863+00:00)

    What command(s) is the bug in?

    forge build

    Operating System

    Linux

    Describe the bug

    When I open a new project but change the solidity version to 0.6.12 forge build fails:

    $ forge init forge-2
    Initializing $PATH/forge-2...
    Installing ds-test in "$PATH/forge-2/lib/ds-test", (url: https://github.com/dapphub/ds-test, tag: None)
        Installed ds-test
        Initialized forge project.
    $ cd forge-2
    $ forge build
    [⠊] Compiling...
    [⠢] Compiling 3 files with 0.8.10
    Compiler run successful
    $ sed -i 's/0.8.10/0.6.12/' src/Contract.sol 
    $ grep pragma src/Contract.sol
    pragma solidity 0.6.12;
    $ forge build
    [⠢] Compiling...
    Error: 
       0: Solc Error: 
    
    Location:
       cli/src/cmd/utils.rs:40
    
    Backtrace omitted.
    Run with RUST_BACKTRACE=1 environment variable to display it.
    Run with RUST_BACKTRACE=full to include source snippets.
    $ forge --version
    forge 0.2.0 (b951f65 2022-03-26T04:46:06.407207863+00:00)
    
    T-bug C-forge P-high Cmd-forge-build 
    opened by lithp 27
  • Anvil seems to hang/crash when submitting transactions through Metamask on a forked network.

    Anvil seems to hang/crash when submitting transactions through Metamask on a forked network.

    Component

    Anvil

    Have you ensured that all of these are up to date?

    • [X] Foundry
    • [X] Foundryup

    What version of Foundry are you on?

    forge 0.2.0 (dc83894 2022-06-11T00:06:34.928765727Z)

    What command(s) is the bug in?

    anvil

    Operating System

    Linux

    Describe the bug

    I'm trying to test submitting transactions through Metamask connected to anvil (localhost:8545).

    This is the example anvil command I'm running:

    anvil --fork-url="https://eth-mainnet.alchemyapi.io/v2/XXXXXXXXXXXXXXXXXXXXXXXXX" --fork-block-number=14812197 --port=8545 -b=5 --chain-id=1

    Example steps I've done to reproduce:

    1. I fork a specific block, set the block time to be a certain interval
    2. Launch opensea.io and sign in with one of my wallets that has an NFT
    3. List the item and in the process, calling setApprovalForAll on the NFT
    4. Notice that the transaction never goes through and anvil just freezes up (No blocks are getting produced anymore every 5s, it just seems to completely freeze and hang)
    T-bug C-anvil 
    opened by sunwrobert 26
  • feat(forge): Invariant Testing v2

    feat(forge): Invariant Testing v2

    Alright, opening for review since it's growing too much. Let's iterate from here.

    Summary:

    1. Functions should start with invariant. eg: invariant_neverFalse()
    2. Invariants have the following parameters on the config file
        /// The number of runs that must execute for each invariant test group.
        pub invariant_runs: u32,
        /// The number of calls executed to attempt to break invariants in one run.
        pub invariant_depth: u32,
        /// Fails the invariant fuzzing if a reversion occurs
        pub invariant_fail_on_revert: bool,
        /// Allows randomly overriding an external call when running invariant tests
        pub invariant_call_override: bool,
    
    1. An invariant with depth of 15 and 256 invariant_runs will have a total of 3840 calls (excluding the invariant checks), if everything succeeds.
    2. We currently fuzz the sender_address, target_address and calldata. 3.1 This data is generated by different proptest::TestRunner. 3.2 The data is influenced by a dictionary that is filled with new values throughout the runs.
    3. Invariants are checked right after setUp() and before anything is called.
    4. After each call we: 4.1 Collect stack/memory data to add to the fuzzing dictionary. 4.2 Collect newly created contracts and add them as potential target_address. 4.3 Make calls to the test contract invariant* functions. If any fails, we exit the run. 4.4 If all invariants have been broken, then exit asap.

    Filtering

    To better bound the test space there are certain filters that can be used:

    • targetContracts(): address[]: a contract address will be chosen from this list.
    • targetSenders(): address[]: 80% chance that a contract address will be chosen from this list.
    • targetSelectors(): (address, bytes4[])[]: adds to targetContracts list, and only the selectors provided will be called.
    • excludeContracts(): address[]: contract addresses from the setup process which are to be excluded from being targeted.

    Unsafe/External call overriding

    invariant_call_override allows for an external call to be overridden to simulate unsafe calls. This feature is false by default, since it requires some work, although it's already functional. (eg. testdata/fuzz/invariant/InvariantReentrancy.t.sol). More: https://github.com/foundry-rs/foundry/pull/1572#issuecomment-1186479575

    Examples

    testdata/fuzz/invariant/
    ├── InvariantInnerContract.t.sol
    ├── InvariantReentrancy.t.sol
    ├── InvariantTest1.t.sol
    └── target
        ├── ExcludeContracts.t.sol
        ├── TargetContracts.t.sol
        ├── TargetSelectors.t.sol
        └── TargetSenders.t.sol
    
    1 directory, 7 files
    

    Follow-up (in no particular order)

    • [ ] Improve report (https://github.com/foundry-rs/foundry/pull/1572#issuecomment-1191969303, https://github.com/foundry-rs/foundry/pull/1572#issuecomment-1193141900)
    • [ ] Export failures in a friendly format.
    • [ ] Replay (https://github.com/foundry-rs/foundry/issues/991#issuecomment-1107533935)
    • [x] Filter by artifact name. (giving priority here)
    • [ ] Proxy Support
    • [ ] Improve Call override report (current trace/report is a bit misleading)
    • [ ] Time based (just set up a real big invariant_runs for now...)
      • [ ] Parallelize runs if time is infinity
    • [x] Shrinking
    • [ ] Save >1 cases per broken invariant.
    • [ ] User defined weights (https://github.com/foundry-rs/foundry/pull/1572#discussion_r934075997)
    • [ ] Rename fuzz_seed to rng_seed
    old summary However, since the repo diverged quite a bit from the `sputnik` times, I wanted to get some potential feedback, since I'm still getting acquainted with the fuzzing modules, and I'm probably missing some things and/or design choices.

    Missing

    • [ ] forgetest!()
    • [ ] clean-up
    • [ ] ...

    Summary

    • [x] invariant_depth
    • [x] targetContracts(). if not found, then just fuzz every contract created at setUp
    • [x] targetSenders(). if not found, then just fuzz the sender
    • [x] excludeContracts()
    • [x] targetSelectors()
    • [x] invariant_fail_on_revert
    • [x] identify created contracts and fuzz them too

    Future/Now?

    • random msg.value

    ref #849

    T-feature 
    opened by joshieDo 26
  • Dynamic linking not supported in `create` command

    Dynamic linking not supported in `create` command

    Component

    Forge

    Have you ensured that all of these are up to date?

    • [X] Foundry
    • [X] Foundryup

    What version of Foundry are you on?

    forge 0.2.0 (a84a281 2022-04-16T00:15:54.385011+00:00)

    What command(s) is the bug in?

    forge create

    Operating System

    macOS (M1)

    Describe the bug

    Still getting a Dynamic linking not supported in create command error after changing foundry.toml when deploying to a testnet.

    First ran forge create Library which works fine.

    Got the address from that then add the following line to foundry.toml

    libraries= ['./src/lib/LibraryContract.sol:Library:0xaddress']

    I've also tried adding the contract that imports the library:

    libraries= ['./src/Contract.sol:Library:0xaddress']

    T-bug C-forge Cmd-forge-create 
    opened by evmcheb 26
  • Verifying contracts on optimsm doesn't work on Optimism

    Verifying contracts on optimsm doesn't work on Optimism

    Component

    Forge

    Have you ensured that all of these are up to date?

    • [ ] Foundry
    • [X] Foundryup

    What version of Foundry are you on?

    forge 0.2.0 (6130af7 2022-04-06T00:04:11.858449+00:00)

    What command(s) is the bug in?

    forge verify-contract

    Operating System

    macOS (M1)

    Describe the bug

    Trying to verify an optimism contract with:

    forge verify-contract --chain-id 69 --num-of-optimizations 1000000 --constructor-args < abi-encoded-args > --compiler-version v0.8.13+commit.abaa5c0e < contract-address > < path:contract > < etherscan-key >

    does not work. When verifying the verification I get the message below which is not very telling. Not sure what could be wrong, followed the docs very closely.

    Error: 0: Contract verification failed: Response: NOTOK Details: Fail - Unable to verify

    T-bug C-forge Cmd-forge-verify 
    opened by FredCoen 25
  • Feat: Reduce Build Time by 2/3 for Darwin aarch64/x86

    Feat: Reduce Build Time by 2/3 for Darwin aarch64/x86

    Component

    Other (please describe)

    Describe the feature you would like

    Upgrade XCode SDK and use latest linker for perf.

    compile take long. foundry too many thingys. make go faster. use latest lld linker, much improve

    Background

    Currently foundry is building against XCode 12.3 SDK (released on 26 Jan 2021) for providing macOS binaries for both x86 and aarch64. This is the last version of XCode that provides support for macOS 10.15.4+.

    With Xcode 14.2 released a few weeks ago aarch64 (m1/m2) users can enjoy stupid fast builds thanks to the massive upgrades Apple has done to the long neglected ld64.lld linker

    See Apples wwdc2022 presentation on the changes made for the linker and an additional presentation specific to runtime info on ld64 linker updates with XCode 14

    Proposed Solution

    Add an ADDITIONAL build for aarch64 users or provide a link for those users to grab it I am building them for my own usage as the benefit is worth it.

    • additional binary using an upgrade XCode 14 SDK and l64.lld linker
    • consider deprecating support for anything below macOS 11
    • construct benchmarks for both CI build time and user usage

    For XCode >14 use ld64.lld with fixes

    Building with ld64.lld

    gh repo clone foundry-rs/foundry && cd foundry
    wget https://github.com/keith/ld64.lld/releases/download/12-22-22/ld64.tar.gz 
    tar -xf ld64.tar.gz 
    RUSTFLAGS="-Clink-arg=-fuse-ld=$PWD/ld64.lld" cargo build --release --bins --target aarch64-apple-darwin
    

    Speed Improvements

    We can see the build time for the entire repo is 13m 21s

    Build times using default configuration was just under 12m 58s on my local machine

    Build times using the additional linker and XCode 14 resulted in a build time of 4m 51s.

    usr@foundry:~$  Finished release [optimized] target(s) in 4m 51s
    

    References

    Additional context

    I can literally recompile foundry 3 times over while u still be compiling, we are not the same (arch)

    T-feature 
    opened by sambacha 0
  • Behavior when importing files with wrong capitalization is confusing across OSes

    Behavior when importing files with wrong capitalization is confusing across OSes

    Component

    Forge

    Have you ensured that all of these are up to date?

    • [X] Foundry
    • [X] Foundryup

    What version of Foundry are you on?

    forge 0.2.0 (848bb44 2022-12-28T00:13:43.163127Z)

    What command(s) is the bug in?

    forge build

    Operating System

    Linux

    Describe the bug

    On OSX, forge does not seem to care too much about the capitalization of import file names. For example this:

    import "forge-std/test.sol";
    

    Works perfectly fine on a Mac even tho it should be Test.sol, while in CI it will yield this message:

    Run forge build --sizes
    Error: 
    Failed to resolve file: "/home/runner/work/athena/athena/lib/forge-std/src/test.sol": No such file or directory (os error 2).
        --> "/home/runner/work/athena/athena/test/Athena.t.sol"
            "forge-std/test.sol"
        Check configured remappings.
    

    This error message had me pretty confused for a while (it's only off by 2 characters), esp since it worked on Mac.

    The error message isn't necessarily at fault, but this whole flow was a little confusing to debug for multiple reasons. I'd argue it's a small footgun that it wouldn't hurt to mitigate somehow, maybe by:

    • Ensuring foundry is case insensitive on linux or
    • Ensuring foundry is case sensitive on OSX

    and/or

    • Augmenting this error message to note if there's a similar file with different caps
    T-bug 
    opened by transmissions11 0
  • rerun only failing tests

    rerun only failing tests

    Component

    Forge

    Describe the feature you would like

    As title, would be useful to have a mode to rerun all the failing tests.

    Additional context

    No response

    T-feature 
    opened by ssadler 0
  • Forge get geth style trace of test case

    Forge get geth style trace of test case

    Component

    Forge

    Describe the feature you would like

    As title, it would be useful in Forge to be able to get a debug_traceTransaction style trace for a test case, in case you want to look at the exact storage ops or something.

    Additional context

    No response

    T-feature 
    opened by ssadler 0
  • Test case failure should report first error (not last)

    Test case failure should report first error (not last)

    Component

    Forge

    Describe the feature you would like

    If you have a failing test case, and there are many errors, the first error is probably more indicative of where to start debugging rather than the last. Currently it reports the last, which can be a bit misleading.

    Additional context

    No response

    T-feature 
    opened by ssadler 0
Releases(nightly-a44159a5c23d2699d3a390e6d4889b89a0e5a5e0)
Owner
Georgios Konstantopoulos
cto & research partner at paradigm.xyz. mev, layer 2, proof of stake, zkps. we're hiring engineers internally & for the portfolio: georgios at paradigm dot xyz
Georgios Konstantopoulos
Blazing fast toolkit for developing Starknet contracts.

Starknet Foundry Blazingly fast toolkit for developing Starknet contracts designed & developed by ex Protostar team from Software Mansion based on nat

Foundry 149 Aug 1, 2023
A low-level assembly language for the Ethereum Virtual Machine built in blazing-fast pure rust.

huff-rs • huff-rs is a Huff compiler built in rust. What is a Huff? Huff is a low-level programming language designed for developing highly optimized

Huff 276 Dec 31, 2022
Heimdall is an advanced Ethereum smart contract toolkit for forensic and heuristic analysis.

Heimdall is an advanced EVM toolkit which aims to make dealing with smart contracts on EVM based chains easier. Installation & Usage Heimdall's update

Jonathan Becker 489 Jan 2, 2023
Ethereum (and Ethereum like) indexer using P2P message to fetch blocks and transactions

Ethereum P2P indexer This project is an indexer for Ethereum and Ethereum forks. It takes advantage of the ETH (Ethereum Wire Protocol) to fetch block

null 5 Nov 10, 2023
Open sourcing a profitable MEV Arbitrage Bot written in blazing fast Rust.

Dex Arbitrage - MEV Bot Open sourcing a profitable MEV Arbitrage Bot written in blazing fast Rust. Before Starting I am a self-taught programmer, a co

null 4 Sep 18, 2023
A secure development tool box and fintech application made with Rust to be used for developing cryptocurrencies on the blockchain.

Crypto Fintech Tools for Rust (CFT) Dependencies Rust MacOS Homebrew # xcode cli tools xcode-select --install # install dependencies using Homebrew b

Phil Hills 1 Apr 15, 2022
Unified directories for different use cases of an application, providing standard directories for local development, when run as service or when run by a user.

UniDirs Unified directories for different use cases of an application, providing standard directories for local development, when run as service or wh

Dominik Nakamura 3 Sep 30, 2022
A blazing fast, type-safe template engine for Rust.

markup.rs A blazing fast, type-safe template engine for Rust. markup.rs is a template engine for Rust powered by procedural macros which parses the te

Utkarsh Kukreti 209 Dec 24, 2022
🥷🩸 Madara is a ⚡ blazing fast ⚡ Starknet sequencer, based on substrate, powered by Rust 🦀

Report a Bug - Request a Feature - Ask a Question ⚡ Madara: Starknet Sequencer on Substrate ?? Welcome to Madara, a blazing fast ⚡ Starknet sequencer

Keep StarkNet Strange 138 Apr 22, 2023
Blazing fast Pedersen hash implementation for Node.JS

pedersen-fast Blazing fast Pedersen hash implementation for Node.JS Exposes starknet-crypto's implementation written in Rust as WASM package. Usage np

L2BEAT 7 Mar 10, 2023
A modern, portable, easy to use crypto library.

Sodium is a new, easy-to-use software library for encryption, decryption, signatures, password hashing and more. It is a portable, cross-compilable, i

Frank Denis 10.7k Jan 3, 2023
The fast, light, and robust client for the Ethereum mainnet.

OpenEthereum Fast and feature-rich multi-network Ethereum client. » Download the latest release « Table of Contents Description Technical Overview Bui

OpenEthereum 1.6k Dec 28, 2022
The fast, light, and robust client for Ethereum-like networks.

The Fastest and most Advanced Ethereum Client. » Download the latest release « Table of Contents Description Technical Overview Building 3.1 Building

OpenEthereum 6.7k Dec 24, 2022
A small and modular media manager

Bookshelf - a small and modular media manager Bookshelf is made for managing media, mainly books. Modules are to be made by the user (or stolen from t

Chocolate Overflow 33 Jul 21, 2022
An implementation of the paper "Honey Badger of BFT Protocols" in Rust. This is a modular library of consensus.

Honey Badger Byzantine Fault Tolerant (BFT) consensus algorithm Welcome to a Rust library of the Honey Badger Byzantine Fault Tolerant (BFT) consensus

null 335 Dec 25, 2022
Highly modular & configurable hash & crypto library

Octavo Highly modular & configurable hash & crypto library written in pure Rust. Installation [dependencies] octavo = { git = "https://github.com/libO

Octavo Developers 139 Dec 29, 2022
Kraken is a Starknet modular decentralized sequencer implementation.

Lambda Starknet Sequencer A Starknet decentralized sequencer implementation. Getting started The objective of this project is to create an L2 decentra

Lambdaclass 10 Jun 25, 2023
dWallet Network, a composable modular signature network is the home of dWallets

Welcome to dWallet Network dWallet Network, a composable modular signature network is the home of dWallets. A dWallet is a noncollusive and massively

dWallet Labs 8 Feb 26, 2024
Next-generation implementation of Ethereum protocol ("client") written in Rust, based on Erigon architecture.

?? Martinez ?? Next-generation implementation of Ethereum protocol ("client") written in Rust, based on Erigon architecture. Why run Martinez? Look at

Arthur·Thomas 23 Jul 3, 2022