> For the complete documentation index, see [llms.txt](https://docs.prozora.network/bank-integration/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.prozora.network/bank-integration/eng/api-methods/transfer/multisignature-for-transfers.md).

# Multisignature for transfers

By default only a user key signs transactions on Stellar blockchain.

<figure><img src="/files/jHdazPW24Yx8Ksm23hTY" alt="" width="385"><figcaption><p>Default flow with a single signer</p></figcaption></figure>

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):

<figure><img src="/files/hCCrmGpiC1SelcyK2pBv" alt="" width="443"><figcaption><p>Relations between private keys and secrets</p></figcaption></figure>

## Key principles

1. 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
2. 3 signatures are required to post a transaction (counterparty, DCM & Customer)
3. customer’s seed is encrypted on DCM side
4. a secret (stored by the Counterparty) is required to decrypt the customer’s seed
5. the Counterparty uses its own seed to sign a transaction&#x20;

## Confirm payment with multisignature

At steps 4, 5, and 9 all three signatures are added to a transaction envelope.&#x20;

<figure><img src="/files/3ZxqTFCineGSv6G3qiiX" alt=""><figcaption><p>Confirm a payment</p></figcaption></figure>

### POST /sign

#### Request example <a href="#request-example" id="request-example"></a>

No authentication is used&#x20;

<pre class="language-json"><code class="lang-json"><strong>{
</strong>"address":[
    "GALY4D4HZ6XMC2YI5FOWXZ3JKMEOYPWZPADPXBC7ZA232SSEEUCGAR5X"    
    ],
"transaction_xdr":"AAAAAgAAAAAOc/Ep0SpnfQ9wyROTSWSDI5dnsJpSL15kDAmaTEqyIwAAAMgAExmIAAAAAgAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAQAAAAC9uikHe+PC/4jPg01zIk3O7mOC0oFATGCEC3VG3Sz8BAAAAAFlVUFIAAAAAL26KQd748L/iM+DTXMiTc7uY4LSgUBMYIQLdUbdLPwEAAAAAAABhqAAAAAAAAAACgAAAAxwYXltZW50X2d1aWQAAAABAAAAJGRiNzhjNzVjLTFhNTAtMTFlZS1iZDVmLTNhNmFhNDQzNmZlZQAAAAAAAAAA"
}
</code></pre>

The attribute `address` lists all the expected signers for the transfer.&#x20;

