{"id":136514,"date":"2026-02-19T07:26:40","date_gmt":"2026-02-19T07:26:40","guid":{"rendered":"https:\/\/mycryptomania.com\/?p=136514"},"modified":"2026-02-19T07:26:40","modified_gmt":"2026-02-19T07:26:40","slug":"how-to-decode-solana-transaction-data-and-how-it-differs-from-evm","status":"publish","type":"post","link":"https:\/\/mycryptomania.com\/?p=136514","title":{"rendered":"How to Decode Solana Transaction Data (and how it differs from EVM)"},"content":{"rendered":"

Photo by GuerrillaBuzz<\/a> on\u00a0Unsplash<\/a><\/p>\n

If you\u2019re coming from the EVM world, decoding Solana transactions can feel like learning a new language. In Ethereum, you\u2019d use ABIs and tools like ethers.js<\/a> to decode transaction data. In Solana, the process is different\u200a\u2014\u200abut once you understand it, it\u2019s just as powerful.<\/p>\n

This guide is for:<\/strong>
\u2022 EVM developers moving to Solana
\u2022 Backend engineers building indexers, bridges, analytics platforms,\u00a0\u2026<\/strong>
\u2022 Anyone decoding on-chain Solana\u00a0data<\/strong><\/p>\n

I\u2019ll walk you through decoding Solana transaction data using a real-world example: an on-chain auction program (i.e., smart contract). We\u2019ll use the Solana Transaction Parser library from Debridge Finance<\/a> and learn how to handle custom program instructions that aren\u2019t decoded by\u00a0default.<\/p>\n

Source code:<\/strong> https:\/\/github.com\/AndreAugusto11\/example-usage-solana-parser<\/a><\/p>\n

Getting Started<\/h3>\n

Before we dive in, clone the repository and set up your environment:<\/p>\n

git clone https:\/\/github.com\/AndreAugusto11\/example-usage-solana-parser.git
cd example-usage-solana-parser
npm install<\/p>\n

You\u2019ll also need TypeScript tooling:<\/p>\n

npm install -D typescript ts-node<\/p>\n

Requirements:<\/strong><\/p>\n

Node.js 18+ (recommended)npm<\/p>\n

EVM vs Solana: Understanding the Fundamentals<\/h3>\n

Before we dive into code, let\u2019s understand how transaction decoding differs between these two ecosystems.<\/p>\n

The EVM Approach: ABIs and Function Selectors<\/h4>\n

In Ethereum and other EVM chains, transaction decoding relies\u00a0on:<\/p>\n

ABIs (Application Binary Interfaces):<\/strong> JSON files that describe contract interfaces, including function signatures, parameter types, and return values. When you call a contract function, your transaction data includes:<\/p>\n

0x23b872dd \/\/ Function selector (first 4 bytes of keccak256 hash)
0000000… \/\/ Encoded parameters (ABI-encoded)<\/p>\n

Function selectors:<\/strong> The first 4 bytes of the keccak256 hash of the function signature (e.g., transfer(address,uint256)). Tools like ethers.js and web3.js use the ABI to automatically decode these transactions.<\/p>\n

The workflow is straightforward:<\/strong><\/p>\n

Get the contract ABI (from Etherscan or the\u00a0project)Pass it to your library (ethers.js, web3.js)The library handles all decoding automatically<\/p>\n

The Solana Approach: IDLs and Discriminators<\/h4>\n

Solana\u2019s architecture is fundamentally different. Programs are stateless and transactions can call multiple programs in sequence. This requires a different decoding approach:<\/p>\n

IDLs (Interface Description Language):<\/strong> Similar to ABIs, but specific to the Anchor framework (the most popular Solana development framework). An IDL describes:<\/p>\n

Instructions (equivalent to contract functions)Accounts (data structures stored on-chain)Types and their serialization format<\/p>\n

Discriminators:<\/strong> 8-byte identifiers (not 4 bytes like EVM) derived from the sha256 hash of a namespace and name. For instructions, this is global:instruction_name. For accounts, it’s account:account_name.<\/p>\n

c7385526 92f3259e \/\/ 8-byte discriminator (first 8 bytes of sha256)
0000000… \/\/ Borsh-serialized parameters<\/p>\n

The key differences:<\/strong><\/p>\n

Comparison between EVM and\u00a0Solana<\/p>\n

Why Solana Decoding is More\u00a0Manual<\/h4>\n

In the EVM world, most tools come with built-in ABI decoding. Pass in an ABI, and you\u2019re done. In Solana, while the Anchor framework provides IDLs, you often need\u00a0to:<\/p>\n

Fetch and fix IDLs:<\/strong> IDLs from explorers may be incompleteCalculate discriminators manually:<\/strong> These aren\u2019t always included in IDL\u00a0filesImplement custom parsers:<\/strong> The Solana Transaction Parser library doesn\u2019t know about your custom\u00a0programsHandle Borsh serialization:<\/strong> You need to understand the binary layout of your\u00a0data<\/p>\n

This might seem more complex, but it gives you fine-grained control over transaction parsing and a deeper understanding of what\u2019s happening on-chain.<\/p>\n

What We\u2019ll\u00a0Build<\/h4>\n

In this tutorial, we\u2019ll decode transactions from Mayan Swift\u2019s auction program (Mayan Swift is a fast bridge between multiple blockchains, serving as a very important piece in the Solana ecosystem, https:\/\/docs.mayan.finance\/architecture\/swift<\/a>). You\u2019ll learn\u00a0to:<\/p>\n

Extract and prepare IDL\u00a0filesCalculate discriminators for instructions and\u00a0accountsBuild a custom decoder that transforms raw buffers into readable\u00a0dataIntegrate your decoder with the Solana Transaction Parser<\/p>\n

By the end, you\u2019ll be able to decode any Anchor-based Solana program\u2019s transactions.<\/p>\n

The Problem: Unknown Instructions<\/h3>\n

Now let\u2019s see this in action. We want to decode data from Mayan Swift\u2019s auction program (9w1D9okTM8xNE7Ntb7LpaAaoLc6LfU9nHFs2h2KTpX1H).<\/p>\n

Here\u2019s our starting point\u200a\u2014\u200aa transaction hash from a bid instruction: Ahy9GEyiPzkrw54Js6rw43bD6m6V3zmDDK6nn6e8N2tskrbkiozhsMjcdBLvCgH5JAc8CFyUZiwWpyCNqQ4wmQb.Feel free to choose another from https:\/\/solscan.io\/account\/9w1D9okTM8xNE7Ntb7LpaAaoLc6LfU9nHFs2h2KTpX1H<\/a><\/p>\n

Let\u2019s try to parse it without any custom decoders. Create a file src\/no-custom-decoder.ts:<\/p>\n

import { Connection, clusterApiUrl } from “@solana\/web3.js”;
import { SolanaParser } from “@debridge-finance\/solana-transaction-parser”;const rpcConnection = new Connection(clusterApiUrl(“mainnet-beta”));
const txParser = new SolanaParser([]);const parsed = await txParser.parseTransactionByHash(
rpcConnection,
“Ahy9GEyiPzkrw54Js6rw43bD6m6V3zmDDK6nn6e8N2tskrbkiozhsMjcdBLvCgH5JAc8CFyUZiwWpyCNqQ4wmQb”
);console.log(JSON.stringify(parsed, null, 2));<\/p>\n

Run it\u00a0with:<\/p>\n

npx ts-node src\/no-custom-decoder.ts<\/p>\n

The parser successfully decodes some instructions automatically\u200a\u2014\u200athe compute budget instructions and system program calls are recognized because they\u2019re common programs already loaded into the parser by\u00a0default:<\/p>\n

[
{
name: ‘setComputeUnitLimit’,
accounts: [],
args: { units: 74200 },
programId: ‘ComputeBudget111111111111111111111111111111’
},
{
name: ‘setComputeUnitPrice’,
accounts: [],
args: { microLamports: 60000 },
programId: ‘ComputeBudget111111111111111111111111111111’
},
\/\/ … but then we hit our auction instruction:
{
programId: ‘9w1D9okTM8xNE7Ntb7LpaAaoLc6LfU9nHFs2h2KTpX1H’,
accounts: [ … ],
args: {
unknown: <Buffer c7 38 55 26 92 f3 25 9e 00 00 00 00 00 00 00 00 …>
},
name: ‘unknown’
}
]<\/p>\n

That unknown Buffer is your encoded instruction data\u2014255 bytes of Borsh-serialized parameters that the parser can’t decode without the program’s IDL. This is where our work\u00a0begins.<\/p>\n

Step 1: Get the\u00a0IDL<\/h3>\n

First, fetch the IDL for your program. For Anchor programs, you can find this on\u00a0Solscan:<\/p>\n

Solscan:<\/strong> https:\/\/solscan.io\/account\/9w1D9okTM8xNE7Ntb7LpaAaoLc6LfU9nHFs2h2KTpX1H#anchorProgramIdl<\/a><\/p>\n

Save the JSON file to src\/idl\/swift_auction.json.<\/p>\n

Step 2: Convert IDL to TypeScript<\/h3>\n

Install the Anchor IDL to TypeScript converter, such that the tool can parse its data\u00a0types:<\/p>\n

cargo install simple-anchor-idl-ts<\/p>\n

Run the converter:<\/p>\n

simple-anchor-idl-ts src\/idl\/swift_auction.json<\/p>\n

This creates src\/idl\/swift_auction.ts with TypeScript type definitions.<\/p>\n

Step 3: Fix the IDL (Making it Anchor-Compliant)<\/h3>\n

The IDL exported from Solscan is incomplete and won\u2019t work with Anchor\u2019s TypeScript client. We need to fix three critical issues to make it compliant with the Anchor IDL specification. Think of this as the difference between a draft ABI and a production-ready one.<\/p>\n

Issue #1: Missing address and metadata\u00a0fields<\/h4>\n

The Anchor IDL specification requires these fields at the root level, but Solscan\u2019s export omits them. Without these, the Anchor TypeScript client won\u2019t recognize the IDL structure.<\/p>\n

Why it matters:<\/strong> The address field ties the IDL to the specific on-chain program, while metadata provides versioning and spec information that tools use for compatibility checks.<\/p>\n

At the top of your IDL type definition, add:<\/p>\n

export type SwiftAuctionIDLType = {
“version”: “0.1.0”,
“name”: “swift_auction”,
“address”: “9w1D9okTM8xNE7Ntb7LpaAaoLc6LfU9nHFs2h2KTpX1H”, \/\/ Add this
“metadata”: { \/\/ Add this
“name”: “Swift Auction”,
“version”: “0.1.0”,
“spec”: “”
},
“instructions”: [
\/\/ …
]
}<\/p>\n

Don\u2019t forget to update the corresponding SwiftAuctionIDL object (around line 408) with the same\u00a0fields.<\/p>\n

Issue #2: Missing discriminators<\/h4>\n

This is the critical part. Remember those 8-byte discriminators we discussed earlier? They\u2019re how Solana programs route instructions and identify account types. Without them, we can\u2019t match instruction data to the correct decoder function.<\/p>\n

Why it matters:<\/strong> When a transaction comes in with data starting with c7 38 55 26 92 f3 25 9e, we need to know that it maps to the bid instruction. Discriminators make this possible.<\/p>\n

Create a helper script calculate-discriminator.js:<\/p>\n

const crypto = require(‘crypto’);const name = process.argv[2];
if (!name) {
console.log(‘Usage: node calculate-discriminator.js <namespace:name>’);
process.exit(1);
}const hash = crypto.createHash(‘sha256’).update(name).digest();
const discriminator = Array.from(hash.slice(0, 8));
console.log(`Discriminator: “discriminator”: [${discriminator.join(‘, ‘)}]`);<\/p>\n

Now calculate discriminators for each instruction using the global: namespace:<\/p>\n

node calculate-discriminator.js global:bid
# Output: “discriminator”: [199, 56, 85, 38, 146, 243, 37, 158]node calculate-discriminator.js global:postAuction
# Output: “discriminator”: [123, 68, 53, 83, 90, 211, 160, 63]node calculate-discriminator.js global:closeAuction
# Output: “discriminator”: [214, 18, 110, 197, 2, 7, 153, 74]node calculate-discriminator.js global:updateConfig
# Output: “discriminator”: [102, 77, 158, 235, 28, 216, 191, 121]<\/p>\n

And for accounts using the account: namespace:<\/p>\n

node calculate-discriminator.js account:auctionState
# Output: “discriminator”: [110, 220, 44, 10, 38, 234, 132, 215]node calculate-discriminator.js account:auctionTime
# Output: “discriminator”: [173, 208, 94, 49, 209, 242, 0, 214]<\/p>\n

Add these discriminators to each instruction and account definition in your IDL file. For\u00a0example:<\/p>\n

{
“name”: “bid”,
“discriminator”: [199, 56, 85, 38, 146, 243, 37, 158], \/\/ Add this array
“accounts”: [ … ],
“args”: [ … ]
}<\/p>\n

Pro tip:<\/strong> Notice how the first bytes of our unknown buffer (c7 38 55 26…) match the bid discriminator? That’s how we’ll route it to the right\u00a0decoder!<\/p>\n

Issue #3: Fix defined type references<\/h4>\n

The IDL converter sometimes generates incorrect type references. The Anchor specification expects a specific format for custom type definitions.<\/p>\n

Why it matters:<\/strong> Without the correct format, the TypeScript types won\u2019t compile, and your decoder won\u2019t\u00a0work.<\/p>\n

Find any instances of:<\/p>\n

“defined”: “OrderInfo”<\/p>\n

And change them\u00a0to:<\/p>\n

“defined”: {
“generics”: [],
“name”: “OrderInfo”
}<\/p>\n

This matches the Anchor IDL specification for type references and ensures proper TypeScript type generation.<\/p>\n

Verification<\/h4>\n

After these fixes, your IDL should be fully Anchor-compliant. You can verify this by checking\u00a0that:<\/p>\n

The root object has address and metadata\u00a0fieldsEvery instruction and account has a discriminator arrayAll defined types use the object\u00a0notation<\/p>\n

Now we\u2019re ready to build the actual\u00a0decoder!<\/p>\n

Step 4: Build Your Custom\u00a0Decoder<\/h3>\n

Now comes the exciting part: transforming raw bytes into meaningful data. We\u2019ll build a decoder that mimics how Anchor programs read instruction data on-chain.<\/p>\n

Understanding the Decoding\u00a0Strategy<\/h4>\n

When a Solana program receives instruction data, it follows this\u00a0pattern:<\/p>\n

Read the discriminator<\/strong> (first 8 bytes) to identify which instruction was\u00a0calledDeserialize the remaining bytes<\/strong> using Borsh according to the instruction\u2019s argument structure<\/p>\n

Our decoder will do the same thing, but in TypeScript rather than\u00a0Rust.<\/p>\n

Setting Up the\u00a0Parser<\/h4>\n

Create src\/custom-parsers\/swift-auction-parser.ts:<\/p>\n

import { TransactionInstruction } from “@solana\/web3.js”;
import { SwiftAuctionIDL, SwiftAuctionIDLType } from “..\/idl\/swift_auction”;
import {
ParsedIdlInstruction,
ParsedInstruction
} from “@debridge-finance\/solana-transaction-parser”;
import { decodeOrderInfo } from “..\/decodeOrderInfo”;
import BN from “bn.js”;\/\/ Extract function selectors (first byte of each discriminator)
\/\/ This creates a lookup table: { “bid”: 199, “postAuction”: 123, … }
const FUNCTION_SELECTORS = SwiftAuctionIDL[“instructions”].reduce((acc, i) => {
acc[i.name] = i.discriminator[0];
return acc;
}, {} as Record<string, number>);function decodeSwiftAuctionInstruction(
instruction: TransactionInstruction
): ParsedInstruction<SwiftAuctionIDLType> {<\/p>\n

\/\/ The first byte tells us which instruction this is
const instruction_selector = instruction.data[0];<\/p>\n

\/\/ Everything after byte 0 is the Borsh-serialized arguments
const remaining_data = instruction.data.slice(1); \/\/ Route to the appropriate decoder based on the selector
switch (instruction_selector) {
case FUNCTION_SELECTORS[“bid”]:
return decodeBidInstruction(instruction, remaining_data);<\/p>\n

case FUNCTION_SELECTORS[“postAuction”]:
\/\/ You would implement this similarly
throw new Error(“postAuction decoder not yet implemented”);<\/p>\n

\/\/ Add more cases for other instructions as needed
default:
throw new Error(`Unknown instruction selector: ${instruction_selector}`);
}
}export { decodeSwiftAuctionInstruction };<\/p>\n

What\u2019s happening here:<\/strong><\/p>\n

We use only the first byte<\/strong> of the discriminator as a selector (in practice, using all 8 bytes is more collision-resistant, but the first byte works for small instruction sets)We slice off the first byte and pass the remaining data to instruction-specific decodersEach decoder knows the exact memory layout of its arguments<\/p>\n

Decoding the Bid Instruction<\/h4>\n

Now let\u2019s implement the decoder for the bid instruction:<\/p>\n

function decodeBidInstruction(
instruction: TransactionInstruction,
data: Buffer
): ParsedIdlInstruction<SwiftAuctionIDLType, “bid”> {<\/p>\n

return {
name: “bid”,
programId: instruction.programId,<\/p>\n

\/\/ Map instruction accounts to their semantic names
\/\/ The order matches the IDL’s account definition
accounts: [
{ name: “config”, pubkey: instruction.keys[0].pubkey },
{ name: “driver”, pubkey: instruction.keys[1].pubkey },
{ name: “auctionState”, pubkey: instruction.keys[2].pubkey },
{ name: “systemProgram”, pubkey: instruction.keys[3].pubkey },
],<\/p>\n

\/\/ Decode the arguments according to the IDL structure
args: {
\/\/ The ‘order’ field is a complex struct defined in the IDL
\/\/ We need a custom decoder for it (see below)
order: decodeOrderInfo(data),<\/p>\n

\/\/ The ‘amountBid’ field is a u64 at the end of the buffer
\/\/ Read it as a big-endian 64-bit unsigned integer
amountBid: new BN(data.readBigUInt64LE(data.length – 8)),
}
} as ParsedIdlInstruction<SwiftAuctionIDLType, “bid”>;
}<\/p>\n

Key points:<\/strong><\/p>\n

Accounts mapping:<\/strong> The IDL tells us each account\u2019s purpose. We map instruction.keys array indices to semantic\u00a0namesArgument layout:<\/strong> According to the IDL, a bid instruction has two arguments: order (a struct) and amountBid (a\u00a0u64)Borsh deserialization:<\/strong> The order struct comes first in the buffer, followed by the u64 at the\u00a0end<\/p>\n

Decoding Complex\u00a0Structs<\/h4>\n

The OrderInfo struct contains multiple fields with different types. You’ll need to create src\/decodeOrderInfo.ts to handle\u00a0this:<\/p>\n

import BN from “bn.js”;export function decodeOrderInfo(data: Buffer) {
let offset = 0;<\/p>\n

\/\/ Read each field according to the IDL type definition
\/\/ Borsh serializes fields sequentially in declaration order<\/p>\n

const trader = Array.from(data.slice(offset, offset + 32));
offset += 32;<\/p>\n

const chainSource = data.readUInt16LE(offset);
offset += 2;<\/p>\n

const tokenIn = Array.from(data.slice(offset, offset + 32));
offset += 32;<\/p>\n

const addrDest = Array.from(data.slice(offset, offset + 32));
offset += 32;<\/p>\n

const chainDest = data.readUInt16LE(offset);
offset += 2;<\/p>\n

const tokenOut = Array.from(data.slice(offset, offset + 32));
offset += 32;<\/p>\n

\/\/ Continue for all fields defined in the OrderInfo struct…
const amountOutMin = new BN(data.slice(offset, offset + 8), ‘le’);
offset += 8;<\/p>\n

\/\/ … and so on for the remaining fields<\/p>\n

return {
trader,
chainSource,
tokenIn,
addrDest,
chainDest,
tokenOut,
amountOutMin,
\/\/ … other fields
};
}<\/p>\n

The pattern:<\/strong><\/p>\n

Start at offset\u00a00Read each field according to its type (u8, u16, u64, [u8; 32],\u00a0etc.)Advance the offset by the field\u2019s\u00a0sizeReturn an object matching the IDL\u2019s type definition<\/p>\n

This is exactly how Borsh deserialization works\u200a\u2014\u200asequential, fixed-layout reads.<\/p>\n

Integrating with the\u00a0Parser<\/h4>\n

Finally, register your custom decoder with the Solana Transaction Parser. Create src\/auction-custom-decoder.ts:<\/p>\n

import { Connection, clusterApiUrl } from “@solana\/web3.js”;
import { SolanaParser } from “@debridge-finance\/solana-transaction-parser”;
import { decodeSwiftAuctionInstruction } from “.\/custom-parsers\/swift-auction-parser”;const SWIFT_AUCTION_PROGRAM_ID = “9w1D9okTM8xNE7Ntb7LpaAaoLc6LfU9nHFs2h2KTpX1H”;const rpcConnection = new Connection(clusterApiUrl(“mainnet-beta”));\/\/ Create parser with custom decoder
const txParser = new SolanaParser([
{
programId: SWIFT_AUCTION_PROGRAM_ID,
instructionParser: decodeSwiftAuctionInstruction,
}
]);\/\/ Parse the same transaction we tried earlier
const parsed = await txParser.parseTransactionByHash(
rpcConnection,
“Ahy9GEyiPzkrw54Js6rw43bD6m6V3zmDDK6nn6e8N2tskrbkiozhsMjcdBLvCgH5JAc8CFyUZiwWpyCNqQ4wmQb”
);console.log(JSON.stringify(parsed, null, 2));<\/p>\n

Run it\u00a0with:<\/p>\n

npx ts-node src\/auction-custom-decoder.ts<\/p>\n

The parser will now use your custom decoder whenever it encounters an instruction from the Swift Auction\u00a0program!<\/p>\n

Running the\u00a0Examples<\/h3>\n

To see the difference between parsed and unparsed transactions:<\/p>\n

Without custom\u00a0decoder:<\/strong><\/p>\n

npx ts-node src\/no-custom-decoder.ts<\/p>\n

With custom\u00a0decoder:<\/strong><\/p>\n

npx ts-node src\/auction-custom-decoder.ts<\/p>\n

The second command will show the fully decoded bid instruction with all its parameters visible and readable.<\/p>\n

The Result: From Bytes to\u00a0Meaning<\/h3>\n

Let\u2019s compare what we had before and after implementing our custom\u00a0decoder.<\/p>\n

Before (Unknown\u00a0Buffer):<\/h4>\n

{
programId: ‘9w1D9okTM8xNE7Ntb7LpaAaoLc6LfU9nHFs2h2KTpX1H’,
accounts: [ … ],
args: {
unknown: <Buffer c7 38 55 26 92 f3 25 9e 00 00 00 00 00 00 00 00 …>
},
name: ‘unknown’
}<\/p>\n

After (Fully Decoded):<\/h4>\n

{
name: ‘bid’,
programId: ‘9w1D9okTM8xNE7Ntb7LpaAaoLc6LfU9nHFs2h2KTpX1H’,
accounts: [
{ name: ‘config’, pubkey: ’93boUvm9QnkHTa5sUGMuFegLaxYsJQVMrNCAz7HojnY5′ },
{ name: ‘driver’, pubkey: ‘B88xH3Jmhq4WEaiRno2mYmsxV35MmgSY45ZmQnbL8yft’ },
{ name: ‘auctionState’, pubkey: ‘Cq8nomBLmD4LwrYBA4J3Wk6C4GtcRT72Nb5e1RJcdk8C’ },
{ name: ‘systemProgram’, pubkey: ‘11111111111111111111111111111111’ }
],
args: {
order: {
trader: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 43, 90, 122, 111, …],
chainSource: 30,
tokenIn: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 131, 53, 137, 252, …],
addrDest: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 43, 90, 122, 111, …],
chainDest: 4,
tokenOut: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 85, 211, 152, 50, …],
amountOutMin: <BN: 39ccb90fc0>, \/\/ 250,000,000,000 (250 USDC)
gasDrop: <BN: 0>,
feeCancel: <BN: 1edf>, \/\/ 7,903 lamports
feeRefund: <BN: 45e>, \/\/ 1,118 lamports
deadline: <BN: 685e7892>, \/\/ Unix timestamp
addrRef: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 165, 170, 110, 33, …],
feeRateRef: 0,
feeRateMayan: 3, \/\/ 0.03% fee
auctionMode: 2, \/\/ Dutch auction
keyRnd: [74, 172, 120, 171, 220, 249, 5, 206, …] \/\/ Random key
},
amountBid: <BN: 3a1d331485> \/\/ 250,123,456,645 lamports
}
}<\/p>\n

