Solana mainnet v2 transactions fail when signed with 3rd party wallets (e.g., phantom, backpack, coinbase)

[Max-the-dev]

Context:

• Solana devnet payments work fine
• Base mainnet/testnet payments work fine
• Only Solana mainnet fails
  • transaction_simulation_failed response from x402 verify endpoint
  • it appears the facilitator does not work unless using the official signer (programmatic signer with private keys)

Additional Context:

• This flow was fully functional when on v1.
• Key question: Did the signing scheme change between the two versions?

Discovery:

While debugging, observed that Phantom wallet modifies transactions on mainnet (not devnet). Specifically, it appears
to inject the Lighthouse program for user protection:

• Transaction before Phantom signs: 7 accounts
• Transaction after Phantom signs: 8 accounts (includes Lighthouse program)

Hypothesis:

The v2 SDK flow may not accommodate third-party wallets that modify transactions before signing. The signature
is valid for the modified transaction, but CDP simulation may be failing because:

• It's validating against an expected transaction structure
• Or reconstructing/simulating a transaction that doesn't match what was actually signed

Questions:

1. Does CDP's Solana verification expect a specific transaction structure?
2. Can the flow accommodate wallet-modified transactions ?
3. Any known issues or guidance for Phantom on mainnet with v2?

[Max-the-dev]

Example: phantom adds a lighthouse address to the signed tx
which increases the total length to 8 vs. the expected 7 in the SDK

[phdargen]

Thanks a lot for your investigation @Max-the-dev, summoning @CarsonRoscoe and @notorious-d-e-v

[Max-the-dev]

Confirmed the rest of the implementation is correct by bypassing the phantom signature.

Created script following this example:
https://github.com/coinbase/x402/blob/cbfecfaa97ac9b52e4857b8040db30a11df7eba6/examples/typescript/clients/fetch/index.ts

Hit my article purchase endpoint directly - success
Hit Donate and Tip endpoints directly - success

Let me know if you want to see logs. I have a ton.

[notorious-d-e-v]

Thanks for reporting @Max-the-dev !

This is specific to Phantom adding a lighthouse instruction to the transaction.

The solana exact scheme implementation expects three instructions only (atm):

1. ComputeBudgetLimit
2. ComputeBudgetPrice
3. TransferChecked

So when phantom adds a lighthouse instruction as a fourth instruction in the transaction, the server/facilitator rejects the transaction.

This is mostly for security and simplicity.

A couple of potential solutions, will tag some folks at the end to get their thoughts as well.

1. Can Phantom allow an override?

Would Phantom wallet be open to adding an override in the transaction signing call that would stop the lighthouse instruction from being added to the transaction?

2. Do we want more flexible transaction introspection?

Should we allow for more flexible transactions such that the facilitator only checks for 2 things:

1. The merchant's (PayTo) token account balance is increased by the expected amount
2. The feePayer (merchant or facilitator account) is not in any of the instructions' accounts lists

Check number 2 would be asserting that none of the instructions in the transaction require the feePayer (merchant or facilitator) signature. Which means that the merchant/facilitator is not signing away anything.

This would allow the tx to have an arbitrary number of instructions, which also allows for more flexible use cases.

For example it would unlock smart wallet support #646 on Solana

Thoughts?

@amilz (solana), @aggdotred (phantom), @alexanderguy (corbits), @tenequm

Feel free to tag or share with any other experts that could contribute to this discussion.

[CarsonRoscoe]

Thanks for the reporting @Max-the-dev and the breakdown @notorious-d-e-v

Ideally we'd go for the second approach imo, as long as we are sure this can be done securely. Would definitely want someone from the Solana Foundation to review the proposed changes.

Assuming it can be done securely however, it would open the gate for not only smart wallets, but I could see it being leveraged by unique x402 Solana extensions, or other atomic integrations such as a resource server minting NFTs in the same transaction that gets them paid. It would be a powerful unlock to get that flexibility

[tenequm]

Assuming it can be done securely however, it would open the gate for not only smart wallets, but I could see it being leveraged by unique x402 Solana extensions, or other atomic integrations such as a resource server minting NFTs in the same transaction that gets them paid. It would be a powerful unlock to get that flexibility

Absolutely, that was the idea behind recent update I made to #646

I'll reach out to Solana Foundation to get a peer review from their side.
Will post an update as soon as I'll have any progress with that.

