docs(svm): propose a Solana network driver design

[atharrva01]

Proposal for a Solana (SVM) network driver, a third non-Fabric backend alongside the in-progress EVM driver.

It reuses the EVM driver's trust model (off-chain Go validation via driver.Validator, on-chain signature-threshold checking only) rather than designing from scratch, and calls out the two places it deliberately doesn't just port that design: one PDA per token instead of one contract-wide mapping so Sealevel can actually parallelize unrelated transfers, and Solana's native commitment levels replacing the EVM driver's whole confirmation-depth/reorg-detection subsystem. It also treats the EVM driver's most expensive lesson, a multi-TMS state-sharing bug that took a dedicated bug-hunt round to find, as a day-one design requirement instead of something to discover the hard way twice.

No code, no branch work started, just the design doc for discussion, same stage the EVM driver's own design doc was at before implementation began.

[atharrva01]

@adecaro , @AkramBitar , @Effi-S would love everyone's thought on this proposal

[Effi-S]

@atharrva01, I think this would be a nice addition

[AkramBitar]

Review

This is a great idea and a well-structured design. Reusing the off-chain-validation + on-chain-signature-threshold trust model instead of starting from scratch is exactly the right call, the per-token PDA reasoning is sound (Sealevel parallelism is real and a shared-mapping design would throw it away), the finality simplification relative to the EVM driver is correctly identified, and carrying the multi-TMS isolation lesson forward as a day-one requirement rather than a later fix is the most important thing this doc gets right.

A few gaps to address before implementation starts:

1. Durable nonce / endorsement flow interaction unspecified
§9 identifies the blockhash-expiry problem and recommends durable nonce accounts, but doesn't specify where in the RequestApproval flow the nonce is advanced. If before collecting endorsements: the nonce is consumed even if endorsement collection fails. If after: the blockhash-expiry race is back. The EVM driver's NonceManager.WithNonce held a lock across the whole allocate-and-use step — the Solana equivalent needs the same explicit sequencing here.

2. internal_tx_id replay protection — unbounded PDA growth risk
§4 says apply_state_delta rejects a delta whose internal_tx_id has been seen before, and §9 also relies on Solana's blockhash-expiry window. The doc should clarify which is the primary mechanism. If internal_tx_id is primary (i.e. the driver doesn't rely on Solana's window), storing every seen ID as on-chain state creates unbounded PDA growth — how is that pruned or bounded?

3. Transaction-size ceiling needs quantification before implementation
§4 flags the chunked two-phase-commit as "v1.1, don't build speculatively." But a TokenRequest with 4 inputs + 4 outputs already needs 8 token PDAs + TMS config + system program + Ed25519 program + N endorser pubkeys in the account list — this can hit the ~1232-byte ceiling with modest-sized requests. This is a hard constraint, not a speculative one. It should be quantified ("a request with up to X inputs and Y outputs fits one transaction") before Phase 5 starts, not deferred.

4. Multi-listener design asserted but not specified
§7 says AddFinalityListener supports "more than one listener per anchor from the start." The EVM driver's fix for this was non-trivial. Stating the requirement without a concrete design (map to []Listener, fanout bus, etc.) leaves the implementer to rediscover the hard parts independently.

5. Companion docs/services/network-solana.md is its own prerequisite
The doc itself says this companion doc should be written before this design doc is treated as final. That doc doesn't exist yet — worth creating it first, or at least in parallel, before this goes to implementation.

[AkramBitar]

@atharrva01

Please see my comments.

Thanks a lot,
Akram