Now we can see exactly<\/strong> what this transaction does:<\/p>\n

Instruction:<\/strong> A user is placing a bid in an\u00a0auctionAccounts:<\/strong> The bid interacts with a specific config, driver, and auction state\u00a0accountParameters:<\/strong>The order details show a cross-chain swap from chain 30 to chain\u00a04<\/p>\n

2. The minimum output amount is 250\u00a0USDC<\/p>\n

3. The bid amount is ~250.12\u00a0SOL<\/p>\n

4. It\u2019s a Dutch auction (mode 2) with a 0.03% Mayan\u00a0fee<\/p>\n

5. Includes deadline, fee structures, and referral information<\/p>\n

What We Accomplished<\/h3>\n

Remember our theoretical comparison at the beginning? We\u2019ve successfully:<\/p>\n

Fetched the IDL<\/strong> (Solana\u2019s equivalent of an\u00a0ABI)Calculated 8-byte discriminators<\/strong> (vs EVM\u2019s 4-byte selectors)Implemented Borsh deserialization<\/strong> (vs ABI decoding)Built a custom parser<\/strong> (vs automatic ethers.js decoding)<\/p>\n

Key Takeaways for EVM Developers<\/h3>\n

If you\u2019re transitioning from Ethereum to Solana, here are the essential mindset\u00a0shifts:<\/p>\n

