Solana

Roadmap Solana is an explicit target blockchain family for ChatterPay B2B and uses a native adapter built on its own network primitives: accounts owned by on-chain programs, one associated token account per token, and Ed25519 signatures.

Accounts and token balances

Solana keeps state in accounts owned by on-chain programs. The native SOL balance lives on the wallet account itself, while every SPL token balance lives in a separate associated token account derived from the owner and the token mint.

That has a practical consequence a Partner should know about: receiving a token for the first time may require creating that associated account, and the account must hold a small rent-exempt minimum in SOL to remain alive. The adapter creates and funds it as part of the operation instead of failing the transfer.

Signing

Solana signs with Ed25519, the same curve Cardano uses and a different one from the EVM and Bitcoin families. The Partner Signer Gateway holds Solana key references and signs the serialized message, so the private key never reaches the API.

Transaction lifetime

A Solana transaction references a recent blockhash and is only valid for a short window after it. A transfer that is not confirmed inside that window cannot be resubmitted as-is: it has to be rebuilt with a fresh blockhash and signed again.

Because of that, a retry is a new signature request, and the reconciler treats an expired transaction as a definitive non-execution rather than an unknown state. Priority fees and the requested confirmation level are part of the same quote.

Transfer flow

sequenceDiagram
    autonumber
    participant P as Partner backend
    participant API as B2B API
    participant OP as Operation worker
    participant A as Solana adapter
    participant N as Solana RPC
    participant SG as Partner Signer Gateway
    participant R as Observer/Reconciler
    P->>API: Transfer SOL/SPL token
    API->>OP: Operation + reserve
    OP->>A: Prepare transaction
    A->>N: Recent blockhash + account state
    N-->>A: Blockhash + rent/ATA status
    A->>A: Instructions, ATA creation, priority fee
    A->>SG: Sign message
    SG-->>A: Ed25519 signature
    A->>N: Send transaction
    N-->>A: Signature (tx id)
    R->>N: Observe confirmation level
    R->>OP: Reconcile amounts and fees
    OP-->>P: Webhook / state

What each step does

1. Partner backend → API. The Partner asks to send SOL or an SPL token.
2. API → operation worker. The Operation is persisted and the balance reserved, which is what makes the flow survive a restart.
3. Worker → Solana adapter. The adapter holds the rules of this family: accounts owned by programs, one token account per token, and transactions that expire.
4. Adapter → RPC: recent blockhash and account state. Both are needed at once: the blockhash the transaction will reference, and whether the recipient's associated token account already exists.
5. RPC → adapter: blockhash and rent/ATA status. The answer says which associated token accounts exist and how much SOL each needs to stay rent-exempt.
6. The adapter builds the transaction. The transfer instructions, the creation of the recipient's associated token account when it is missing, the minimum SOL that account needs to keep existing, and the priority fee.
7. Adapter → Partner Signer Gateway. The serialized message travels with the Solana key reference. Solana signs with Ed25519 and keeps its own keys and addresses.
8. Gateway → adapter: Ed25519 signature. The signature returns and the private key stays inside the gateway.
9. Adapter → RPC: send the transaction. From here the blockhash starts running out: the transaction is valid for a short window.
10. RPC → adapter: signature (tx id). The signature of the transaction is its identifier on the network.
11. Observer → RPC: confirmation level. Each operation declares the level it waits for. A transaction that expires without confirming is a definitive non-execution, and a retry is a new transaction with a fresh blockhash and a fresh signature.
12. Reconciler → worker. The amounts settled and the fees paid are contrasted against the ledger.
13. Worker → Partner. The final state travels as a signed webhook, and the same result can be read from the Operation.

References

• Solana Docs — Accounts
• Solana Docs — Transactions and instructions
• Solana Program Library — Associated Token Account

Capabilities in this area

This area covers the capabilities below. The Roadmap states the current availability of each one.

• Native adapter and account model — Solana keeps balances in accounts owned by programs, and each token balance lives in its own separate account. The adapter derives and creates those accounts, and deposits the minimum amount of SOL they need in order not to be deleted.

• SOL and SPL token transfers — Sending the native coin and SPL tokens through the same Operation model as the other families, building both the instruction that moves the amount and the one that creates the recipient's token account when it does not exist yet.

• Blockhash-based transaction lifecycle — A Solana transaction carries a recent blockhash and expires a short while later. When it expires, the adapter builds it again with a new blockhash and asks for a new signature. The quote also states the priority fee and the confirmation level being waited for.

• Solana observation and reconciliation — A component watches for incoming transfers and checks the settled amounts against the ledger, waiting for the confirmation level agreed for each operation before treating it as final.

• Devnet — Solana available on its public development network from the API, the SDK and the Sandbox. A Partner can send and receive SOL and SPL tokens with no funds at risk, and check every transaction in a public explorer.

• Mainnet — Solana on the network where the funds are real. It depends on the custody, security and operational capabilities listed in the other areas being finished first.