Merkle Verification

Status: Under Development

The contents of this page are currently under development and may be updated frequently without prior notice. It is not recommended to use the information on this page for production purposes.

mETH Protocol has partnered with Veda for Merkle verification and vault components. For more information, please visit: https://docs.veda.tech/.

Simplified Diagram

Key Points

  • Each permitted action of the Strategist is detailed within a Merkle Leaf 's structured data, and hashed into a MerkleLeafDigest or MerkleProof.

  • When a Strategist attempts to take a rebalancing action (e.g. transfer mETH from the BoringVault to PositionManager1), this call must be accompanied with the corresponding MerkleProof which is verified against the MerkleRoot.

  • The MerkleRoot is the cryptographic summary of all MerkleLeafs. Currently active Roots and Leafs can be found here: Merkle Roots

  • The BoringVault.Manager contract can contain multiple MerkleRoots and assigned Strategists. This allows for flexibility (for example we can have limited function and full function MerkleRoots) and redundancy (for example we can have multiple backup Strategist incase the primary Strategist is offline).

Component Details

MerkleLeafs

Key Points

A list of all active Leafs and Roots can be found here Merkle Roots.

[Placeholder for key points text]

Example Format

The code example below is for one Leaf associated with the rebalancing of mETH to the WithdrawerContract. This involves: interacting with the mETHToken (targetAddress: 0xd5...ADfa); and Transfer function (0xa9059bb); and with Destination Address being the DelayWithdrawal contract (AddressArguement: 0x12....B113). 

{
            "AddressArguments": [
                "0x12Be34bE067Ebd201f6eAf78a861D90b2a66B113"
            ],
            "CanSendValue": false,
            "DecoderAndSanitizerAddress": "0xa728337af7dD226B74B0b1546AA7dD54d340d5Eb",
            "Description": "Transfer mETH to the delayed withdrawer contract",
            "FunctionSelector": "0xa9059cbb",
            "FunctionSignature": "transfer(address,uint256)",
            "LeafDigest": "0x354d2d9c40ed196e4ecb482c8117a33dce43d100ef8b68a3f5886f4d8d2877d9",
            "PackedArgumentAddresses": "0x12be34be067ebd201f6eaf78a861d90b2a66b113",
            "TargetAddress": "0xd5F7838F5C461fefF7FE49ea5ebaF7728bB0ADfa"
}

Descriptions

ItemDescription

LeafDigest

This serves as a Leaf "Id". It is a "hash result of structured data in every leaf element, and merkle tree constructed with the range of leaf digests by a fixed sequence". For more details see: https://soliditydeveloper.com/merkle-tree

TargetAddress

The smart contract address being interacted with. For example: for transfering mETH token it will be the mETH token address; for existing restaking positions it will be the restaking protocol smart contract address.

FunctionSelector, FunctionSignature

The smart contract function being called. For example: transfer, deposit, withdraw, claim, delegate.

AddressArguments

Contains the address arguments if required as part of the Function. For example: transfer destination addresses.

DecoderAndSanitizer

DecodersAndSanitizers are required when integrating with a new external protocol. Their job is to decode input target data, extract a bytes value comprised of addresses found in the target data, and to sanitize other non address argument values. https://docs.veda.tech/architecture-overview/decoderandsanitizer

MerkleRoots

Key Points

A list of all active Leafs and Roots can be found here Merkle Roots.

[Placeholder for key points text]

Example Format 

{
        "AccountantAddress": "0x6049Bd892F14669a4466e46981ecEd75D610a2eC",
        "BoringVaultAddress": "0x33272D40b247c4cd9C646582C9bbAD44e85D4fE4",
        "DecoderAndSanitizerAddress": "0xa728337af7dD226B74B0b1546AA7dD54d340d5Eb",
        "DigestComposition": [
            "Bytes20(DECODER_AND_SANITIZER_ADDRESS)",
            "Bytes20(TARGET_ADDRESS)",
            "Bytes1(CAN_SEND_VALUE)",
            "Bytes4(TARGET_FUNCTION_SELECTOR)",
            "Bytes{N*20}(ADDRESS_ARGUMENT_0,...,ADDRESS_ARGUMENT_N)"
        ],
        "LeafCount": 60,
        "ManageRoot": "0x9746e6e59bb9c9a05af48b466df5be3dbd2bd8db622ecb1e7d1c1451de273e2c",
        "ManagerAddress": "0xAEC02407cBC7Deb67ab1bbe4B0d49De764878bCE",
        "TreeCapacity": 64
}

Updating MerkleRoots

Key Points

  • Full name: BoringVaultManager.setManageRoot()

  • This function is called when modifying constraints (MerkleRoots) or Strategists.

  • There can be multiple MerkleRoots and assigned Strategists.

  • Each Strategist can only be assigned one MerkleRoot.

Etherscan Interface

Rebalancing mETH

Key Points

Etherscan Interface

Strategist Walkthrough

For manual rebalancing

Additional Resources

https://soliditydeveloper.com/merkle-tree

https://docs.veda.tech/architecture-overview/manager/managerwithmerkleverification

https://docs.alchemy.com/docs/merkle-trees-in-blockchains

https://ethereum.org/en/developers/docs/data-structures-and-encoding/patricia-merkle-trie/

PreviousUnstake LifecycleNextTokenomics

Last updated