Solana: the field guide

The short answer

Solana uses an account-based model with a parallelized execution runtime. Wallets are base58-encoded 32-byte public keys, transactions can carry multiple instructions to different on-chain programs, and fees are paid in SOL through two separate mechanisms: a fixed base fee and an optional priority fee.

That combination—cheap base costs, a competitive priority-fee market, and permissionless token creation—is what makes Solana the primary venue for very early, very fast memecoin trading.

The account model, in practice

Everything on Solana is an account: wallets, token balances, and program data all live in accounts with an owner, a data buffer, and a lamport balance. Programs themselves are stateless—logic lives in the program account, while the data it reads and writes lives in separate accounts the transaction explicitly lists.

Fungible tokens are not native balances on your wallet account. Each SPL token requires its own token account, almost always an Associated Token Account (ATA) deterministically derived from your wallet address and the token’s mint. A wallet holding ten different tokens has ten separate token accounts, each created and rented independently (Solana docs).

What you actually pay

Every Solana transaction charges a base fee, and most active trenchers also pay a priority fee. A separate, one-time rent deposit covers new accounts.

• Base fee. A fixed 5,000 lamports (0.000005 SOL) per signature, charged whether the transaction succeeds or fails. Half is burned, half goes to the validator that processed it (Solana docs).
• Priority fee. An optional bid—compute unit price × compute unit limit, divided by 1,000,000—that goes entirely to the validator and determines queue position during congestion (Solana fee structure).
• Rent. New accounts, including each token account, require a refundable minimum SOL deposit to stay rent-exempt. Closing the account returns the deposit.
• Jito tips. A separate payment—minimum 1,000 lamports—sent to one of Jito’s tip accounts to win inclusion in a bundle. Tips are not priority fees, and conflating the two is a common and costly mistake.

Base fees stay flat regardless of network demand; priority fees and tips are where real competition—and real cost—shows up during a hot launch. See Solana vs. Robinhood Chain fees, compared for how this fee stack stacks up against the EVM side.

What a Solana journal must reconstruct

1. Signatures and outcome. Whether the transaction landed, and every instruction it executed.
2. Fees, kept separate. Base fee, priority fee, and any Jito tip, distinguished from the trade itself.
3. Token account changes. Balance deltas across every SPL token account touched, not just the wallet’s SOL balance.
4. Program routes. Which programs were called—Pump.fun, PumpSwap, Jupiter, a DEX, or an unknown contract—and in what order.
5. Rent and account lifecycle. New token accounts opened, and any closed accounts that returned rent.

Every one of these facts is public and readable directly on a block explorer—see reading a block explorer for how to pull them yourself before trusting a dashboard's summary.

Where early Solana trading actually happens

Most trenching activity on Solana starts on a launchpad and a bonding curve, then migrates to a standard automated market maker once the token graduates.

• Pump.fun. New tokens launch on a constant-product bonding curve with a combined protocol and creator fee near 1.25% per trade. Price rises algorithmically with buys until the curve graduates (Pump.fun docs).
• PumpSwap. The AMM venue graduated tokens migrate into, where standard pooled liquidity and swap fees replace the bonding curve.
• Jupiter and other DEX routers. Aggregate liquidity across pools to fill a swap at the best available route, which matters once slippage tolerance and price impact become the binding constraint—see Jupiter and DEX routing for how that routing actually works.

For the full mechanics of how a curve prices a token before graduation, see bonding curves and launches, and for the fee schedule and canonical-pool mechanics on the PumpSwap side, see Pump.fun and PumpSwap: a deep dive.

Why this is not an EVM chain with new labels

Robinhood Chain and other EVM networks use transactions, receipts, contract logs, ERC-20 tokens, and ETH gas. Solana uses signatures, program instructions, account balance changes, SPL token accounts, and a two-part SOL fee. Both can feed a normalized journal, but the raw evidence, failure modes, and fee accounting differ completely.

Trenchables uses one adapter per chain feeding a single accounting model, with confidence measured separately per chain—so reliable Solana coverage can’t mask weak Robinhood Chain coverage, or the reverse.

Every SPL token account can also carry a delegate—Solana's own equivalent of an EVM approval, and a common target for drainers.

Moving value between Solana and an EVM chain like Robinhood Chain requires a bridge—neither chain can natively read the other's state.

Official sources