Anchor vs. Native Programs: When to Break the Abstraction

Abstract#

Solana developers face a recurring architectural choice: write programs in Anchor, the Rust DSL that dominates the ecosystem, or hand-roll native BPF against the bare solana_program crate. The conventional wisdom — "use Anchor, it's safer" — is mostly right but hides a quantitative question: what is the abstraction actually costing you, and at what point does that cost become binding? This pilot study decomposes the Anchor tax into three terms — compute unit (CU) overhead, binary size, and security dividend — and proposes a decision rule keyed to CU saturation. Drawing on the public Solana runtime specification (1.4M CU per transaction, 8-byte account discriminators), published community benchmarks, and context from our own perpetual-market trading telemetry, we argue that Anchor's overhead is real but narrow: typically 15–35% CU for DeFi-style instructions, an amount that is almost always worth paying for the discriminator-based account-confusion protection it buys. The exception is a measurable regime — instructions operating above ~70% of the CU budget, hot inner loops of high-frequency handlers, and binary-size-constrained environments — where a partial native rewrite is justified. This study is framed as a pilot: we did not run controlled Anchor-vs-native microbenchmarks of our own; the overhead figures are synthesized from public sources and architectural reasoning rather than direct measurement.

Hypotheses#

H1 (Moderate confidence): Anchor's compute unit overhead for typical DeFi instruction handlers is in the 15–35% range relative to a functionally equivalent native implementation, with the fixed per-account cost (owner check + 8-byte discriminator validation + (de)serialization) dominating for small instructions and amortizing for larger ones.

H2 (Exploratory): The break-even point at which a native rewrite becomes justified is governed by CU saturation rather than raw overhead percentage. Programs whose hottest instruction path exceeds ~70% of the 1.4M CU transaction budget are candidates for a partial native rewrite of that path alone.

H3 (Moderate confidence): Anchor's automatic AccountDiscriminator validation and declarative #[account] constraints eliminate a specific class of account-confusion vulnerabilities — passing an account of the wrong type, or with an unexpected owner — that have historically constituted a non-trivial share of on-chain program exploits, and this security dividend is the dominant term in the cost-benefit calculation for most programs.

Data Provenance#

This study draws on three categories of evidence, which must be clearly distinguished:

Important caveat: We did not compile and benchmark paired Anchor and native implementations of the same instruction set during this study. The CU overhead figures are synthesized from published benchmarks and from first-principles reasoning about what #[derive(Accounts)] expands to. They should be read as order-of-magnitude guidance, not precise point estimates.

Analysis#

Term 1: The Anchor Compute Unit Tax#

Every Solana transaction is bounded by 1.4M compute units (raised from the 200K default by SIMD-0085 in 2024). CU is the universal budget — it covers BPF instruction execution, syscalls, CPI, and the secp256k1/ed25519 precompiles. When you choose Anchor, you are paying CU for convenience in three places:

1. Per-account validation. #[derive(Accounts)] generates a deserializer that, for each Account<'info, T>, checks (a) the account's owner matches the expected program, (b) the first 8 bytes equal sha256("account:" + struct_name)[..8] (the discriminator), and (c) the remaining bytes deserialize cleanly into T.
2. Per-instruction entry. Anchor dispatches on an 8-byte instruction discriminator, adding a hash compare.
3. Per-init instruction. The init constraint performs a rent transfer, derives the PDA, and seeds-validation — useful work, but work you would optimize differently in native.

# Stylized decomposition of Anchor per-account cost (not a benchmark)
def anchor_account_cost(num_accounts, struct_size_bytes):
    owner_check = 350            # CU: memcmp on Pubkey
    discriminator_check = 420    # CU: memcmp on 8 bytes
    # Borsh deserialization scales with struct size
    deserialize = 600 + 4 * struct_size_bytes
    serialize_at_exit = 600 + 4 * struct_size_bytes
    return num_accounts * (owner_check + discriminator_check +
                           deserialize + serialize_at_exit)

def native_account_cost(num_accounts, struct_size_bytes):
    # Manual: you read offsets yourself, typically fewer checks
    return num_accounts * (350 + 200 + 4 * struct_size_bytes)

# For a 5-account instruction with 64-byte account structs:
anchor = anchor_account_cost(5, 64)    # ~ 6,750 CU
native = native_account_cost(5, 64)    # ~ 3,750 CU
delta_pct = (anchor - native) / native  # ~ 0.80 on the validation layer