[Max-the-dev]

fantastic thank you @CarsonRoscoe @tenequm @notorious-d-e-v

Did a little bit more scripting and testing to be certain. I can report that all other major wallets work (solflare, backpack, etc.)

Same wallet (keyPair) works when running a script to hit my x402 endpoints directly - bypassing the manual phantom signature in the browser.

Solflare & Backpack do not modify the signature, so input = output in terms of # and type of instructions.

Only phantom.

BEFORE PHANTOM SIGNING

Signatures: 2
[0] (empty - fee payer)
[1] (empty - user)

Accounts: 7
[0] L54zkaPQFeTn1UsEqieEXBqWrPShiaZEPD7mS5WXfQg (fee payer)
[1] cAXdcMFHK6y9yTP7AMETzXC7zvTeDBbQ5f4nvSWDx51 (user)
[2] 82UCWj35ou7iLSchsy81inLM42ZBbQ1Fv2m8o1ED1GUm (source ATA)
[3] C96R71Na8F6XCG8jmSdyZqLy5sNDQqGN9AXT8wNtHgD3 (dest ATA)
[4] ComputeBudget111111111111111111111111111111
[5] EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v (USDC mint)
[6] TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA (Token Program)

Instructions: 3
[0] ComputeBudget - setComputeUnitLimit
[1] ComputeBudget - setComputeUnitPrice
[2] Token Program - transferChecked (indices: [2, 5, 3, 1])

AFTER PHANTOM SIGNING

Signatures: 2
[0] (empty - fee payer)
[1] SIGNED by user

Accounts: 8 ← ADDED 1
[0] L54zkaPQFeTn1UsEqieEXBqWrPShiaZEPD7mS5WXfQg (fee payer)
[1] cAXdcMFHK6y9yTP7AMETzXC7zvTeDBbQ5f4nvSWDx51 (user)
[2] 82UCWj35ou7iLSchsy81inLM42ZBbQ1Fv2m8o1ED1GUm (source ATA)
[3] C96R71Na8F6XCG8jmSdyZqLy5sNDQqGN9AXT8wNtHgD3 (dest ATA)
[4] ComputeBudget111111111111111111111111111111
[5] L2TExMFKdjpN9kozasaurPirfHy9P8sbXoAN1qA3S95 ← INJECTED (Lighthouse)
[6] TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA (Token Program)
[7] EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v (USDC mint - MOVED)

Instructions: 4 ← ADDED 1
[0] ComputeBudget - setComputeUnitLimit
[1] ComputeBudget - setComputeUnitPrice
[2] Token Program - transferChecked (indices: [2, 7, 3, 1]) ← INDEX CHANGED
[3] Lighthouse - L2TExMFKdjpN9kozasaurPirfHy9P8sbXoAN1qA3S95 ← INJECTED

[Max-the-dev]

@notorious-d-e-v may be a silly question, but could we not extend to 4 instructions to accommodate phantom specifically as an intermediate fix?

would help a lot as phantom has the market share of smart wallet users on Sol.

I'd be happy to contribute to that.

[alexanderguy]

Thoughts?

Yah, we've talked a bit about this internally (e.g. thinking about #646). Our big issues with making things too open ended, is the attack surface area balloons. If there's one thing this ecosystem is good at doing, it's people figuring out how to exploit almost anything you get wrong.

Accepting too many instructions makes your facilitator dangerously close to a fee paying RPC endpoint. Obviously we'll support anything reasonable in Faremeter, but I would personally rather keep a running explicit whitelist of things we're willing to tolerate with exact. This keeps it simple.

I think the more complicated usecases should be moved to existing tooling/contracts on chain, with more enhanced schemes that are specific to the mechanics of the chain being used.

[tenequm]

@alexanderguy The "fee-paying RPC endpoint" concern is exactly the right threat model.

I've just posted an updated RFC with hardened security rules that addresses this. The key additions:

• Fee payer must not be signer in ANY instruction (not just transfer authority/source)
• Exactly ONE of each ComputeBudget instruction type required
• Block all account creation funded by fee payer
• Explicit Token-2022 extension handling

These create bounded facilitator risk (≤0.1 SOL per tx worst case).

On whitelisting - the concern I have is that it becomes a never-ending spec update cycle. Squads adds a feature, spec update. Phantom Lighthouse, spec update. New wallet innovation, spec update. Each addition also creates combinatorial interactions with existing whitelisted instructions that need security review.

