Search for projects by name or address
Liquidity bridge and messaging protocol using the MAP relay chain (an alt-L1) and its light-client network to verify cross-chain messages.
Liquidity bridge and messaging protocol using the MAP relay chain (an alt-L1) and its light-client network to verify cross-chain messages.
Symbol | Last 24h
Volume | Last 24h
transfer count | Last 24h avg.
transfer time | Last 24h avg.
transfer value | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Symbol | Last 24h
Volume | Last 24h
transfer count | Last 24h avg.
transfer time | Last 24h avg.
transfer value | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Symbol | Last 24h
Volume | Last 24h
transfer count | Last 24h avg.
transfer time | Last 24h avg.
transfer value | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Timestamp | Tokens | Value | Bridge | Transfer time | Chains | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Timestamp | Tokens | Value | Bridge | Transfer time | Chains | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Timestamp | Tokens | Value | Bridge | Transfer time | Chains | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
7702 re-delegation of a multisig signer.
7702 re-delegation of a multisig signer.
| EOA (base:0x386ce1a187eC7329CFb8E467EB02FB07c698256A) { | |
| +++ description: None | |
| values.$implementation: | |
| - | "base:0xa845C74344Fc9405b1Fcf712f04668979573c1bf" |
| + | "base:0xe40ccB2D94975c51bff0C004eFDfd9B3a5796fA4" |
| } | |
Butter interop protocol init disco: validation checks BLS sigs of a validator set on an external L1 (MAP Protocol). Validators can update the set with the discovered quorum. Each bridge tx verifies a merkle proof agains validator-signed block headers from the external L1. The L1 is supposed to run light clients of all participating chains.
Butter interop protocol init disco: validation checks BLS sigs of a validator set on an external L1 (MAP Protocol). Validators can update the set with the discovered quorum. Each bridge tx verifies a merkle proof agains validator-signed block headers from the external L1. The L1 is supposed to run light clients of all participating chains.
| + | Status: CREATED |
| contract Butter Bridge (base:0x0000317Bec33Af037b5fAb2028f52d14658F6A56) [butternetwork/Bridge] | |
| +++ description: Butter's Base bridge endpoint. Outbound transfers lock or burn assets and emit messages for the MAP relay chain; inbound transfers execute only after a LightNode-validated receipt proof for the configured MAP relay contract. The bridge can mint configured mintable tokens, release escrowed assets, and invoke receiver callbacks, so compromise of validation, relay configuration, or management authority can lead to loss of bridged funds. | |
| + | Status: CREATED |
| contract Butter MAP LightNode (base:0x0001805c0B57DBd48B5c5c26E237a135dDC678ae) [butternetwork/LightNode] | |
| +++ description: Upgradeable MAP relay-chain light client used by Butter bridges. It verifies relay-chain headers with the stored BLS validator set and verifies receipt Merkle proofs against accepted headers. It is the destination-chain validation boundary for bridged messages. | |
| + | Status: CREATED |
| EOA (base:0x386ce1a187eC7329CFb8E467EB02FB07c698256A) | |
| +++ description: None | |
| + | Status: CREATED |
| contract SafeL2 (base:0x9987463102993e177b107e0cE97a0420428D1999) [GnosisSafe] | |
| +++ description: None | |
| + | Status: CREATED |
| contract SafeL2 (base:0xAAAaEE7549a61282F2B4Ca1766f46249D9e71aaA) [GnosisSafe] | |
| +++ description: None | |
| + | Status: CREATED |
| contract Butter AuthorityManager (base:0xACC31A6756B60304C03d6626fc98c062E4539CCA) [butternetwork/AuthorityManager] | |
| +++ description: OpenZeppelin AccessManager-derived authority for Butter's restricted Bridge and FeeService functions. Its role configuration controls who can change bridge validation dependencies, relay and token settings, fee parameters, pause state, and implementation upgrades. | |
| + | Status: CREATED |
| contract Butter VerifyTool (base:0xc3393567DC2F1d071254E880c9f501641491471f) [butternetwork/VerifyTool] | |
| +++ description: Cryptographic and RLP/Merkle-proof helper contract called by the Butter MAP LightNode to validate relay-chain headers and transaction receipts. | |
| + | Status: CREATED |
| contract Butter FeeService (base:0xfeE31a1FD7FcA0E05428ff751242e46F6D5769a6) [butternetwork/FeeService] | |
| +++ description: Fee configuration contract used by Butter Bridge to calculate cross-chain message fees and select the fee recipient. | |
A Multisig with 3/5 threshold.
A Multisig with 2/3 threshold.
OpenZeppelin AccessManager-derived authority for Butter’s restricted BridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. and FeeService functions. Its role configuration controls who can change bridge validation dependencies, relay and token settings, fee parameters, pause state, and implementation upgrades.
Butter’s Base bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. endpoint. Outbound transfers lock or burn assets and emit messages for the MAP relay chain; inbound transfers execute only after a LightNode-validated receipt proof for the configured MAP relay contract. The bridge can mint configured mintable tokens, release escrowed assets, and invoke receiver callbacks, so compromise of validation, relay configuration, or management authority can lead to loss of bridged funds.
Upgradeable MAP relay-chain light clientSometimes labelled interchangeably as a “node”, they are tasked with processing transactions and managing the blockchains's state. They run the computations for each transaction according to the rollup's virtual machine and protocol rules. If comparing to Ethereum clients, these would be execution clients such as Geth, as opposed to consensus clients. used by Butter bridges. It verifies relay-chain headers with the stored BLS validatorIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier set and verifies receipt Merkle proofsHashing the pairs of values at each level and climbing up the (Merkle) Tree until you obtain the root hash. Merkle proofs help check if the data belongs to a set without having to store the entire set. against accepted headers. It is the destination-chain validation boundary for bridged messages.
Cryptographic and RLP/Merkle-proof helper contract called by the Butter MAP LightNode to validate relay-chain headers and transaction receipts.
Fee configuration contract used by Butter BridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. to calculate cross-chain message fees and select the fee recipient.
The current deployment carries some associated risks:
Funds can be stolen if a contract receives a malicious code upgrade. There is no delay on code upgrades (CRITICAL).