npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

@nahmii/contracts-bedrock

v3.2.1

Published

Contracts for Bedrock in Nahmii 3

Downloads

926

Readme

Nahmii Smart Contracts (Bedrock)

This package contains the smart contracts that compose the on-chain component of Nahmii's upcoming Bedrock upgrade. We've tried to maintain 100% backwards compatibility with the existing system while also introducing new useful features. You can find detailed specifications for the contracts contained within this package here.

Contracts Overview

Contracts deployed to the base layer

| Name | Proxy Type | Description | |--------------------------------------------------------------------------------------| ----------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- | | L1CrossDomainMessenger | ResolvedDelegateProxy | High-level interface for sending messages to and receiving messages from Nahmii | | L1StandardBridge | L1ChugSplashProxy | Standardized system for transfering ERC20 tokens to/from Nahmii | | L2OutputOracle | Proxy | Stores commitments to the state of Nahmii which can be used by contracts on L1 to access L2 state | | NahmiiPortal | Proxy | Low-level message passing interface | | NahmiiMintableERC20Factory | Proxy | Deploys standard NahmiiMintableERC20 tokens that are compatible with either StandardBridge | | ProxyAdmin | - | Contract that can upgrade L1 contracts |

Contracts deployed to the derived layer

| Name | Proxy Type | Description | |--------------------------------------------------------------------------------------| ------------------------------------------ | ------------------------------------------------------------------------------------------------ | | GasPriceOracle | Proxy | Stores L2 gas price configuration values | | L1Block | Proxy | Stores L1 block context information (e.g., latest known L1 block hash) | | L2CrossDomainMessenger | Proxy | High-level interface for sending messages to and receiving messages from L1 | | L2StandardBridge | Proxy | Standardized system for transferring ERC20 tokens to/from L1 | | L2ToL1MessagePasser | Proxy | Low-level message passing interface | | SequencerFeeVault | Proxy | Vault for L2 transaction fees | | NahmiiMintableERC20Factory | Proxy | Deploys standard NahmiiMintableERC20 tokens that are compatible with either StandardBridge | | L2ProxyAdmin | - | Contract that can upgrade L2 contracts when sent a transaction from L1 |

Legacy and deprecated contracts

| Name | Location | Proxy Type | Description | | --------------------------------------------------------------- | -------- | ------------------------------------------ | ------------------------------------------------------------------------------------- | | AddressManager | L1 | - | Legacy upgrade mechanism (unused in Bedrock) | | DeployerWhitelist | L2 | Proxy | Legacy contract for managing allowed deployers (unused since EVM Equivalence upgrade) | | L1BlockNumber | L2 | Proxy | Legacy contract for accessing latest known L1 block number, replaced by L1Block |

Installation

We export contract ABIs, contract source code, and contract deployment information for this package via npm:

npm install @nahmii/contracts-bedrock

Development

Dependencies

We work on this repository with a combination of Hardhat and Foundry.

  1. Install Foundry by following the instructions located here.

  2. Install node modules with yarn (v1) and Node.js (16+):

    yarn install

Build

yarn build

Tests

yarn test

Deployment

Configuration

  1. Create or modify a file <network-name>.json inside of the deploy-config folder.
  2. Fill out this file according to the deployConfigSpec located inside of the `hardhat.config.ts

Execution

  1. Copy .env.example into .env
  2. Fill out the L1_RPC and PRIVATE_KEY_DEPLOYER environment variables in .env
  3. Run npx hardhat deploy --network <network-name> to deploy the L1 contracts
  4. Run npx hardhat etherscan-verify --network <network-name> --sleep to verify contracts on Etherscan

Standards and Conventions

Style

Comments

We use Seaport-style comments with some minor modifications. Some basic rules:

  • Always use @notice since it has the same general effect as @dev but avoids confusion about when to use one over the other.
  • Include a newline between @notice and the first @param.
  • Include a newline between @param and the first @return.
  • Use a line-length of 100 characters.

We also have the following custom tags:

  • @custom:proxied: Add to a contract whenever it's meant to live behind a proxy.
  • @custom:upgradeable: Add to a contract whenever it's meant to be used in an upgradeable contract.
  • @custom:semver: Add to a constructor to indicate the version of a contract.
  • @custom:legacy: Add to an event or function when it only exists for legacy support.

Errors

  • Use require statements when making simple assertions.
  • Use revert if throwing an error where an assertion is not being made (no custom errors). See here for an example of this in practice.
  • Error strings MUST have the format "{ContractName}: {message}" where message is a lower case string.

Function Parameters

  • Function parameters should be prefixed with an underscore.

Event Parameters

  • Event parameters should NOT be prefixed with an underscore.

Spacers

We use spacer variables to account for old storage slots that are no longer being used. The name of a spacer variable MUST be in the format spacer_<slot>_<offset>_<length> where <slot> is the original storage slot number, <offset> is the original offset position within the storage slot, and <length> is the original size of the variable. Spacers MUST be private.

Proxy by Default

All contracts should be assumed to live behind proxies (except in certain special circumstances). This means that new contracts MUST be built under the assumption of upgradeability. We use a minimal Proxy contract designed to be owned by a corresponding ProxyAdmin which follow the interfaces of OpenZeppelin's Proxy and ProxyAdmin contracts, respectively.

Unless explicitly discussed otherwise, you MUST include the following basic upgradeability pattern for each new implementation contract:

  1. Extend OpenZeppelin's Initializable base contract.
  2. Include a uint8 public constant VERSION = X at the TOP of your contract.
  3. Include a function initialize with the modifier reinitializer(VERSION).
  4. In the constructor, set any immutable variables and call the initialize function for setting mutables.

Versioning

All (non-library and non-abstract) contracts MUST extend the Semver base contract which exposes a version() function that returns a semver-compliant version string. During the Bedrock development process the Semver value for all contracts SHOULD return 0.0.1 (this is not particularly important, but it's an easy standard to follow). When the initial Bedrock upgrade is released, the Semver value MUST be updated to 1.0.0.

After the initial Bedrock upgrade, contracts MUST use the following versioning scheme:

  • patch releases are to be used only for changes that do NOT modify contract bytecode (such as updating comments).
  • minor releases are to be used for changes that modify bytecode OR changes that expand the contract ABI provided that these changes do NOT break the existing interface.
  • major releases are to be used for changes that break the existing contract interface OR changes that modify the security model of a contract.

Exceptions

We have made an exception to the Semver rule for the WETH contract to avoid making changes to a well-known, simple, and recognizable contract.