Solana charge intent specification by lgalabru · Pull Request #188 · tempoxyz/mpp-specs

lgalabru · 2026-03-18T21:10:09Z

Summary

Defines the charge intent for the solana payment method within the HTTP Payment Authentication Scheme. Supports
one-time payments in native SOL and SPL tokens (including Token-2022).

Settlement modes

Pull mode (type="transaction", default): client signs, server broadcasts. Enables fee sponsorship and server-side
retry.
Push mode (type="signature", fallback): client broadcasts and presents the confirmed signature.

Key features

Fee sponsorship — server co-signs as fee payer; client only signs the transfer authority
Payment splits — multiple recipients in a single transaction (ex: platform fees, revenue sharing, fee recovery)
Optional Server-provided blockhash — recentBlockhash in the challenge eliminates client RPC dependency in pull mode
Transaction simulation — servers SHOULD simulate before broadcast to prevent wasted fees
Token program auto-detection — tokenProgram is a hint; clients resolve from the mint if absent (supports PYUSD,
Token-2022, etc.)
externalId as memo — written on-chain via Memo Program for auditing and reconciliation

Request schema

Shared fields: amount, currency, recipient, description, externalId

Method details: network, splToken, decimals, tokenProgram, reference, feePayer, feePayerKey, splits, recentBlockhash

Reference implementation

solana-mpp-sdk - includes unit tests, integration tests, and an interactive demo.

AI assistance (Claude + Codex) were used in drafting this specification. All content has been reviewed for accuracy and RFC compliance.

specs/methods/solana/draft-solana-charge-00.md

brendanjryan · 2026-03-20T18:27:46Z

specs/methods/solana/draft-solana-charge-00.md

