Sample transactions for all types of transactions in main API
Overview
Here are some samples of the transaction object that is created in create transaction method. Rango currently returns 6 different types of transactions based on the blockchain that the transaction is happening on. This includes:
EVM: For all EVM-based blockchains, including Ethereum, Polygon, Avalanche, etc.
COSMOS: For all the cosmos-based networks, including the Cosmos itself, Osmosis, Akash, Thorchain, Maya and etc.
TRANSFER: For UTXO blockchains, including Bitcoin, Litecoin, Doge, etc.
Here is the structure of an EVM transaction in the code below.
If the user lacks sufficient approval for the transaction, the create transaction method will respond with an approval transaction. (isApproval field is true in this case.) The user must first sign this approval transaction to ensure they have the necessary approval. Then, they should call the create transaction method again to obtain and sign the main transaction. The fields and schema for the approval and main transactions are identical.
For the gas price of the transaction, if the blockchain supports the new versions of gas price, such as maxPriorityFeePerGas and maxFeePerGas, these fields will be populated. However, for blockchains that have not yet updated their gas model, the gas price will be set in the gasPrice field as before. You can check the list of all chains that support the new gas price versions in the meta or blockchains methods. (There is an enableGasV2 field in the response body, included for each blockchain.)
This type is only used in limited swappers like WYNDDex (and Juno Blockchain) and we are going to deprecate support for Cosmos Direct transaction types whenever possible. You could sign this type of transactions using Stargate Client library.
"transaction": {
"type": "COSMOS",
"fromWalletAddress": "juno1unf2rcytjxfpz8x8ar63h4qeftadptg54xrtf3",
"blockChain": "JUNO",
"data": {
"chainId": "juno-1",
"account_number": 125507,
"sequence": "309",
"msgs": [
{
"typeUrl": "/cosmwasm.wasm.v1.MsgExecuteContract",
"value": {
"sender": "juno1unf2rcytjxfpz8x8ar63h4qeftadptg54xrtf3",
"contract": "juno1pctfpv9k03v0ff538pz8kkw5ujlptntzkwjg6c0lrtqv87s9k28qdtl50w",
"msg": "eyJleGVjdXRlX3N3YXBfb3BlcmF0aW9ucyI6eyJvcGVyYXRpb25zIjpbeyJ3eW5kZXhfc3dhcCI6eyJhc2tfYXNzZXRfaW5mbyI6eyJuYXRpdmUiOiJpYmMvQzRDRkY0NkZENkRFMzVDQTRDRjRDRTAzMUU2NDNDOEZEQzlCQTRCOTlBRTU5OEU5QjBFRDk4RkUzQTIzMTlGOSJ9LCJvZmZlcl9hc3NldF9pbmZvIjp7Im5hdGl2ZSI6InVqdW5vIn19fV0sIm1heF9zcHJlYWQiOiIwLjAxIn19",
"funds": [
{
"denom": "ujuno",
"amount": "1000000"
}
]
}
}
],
"protoMsgs": [],
"memo": "",
"source": null,
"fee": {
"gas": "1000000",
"amount": [
{
"denom": "ujuno",
"amount": "2500"
}
]
},
// Sign type, could be AMINO or DIRECT
"signType": "DIRECT",
"rpcUrl": "https://rpc-juno.itastakers.com:443/"
},
// @deprecated An alternative to CosmosMessage object for the cosmos wallets
"rawTransfer": null
}
Here is the structure of an UTXO (Transfer) transaction:
"transaction": {
// This field equals to TRANSFER for all UTXO Transactions
"type": "TRANSFER",
// The method that should be passed to wallet including deposit, transfer
"method": "transfer",
// Source wallet address that can sign this transaction
"fromWalletAddress": "bc1qagtumlttplyp93fnxndkkcf80ladl4gpnmv25u",
// Destination wallet address that the fund should be sent to
"recipientAddress": "bc1qeqc7py84yjrtc3cnfnjx9p9xyvjm8887kexdfu",
// The memo of transaction, can be null
"memo": "=:ETH.ETH:0x6f33bb1763eebead07cf8815a62fcd7b30311fa3:1080176077:rg:0",
// The machine-readable amount of transaction
"amount": "1000000000",
// The decimals of the asset
"decimals": 8,
// An asset with its ticker
"asset": {
"blockchain": "BTC",
"symbol": "BTC",
"address": null,
"ticker": "BTC"
},
// list of available utxo for wallet address
"utxo": [
{
"txId": "dcc7dda1e5e2b33c649cb851e8290ff8ef41401db5946703cabee4b6cd9f163b",
"index": 0,
"script": "0014ea17cdfd6b0fc812c53334db6b61277ffadfd501",
"value": "2495200",
"blockHeight": "882563"
},
{
"txId": "6c9bf5dc24810010656635a95e5e4ce274dd76998d6733297b0cd0bc68c27a07",
"index": 1,
"script": "0014ea17cdfd6b0fc812c53334db6b61277ffadfd501",
"value": "655",
"blockHeight": "882419"
}
],
// Partially signed bitcoin transaction
"psbt": {
"unsignedPsbtBase64": "cHNidP8BAH0CAAAAAdeeknt27QIuENUtqyEuDWKi0HjMR6J8OyFIH0AeCowYAAAAAAD/////AoCWmAAAAAAAIlEgD5gCxhBANQBrbG92Di7Y0wPGEgBXxa9K7mVT0IIvONIM+SMCAAAAABYAFOoXzf1rD8gSxTM022thJ3/639UBAAAAAAABAR9QkbwCAAAAABYAFOoXzf1rD8gSxTM022thJ3/639UBAAAA",
"inputsToSign": [
{
"address": "bc1qagtumlttplyp93fnxndkkcf80ladl4gpnmv25u",
"signingIndexes": [
0
]
}
]
}
}
Here is the structure of a Tron transaction. Similar to EVM transactions, it can be either an approval transaction or a main transaction, depending on the isApproval field
Here is the structure of a Starknet transaction. Like EVM transactions, it can be either an approval transaction or a main transaction, depending on the isApproval field. Whenever possible, in Starknet, we batch the approval and main transactions into a single transaction using the calls array, as shown in the example below.
Remember to broadcast the signed transaction to Solana RPCs with base64 encoding. The base58 encoding is deprecated, but it is still the default method in Solana docs.
Versioned vs Legacy
All supported routes for Solana are VERSIONED transactions except a special case of converting SOL to WSOL or vice versa via Solana Wrapper. (which you can ignore it.)
"transaction": {
// This field equals to SOLANA for all SOLANA Transactions
"type": "SOLANA",
// Transaction blockchain
"blockChain": "SOLANA",
// Wallet address of transaction initiator
"from": "3HsNMDtxPRUzwLpDJemmNVbasm11Ei5CGGCjktgHh27F",
// Transaction identifier in case of retry
"identifier": "Swap",
// List of instructions
"instructions": [ ],
// Recent blockHash. Nullable. Filled only if message is already partially signed
"recentBlockhash": null,
// List of signatures. Filled only if message is already partially signed
"signatures": [ ],
// When serialized message appears, there is no need for other fields and you just sign and send it
"serializedMessage": [1, 0, 95, 96, ..., 1, 253],
// Could be LEGACY or VERSIONED
"txType": "VERSIONED"
}
The unsignedPtbBase64 field is a base64-encoded string that contains the transaction's raw data. This is typically used to create the signed transaction, which would then be broadcasted to the blockchain.