The envelope from `tranasction_xdr` for testing purposes can be decoded manually via [Stellar.Laboratory](https://laboratory.stellar.org/#xdr-viewer?input=AAAAAgAAAAAOc%2FEp0SpnfQ9wyROTSWSDI5dnsJpSL15kDAmaTEqyIwAAJxAAExmIAAAAAQAAAAEAAAAAAAAAAAAAAABk7eGKAAAAAAAAAAEAAAABAAAAAA5z8SnRKmd9D3DJE5NJZIMjl2ewmlIvXmQMCZpMSrIjAAAAAQAAAAAOc%2FEp0SpnfQ9wyROTSWSDI5dnsJpSL15kDAmaTEqyIwAAAAAAAAAAAvrwgAAAAAAAAAABRCUEYAAAAEA8LnHlLxq1KAwEQkGtp%2FuJf3JPiv3F06KXzikGaN3WXIz8DbWqc2CttZmIkXq%2BfjvTRYvjQFvFWDWwZgpVS0gI\&type=TransactionEnvelope\&network=test).&#x20;

<details>

<summary>Decoded example:</summary>

<pre class="language-yaml"><code class="lang-yaml">v1
<strong>  tx
</strong>    sourceAccount: [keyTypeEd25519]
      ed25519: GAHHH4JJ2EVGO7IPODERHE2JMSBSHF3HWCNFEL26MQGATGSMJKZCGJYJ
    fee: 200
    seqNum: 5376096463749122
    cond: [precondTime]
      timeBounds
        minTime: 0
        maxTime: 0
    operations: Array[2]
      [0]
        sourceAccount: none
        body: [payment]
          paymentOp
            destination: [keyTypeEd25519]
              ed25519: GC63UKIHPPR4F74IZ6BU24ZCJXHO4Y4C2KAUATDAQQFXKRW5FT6AJKYS
            asset: [assetTypeNative]
              alphaNum4
                assetCode: UAH
                issuer: [publicKeyTypeEd25519]
                  ed25519: GC63UKIHPPR4F74IZ6BU24ZCJXHO4Y4C2KAUATDAQQFXKRW5FT6AJKYS
              amount: 0.00001 (raw: 100)
      [1]
        sourceAccount: none
        body: [manageData]
          manageDataOp
            dataName: payment_guid [hex: ZXh0ZXJuYWxfcGF5bWVudF9ndWlk]
            dataValue: db78c75c-1a50-11ee-bd5f-3a6aa4436fee [hex: ZGI3OGM3NWMtMWE1MC0xMWVlLWJkNWYtM2E2YWE0NDM2ZmVl]
    ext: [undefined]
  signatures: Array[1] Signatures checked!
    [0]
      hint: G______________________________________________MJKZC____
      signature: C26wsxgT6q/Pdelp7wEXYfZJUZxfU24yyK7nomVPRMEZ/bUELq1fzL4A7OEjSPeBzzekG+R+Oc9lteZKA0OuAQ== 
</code></pre>

</details>

The block "manageDataOp" contains an attribute `payment_guid` that should be used in the method [Transfer](/bank-integration/eng/api-methods/transfer.md#counterparty-counterparty_guid-payments-payment_guid)  to obtain the transfer details.&#x20;

#### Response example <a href="#response-example" id="response-example"></a>

<pre class="language-json"><code class="lang-json">{
"address": [
    "GALY4D4HZ6XMC2YI5FOWXZ3JKMEOYPWZPADPXBC7ZA232SSEEUCGAR5X"
<strong>    ],
</strong>"transaction_xdr": "AAAAAgAAAAAOc/Ep0SpnfQ9wyROTSWSDI5dnsJpSL15kDAmaTEqyIwAAAMgAExmIAAAAAgAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAQAAABB0ZXN0IG1hbmFnZV9kYXRhAAAAAgAAAAAAAAABAAAAAL26KQd748L/iM+DTXMiTc7uY4LSgUBMYIQLdUbdLPwEAAAAAAAAAAAAAABkAAAAAAAAAAoAAAAVZXh0ZXJuYWxfcGF5bWVudF9ndWlkAAAAAAAAAQAAACRkYjc4Yzc1Yy0xYTUwLTExZWUtYmQ1Zi0zYTZhYTQ0MzZmZWUAAAAAAAAAAUxKsiMAAABAC26wsxgT6q/Pdelp7wEXYfZJUZxfU24yyK7nomVPRMEZ/bUELq1fzL4A7OEjSPeBzzekG+R+Oc9lteZKA0OuAQ=="
}
</code></pre>

Both attributes are obligatory in response: address indicates the address signed the envelope. At least 1 signature is required in `transaction_xdr`.&#x20;

{% hint style="info" %}
Stellar SDK to work with signatures:&#x20;

1. [Key generation](https://pkg.go.dev/github.com/stellar/go@v0.0.0-20230829144906-bf6fa606f4bf/keypair#Random)
2. [Sign a transaction](https://pkg.go.dev/github.com/stellar/go@v0.0.0-20230829144906-bf6fa606f4bf/txnbuild#Transaction.Sign)
   {% endhint %}

#### Expected errors <a href="#get-key" id="get-key"></a>

1. 400 Bad request: when envelope is malformed&#x20;
   * transfer is stopped
2. 401 Unauthorized: none of addresses from the request are available for signing&#x20;
   * transfer is stopped
3. 404 Not found: in case a response from GET /payments returns no results.&#x20;
   * a retry will be sent later to POST /sign (up to 5 retries)&#x20;

## Create customer with multisignature

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.

<figure><img src="/files/F03w79mXuQuvIjDSFkqV" alt=""><figcaption><p>Create a customer</p></figcaption></figure>