Multisignature for transfers
Last updated
Last updated
By default only a user key signs transactions on Stellar blockchain.
As an option, in order to mitigate the risk of secret forgery a transaction can also be signed by multiple participants.
This flow combines signatures from 2 sides (counterparty and DCM):
counterparty decides from the very beginning, either they use multisignature or a default approach with single signature is implemented
counterparty generates 2 key pairs and provides public parts to DCM before start
3 signatures are required to post a transaction (counterparty, DCM & Customer)
customer’s seed is encrypted on DCM side
a secret (stored by the Counterparty) is required to decrypt the customer’s seed
the Counterparty uses its own seed to sign a transaction
At steps 4, 5, and 9 all three signatures are added to a transaction envelope.
No authentication is used
The attribute address
lists all the expected signers for the transfer.
Both attributes are obligatory in response: address indicates the address signed the envelope. At least 1 signature is required in transaction_xdr
.
400 Bad request: when envelope is malformed
transfer is stopped
401 Unauthorized: none of addresses from the request are available for signing
transfer is stopped
404 Not found: in case a response from GET /payments returns no results.
a retry will be sent later to POST /sign (up to 5 retries)
In order a customer digital entity has 3 signers, the flow of customer creation is amended with step 9, when a pre-configured set of public keys are attributed to a Stellar address as signers.
In terms of integration with API, creation happens as usual.
The envelope from tranasction_xdr
for testing purposes can be decoded manually via .
The block "manageDataOp" contains an attribute payment_guid
that should be used in the method to obtain the transfer details.