bridge

bridge-server

This is a stand alone server written in go. It is designed to make connecting to the Stellar network as easy as possible. It allows you to be notified when a payment is received by a particular account. It also allows you to send a payment via a HTTP request. It can optionally be connected to a compliance server if you want to carry out the compliance protocol. It can be used by any project that needs to accept or send payments such as anchors or merchants accepting payments.

Handles:

• Creating Stellar transactions.
• Monitoring a receiving Stellar account.

Downloading the server

Prebuilt binaries of the bridge-server server are available on the releases page.

Alternatively, you can build the binary yourself.

Config

The bridge.cfg file must be present in a working directory (you can load another file by using -c parameter). Here is an example configuration file. Config file should contain following values:

• port - server listening port
• api_key - when set, all requests to bridge server must contain api_key parameter with a correct value, otherwise the server will respond with 503 Forbidden
• network_passphrase - passphrase of the network that will be used with this bridge server:
  • test network: Test SDF Network ; September 2015
  • public network: Public Global Stellar Network ; September 2015
• compliance - URL to compliance server instance if you want to carry out the compliance protocol
• horizon - URL to horizon server instance
• assets - array of approved assets codes that this server can authorize or receive. These are currency code/issuer pairs. Use asset code 'XLM' with no issuer to listen for XLM payments. See bridge_example.cfg for example.
• database
  • type - database type (mysql, postgres)
  • url - url to database connection:
    • for mysql: user:password@(host:port)/dbname (more info)
    • for postgres: postgres://user:password@host/dbname?sslmode=sslmode (more info)
• accounts
  • base_seed - The secret seed of the account used to send payments. If left blank you will need to pass it in calls to /payment.
  • authorizing_seed - The secret seed of the public key that is able to submit allow_trust operations on the issuing account.
  • issuing_account_id - The account ID of the issuing account (only if you want to authorize trustlines via bridge server, otherwise leave empty).
  • receiving_account_id - The account ID that receives incoming payments. The callbacks.receive will be called when a payment is received by this account.
• callbacks
  • receive - URL of the webhook where requests will be sent when a new payment is sent to the receiving account. The bridge server will keep calling the receive callback indefinitely until 200 OK status is returned by it. WARNING The bridge server can send multiple requests to this webhook for a single payment! You need to be prepared for it. See: Security.
  • error - URL of the webhook where requests will be sent when there is an error with an incoming payment
• log_format - set to json for JSON logs
• mac_key - a stellar secret key used to add MAC headers to a payment notification.

Check bridge_example.cfg.

The minimal set of config values contains:

• port
• network_passphrase
• horizon

It will start a server with a single endpoint: /payment.

Getting started

After creating bridge.cfg file, you need to run DB migrations:

./bridge --migrate-db

Then you can start the server:

./bridge

API

Content-Type of requests data should be application/x-www-form-urlencoded.

POST /create-keypair

Creates a new random key pair.

Response

{
  "public_key": "GCSLLOYK7IKDQKUDSSAPHSJT3Y5XLIDIAFPVO5K42IN5CAQPNHIHJ2DE",
  "private_key": "SCJAOTWONWSOQLILCHNSGUOIXWCMIJQ563SPHMG25OPFX3IUDBAFU4SV"
}

In case of error it will return the following error:

• InternalServerError

POST /builder

Builds a transaction from a given request. Content-Type of this request should be application/json. Check List of operations doc to learn more about how each operation looks like.

Note This will not submit a transaction to the network. Please use Horizon to submit a transaction.

Request

Check example request below (remove comments before submitting it to the bridge server):