1. IDLs vs ABIs: Similar Purpose, Different Implementation<\/h4>\n

EVM:<\/strong> ABIs are universally supported. Pass one to ethers.js and you\u2019re\u00a0done.<\/p>\n

Solana:<\/strong> IDLs are Anchor-specific and require more manual setup. But this gives you visibility into exactly how data flows through your programs.<\/p>\n

2. Discriminators vs Function Selectors: More Bytes, More\u00a0Context<\/h4>\n

EVM:<\/strong> 4-byte function selectors from keccak256(functionSignature).slice(0,4)<\/p>\n

Example: transfer(address,uint256) \u2192 0xa9059cbb<\/p>\n

Solana:<\/strong> 8-byte discriminators from sha256(namespace:name).slice(0,8)<\/p>\n

Example: global:bid \u2192 [199, 56, 85, 38, 146, 243, 37,\u00a0158]<\/p>\n

The extra bytes reduce collision risk (which has been used in the past in contract exploits) and support namespacing for instructions, accounts, and\u00a0events.<\/p>\n

3. Decoding Tools: Automatic vs\u00a0Manual<\/h4>\n

EVM ecosystem:<\/strong><\/p>\n

const contract = new ethers.Contract(address, abi, provider);
const tx = await contract.populateTransaction.transfer(to, amount);
\/\/ Everything decoded automatically<\/p>\n

