[BIP-471] Update LayerZero Configs for Avalanche

PR with Payload:


The LayerZero team is moving their validation from MPT, to a new featherproof library this is due to the handling of large call data and event sizes across the network. In order for AVAX rewards to properly be streamed in the future Balancer must update the inbound proof library from MPT to feather proof. There also must be a similar update to the outbound mainnet configuration. This will require two transactions handled by the DAO multisigs on each network.


BAL must continue to stream to all of Balancer’s supported networks. By making these updates we will be able to continue to do this, in particular in this case for Avalanche.


Version of 0 and configTypes can be confirmed here.
chainIds can be confirmed here.



  • The DAO Multisig 0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f will interact with the BALProxy 0xE15bCB9E0EA69e6aB9FA080c4c4A5632896298C3 by writing setConfig passing the following arguments:
    _version: 0
    _chainId: 106 for Avalanche
    _configType: 4 for an outbound proof type
    _config: 0x0000000000000000000000000000000000000000000000000000000000000002 for featherproof


  • The DAO Multisig 0x17b11FF13e2d7bAb2648182dFD1f1cfa0E4C7cf3 will interact with the BALProxy contract 0xE15bCB9E0EA69e6aB9FA080c4c4A5632896298C3 by writing setConfig passing the following arguments:
    _version: 0
    _chainId: 101 for Ethereum
    _configType: 1 for an inbound proof library version
    _config: 0x0000000000000000000000000000000000000000000000000000000000000002 for featherproof
1 Like


Just to add a bit more context to the references above:

  • This is the TX with the weekly checkpoints where the current library failed to bridge the funds to Avax. As stated in the summary, the current MPT default library fails to parse such a large set of events, and this is the motivation for the configuration change.
  • LayerZero has endpoints in Mainnet and in Avalanche. We want to upgrade the library to send from Mainnet and receive in Avalanche, which is why we configure the outbound library in the former, and the inbound library in the latter.
  • Featherproof library is already in use by Stargate. These are the details for anyone who wants to double check:

To verify the current configuration of the endpoint for Stargate, call getConfig with the following parameters:

  • _version: 0
  • _chainId: 106 (Avax)
  • _userApplication: 0x296F55F8Fb28E498B858d0BcDA06D955B2Cb3f97 (Stargate Bridge)
  • _configType: 4 (outbound library)

The result of the query is 0x0000000000000000000000000000000000000000000000000000000000000002, which corresponds to the Featherproof library that we are going to use as well.

Hope this helps!


Just to wrap up the thread, after the upgrade BAL seems to be flowing again to AVAX.

As you can see, the tx is ~2 weeks old, and the Avax TX is just a few hours old as I write this post. The library upgrade allowed this to happen, as expected.

1 Like