{
  // Transaction source account
  "source": "GBDCOZD7CHY26KS6ABEZPIJAMS2G7GP3YSTJ6DIRIQ6YUU77ZAPI2LVT",
  // Sequence number
  "sequence_number": "123",
  // List of operations in this transaction
  "operations": [
    // First operation
    {
      // Operation type
      "type": "create_account",
      // Operation body
      "body": {
        // Don't send source field if operation source account is equal to transaction source account
        "source": "GBDCOZD7CHY26KS6ABEZPIJAMS2G7GP3YSTJ6DIRIQ6YUU77ZAPI2LVT",
        "destination": "GBDCOZD7CHY26KS6ABEZPIJAMS2G7GP3YSTJ6DIRIQ6YUU77ZAPI2LVT",
        "starting_balance": "50"
      }
    },
    // Second operation
    {
      "type": "payment",
      "body": {
        "source": "GBDCOZD7CHY26KS6ABEZPIJAMS2G7GP3YSTJ6DIRIQ6YUU77ZAPI2LVT",
        "destination": "GBDCOZD7CHY26KS6ABEZPIJAMS2G7GP3YSTJ6DIRIQ6YUU77ZAPI2LVT",
        "amount": "1050",
        "asset": {
          "code": "USD",
          "issuer": "GBDCOZD7CHY26KS6ABEZPIJAMS2G7GP3YSTJ6DIRIQ6YUU77ZAPI2LVT"
        }
      }
    },
    {
      "type": "path_payment",
      "body": {
        "source": "GBDCOZD7CHY26KS6ABEZPIJAMS2G7GP3YSTJ6DIRIQ6YUU77ZAPI2LVT",
        "destination": "GBDCOZD7CHY26KS6ABEZPIJAMS2G7GP3YSTJ6DIRIQ6YUU77ZAPI2LVT",
        "destination_amount": "10",
        "send_max": "1050",
        "send_asset": {
          "code": "USD",
          "issuer": "GBDCOZD7CHY26KS6ABEZPIJAMS2G7GP3YSTJ6DIRIQ6YUU77ZAPI2LVT"
        },
        "destination_asset": {
          "code": "EUR",
          "issuer": "GBDCOZD7CHY26KS6ABEZPIJAMS2G7GP3YSTJ6DIRIQ6YUU77ZAPI2LVT"
        },
        "path": [
          {}, // Native asset
          {
              "code": "ZAR",
              "issuer": "GBNIVKJTD2SMAXB5ALPBZ7CHRYYLCO5XSH55H6TI3Z37P7SCRXQVESG2"
            }
        ]
      }
    },
    {
        "type": "manage_offer",
        "body": {
          "selling": {
            "code": "EUR",
            "issuer": "GDOJMKTDLGGLROSSM5BV5MXIAQ3JZHASQFUV55WBJ45AFOUXSVVFGPTJ"
          },
          "buying": {
            "code": "USD",
            "issuer": "GACETOPHMOLSZLG5IQ3D6KQDKCAAYUYTTQHIEY6IGZE4VOBDD2YY6YAO"
          },
          "amount": "123456",
          "price": "2.93850088",
          "offer_id": "100"
        }
    },
    {
        "type": "create_passive_offer",
        "body": {
          "selling": {
            "code": "EUR",
            "issuer": "GDOJMKTDLGGLROSSM5BV5MXIAQ3JZHASQFUV55WBJ45AFOUXSVVFGPTJ"
          },
          "buying": {
            "code": "USD",
            "issuer": "GACETOPHMOLSZLG5IQ3D6KQDKCAAYUYTTQHIEY6IGZE4VOBDD2YY6YAO"
          },
          "amount": "123456",
          "price": "2.93850088"
        }
    },
    {
        "type": "set_options",
        "body": {
          "inflation_dest": "GBMPZVOMJ67WQBTBCVURDKTGL4557272EGQMAJCXPSMLOE63XPLL6SVA",
          "set_flags": [1, 2],
          "clear_flags": [4],
          "master_weight": 100,
          "low_threshold": 1,
          "medium_threshold": 2,
          "high_threshold": 3,
          "home_domain": "stellar.org",
          "signer": {
            "public_key": "GA6VMJJQM2QBPPIXK2UVTAOS4XSSSAKSCOGFQE55IMRBQR65GIVDTTQV",
            "weight": 5
          }
        }
    },
    {
      "type": "change_trust",
      "body": {
        "source": "GBDCOZD7CHY26KS6ABEZPIJAMS2G7GP3YSTJ6DIRIQ6YUU77ZAPI2LVT",
        "asset": {
          "code": "USD",
          "issuer": "GBDCOZD7CHY26KS6ABEZPIJAMS2G7GP3YSTJ6DIRIQ6YUU77ZAPI2LVT"
        }
      }
    },
    {
      "type": "allow_trust",
      "body": {
        "source": "GBDCOZD7CHY26KS6ABEZPIJAMS2G7GP3YSTJ6DIRIQ6YUU77ZAPI2LVT",
        "trustor": "GBDCOZD7CHY26KS6ABEZPIJAMS2G7GP3YSTJ6DIRIQ6YUU77ZAPI2LVT",
        "asset_code": "USD",
        "authorize": true
      }
    },
    {
        "type": "account_merge",
        "body": {
          "destination": "GBLH67TQHRNRLERQEIQJDNBV2DSWPHAPP43MBIF7DVKA7X55APUNS4LL"
        }
    },
    {
        "type": "inflation",
        "body": {}
    },
    {
        "type": "manage_data",
        "body": {
          "name": "test_data",
          "data": "AQIDBAUG"
        }
    }
  ],
  // Array of signers
  "signers": ["SDOTALIMPAM2IV65IOZA7KZL7XWZI5BODFXTRVLIHLQZQCKK57PH5F3H"]
}

Assets are represented by a JSON object with two fields: code and issuer. Empty JSON object represents native asset.

Response

When transaction can be successfully built it will return a JSON object with a single transaction_envelope field that will contain base64-encoded TransactionEnvelope XDR object:

{
    "transaction_envelope": "AAAAAEYnZH8R8a8qXgBJl6EgZLRvmfvEpp8NEUQ9i..."
}

In case of error it will return one of the following errors:

• InternalServerError
• InvalidParameterError

POST /payment

Builds and submits a transaction with a single payment, path_payment or create_account (when sending native asset to account that does not exist) operation built from following parameters.

Safe transaction resubmittion

It’s possible that you will not receive a response from Bridge server due to a bug, network conditions, etc. In such situation it’s impossible to determine the status of your transaction and sending the same request to the Bridge server may result in "double-spend" of the funds. That’s why you should always send a request with id parameter set. Then when you resubmit a transaction with the same id the previously used sequence number will be reused.

