The Interface Gap: Ethereum ERCs, Solana Programs and Vault Standards

Executive summary

Ethereum ERCs and Solana program standards address the same coordination problem: how can unrelated applications integrate without bespoke work every time? The execution models differ, so the standardization surface differs. Ethereum ERCs typically standardize functions, events, and behavior around contract addresses. Solana standards need to describe program IDs, accounts, authorities, instruction data, PDA conventions, and cross-program expectations.

Problem or question

Teams coming from Ethereum often ask for the Solana equivalent of an ERC. That is a useful instinct but an incomplete translation. If a Solana program requires the caller to supply state accounts, the interface is not only the instruction name. It is also the account graph and the semantic rules around those accounts. Vaults make this gap visible because share accounting, asset custody, requests, authorities, and extensions all need predictable mapping.

System or market context

ERC-20 gave exchanges and wallets a common token interface. ERC-4626 did the same for vault shares and asset conversions. ERC-7540 extends vault behavior to asynchronous request flows. Solana already has standards and conventions such as token programs, associated token accounts, Token-2022, SPL patterns, and sRFC discussions. The issue is not absence of standards; it is that more behavior must be specified outside an ABI.

Design or analytical framework

A Solana interface standard should state the behavior, required accounts, optional accounts, address derivation rules, authority model, events/logs, error semantics, and conformance tests. For vaults, it should define request lifecycle, share mint behavior, asset custody, fee timing, NAV assumptions, and extension points. SDK support matters because account resolution is part of the interface. Without it, integrators rebuild fragile adapter code.

Trade-offs and failure modes

Over-standardization can block Solana-native patterns. Under-standardization leads to adapters, inconsistent analytics, weak custody support, and due-diligence friction. Interface compatibility can hide economic differences, such as synchronous versus asynchronous redemptions or different fee timing. Offchain metadata can help discovery but becomes brittle if there is no deterministic fallback.

Practical implications

Institutional teams should ask whether a standard includes conformance tests and integration tooling. Protocol teams should document account expectations with the same care Ethereum teams document method behavior. Wallets and custodians need stable semantics, not only code examples. Standards should reduce operational ambiguity as much as developer typing.

Verification note

For builders, the practical test is whether a third party can integrate without private explanation from the original team. If the answer depends on a bespoke script, a Slack thread, or a single maintainer knowing which accounts to pass, the interface is not yet standardized in the operational sense. A useful Solana standard should leave enough room for native design while giving wallets, indexers, custodians, allocators, and protocols predictable behavior. That includes error cases and lifecycle states, not just happy-path instructions. Vaults make this especially clear because an integrator must know whether assets are immediately withdrawable, queued for settlement, subject to fees, or controlled by an extension.

Review discipline

Interface standards should be maintained like production dependencies. A standard that is accurate today can still become misleading if programs change account conventions, SDKs move, wallets add partial support, or vault implementations diverge. For that reason, a Solana interface review should name its conformance assumptions and refresh triggers. If account resolution, authority semantics, or request lifecycle behavior changes, downstream adapters need to know. The standard is valuable only if it reduces operational surprise after launch.

Conclusion

The interface gap is not a mark against either ecosystem. It follows from different state and execution models. The productive path is to standardize the surfaces integrators actually touch: behavior, accounts, authorities, events, and tests. Vault standards are a good proving ground because the cost of ambiguity is immediately visible.