OpenZeppelin Contracts Upgradeable

This directory provides a suite of contracts designed for sending and receiving cross-chain messages following the ERC-7786 standard. The implementation is divided into two main categories: communication helpers and bridge constructions.

Communication Helpers

These contracts facilitate the underlying messaging mechanics:

• CrosschainLinked: A helper to enable communication between a contract on a local chain and its counterparts on remote chains via ERC-7786 gateways.
• CrosschainRemoteExecutor: An executor contract used to relay transactions from a controller located on a remote chain.
• ERC7786Recipient: A generic contract designed to receive messages from a trusted gateway.

Bridge Constructions

These contracts implement specific logic for transferring assets across chains:

• Fungible Assets (ERC-20/ERC-7802): Uses BridgeFungible core logic. Implementations include BridgeERC20, BridgeERC7802, and ERC20Crosschain.
• Non-Fungible Assets (ERC-721): Uses BridgeNonFungible core logic. Implementations include BridgeERC721 and ERC721Crosschain.
• Multi-Token Assets (ERC-1155): Uses BridgeMultiToken core logic. Implementations include BridgeERC1155 and ERC1155Crosschain.
• Standalone Bridges: Specific contracts for BridgeERC20, BridgeERC721, BridgeERC1155, and BridgeERC7802 to connect token contracts with remote counterparts.

This directory provides a suite of upgradeable contracts designed for building accounts and paymasters within the ERC-4337 (Account Abstraction) ecosystem. The components are categorized into Core accounts, Extensions for modularity, specialized Paymasters, and Utility functions.

Core Accounts

• Account: The base ERC-4337 smart account implementation containing core logic for processing user operations.
• AccountERC7579: An extension of Account that adds support for ERC-7579 modules.
• AccountERC7579Hooked: An extension of AccountERC7579 that supports a single hook module (type 4).
• ERC7821: Minimal batch executor implementation contracts used to enable easy batch execution for smart contracts.

Paymasters

Paymasters handle the validation and payment of gas for user operations.

• Paymaster: The base ERC-4337 paymaster implementation.
• PaymasterERC20: Allows users to pay for user operations using ERC-20 tokens.
• PaymasterERC20Guarantor: Enables third parties to guarantee user operations by pre-funding gas costs (with options for user repayment or guarantor absorption).
• PaymasterERC721Owner: Sponsors user operations for users who hold specific ERC-721 tokens.
• PaymasterSigner: Sponsors user operations authorized via a signature.

Utilities

• ERC4337Utils: Helper functions for working with ERC-4337 user operations.
• ERC7579Utils: Helper functions for working with ERC-7579 modules and account modularity.

An inflation attack targets ERC-4626 vaults by manipulating the exchange rate between assets and shares. Because the number of shares minted is rounded towards zero, an attacker can donate a large amount of assets to an empty or low-liquidity vault to move the exchange rate so high that subsequent small deposits result in 0 shares being minted. This effectively steals the entire deposit, which is then redeemable by the attacker.

Attack Scenario:

1. Attacker deposits a tiny amount of assets ($a_0$) to become a shareholder.
2. Attacker donates a large amount of assets ($a_1$) directly to the vault.
3. The exchange rate becomes so skewed that a user's deposit ($u$) results in $< 1$ share, which rounds to 0.
4. The attacker redeems their shares to claim the user's assets.

To prevent this, the amount of funds an attacker must commit is roughly equivalent to the amount they can steal, making the attack highly sensitive to the vault's initial state.

The ERC-1155 standard is implemented through a set of core interfaces and contracts that allow for managing multiple token types within a single contract.

Core Interfaces

• IERC1155: The mandatory interface for the standard.
• IERC1155MetadataURI: An optional extension interface for metadata.
• IERC1155Receiver: An interface used to allow contracts to receive ERC-1155 tokens.

Core Implementation

• ERC1155: The base implementation that fulfills IERC1155 and the optional IERC1155MetadataURI. It uses a substitution mechanism to use the same URI for all token types, which significantly reduces gas costs compared to individual URIs per token.

Design Philosophy

These contracts are designed to be unopinionated. Developers can inherit from ERC1155 and access internal functions (such as _mint(address,uint256,uint256,bytes)) to expose them as external functions according to their specific requirements.

The P256 library provides support for NIST-standardized P256 signatures.

• verify: Attempts to use the RIP-7212 precompile at address 0x100 if available, otherwise falls back to a Solidity implementation.
• verifyNative: Use this if you are certain the RIP-7212 precompile is available on your target chain to save gas.

Important: The library only supports s values in the lower order of the curve (s <= N/2) to prevent malleability. If your tooling produces signatures on the other side of the curve, you must flip the s value.

using P256 for bytes32;

// Standard verification (precompile or fallback)
function _verify(
    bytes32 data,
    bytes32 r,
    bytes32 s,
    bytes32 qx,
    bytes32 qy
) internal view returns (bool) {
    return data.verify(r, s, qx, qy);
}

// Native verification (precompile only)
function _verifyNative(
    bytes32 data,
    bytes32 r,
    bytes32 s,
    bytes32 qx,
    bytes32 qy
) internal view returns (bool) {
    return data.verifyNative(r, s, qx, qy);
}