The outcome-based approach with explicit security invariants flips this: instead of "allow these N instruction types," it's "block anything that could exploit the facilitator's signature." The attack surface is defined by what the facilitator controls, not by enumerating every possible valid transaction structure.

[amilz]

IMO Yes to option 2 would be ideal. In fact, we do this with our Kora Gasless Relayer as a Facilitator. Ideally the facilitator spec would allow for the facilitator server to add additional customization (e.g., additional instructions after the expected instructions, allowed/disallowed programs, allowed/disallowed accounts, etc.).

2. Do we want more flexible transaction introspection?

Should we allow for more flexible transactions such that the facilitator only checks for 2 things:

1. The merchant's (PayTo) token account balance is increased by the expected amount
2. The feePayer (merchant or facilitator account) is not in any of the instructions' accounts lists

Check number 2 would be asserting that none of the instructions in the transaction require the feePayer (merchant or facilitator) signature. Which means that the merchant/facilitator is not signing away anything.

[notorious-d-e-v]

I agree with @alexanderguy that simpler is better and increasing the surface area will lead to unwanted consequences.

For example, the merchant or facilitator can be griefed for gas, even if none of the instructions in the transaction are explicitly malicious. If there are compute-heavy instructions, or a large set of instructions, the merchant/facilitator will pay much more than they would like to in network fees.

Also agree with @CarsonRoscoe, @amilz, @tenequm that the flexibility is powerful and opens up use cases like smart wallets, or more complex flows via extensions.

It seems like there is one issue here where we are tightly coupling the spec (definition of exact on svm) and the transaction introspection/validation.

An approach could be to make the definition of exact on svm more permissive such that it doesn't have to be updated every time a new use case surfaces, while keeping the transaction introspection in the reference implementation strict.

Especially since it is still early and the things we are trying to accomplish are finite and well known (smart wallet support and accommodating phantom lighthouse program).

