- Do you anticipate needing the Construction API to send from accounts controlled by multiple public keys (i.e. multi-sig accounts)?
- If yes, which predicate is it important that we support properly? For example, we have a
keys-allpredicate that requires that all public keys be used. We also have a
keys-anypredicate that requires that only one of the public keys in a multi-sig account sign the transaction. And we have a
keys-2predicate that requires that only two of the public keys sign the transaction.
- If yes, how will you figure out which keys to use before submitting to the
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
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:
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!