Safe Harbor Cross-Chain Compatability

[Robert-MacWha]

Discussion to decide the best approach for cross-chain compatibility with Safe Harbor. The end goal is to create a system that allows protocols from all chains, EVM and non-EVM, to easily adopt Safe Harbor while keeping with the current on-chain registry approach.

[Robert-MacWha]

Currently I've got two options in mind:

1. Separate registry implementations for each incompatible blockchain architecture.
2. Upgrade the EVM registry to allow for non-evm chainIDs and addresses.

Option 1 lets us deploy the registry across all chains, increasing compatibility with different governance systems. However, it also means we need to maintain multiple concurrent instances of safe harbor with different implementations, languages, and features. That's more work than is ideal.

Option 2 lets us keep a single registry written in a single language, but limits the registry to being deployed on EVM-compatible chains. It also would potentially require ownership and more frequent upgrades to deal with different address & chainID systems across the ecosystem.

[Robert-MacWha]

I'm leaning towards Option 2

Implementation Details

1. Convert the assetRecoveryAddress and accountAddress fields into strings, so they can support different address formats.
2. Instead of using ChainIDs, create a mapping(uint => string) that maps integers to chain identifiers. Similar to Wormhole Chain IDs. This lets us assign UUIDs to non-EVM chains.
3. Create a permissioned account that has append-only access to the ChainIDs mapping. This does introduce potential attack vectors since the registry is no longer immutable, but with append-only access a malicious actor wouldn't be able to mess up existing agreements, only confuse new ones.

Legal Changes (assumption - I'll meet with Rodrigo tomorrow to check):

1. Explain the permissioned actor.
2. Explain how the chainID mapping works.

Downsides

1. If there are radically different chain or address structures, it may be infeasible. Having the accountAddress be a string grants some flexibility, but it's possible that it isn't enough.
2. The registry contract is still EVM-focused, being written in solidity and only deployed on EVM chains. From a maintainer perspective this is a feature, but it could harm adoption for some parties with governance exclusively on non-EVM chains.

[Robert-MacWha]

I'll maintain this compatibility chart into the future. Others feel free to adjust if they have different information.

Compatibility

Chain	Compatible	Notes	Account Identification
EVM	Yes	Native	0x-prefixed hex string (42 chars)
Solana	Yes	No ChainID and Addresses are a different format to EVM	Base58-encoded public key
Polkadot EVM Environment	Yes	Same Address system as EVM	0x-prefixed hex string (42 chars)
Polkadot Substrate Environment	Maybe	Pallets lack UUIDs, so may be challenging to identify1	Pallet Name(?)
Cosmos		No ChainID or UUIDs	Bech32 address
Near		Human-readable accounts instead of addresses	Human-readable account names (.near suffix) or implicit accounts (64-char hex)
Tezos		Base58check addresses, no ChainID	tz1/tz2/tz3/KT1 prefixed Base58Check strings
Algorand		base32-checksummed addresses, application IDs for code, no ChainID	Base32 string with checksum
Sui		No ChainID	0x-prefixed hex string (variable length)
Aptos		No ChainID	0x-prefixed 64-char hex string
Ton			base64url-encoded address with workchain ID prefix
Bitcoin	Yes	No ChainID	Base58Check encoded P2PKH/P2SH or Bech32 encoded for SegWit

1. SEAL Safe Harbour for Polkadot

[Robert-MacWha]

Information for Rodrigo:

1. We're adding new non-EVM chains. This poses a problem because we can't currently uniquely identify non-evm chains or accounts on non-evm chains. For example, Solana doesn't have a chainID, or polkadot doesn't have addresses.
2. The way I am planning to uniquely identify non-EVM chains is by creating a mapping in the smart contract registry of "Safe Harbor ChainID" to "Chain", which adopters can use to specify both EVM and non-EVM chains.
3. The way I am planning to uniquely identify non-EVM accounts will vary from chain to chain. You can see the representations in the table above. In general I think it will need to be up to the discretion of each chain how things are identified.

Questions for Rodrigo:

1. Will having a permissioned actor that can add new ChainID<>Chain pairings to the be ok? They'll have permission to add new mappings, but not to edit or remove existing mappings, nor edit anything within the agreements themselves.
2. How do you suggesting dealing with the variable methods to uniquely identify accounts?

[Robert-MacWha]

Apparently a very long time coming, but this is done! Resolved by release 1.1 #25