Chain policy config written to vstorage

[LuqiPan]

What is the Problem Being Solved?

Description of the Design

Security Considerations

Scaling Considerations

Test Plan

Upgrade Considerations

[samsiegart]

Chain policies would be keyed by chainId, which is the numeric identifier for each chain. E.g. ETH:1, OP: 10, ARB: 42161, etc..

The policy for each chain would contain:

nobleContractAddress: Hex;

• The address of Noble's wrapper contract that users interact with via NobleExpress
• msg.sender of DepositAndBurn must be this address to prevent users from calling replaceDepositForBurn

cctpTokenMessengerAddress: Hex;

• The contract address for the CCTP TokenMesenger deployment on that Chain
• See Circle EVM Contracts

confrimations: integer; The number of confirmations needed before a submission occurs

bridgeContractAddress?: Hex; Denotes the bridging contract, or equivalent, we want the Oracle Operator to query to determine L1 inclusion Note: L2's communicate finality to ETH differently, so the term "bridgeContract" may not apply to all chains

We are also considering adding the following fields to the policy:

chainName: string; Since chainId is an integer, is it helpful to also include a human-readable identifier?

nobleDomainId: integer;

• same for every chain, so probably should belong in a "FastUSDC Policy"

nobleAgoricChannelId: IBCChannelID;

• same for every chain, so probably should belong in a "FastUSDC Policy"

eventFilter: ABIString;

• e.g. 'event DepositForBurn(uint64 indexed nonce, address indexed burnToken, uint256 amount, address indexed depositor, bytes32 mintRecipient, uint32 destinationDomain, bytes32 destinationTokenMessenger, bytes32 destinationCaller)'

chainType: Enum;

• FastUSDC only calls for evm chains, so this value might be the same for every chain

  isL2: boolean; helps identify chains that also require tx inclusion checks on L1 potentially redundant