Solana ecosystem:<\/strong><\/p>\n

const txParser = new SolanaParser([customDecoder]);
const parsed = await txParser.parseTransactionByHash(connection, hash);
\/\/ Custom decoders required for new programs<\/p>\n

The Solana approach requires more initial work but teaches you the internals of program communication.<\/p>\n

Next Steps<\/h3>\n

Now that you can decode transaction data, you\u00a0can:<\/p>\n

Build transaction explorersCreate analytics dashboardsBuild indexers for your\u00a0dApps<\/p>\n

The full source code is available on GitHub: https:\/\/github.com\/AndreAugusto11\/example-usage-solana-parser<\/a><\/p>\n

Additional Resources:<\/strong><\/p>\n

DeBridge Finance Solana Transaction Parser<\/a>Anchor Framework Documentation<\/a>Solana Program\u00a0Library<\/a><\/p>\n

Welcome to Solana!\u00a0\ud83d\ude80<\/p>\n

Found this helpful? Follow me for more tutorials and cross-chain insights.<\/em><\/p>\n

How to Decode Solana Transaction Data (and how it differs from EVM)<\/a> was originally published in Coinmonks<\/a> on Medium, where people are continuing the conversation by highlighting and responding to this story.<\/p>","protected":false},"excerpt":{"rendered":"

Photo by GuerrillaBuzz on\u00a0Unsplash If you\u2019re coming from the EVM world, decoding Solana transactions can feel like learning a new language. In Ethereum, you\u2019d use ABIs and tools like ethers.js to decode transaction data. In Solana, the process is different\u200a\u2014\u200abut once you understand it, it\u2019s just as powerful. This guide is for: \u2022 EVM developers […]<\/p>\n","protected":false},"author":0,"featured_media":136515,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-136514","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-interesting"],"_links":{"self":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/posts\/136514"}],"collection":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=136514"}],"version-history":[{"count":0,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/posts\/136514\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/media\/136515"}],"wp:attachment":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=136514"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=136514"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=136514"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}