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 | mutation($type: SubWalletType!, $name: String!, $walletId: String!, ) { |
Variables
1 | { |
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 | mutation ( |
Variables
1 | { |
Lets go through the input variables.
assetSymbol
. This field is specified when you want to send either nativeBNB
or supportedBEP-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 theassetSymbol
then this field is the ultimate recipient of the transaction. If you are sendingBNB
it will generate the underlying transaction. If you are sending a rawTransaction (see below), theto
field is the contract or EOA you want to send the transaction to.speed
. Setting toFAST
will use the gas fee estimates provided by TrustVault.currency
. This will return thechainRate
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 basicBEP-20
transfer. (When using a supported token, theto
is the ultimate receiptient of the token and NOT the token contract).
1 | mutation ( |
Variables
1 | { |
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.