Bootstrapping the operator accounts at & after genesis

[mmagician]

USDCx Faucet Launch Plan

1. Generate the AccountId of the USDCx faucet

Needed for both testnet and mainnet.

1.1 Generate / gather the AccountIds for all the roles

Includes:

• ADMIN
• ATTEST_ADMIN
• DOM_PAUSER
• DOM_UNPAUSER
• BLK_MANAGER
• RELAYER

1.2 Gather other data needed for seeding the account

This is only the attestation pubkey from Circle.

1.3 Derive the AccountId for the faucet itself

We should be able to deterministically derive the AccountId on both networks before launching anything, and supply that to Circle so that they can start the registration process on their end (even if our network won't be ready by then).

2. Distributor account (DISTRIBUTOR)

To make the first tx on Miden, we need at least one account to hold the native token.
This could be a burner distributor account, whose only role is to have funds seeded at genesis, and send them out to the RELAYER (who submits mint attestations) and other bridge role accounts (DOM_PAUSER, etc.).

This account also needs to be generated ahead of launch.

3. Send funds to the Ethereum/Sepolia USDCx contract

Once Circle registers Miden's domain, we need to make a deposit on Ethereum/Sepolia → Miden, with the DISTRIBUTOR as the destination.

We need to ensure that we hold enough ETH to cover the gas fee, and init_amount of USDCx, in an Ethereum wallet.

Exact amounts of USDCx to be deposited are:

• mainnet: 100 USDC
• testnet: 1,000,000,000 USDC (pending confirmation)

For testnet we'd like to start with a relatively large amount, so that after genesis we can already test the functionality of Miden itself without relying on the USDCx bridging process (since this is the first time we'd be integration-testing it).

4. Miden genesis

• We set the USDCx faucet as the native faucet (same AccountId as in step 1).
• We seed the DISTRIBUTOR with init_amount of USDCx.

5. Batch builder

Since we don't have a BATCH_FEE note, nor the collection thereof by the block builder, implemented, we don't need to worry about pre-funding the batch builder account at this point.

6. Bridge operator roles

Aside from the relayer that submits mint requests to the faucet, the other operational roles like ADMIN, ATTEST_ADMIN, etc. need to hold funds as well, so that they can be operational as soon as the network is up and running.

These could be seeded at genesis (part of step 4), but it's easier to have them funded via a P2ID transfer from the DISTRIBUTOR shortly after genesis.

USDCx accounts to be funded

As listed in 1.1 above.

cc @Keinberger — could you confirm please?

AggLayer accounts to be funded

• BRIDGE_ADMIN
• PAUSER(s) — potentially several accounts
• FAUCET_ADMIN, per faucet. Same account as BRIDGE_ADMIN by default
• FAUCET_MNGR (managed by Gateway)
• GER_INJECTOR (managed by Gateway)
• GER_REMOVER (managed by Gateway)
• FEE_MNGR (managed by Gateway)

cc @mandrigin — could you confirm please?

Note

This initial funding step only covers the first few transactions - though we can make sure to cover a few thousand transactions e.g. with 10 USDC. Going forward, the operators need to ensure their accounts always remain funded (cc @mandrigin for AggLayer; @Keinberger for USDCx).

7. Funding service

For the partner mainnet, we want to have a funding service that sends funds to the allowlisted accounts, as described in #2561.

This account can be funded in the same manner as the bridge operator roles in step 6.

Local deployment & devnet

As discussed offline with @Mirko-von-Leipzig, it might be easiest if in v0.17+, local and devnet environments also use the USDCx faucet as the native faucet, to keep things in sync.

Since there is no accounting to be tracked with Circle, we can:

• In genesis, seed with a large amount of funds.
• Set ourselves as the minting authority. This requires creating a service that submits signed MINT attestations against the USDCx faucet, thus adding a bit of operational setup. Perhaps this could be the role of the faucet operator service itself — TBD.