Solana/SVM Support

[layertau]

Summary

Research and implement first-class Solana/SVM support in WAVS. Today WAVS has explicit EVM and Cosmos paths for chain config, triggers, service managers, CLI deployment, component WIT bindings, signing/submission, and middleware. Solana support should be designed as a set of explicit abstraction points rather than squeezed into the existing EVM/Cosmos shapes.

Current WAVS architecture touched

From a quick repository pass:

• Core flow is TriggerManager -> Dispatcher -> Engine -> SubmissionManager -> Aggregator -> Chain (docs/ARCHITECTURE.md).
• Chain-aware types currently model only EVM and Cosmos:
  • packages/types/src/chain_config.rs: AnyChainConfig, ChainConfigs, builders
  • packages/types/src/service.rs: ServiceManager, Trigger, TriggerData, Submit, SignatureKind
• Trigger manager has EVM/Cosmos-specific lookup and stream paths under packages/wavs/src/subsystems/trigger*.
• Component/aggregator WIT conversions mirror the same variants under packages/engine/src/bindings/types/*.
• CLI/service JSON validation and deploy/save paths branch on EVM/Cosmos in packages/cli/src/*.
• WASI helpers currently include EVM query helpers (packages/wasi-utils/src/evm, packages/wavs-rig/src/tools/evm.rs).
• Middleware patterns exist for EVM/EigenLayer, POA, and CosmWasm. A contracts/svm-middleware submodule pointer exists in the monorepo, but it was not checked out in the workspace used for this research.

Proposed implementation areas

1. Chain/config model

Add a Solana/SVM chain namespace and config variant instead of overloading EVM/Cosmos:

• SolanaChainConfig / AnyChainConfig::Solana
• fields likely needed:
  • chain_id or cluster id (localnet, devnet, testnet, mainnet-beta, custom)
  • rpc_endpoint
  • ws_endpoint
  • default commitment (confirmed or finalized)
  • optional faucet/airdrop endpoint for local/dev
  • optional priority fee / compute budget defaults

2. Solana trigger source

Add Solana trigger and trigger-data variants, likely starting with program logs/events:

• Trigger::SolanaProgramEvent { program_id, chain, filters, commitment, ... }
• TriggerData::SolanaProgramEvent { chain, program_id, signature, slot, block_time, instruction_index, inner_instruction_index, log_index, logs, parsed_anchor_event?, accounts? }
• Trigger::BlockInterval should work with Solana slots/blocks, or have an explicit Solana slot interval if current “block height” semantics are too EVM/Cosmos-specific.

Solana-specific event ingestion considerations:

• RPC/websocket subscriptions: logsSubscribe, programSubscribe, signatureSubscribe, and possibly blockSubscribe where provider-supported.
• Anchor events: base64 payloads in logs (Program data:) with 8-byte discriminators.
• Native programs may emit only textual logs; callers may need filter/discriminator configuration.
• Event identity must be replay-safe and unique: include slot, transaction signature, instruction index, inner instruction index, and log index.
• Finality/commitment must be explicit (processed/confirmed/finalized) and rollback handling should be documented/tested.

3. Solana destination/submission target

Add an aggregator submission path capable of building, signing, retrying, and confirming Solana transactions:

• transaction construction from aggregator output
• fee payer management
• recent blockhash refresh and expiry handling
• compute budget / priority fee instructions
• optional durable nonce policy if needed
• confirmation polling/subscription at configured commitment
• idempotent replay protection on-chain/program-side

4. Solana service-manager equivalent / middleware

Design a Solana program (Anchor or native Rust) equivalent to the WAVS service manager/handler pattern:

• service config PDA(s), including service URI and workflow metadata
• operator/quorum registry or mirrored registry PDA(s)
• submission/replay PDA(s) keyed by service/workflow/event id
• handler instruction(s) to consume verified envelopes and route application-specific actions
• upgrade authority and admin model
• optional SPL token / account integration examples

Open design choice: Anchor is likely the fastest path for developer ergonomics and event parsing, but native Rust may be preferable for minimal dependencies or tighter control. The issue should track this as an explicit decision.

5. Operator signatures and quorum verification

Solana changes the signing/verifying model:

• Solana accounts use Ed25519, while existing EVM middleware heavily assumes secp256k1/EIP-191 in places.
• SignatureKind is already algorithm/prefix-extensible; add/verify an Ed25519 + Solana domain-separated message format if missing.
• Program-side verification may use the Solana Ed25519 program / instruction introspection pattern, or another verified-envelope scheme.
• Define canonical message bytes for Solana envelopes, including chain id/cluster, service id, workflow id, trigger id, slot/signature, payload hash, nonce, and expiry if any.
• Decide whether operator identity maps to Solana pubkeys, existing EVM operator keys, BLS aggregate keys, or a mirrored operator registry.

6. SDK/component APIs and host tooling

Expose Solana data to components and add optional host/query utilities:

• WIT types for Solana triggers and submissions.
• WASI helper/client for read-only Solana RPC (getAccountInfo, getProgramAccounts, getTransaction, simulateTransaction, etc.).
• wavs-rig tool equivalent to EvmQueryTool for Solana account/program queries.
• TypeScript/Rust examples for decoding Anchor events and account data.

7. CLI, service JSON, and deployment UX

Update the operator/dev UX:

• service JSON schema/validation for Solana chain config, triggers, and service manager addresses/program IDs
• CLI deploy/set-service-uri equivalent for Solana program state
• localnet defaults and examples
• documentation for provider limitations (websocket support, historical logs, rate limits)

8. Test harness

Add deterministic local tests before attempting devnet/mainnet flows:

• solana-test-validator/Anchor localnet in dev scripts/CI where practical
• local program deployment fixture
• websocket log trigger integration test
• finality/rollback/resubscription tests at the abstraction level
• aggregator submission test with blockhash refresh/retry
• program tests for replay protection, account constraints, signer constraints, PDA derivation, and upgrade authority controls

Key risks / gotchas

• Solana has no EVM-style universal contract logs; event parsing depends on logs, transactions, account changes, or Anchor conventions.
• Commitment/finality semantics are not the same as EVM confirmations or Cosmos block finality.
• Recent blockhash expiry makes submission retry semantics materially different from EVM/Cosmos.
• Program-side Ed25519 verification has compute and instruction-introspection constraints.
• RPC providers differ on websocket subscription support, historical retention, and blockSubscribe availability.
• Localnet/devnet/mainnet parity is imperfect; there is no standard mainnet-fork workflow like Foundry/Anvil.
• PDA/account constraint mistakes are a primary security risk for Solana middleware.

Open questions

1. Is initial scope “Solana as trigger source only”, or should v1 also support Solana as an aggregator submission destination?
2. Should the service-manager equivalent be built with Anchor or native Solana Rust?
3. What should be the canonical Solana envelope/signature format, and should operators sign with Solana Ed25519 keys or existing WAVS/EVM operator keys?
4. Should Solana operator/quorum state be native on Solana, mirrored from EVM/EigenLayer, or POA-style for the first release?
5. Which commitment level should be the default for production triggers (confirmed vs finalized)?
6. Which first example should drive the design: Anchor event -> WAVS component -> Solana handler, or Solana event -> WAVS component -> EVM/Cosmos handler?

Suggested milestones

• Design doc for Solana/SVM support boundaries and v1 scope.
• Add Solana chain config/types and service JSON schema support.
• Add Solana trigger ingestion abstraction with local validator test.
• Add WIT/component bindings for Solana trigger data.
• Add Solana query helper/tool for WASI components.
• Design/implement Solana service-manager/handler program.
• Add Ed25519/Solana envelope signing and verification path.
• Add aggregator submission path to Solana with blockhash refresh and confirmation handling.
• Add localnet example AVS and docs.
• Document provider/finality/security operational guidance.

Acceptance criteria

A first complete Solana support slice should demonstrate:

• A WAVS service can be configured with a Solana chain and Solana program trigger.
• A local Solana program emits an event/log that WAVS observes exactly once at the configured commitment.
• The operator component receives typed Solana trigger data via WIT bindings.
• The aggregator can either submit to an existing EVM/Cosmos target from a Solana trigger, or submit a verified envelope to a Solana handler program (depending on selected v1 scope).
• Replay protection and event identity are tested.
• Local developer flow runs against solana-test-validator/Anchor localnet and is documented.
• Security docs cover commitment/finality, PDA/account constraints, signature domain separation, fee payer/blockhash retry behavior, and RPC provider limitations.