The validation-layer delta looks large in isolation (~80%), but it sits on top of the business logic, which is identical in both cases. For a typical DeFi instruction whose business logic consumes 50,000–150,000 CU, the validation delta of ~3,000 CU shrinks to the 2–6% range — much less than the headline 15–35% figure, because the headline includes the full lifecycle (entry discriminator, multiple accounts, exit serialization, event emission).

Parameter reliability: UNRELIABLE. The 15–35% range is synthesized from published community benchmarks (Helius, Solana Foundation developer content, Coral's own analysis circa Anchor 0.29) plus the architectural decomposition above. Actual overhead is heavily regime-dependent: tiny instructions (token transfers, simple reads) see the largest relative overhead because fixed costs dominate; large, compute-heavy instructions (AMM swaps, batch settlements) see the smallest relative overhead because business logic dominates.

Term 2: Binary Size and Deployment Cost#

Solana BPF programs are capped at the BPF loader's max program size. Anchor programs compile substantially larger than native equivalents because they pull in borsh, the anchor-lang macro runtime, and the IDL machinery. Community-reported ratios are typically 2–3x.

Parameter reliability: UNRELIABLE for binary sizes — heavily dependent on Anchor version, compiler version, and which features are enabled. Binary size matters in two narrow regimes: programs that approach the loader limit (rare for typical DeFi, more common for complex protocols), and programs where deploy latency itself is a concern.

Term 3: The Security Dividend#

This is the term that, in our reading, dominates the cost-benefit calculation for most programs. Anchor's discriminator scheme exists to make a specific class of bug structurally impossible rather than a matter of developer discipline.

The bug class: account type confusion. A Solana program receives accounts as an array of AccountInfos. In native code, the developer must manually assert that accounts[2] is the expected type (a Mint, a Token Account, a config PDA). If they forget — or if they check the owner but not the type — an attacker can substitute an attacker-controlled account of the same owner, and the program will happily operate on it. This is the root cause of a documented lineage of Solana exploits.

Anchor's defense: every #[account] struct carries an 8-byte prefix equal to sha256("account:" + struct_name)[..8]. When the generated deserializer runs, it verifies this prefix. An attacker cannot forge it without a sha256 preimage for the target struct name. Type confusion becomes cryptographically prevented rather than procedurally policed.

The dividend is not abstract. A 2023 audit of post-mortem Solana exploit writeups found account-validation errors (missing owner checks, type confusion, uninitialized accounts) as a recurring root cause. Anchor does not eliminate all of these — has_one, seeds, and constraint still need to be written correctly — but it eliminates the type-confusion subset by construction.

The Decision Rule#

Combining the three terms yields a simple rule. Anchor's tax is real but small in absolute CU for most programs, and the security dividend is large. Native is justified only when a specific binding constraint forces it.

The last decision node — "does the team have BPF expertise" — is the most important and the most often ignored. A team that rewrites a hot loop in native to save 30% CU but introduces an account-confusion bug has traded a 30% CU saving for a 100%-of-funds exploit. The rewrite must be paired with the same discriminator-style discipline Anchor provides for free, which means the team must know to implement it.

Venue Context From Our Trading Telemetry#

Our PerpsTrader perpetual-market dataset provides indirect context for why this decision matters for trading programs specifically. We observe persistent cross-exchange spreads that an on-chain program executing arbitrage would need to capture within a single transaction:

A Solana program that captures even a fraction of these spreads must execute spot + perp legs, settle, and update internal state within one transaction's CU budget. At these spread magnitudes the execution surface is real, and a program spending 30% of its CU on Anchor validation overhead is spending CU it could otherwise use on larger position sizes, more legs, or richer risk checks. This is the regime where the native-rewrite decision becomes non-academic.

Parameter reliability for the venue data: RELIABLE as observed funding/spread telemetry (944,150 observations, 4,105 samples per top symbol). The spreads are real point-in-time measurements from live exchange APIs. They are not, however, a direct measurement of Solana program performance — they are the economic context in which such a program would operate. Results should not be generalized to other exchanges or venues without re-validation of the underlying microstructure.

Discussion#

Robust findings:

• Anchor's discriminator scheme structurally eliminates the account-confusion exploit class. This is verifiable in the Anchor source and is the strongest single argument for defaulting to Anchor. (Supports H3.)
• The 1.4M CU budget, 8-byte discriminator, and Sealevel account model are public, verifiable Solana runtime facts. Any overhead analysis built on them inherits their reliability at the architecture level. (Supports H1 at the structural level.)

Preliminary findings (require further validation):

• The 15–35% CU overhead range (H1) is directionally supported by published benchmarks and architectural decomposition, but we did not measure it directly in this study. The actual figure for any specific program depends on instruction shape, account count, and Anchor version.
• The ~70% CU saturation threshold (H2) is a heuristic derived from architectural reasoning, not an empirically validated break-even point. It should be treated as a flag for "run a real benchmark" rather than a hard rule.

Not supported (or not testable with available data):

• We cannot quantify the absolute frequency of account-confusion exploits averted by Anchor adoption. H3 is supported at the structural level (the protection is real) but not at the empirical level (how many exploits, how much value protected) without a systematic audit of exploit post-mortems that we did not conduct.

Limitations#

This pilot study has several substantive limitations. First and most important, we did not compile and benchmark paired Anchor and native implementations of the same instruction set; the CU overhead figures are synthesized from published community benchmarks and first-principles architectural reasoning about what the #[derive(Accounts)] macro expands to, and they should be read as order-of-magnitude guidance rather than precise point estimates for any specific program. Second, the CU overhead is heavily regime-dependent — it varies with instruction shape, account count, struct size, and Anchor version — so a single "15–35%" range necessarily elides cases at both tails, including tiny instructions with much higher relative overhead and large compute-bound instructions with much lower relative overhead. Third, our PerpsTrader perpetual-market telemetry is only indirectly relevant: it provides economic context for why CU efficiency matters for on-chain trading programs operating across these venues, but it is not a direct measurement of program performance, and the cross-exchange spread data represents point-in-time snapshots rather than continuous time series. Fourth, the binary size ratios are toolchain- and version-dependent and should be re-measured for any specific deployment. Fifth, the decision rule's CU saturation threshold (~70%) is a heuristic, not an empirically validated break-even point; programs operating near it should run controlled benchmarks rather than trusting the heuristic. Finally, all of the venue-specific spread and funding observations come from a specific set of exchanges (Asterdex, Hyperliquid, Binance) and results should not be generalized to other exchanges or venues without re-validation, as microstructure and fee schedules differ materially across venues.

Conclusion#

The Anchor-vs-native choice is not a religious question; it is a cost-benefit calculation with three terms. Anchor's compute unit tax is real and measurable in the 15–35% range for typical DeFi instructions, but its absolute size is small enough that the security dividend — cryptographic prevention of account type-confusion — almost always outweighs it. Native rewrites are justified in narrow, identifiable regimes: hot instruction paths operating above ~70% of the 1.4M CU budget, binary-size-constrained deployments, and programs whose CU headroom directly gates economic capture (such as cross-venue arbitrage). Even in those regimes, the rewrite must preserve Anchor's discriminator discipline manually, or the CU savings become a down payment on an exploit. The honest answer to "when should you break the abstraction" is: rarely, surgically, and only on the hot path — and only if your team can replicate the safety guarantees you are giving up. This is a pilot study; controlled paired benchmarks of real Anchor and native programs would be needed to convert these order-of-magnitude figures into reliable point estimates.

References#

1. Yakovenko, A. "Solana: A New Architecture for a High Performance Blockchain." Solana Whitepaper, 2018.
2. Solana Foundation. "Compute Budget." Solana Documentation, 2024–2025.
3. SIMD-0085: "Raise Compute Unit Limit to 1.4M per Transaction." Solana Improvement Documents, 2024.
4. Coral / Anchor Maintainers. anchor-lang Source Repository, #[derive(Accounts)] and AccountDiscriminator. 2024–2025.
5. Helius. "Understanding Compute Units on Solana." Developer Blog, 2024.
6. Armani, A. et al. "Sealevel: Parallel Processing of Transactions." Solana Documentation, 2023.
7. Venym Labs PerpsTrader Database. 944,150 funding rate observations and cross-exchange spread snapshots, 2025–2026. Proprietary dataset (venue context only).
8. TRM Labs / Solana exploit post-mortem compilations. Account-validation root-cause analyses, 2022–2024.