Solana session intent specification

[lgalabru]

Specification draft for MPP session intent, driving an implementation that will the audited and maintained by Solana Foundation (not ready for review)

[alexanderattar]

Closed #200 to move things here. I went through the draft and had a few questions.

The lean voucher makes sense to me if channelId is always treated as the authoritative commitment to payer, recipient, asset, and program state. Does that imply the verifier is expected to resolve channel state onchain, or is there an intended offchain-only verification path?

Are you aiming for one canonical channel program, or would any program that implements this instruction set and state model be compatible?

I noticed metering is entirely server-side in this draft, with the voucher only authorizing cumulative payment. Was that intentional?

I had also written up sections on replay protection, crash safety for distributed servers, and Ed25519 instruction introspection that may be worth pulling into this draft if useful.

[lgalabru]

Thanks @alexanderattar, appreciate your help!
The server verifies vouchers off-chain during the session (signature check, monotonicity, balance — no RPC needed per request). The channel state is resolved on-chain only at open (to confirm the deposit landed) and at settle/close (to claim funds). This is the same as Tempo — off-chain during streaming, on-chain at settlement boundaries.

Any compatible program with the spec should be usable, this is why we're proposing channelProgram in the challenge: different programs could offer different trade-offs (grace period length, supported tokens, compression, etc.). The spec defines the logical interface; implementations vary.

[github-actions]

Spec Preview

Spec	Changed	Artifacts
draft-card-charge-00	Yes	HTML · TXT · XML · PDF
draft-evm-charge-00	Yes	HTML · TXT · XML · PDF
draft-hedera-charge-00	Yes	HTML · TXT · XML · PDF
draft-httpauth-payment-00	Yes	HTML · TXT · XML · PDF
draft-lightning-charge-00	Yes	HTML · TXT · XML · PDF
draft-lightning-session-00	Yes	HTML · TXT · XML · PDF
draft-payment-discovery-00	Yes	HTML · TXT · XML · PDF
draft-payment-intent-charge-00	Yes	HTML · TXT · XML · PDF
draft-payment-transport-mcp-00	Yes	HTML · TXT · XML · PDF
draft-solana-charge-00	Yes	HTML · TXT · XML · PDF
draft-solana-session-00	New	HTML · TXT · XML · PDF
draft-stellar-charge-00	Yes	HTML · TXT · XML · PDF
draft-stripe-charge-00	Yes	HTML · TXT · XML · PDF
draft-tempo-charge-00	Yes	HTML · TXT · XML · PDF
draft-tempo-session-00	Yes	HTML · TXT · XML · PDF

Browse preview release assets

[brendanjryan]

Voucher expiration signing is ambiguous. The HTTP shape exposes expiresAt as an ISO 8601/RFC 3339 string, but the signed Borsh payload uses an i64.

[lgalabru]

Addressed with latest

[brendanjryan]

why do you need expiration on both the vouchers and the sessions?

I think this will get pretty complicated to manage, and also introduces a number of edge cases which you need to guard against, like griefing from setting very low expiresAt values

[lgalabru]

Addressed with latest

[brendanjryan]

@lgalabru -- thank for updating this!

Now that there are many proposals for sessions (evm, tempo, and solana) but we have not defined the "generic" intent, we run some risk of divergences on common fields or control flows.

Do you mind if we push fwd a generic spec and then rebase this spec on top of this? Alternative is moving forward with this spec, and then rebasing changes

I expect that we can get a draft for the generic session intent up next week and move pretty quickly to get it approved. Would this work for you? This shouldn't block actual implementation of the method / sdks as long as you can rebase changes in.

[lgalabru]

@brendanjryan sounds like a great plan!