If the transaction has already been successfully applied to the ledger, Horizon server will simply return the saved result and not attempt to submit the transaction again. Only in cases where a transaction’s status is unknown (and thus will have a chance of being included into a ledger) will a resubmission to the network occur.

Request Parameters

Every request must contain required parameters from the following list. Additionally, depending on a type of payment, every request must contain required parameters for equivalent operation type.

The following request to /payment:

forward_destination[domain]=stellar.org&forward_destination[fields][forward_type]=bank_account&forward_destination[fields][swift]=BOPBPHMM&forward_destination[fields][acct]=2382376

will be translate to the following request:

https://FEDERATION_SERVER_READ_FROM_STELLAR_TOML/federation?type=forward&forward_type=bank_account&swift=BOPBPHMM&acct=2382376

Response

It will return SubmitTransactionResponse if there were no errors or with one of the following errors:

• InternalServerError
• InvalidParameterError
• MissingParameterError
• TransactionBadSequence
• TransactionBadAuth
• TransactionInsufficientBalance
• TransactionNoAccount
• TransactionInsufficientFee
• TransactionBadAuthExtra
• PaymentCannotResolveDestination
• PaymentCannotUseMemo
• PaymentSourceNotExist
• PaymentAssetCodeNotAllowed
• PaymentPending
• PaymentDenied
• PaymentMalformed
• PaymentUnderfunded
• PaymentSrcNoTrust
• PaymentSrcNotAuthorized
• PaymentNoDestination
• PaymentNoTrust
• PaymentNotAuthorized
• PaymentLineFull
• PaymentNoIssuer
• PaymentTooFewOffers
• PaymentOfferCrossSelf
• PaymentOverSendmax

Example

curl -X POST -d \
"source=SBNDIK4N7ZM3ZJKDJJDWDSPSRPHNI2RFL36WNNNEGQEW3G3AH6VJ2QB7&\
amount=1&\
destination=GBIUXI4S27PSL6TTJCJMPYDCF3K6AW2MYORFRTC7QBFE6NNEGVOQK46H&\
asset_code=USD&\
asset_issuer=GASZUHRFAFIZX5LR4WNHBWUXJBZNBEWCHFTR4XZHPF5TMVM5XUZBP5DT&\
memo_type=id&\
memo=125" \
http://localhost:8001/payment

POST /authorize

Can be used to authorize other accounts to hold your assets. It will build and submits a transaction with a allow_trust operation. The source of this transaction will be the account specified by accounts.authorizing_seed config parameter. You should make sure that this account is a low weight signer on the issuing account. See Multi-sig for more information.

Request Parameters

Response

It will return SubmitTransactionResponse if there were no errors or with one of the following errors:

• InternalServerError
• InvalidParameterError
• MissingParameterError
• TransactionBadSequence
• TransactionBadAuth
• TransactionInsufficientBalance
• TransactionNoAccount
• TransactionInsufficientFee
• TransactionBadAuthExtra
• AllowTrustMalformed
• AllowTrustNoTrustline
• AllowTrustTrustNotRequired
• AllowTrustCantRevoke

POST /reprocess

Can be used to reprocess received payment.

Request Parameters

Callbacks

The Bridge server listens for payment operations to the account specified by accounts.receiving_account_id. Every time a payment arrives it will send a HTTP POST request to callbacks.receive.

Content-Type of requests data will be application/x-www-form-urlencoded.

callbacks.receive

The POST request with following parameters will be sent to this callback when a payment arrives.

Warning! This callback can be called multiple times. Please check id parameter and respond with 200 OK in case of duplicate payment.

Request

Response

Respond with 200 OK when processing succeeded. Any other status code will be considered an error and bridge server will keep sending this payment request again and will not continue to next payments until it receives 200 OK response.

Payload Authentication

When the mac_key configuration value is set, the bridge server will attach HTTP headers to each payment notification that allow the receiver to verify that the notification is not forged. A header named X-Payload-Mac that contains a base64-encoded MAC value will be included. This MAC is derived by calculating the HMAC-SHA256 of the raw request body using the decoded value of the mac_key configuration option as the key.

This MAC can be used on the receiving side of the notification to verify that the payment notifications was generated from the bridge server, rather than from some other actor, to increase security.

Security

• This server must be set up in an isolated environment (ex. AWS VPC). Please make sure your firewall is properly configured and accepts connections from a trusted IPs only. You can set the api_key config parameter as an additional protection but it's not recommended as the solely protection. If you don't set this properly, an unauthorized person will be able to submit transactions from your accounts!
• Make sure the callbacks you provide only accept connections from the bridge server IP.
• Remember that callbacks.receive may be called multiple times with the same payment. Check id parameter and ignore requests with the same value (just send 200 OK response).

Building

gb is used for building and testing.

Given you have a running golang installation, you can build the server with:

gb build

After a successful build, you should find bin/bridge in the project directory.

Running tests

gb test

Documentation

godoc -goroot=. -http=:6060

Then simply open:

http://localhost:6060/pkg/github.com/caoxuwen/gateway/

in a browser.