Imo we should, in the reference implementation, make an explicit allowance for the phantom lighthouse program as @Max-the-dev suggested, as well as add explicit support for Squads (in #646).

I would propose the following update to the exact scheme on svm, so that it is more focused on what exact means, while creating a separation between normative spec and recommended policies.

We still require some baseline validation to keep the merchant/facilitator safe as MUSTs, but allow for more use cases by defining recommended merchant/facilitator policy as SHOULDs.

Created a PR for the scheme definition so that it's easy to see the diff (#829)

Pasting it below for convenience

Exact Payment Scheme for Solana Virtual Machine (SVM) (exact)

This document specifies the exact payment scheme for the x402 protocol on Solana.

The exact scheme defines outcome-based payment semantics: a client MUST effect an on-chain payment of an exact amount of a specified asset to a specified recipient.

How transaction fees are sponsored—and how the sponsoring party evaluates risk, limits cost, or constrains transaction structure—is intentionally separated from the payment semantics and described as a Sponsor Acceptance Policy. The sponsor MAY be the merchant itself or a third-party facilitator.

---

Scheme Name

exact

---

Terminology

• Client: The end user initiating the payment.
• Merchant: The resource server receiving payment, identified by payTo.
• Sponsor: The entity that signs the transaction as feePayer.
  The sponsor MAY be:
  • the merchant itself, or
  • a third-party facilitator.
• Fee Payer (feePayer): The Solana account of the Sponsor that pays transaction fees and provides the final required signature.

---

Protocol Flow

The protocol flow for exact on Solana is client-driven.

1. Client makes a request to a Resource Server.
2. Resource Server responds with a payment required signal containing PaymentRequired. The extra field contains a feePayer, identifying the sponsor.
3. Client creates a transaction that effects a payment of an asset to the merchant for a specified amount.
4. Client signs the transaction, producing a partially signed transaction.
5. Client serializes the partially signed transaction as Base64.
6. Client sends a request to the Resource Server, submitting the transaction via PaymentPayload alongside the PaymentRequirements.
7. Resource Server forwards the payload to the Sponsor /verify endpoint.
8. Sponsor inspects the transaction.
9. Sponsor returns a VerifyResponse to the Resource Server.
10. Resource Server forwards the payload to the Sponsor /settle.
11. Sponsor signs as feePayer and submits the transaction to the network.
12. Upon settlement, a SettlementResponse is returned from the Sponsor to the Resource Server.
13. Resource Server grants the Client access to the resource in its response.

---

PaymentRequirements for exact

In addition to the standard x402 PaymentRequirements fields, the exact scheme on Solana requires the following:

{
  "scheme": "exact",
  "network": "solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp",
  "amount": "1000",
  "asset": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v",
  "payTo": "2wKupLR9q6wXYppw8Gr2NvWxKBUqm4PPJKkQfoxHDBg4",
  "maxTimeoutSeconds": 60,
  "extra": {
    "feePayer": "EwWqGE4ZFKLofuestmU4LDdK7XM1N4ALgdZccwYugwGd"
  }
}

• asset: The public key of the token mint.
• payTo: The merchant’s public key.
• extra.feePayer: The sponsor’s public key. This MAY equal payTo (merchant-sponsored fees) or be a distinct third party.

PaymentPayload payload Field

The payload field of the PaymentPayload contains:

{
  "transaction": "AAAAAAAAAAAAA...AAAAAAAAAAAAA="
}

The transaction field contains the base64-encoded, serialized, partially-signed versioned Solana transaction.

Full PaymentPayload object:

{
  "x402Version": 2,
  "resource": {
    "url": "https://example.com/weather",
    "description": "Access to protected content",
    "mimeType": "application/json"
  },
  "accepted": {
    "scheme": "exact",
    "network": "solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp",
    "amount": "1000",
    "asset": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v",
    "payTo": "2wKupLR9q6wXYppw8Gr2NvWxKBUqm4PPJKkQfoxHDBg4",
    "maxTimeoutSeconds": 60,
    "extra": {
      "feePayer": "EwWqGE4ZFKLofuestmU4LDdK7XM1N4ALgdZccwYugwGd"
    }
  },
  "payload": {
    "transaction": "AAAAAAAAAAAAA...AAAAAAAAAAAAA="
  }
}

SettlementResponse

The SettlementResponse for the exact scheme on Solana:

{
  "success": true,
  "transaction": "base58 encoded transaction signature",
  "network": "solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp",
  "payer": "base58 encoded public address of the transaction fee payer"
}

---

1. Exact Payment Outcome Definition (Normative)

A transaction satisfies the exact payment scheme if and only if, when executed on-chain, it produces the following outcome.

1.1 Required Payment Outcome (MUST)

The transaction MUST result in:

• A transfer of exactly PaymentRequirements.amount
• Of the asset identified by PaymentRequirements.asset
• To the recipient identified by PaymentRequirements.payTo
• Using one of:
  • spl-token TransferChecked
  • token-2022 TransferChecked
  • Native SOL transfer (if asset denotes SOL, for future extensions)

The payment MUST be:

• Exact (no overpayment or underpayment)
• Atomic (no partial fulfillment)
• Unconditional (not dependent on post-transaction behavior)

1.2 Payment Identification (MUST)

A verifier MUST be able to deterministically identify the payment instruction and confirm:

• Correct mint
• Correct destination account (including ATA derivation)
• Correct amount
• Correct token program

The presence of additional instructions does not invalidate the payment, provided the required outcome is achieved.

1.3 Non-Prescriptive Structure (Explicit)

The exact scheme:

• DOES NOT prescribe a fixed instruction count
• DOES NOT require a fixed instruction order
• DOES NOT restrict additional instructions, provided the payment outcome is achieved

This ensures forward compatibility with wallet behavior, protocol evolution, and auxiliary instructions (e.g., compute budget, safety checks, memos).

---

2. Sponsor Acceptance Policy (Reference)

This section defines minimum required and recommended checks for any sponsor that signs as feePayer (merchant or third-party facilitator).

These rules concern sponsor safety and cost control, not payment validity.

A sponsor MAY reject transactions that satisfy the exact scheme but violate its local policy.

---

2.1 Minimal Safety Baseline (Normative MUSTs)

A sponsor that signs a transaction as feePayer MUST enforce all of the following.

2.1.1 Fee Payer Signer Scope (MUST)

The sponsor’s signature MUST be used only to authorize payment of transaction fees.

Concretely:

• The feePayer MUST NOT appear as a required signer (isSigner = true) in the account metadata of any instruction.
• The feePayer MUST NOT be used as an authority for any instruction.
• No instruction may rely on the feePayer signature to authorize state changes other than fee payment.

The feePayer MAY appear in instruction account lists as a non-signer (read-only or writable), including as the payment recipient when feePayer == payTo.

2.1.2 Fee Payer Fund Safety (MUST)

The sponsor MUST reject any transaction in which the sponsor’s funds could be debited beyond the network fee.

This includes transactions where:

• SOL could be transferred from an account controlled by the sponsor
• Tokens could be transferred from an account for which the sponsor is the authority
• Accounts owned by the sponsor could be closed, allocated, or reassigned in a way that moves lamports

Enforcing §2.1.1 is sufficient to prevent these conditions in standard Solana programs.

2.1.3 Signer Set Integrity (MUST)

The transaction MUST NOT require any additional signatures beyond:

• The client, and
• The sponsor (feePayer)

Additional signatures MAY be present but MUST NOT be required for transaction validity.

2.1.4 Exact Payment Verification (MUST)

The transaction MUST satisfy the Exact Payment Outcome Definition (§1).

---

2.2 Cost and Griefing Controls (Recommended SHOULDs)

The following controls are strongly recommended to mitigate gas griefing and denial-of-service risks.

2.2.1 Compute Budget Controls (SHOULD)

Sponsors SHOULD:

• Reject or override client-supplied ComputeBudgetProgram instructions
• Enforce maximum compute unit limits
• Enforce maximum compute unit price

2.2.2 Instruction Count Limits (SHOULD)

Sponsors SHOULD impose a maximum instruction count to bound execution cost.

2.2.3 Simulation-Based Rejection (SHOULD)

Sponsors SHOULD simulate the exact signed transaction and reject it if:

• Execution fails
• Compute usage exceeds configured limits
• Unexpected program behavior is observed

2.2.4 Program Allow/Deny Lists (SHOULD)

Sponsors SHOULD maintain allowlists for commonly accepted programs (e.g., token programs, ATA, compute budget).

Unknown or high-risk programs SHOULD be rejected or reviewed.

---

2.3 Policy Flexibility (Explicit)

• A transaction MAY be valid under the exact scheme while being rejected by a sponsor’s policy.
• Clients SHOULD NOT assume universal sponsorship for all valid exact transactions.

[amilz]

IMO Yes to option 2 would be ideal. In fact, we do this with our Kora Gasless Relayer as a Facilitator. Ideally the facilitator spec would allow for the facilitator server to add additional customization (e.g., additional instructions after the expected instructions, allowed/disallowed programs, allowed/disallowed accounts, etc.).

Here's an example implementation for discussion of how we could extend the existing instruction rule enforcement and give the facilitator the option to enable additional instruction verification checks (allow additional instructions, white/blacklist programs, create custom rules). These additional checks get registerred with the facilitator.

[tenequm]

@notorious-d-e-v This is exactly the right structure. Separating scheme definition from sponsor policy is the clean architecture this needed.

Your Section 2.1.1 (fee payer signer scope) is the key insight - once you verify the fee payer isn't authorizing anything beyond fee payment, the transaction structure becomes irrelevant. That's what unlocks the flexibility.

A few things that could strengthen Section 2.1 based on some edge cases:

ComputeBudget bypass - If a transaction has multiple SetComputeUnitPrice instructions, only the last one applies. An attacker could put a low value first (passes validation) then a high value later (actually charged). Same for SetComputeUnitLimit. Requiring exactly one of each would close this.

Account creation - Section 2.1.2 says "Enforcing §2.1.1 is sufficient" but CreateAccount with fee payer as from doesn't actually require fee payer as instruction signer - the fee payer role implicitly funds it. Might need an explicit check there.

Token-2022 extensions - Some extensions like NonTransferable or DefaultAccountState=Frozen will cause transfers to always fail. Probably worth explicit rejection in 2.1.

On the SHOULD vs MUST question for Section 2.2 - I'd lean toward making the critical cost controls (compute limits) normative. Otherwise facilitators diverge and clients can't predict acceptance. But curious what others think.

I put together some detailed analysis on these edge cases here if useful for tightening up 2.1.

[tenequm]

@amilz The per-facilitator customization approach concerns me. If each facilitator defines their own allowed programs, instruction limits, and custom rules - clients can't predict which facilitator will accept their transaction.

That breaks the network model. "x402 compatible" should mean something uniform. Otherwise we're not building a standard, we're building a framework where everyone does their own thing. The interoperability benefit disappears.