Stellar Multisig Coordination Service - Rough Draft

multisig-service.md

Stellar Multisig Coordination Service

Objective

SEP-0007 introduced a standard for payment requests (basically templated transactions) on Stellar. In order to provide a smooth user experience when working with multi-signature accounts, wallets need to be able to send each other realtime payment requests.

That requires a new kind of service in the Stellar eco system: A multi-signature coordination service.

It's purpose is to act as a hub for wallet applications to communicate and prepare transactions prior to submitting them to the network. Stellar applications may submit signature requests to it that will then be forwarded to the applications of the other signers. Stellar applications may also request pending signature requests and open an event stream that will push real-time messages to them when a signature is added.

The implementation is straight-forward if there is only a single coordination service. Once there are multiple instances of such a service, routing functionality must be added. Routing is necessary, so that an application A may connect to coordination service X and an application B may connect to coordination service Y, but both applications are able to sign each other's transactions as long as services A and B are connected.

Features

• Signature request submission
• Signature request querying
• Signature update stream
• Routing of signature requests

Standardization

We should push for a common open API that such a service is supposed to implement. The APIs for the features listed above could be provided as an HTTP REST API, using Server-sent events for the update stream and possible web hooks (also REST) for the inter-service communication.

Such an API would be technically very similar to the well-known API of the Stellar horizon nodes.

Open Questions

• Should the coordination service submit the transaction itself once it has been sufficiently signed?
  • Alternative: Just push message to signer wallets that tx has been signed; one of them may submit it then
  • There should at least be an opt-in flag to not submit it automatically, since it might be some kind of timelocked refund tx that needs to be signed up-front, but not yet submitted

Links

• Payment Request Spec SEP-0007

• re: tx submission when signed sufficiently: maybe that can be specified by the person/service who's submitting the request in the beginning? The callback parameter in SEP-0007 seems to be used for that if I understand it correctly.
• Can't this service be spammed easily if anyone can request signatures from anyone? Idea: the requester must be the source account for the transaction (and thus add a signature and pay the tx fee). However, this has the disadvantage that
• re: routing: would a decentralized database work... maybe the Stellar network? 😅 Or maybe something DHT-based?

@andrenarchy See https://gist.github.com/andywer/9ee36d8bccc5486d7959b8c1cd64b072 ;)

I hope it will answer most of your questions.

About using SEP-0007's callback parameter: Yes, potentially. Good point! :)

About using the Stellar network to send those requests: Would be good, since we would save a lot of effort, but I am not sure yet if we need a solution that works faster than the ledger close time for some use cases. @nikhilsaraf also has some ideas how that could be realized using the Stellar network.