Create a Binance Smart Chain Transaction including passing the raw transaction data using the GraphQL endpoint

Who is this tutorial for:

  • API users that will be using GraphQL directly
    • there will be documents soon for those wanting to use the SDK
  • API users that want to send Binance Smart Chain transactions
  • API users that want to send “Raw” Transactions for more complex transaction calls

Brief Outline

With the integration of Binance Smart Chain (BSC) to the TrustVault platform you can now use the TrustAPI to send BSC transactions.

The TrustAPI makes sending native BNB and BEP-20 tokens easy. BEP-20 tokens are very similar to Ethereum’s ERC-20 tokens. You can read about the differences, however for the sake of the TrustAPI’s usage, they operate the same.

Creating the BSC sub-wallet

To create the BSC subwallet simply use the createSubWallet endpoint passing in BINANCE_SMART_CHAIN as the type.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
mutation($type: SubWalletType!, $name: String!, $walletId: String!, ) {
createSubWallet(
createSubWalletInput: {
type: $type,
name: $name,
walletId: $walletId,
}
) {
subWalletId
receiveAddressDetails{
unverifiedAddress
path
publicKey
trustVaultProvenanceSignature
}
}
}

Variables

1
2
3
4
5
{
"type": "BINANCE_SMART_CHAIN",
"name": "My First BSC Sub-Wallet",
"walletId":"<walletIdGuid>"
}

Take note of the returned subWalletId of the form <walletIdGuid>/BINANCE_SMART_CHAIN/<index>. This can be used elsewhere. You should take note of the unverifiedAddress too as this will be needed in other endpoints.

NB: It is called unverfiedAddress because for safety you should verify the publicKey and signature and then derive the address from the trusted publicKey.

Sending native BNB

To send native BNB, you simply use the createEthereum GraphQL endpoint. Please note: The TrustAPI groups all EVM compatible chains into the createEthereum endpoint for simplicity. The key is to include the chainId when you want to interact with other chains. If you forget the chainId it will default to Ethereum mainnet (or testnet in our sandbox environment).

Below is an example of sending BNB to the BSC Testnet.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
mutation (
$from: String!,
$to: String!,
$value: String!,
$assetSymbol: String!
$speed: String
$currency: String
) {
createEthereumTransaction(
createTransactionInput: {
ethereumTransaction: {
assetSymbol: $assetSymbol
fromAddress: $from
to: $to
value: $value
speed: $speed
chainId: 97
}
source: "API"
currency: $currency
sendToNetworkWhenSigned: true
sendToDevicesForSigning: true
}
) {
... on CreateEthereumTransactionResponse {
requestId
}
signData {
transaction {
to
fromAddress
value
gasPrice
gasLimit
nonce
chainId
data
}
hdWalletPath {
hdWalletPurpose
hdWalletCoinType
hdWalletAccount
hdWalletUsage
hdWalletAddressIndex
}
unverifiedDigestData {
transactionDigest
signData: derDigestPath
shaSignData: shaDerDigestPath
}
}
assetRate
chainRate
}
}

Variables

1
2
3
4
5
6
7
8
{
"from": "0x23acD03521e93562eF777E11bB2AAa6e3C76F48D",
"to":"0x61Df7eAb4f740AFCeB8e468cb16d323f262e3990",
"assetSymbol": "BNB",
"value": "100000000000000",
"speed": "FAST",
"currency": "GBP"
}

Lets go through the input variables.

  • assetSymbol. This field is specified when you want to send either native BNB or supported BEP-20 token. Specifying this field is telling the API to construct the underlying transactions details for you.
  • fromAddress. This is the sub-wallet address you would like to send the transaction from. Please specify the correct subwallet.
  • to. This field can be used in 2 ways. If you are specifying the assetSymbol then this field is the ultimate recipient of the transaction. If you are sending BNB it will generate the underlying transaction. If you are sending a rawTransaction (see below), the to field is the contract or EOA you want to send the transaction to.
  • speed. Setting to FAST will use the gas fee estimates provided by TrustVault.
  • currency. This will return the chainRate of the desired (supported) currency.

Sending a “raw” transaction

The TrustAPI can do lots of the heavy lifting when creating a BSC transaction such as calculating the underlying transaction. However, this only works for basic BNB or BEP-20 transactions.

In order to send more complex transactions (e.g. contract invocation) but still take advantage of TrustVault’s features such as multi-sig signing, you will need to change the way you construct the transaction.

The following GraphQL mutation will allow you to construct a “raw” transaction. This is lower level transaction and will require you to specify the exact payload of the transaction. In the example below the transaction data is:

0xa9059cbb000000000000000000000000a346b347217d10b6a5925f870aa14e7695e4eabe000000000000000000000000000000000000000000000000000000001dcd6500

This is actually a transaction to send an BEP-20 transfer. In order to create this payload you will need to use a 3rd party library or construct the data yourself.

For this mutation to work you MUST:

  • remove the assetSymbol . Remember, if you set the asset symbol TrustVault assumes you are sending to a supported asset.
  • set the fromAddress to an address you own.
  • set the to address as the contract you want to call. NB: Don’t confuse this field when using this mutation to send a basic BEP-20 transfer. (When using a supported token, the to is the ultimate receiptient of the token and NOT the token contract).
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
mutation (
$from: String!,
$to: String!,
$value: String!,
$assetSymbol: String!
$data: String
) {
createEthereumTransaction(
createTransactionInput: {
ethereumTransaction: {
fromAddress: $from
to: $to
value: $value
speed: FAST
data: $data
chainId: 97
}
source: "API",
sendToNetworkWhenSigned: true
sendToDevicesForSigning: true
}
) {
... on CreateEthereumTransactionResponse {
requestId
}
signData {
transaction {
to
fromAddress
value
gasPrice
gasLimit
nonce
chainId
data
}
hdWalletPath {
hdWalletPurpose
hdWalletCoinType
hdWalletAccount
hdWalletUsage
hdWalletAddressIndex
}
unverifiedDigestData {
transactionDigest
signData
shaSignData
}
}
assetRate
chainRate
}
}

Variables

1
2
3
4
5
6
{
"from": "<Your Address>",
"to":"<Contract Address>",
"value": "0",
"data": "0xa9059cbb000000000000000000000000a346b347217d10b6a5925f870aa14e7695e4eabe000000000000000000000000000000000000000000000000000000001dcd6500"
}

This will create a transaction that will follow the regular multi-sig rules as any of your wallets and can be signed by iOS devices, external signing keys or our co-signing service as specified in your wallet policy.