spike: fusdc to evm and solana

[0xpatrickdev]

closes: #XXXX
refs: #XXXX

Description

Includes:

• /circle/cttp/v1 protos + .toProtoMsg codegen
• chain hub supports non-cosmos chains (numeric chain ids, ecosystem identifier) (wip)
  • evm + solana chain ids
  • cctpDestinationDomain
  • ecosystem identifier
  • type mechanism for NobleMethods.. maybe chainName can be used? see Orch docs have too much inline chaininfo #9992, types!: Chain takes KnownChainName generic parameter instead of ChainInfo #10213
• cosmos-orchestration-account.js has depositForBurn method (wip)
  • evm (hex)/solana(b58) addr -> byte array functions
• fast usdc advancer calls .depositForBurn (wip)
  • Advancer in .advance (+ unwind to LP on failure)
  • Settler in .forward

Todo:

• chainId.startsWith('noble') is insufficient for determining if an account should have .depositForBurn (via types + run time checks), as noble's testnet is called grand-1. (comment)
• encoding functions for EVM + Solana addresses to Uint8Array (see comment)
• mechanism to determine "ecosystem" from chain address (see IBIS)
• recovery logic if depositForBurn fails during advance
• settler.forward() logic for fallback transfers (should include depositForBurn flow)
• unit and multichain-testing tests

Security Considerations

Scaling Considerations

Documentation Considerations

Testing Considerations

Upgrade Considerations

[0xpatrickdev]

This won't work for testnets, as noble's is grand-1. Seems like the ecosystem field we were talking about, or even something in addition to that, on Chain would be helpful here.

[turadg]

I think we're going to have to ask the ChainHub for info about the address.

[0xpatrickdev]

Feeding an LLM this example code + some data from noble -> solana txs, it claims we need something like this:

const B58_ALPHABET = '123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz';
// For Solana addresses - decode base58 address into bytes
function base58AddrToBytes(addr) {
    let result = 0n;
    for (let i = 0; i < addr.length; i++) {
        result = result * 58n + BigInt(B58_ALPHABET.indexOf(addr[i]));
    }
    
    // Convert to bytes
    const bytes = [];
    while (result > 0n) {
        bytes.unshift(Number(result & 0xffn));
        result = result >> 8n;
    }
    
    // Add leading zeros from original encoding
    let leadingZeros = 0;
    for (let i = 0; i < addr.length && addr[i] === '1'; i++) {
        leadingZeros++;
    }
    
    return new Uint8Array([...new Array(leadingZeros).fill(0), ...bytes]);
}

// For Ethereum addresses - encode hex address into bytes
function hexAddrToBytes(addr) {
    // Remove 0x prefix if present and ensure lowercase
    const hex = addr.replace(/^0x/, '').toLowerCase();
    
    // Pad to 32 bytes (64 chars) with leading zeros
    const padded = hex.padStart(64, '0');
    
    // Convert to bytes
    const bytes = new Uint8Array(32);
    for (let i = 0; i < 32; i++) {
        bytes[i] = parseInt(padded.substr(i * 2, 2), 16);
    }
    
    return bytes;
}

We might prefer to use libraries here, suggestions welcome. For b58 I believe there is base-x

[0xpatrickdev]

see https://github.com/Agoric/agoric-sdk/pull/10967/files#r1946946855

[dckc]

seems like we could use the presence of cctpDestinationDomain.

[0xpatrickdev]

cctpDestinationDomain

i agree

[0xpatrickdev]

this bug was fixed in a different PR that has since been merged to master

[Chris-Hibbert]

I rebased on master because #10988 basically covers the first commit here.

[turadg]

in CAIP-10 parlance,
CID: chain_id (à la CAIP-2)
EUD: account_address

It also has an account_id definition (chain_id + ":" + account_address). I propose the "End User Destination" be that full "account_id". The enclosing object is a "query" and it's not sensical to change CID independent of EUD. IOW, EUD needs to specify the full chain-agnostic account ID.

For backwards compatibility we can make the chain_id implied.

[turadg]

why not just leave it as a string? there's no arithmetic being performed.

[0xpatrickdev]

For eip155 chains, chain ID is uint, so the thinking was to preserve that

[0xpatrickdev]

I don't know of a current use case, but could imagine a smart contract function signature that expects an integer for a chainId parameter. Perhaps these types of functions can handle this concern themselves instead of the orchestration api.

For eth ecosystem chain ids, let's please at least use {number} for the type value.