> For the complete documentation index, see [llms.txt](https://sonic-ai-works.gitbook.io/sonic-networks-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://sonic-ai-works.gitbook.io/sonic-networks-docs/documentation/developers/finance-and-protocols/solana-payments-qr-and-protocol-integrations.md).

# Solana payments, QR & protocol integrations

Solana Pay, QR, RPC, CCTP, x402 and ZK protocol wiring with server-authoritative intent, provider isolation and post-execution verification.

SONIC exposes protocol capabilities through server-side adapters. Browser and mobile code never receive provider secrets, treasury private authority, reconciliation credentials or authoritative commercial logic.

## Integration rule

```
Provider capability
      ↓
Protocol adapter
      ↓
SONIC domain service
      ↓
EconomicOperation
      ↓
Verification / Settlement / Reconciliation
```

No protocol SDK writes directly to the Credit, Reward, Token Allocation or Financial ledger.

## Solana gateway

Solana access is isolated behind logical roles:

```
RPC_READ
RPC_WRITE
RPC_CONFIRMATION
RPC_RECONCILIATION
```

They may initially resolve to the same infrastructure provider, but their policy and failure semantics remain distinct. A write timeout never proves failure; SONIC first checks the known signature/operation and chain state before deciding whether another submission is safe.

## Helius

Helius is used for RPC acceleration, indexing and webhook enrichment. Webhooks enter a durable inbox, are deduplicated and normalized, then trigger independent chain verification.

```
Helius event
→ webhook inbox
→ dedupe
→ normalize
→ verify chain state
→ settle if business policy allows
```

Helius events are observed signals, not final economic authority.

## Solana Pay

SONIC prepares a standards-compliant Solana Pay transfer request only from an existing server-authoritative intent. The URI carries the factual recipient, amount, optional SPL mint, label/message and a unique reference associated with the payment intent.

Preparing or scanning the QR does not settle the transaction. Verification checks network, recipient, mint, atomic amount, reference, transaction success and non-duplication before fulfillment.

## Circle CCTP

CCTP is represented as a feature-gated native-USDC interoperability capability. Provider/program addresses and supported-network configuration come from the protocol registry; enabling the SONIC product flow additionally requires approved USDC mint, destination, fees, recovery policy and checkout policy.

CCTP operations distinguish source burn, attestation and destination mint. Source completion never creates a checkout settlement until destination value is verified.

## x402

x402 uses HTTP `402 Payment Required` semantics for selected API resources. Resource pricing is owned by a versioned SONIC resource catalog, not middleware constants.

The normal flow is:

```
request
→ resource policy
→ price version
→ payment requirement
→ verification
→ entitlement
→ execution
```

Payment replay, stale requirements and resource mismatch are rejected. Facilitator/provider state is normalized behind the x402 adapter.

## ZK / privacy capabilities

ZK functionality is integrated through versioned verifier policies. It can prove defined predicates without making proof libraries the source of product permissions.

Where a proof is sufficient, SONIC minimizes collection of the underlying sensitive data. Proof verification never replaces explicit wallet authorization or on-chain settlement verification.

Token-2022 confidential-balance capabilities, if enabled, remain a separate privacy feature. Confidential amounts do not imply anonymous accounts or anonymous transaction participation.

## Feature status vs deployment status

A protocol can be deployed while the corresponding SONIC feature remains disabled. Public status therefore separates:

* protocol available;
* configured;
* verified;
* product enabled;
* degraded/paused.

A green production status is reserved for verified and enabled mainnet capability.

## Provider degradation

Provider failures degrade only dependent surfaces where possible:

* Birdeye unavailable → market charts/analytics degrade;
* Helius webhook unavailable → reconciliation continues from chain state;
* Jupiter unavailable → verified direct venue routes may remain available;
* Solscan unavailable → explorer links degrade only;
* CCTP unavailable → cross-chain USDC is disabled;
* ZK verifier unavailable → proof-gated actions fail closed;
* RPC disagreement → sensitive writes may be paused.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://sonic-ai-works.gitbook.io/sonic-networks-docs/documentation/developers/finance-and-protocols/solana-payments-qr-and-protocol-integrations.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.