+  "description": "Marketplace purchase",
+  "methodDetails": {
+    "network": "mainnet-beta",
+    "splToken": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v",


nit: why not just token? spl is a bit redundant here given scope

Addressed with 4f2b994

brendanjryan · 2026-03-20T18:28:57Z

specs/methods/solana/draft-solana-charge-00.md

+  account to cover transaction fees
+- MUST verify the transaction contents before signing
+  (see {{transaction-verification}})
+- MAY recover fee costs through pricing or other business


nit: probably not necessary for spec -- technical spec itself doesn't need to define social rules around how to monetize

Addressed with 4f2b994

specs/methods/solana/draft-solana-charge-00.md

brendanjryan · 2026-03-20T18:33:27Z

specs/methods/solana/draft-solana-charge-00.md

+Details, with `Content-Type: application/problem+json`.
+The following problem types are defined for this intent:
+
+https://paymentauth.org/problems/solana/malformed-credential


for non-solana specific ones I think we can just use the standard error types

https://paymentauth.org/problems/

Addressed with 4f2b994

specs/methods/solana/draft-solana-charge-00.md

brendanjryan · 2026-03-20T18:36:01Z

specs/methods/solana/draft-solana-charge-00.md

+~~~json
+{
+  "amount": "10000000",
+  "currency": "SOL",


can we use a lowercase currency here?

in other cases we also just make this the token address directly (e.g. EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v) -- do we need to define splToken? I imagine this may stem from the split of the SPL tokens vs native sol?

Gotcha I think the mix symbol / address got me confused. I thought the "currency" had to be a ticker / human readable.
We'll match Tempo's approach.

Addressed with 4f2b994

alexanderattar · 2026-03-21T14:54:08Z

specs/methods/solana/draft-solana-charge-00.md

+to present the same signature to the server. The
+challenge binding (the credential echoes the challenge
+`id`, which is HMAC-verified) and single-use signature
+enforcement mitigate this: only the party that received


Question on push mode security semantics: is there intended to be any challenge-specific onchain binding beyond matching payment terms?

I see the credential echoing the challenge, and I see the server verifying an unused signature plus a transaction that matches amount / recipient / token. What I’m not sure about is whether the transaction itself is meant to prove that it was constructed for this specific challenge, rather than just for a payment with the same parameters.

For example, if two valid challenges exist for the same payment terms, could a party watching the chain present a matching transaction signature against their own challenge first? If the intent is to provide stronger challenge-specific guarantees in push mode, would it make sense to require a Memo carrying the challenge id, or some other onchain marker, so the transaction is explicitly tied to the issued challenge?

If not, it may be worth documenting push mode as having weaker challenge-specific binding than pull mode.

Per my understanding, this does not materially diverge from the Tempo charge intent: requiring the memo to carry the challenge-id would strengthen challenge-instance binding, but it would also force additional on-chain correlation metadata, so the base spec leaves that privacy vs binding tradeoff to implementations.

Would love to get @brendanjryan's take!

You are free to do whatever you want here, as long as you call out the tradeoffs.

In the tempo charge spec we are actively considering doing something like what was suggested in order to strengthen invariants, but this should be back compat

Thanks @brendanjryan. added a note in 0c86f19

specs/methods/solana/draft-solana-charge-00.md

alexanderattar · 2026-03-21T15:00:41Z

specs/methods/solana/draft-solana-charge-00.md

+   MUST have the server's `feePayerKey` set as the fee
+   payer account.
+
+3. Simulate the transaction using the `simulateTransaction`


This reads like a MUST here, but the fee payer risks section later frames simulation as SHOULD.

For fee-payer mode, MUST seems right since the server is taking fee risk. For non-fee-payer mode, SHOULD seems reasonable

Thanks, I did some back and forth on that one, it deserves a last pass I agree.

Addressed with 1856993

alexanderattar · 2026-03-21T15:04:39Z

specs/methods/solana/draft-solana-charge-00.md

+~~~json
+{


This example is out of sync with the receipt schema above.

The schema defines challengeId, but this decoded receipt omits it. If challengeId is intended to be part of emitted receipts, it should appear here too.

Good catch thanks

Addressed with 9d2575b

alexanderattar · 2026-03-21T15:05:47Z

specs/methods/solana/draft-solana-charge-00.md

+  (`TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA`) or
+  the Token-2022 Program
+  (`TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb`).
+  If omitted, clients MUST determine the correct token


Worth specifying failure behavior here.

If the mint-owner lookup fails, clients should fail closed rather than falling back to the legacy Token Program, especially for Token-2022 assets.

Addressed with 1856993

alexanderattar

Overall this looks strong and close. The main thing I wanted to call out was push-mode challenge-specific binding. I left a few smaller consistency and operational comments as well.

specs/methods/solana/draft-solana-charge-00.md

brendanjryan · 2026-03-23T23:36:23Z

specs/methods/solana/draft-solana-charge-00.md

+to present the same signature to the server. The
+challenge binding (the credential echoes the challenge
+`id`, which is HMAC-verified) and single-use signature
+enforcement mitigate this: only the party that received


You are free to do whatever you want here, as long as you call out the tradeoffs.

In the tempo charge spec we are actively considering doing something like what was suggested in order to strengthen invariants, but this should be back compat

brendanjryan · 2026-03-23T23:38:42Z

specs/methods/solana/draft-solana-charge-00.md

+2. Verify the `mint` field matches the top-level
+   `currency` field from the challenge request.
+
+3. Verify the `tokenAmount.amount` field matches the


is this still true for splits as well? wouldn't this fail on a split payment of

account A: 10
account B: 1

we would check for 11 (10 + 1), when in reality the transfer should be 10

Addressed with eea140b

brendanjryan

LGTM!

github-actions · 2026-03-24T14:52:15Z

Spec Preview

Spec	Changed
`draft-card-charge-00`	Yes
`draft-httpauth-payment-00`	Yes
`draft-lightning-charge-00`	Yes
`draft-lightning-session-00`	Yes
`draft-payment-discovery-00`	Yes
`draft-payment-intent-charge-00`	Yes
`draft-payment-transport-mcp-00`	Yes
`draft-solana-charge-00`	-
`draft-stripe-charge-00`	Yes
`draft-tempo-charge-00`	Yes
`draft-tempo-session-00`	Yes

Download spec artifacts (HTML, TXT, XML, PDF)

lgalabru added 5 commits March 18, 2026 17:08

feat: draft support for Solana

a9f8159

docs: add simulation in flow

831ed1a

fix: nuance confirmed vs finalized

79c7212

feat: add splits

6987a62

fix: streamline terminology

3d9a809

lgalabru changed the title ~~feat: draft support for Solana Charge~~ Solana charge intent specification Mar 19, 2026

lgalabru added 4 commits March 19, 2026 14:27

docs: update security + examples

ed1de1d

feat: wire format bounding

c06337f

fix: add notes on splits

f6e8541

fix: update splits capacity

6d1c98d

brendanjryan reviewed Mar 20, 2026

View reviewed changes

fix: address feedback

4f2b994

alexanderattar reviewed Mar 21, 2026

View reviewed changes

specs/methods/solana/draft-solana-charge-00.md Show resolved Hide resolved

alexanderattar reviewed Mar 21, 2026

View reviewed changes

alexanderattar mentioned this pull request Mar 21, 2026

Add Solana session intent specification #200

Closed

lgalabru added 2 commits March 23, 2026 16:54

fix: tighten semantics, remove reference field

9d2575b

fix: additional semantic fixes

1856993

lgalabru requested review from alexanderattar and brendanjryan March 23, 2026 21:18

brendanjryan reviewed Mar 23, 2026

View reviewed changes

lgalabru added 2 commits March 24, 2026 10:09

fix: transaction verification protocol

eea140b

fix: add note on eventual future direction

0c86f19

lgalabru requested a review from brendanjryan March 24, 2026 14:15

fix: split spec improvement

ae83a09

brendanjryan approved these changes Mar 24, 2026

View reviewed changes

brendanjryan merged commit 7044623 into tempoxyz:main Mar 24, 2026
2 checks passed

		~~~json
		{

Conversation

lgalabru commented Mar 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Settlement modes

Key features

Request schema

Reference implementation

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alexanderattar Mar 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alexanderattar left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

brendanjryan left a comment

Choose a reason for hiding this comment

Uh oh!

github-actions bot commented Mar 24, 2026

Spec Preview

Uh oh!

Uh oh!

lgalabru commented Mar 18, 2026 •

edited

Loading

alexanderattar Mar 21, 2026 •

edited

Loading