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.
mutation($type: SubWalletType!, $name: String!, $walletId: String!, ) {
createSubWallet(
createSubWalletInput: {
type: $type,
name: $name,
walletId: $walletId,
}
) {
subWalletId
receiveAddressDetails{
unverifiedAddress
path
publicKey
trustVaultProvenanceSignature
}
}
}Variables
{
"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 unverifiedAddress 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.
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
{
"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 nativeBNBor supportedBEP-20token. 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 theassetSymbolthen this field is the ultimate recipient of the transaction. If you are sendingBNBit will generate the underlying transaction. If you are sending a rawTransaction (see below), thetofield is the contract or EOA you want to send the transaction to. -
speed. Setting toFASTwill use the gas fee estimates provided by TrustVault. -
currency. This will return thechainRateof 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
fromAddressto an address you own. -
set the
toaddress as the contract you want to call. NB: Don't confuse this field when using this mutation to send a basicBEP-20transfer. (When using a supported token, thetois the ultimate recipient of the token and NOT the token contract).
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
{
"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.