Construction API and Multi-Sig Accounts

  1. Do you anticipate needing the Construction API to send from accounts controlled by multiple public keys (i.e. multi-sig accounts)?
  2. If yes, which predicate is it important that we support properly? For example, we have a keys-all predicate that requires that all public keys be used. We also have a keys-any predicate that requires that only one of the public keys in a multi-sig account sign the transaction. And we have a keys-2 predicate that requires that only two of the public keys sign the transaction.
  3. If yes, how will you figure out which keys to use before submitting to the /payload endpoint?

Integrators we’ve talked to have wide-ranging opinions on using on-chain multi-sig accounts. However, the initial group of Rosetta API integrators typically use a single on-chain key/address and perform some form of TSS scheme off-chain (especially when a blockchain uses the edwards25519:ed25519 scheme).

That being said, it has been a design goal from inception to support on-chain mutli-sig transactions with the Construction API. Right now, the specification only supports multi-sig transaction construction for blockchains that don’t associate multiple keys with a single AccountIdentifier (this does not mean that you can’t attach multiple keys to a given address). This restriction prohibits “Bitcoin-style” multi-sig (usually a single logical AccountIdentifier backed by multiple keys) but tends to allow for multi-key setups in staking scenarios (where the “voter” key may have a different SubAccount than the “funds” key).

We de-prioritized “Bitcoin-style” multi-sig initially as this can require multi-phase signing on some blockchains (where the signature of one key comprises some component of the signing payload for other keys). We felt trying to “boil the ocean” would’ve been a little too much to ship in a first release.

Both “Bitcoin-style” multi-sig and multi-phase signing are in the rosetta-specifications v1.5.0 milestone. You can track that here:

Supporting keys-any should be sufficient for your first pass at the implementation (you can add the multi-sig primitives after the release of v1.5.0). This will work with all the existing tooling, whereas the other “predicates” will not yet fit cleanly into the spec (you would need to do a lot of toying with v1.4.4 to make them work). We anticipate a v1.5.0 to land in a few weeks (and be non-breaking). Best to wait until then so you don’t waste any effort!

I elaborated on this in [Username blockchain model] Deriving public keys to sign with for given account. Let me know if you have any further questions about how this would work!

1 Like