Stellar

Roadmap Stellar is an explicit target payment rail for ChatterPay B2B, with its own native adapter: classic G... accounts, assets identified by code and issuer, Ed25519 signatures, and one account able to sponsor the fees and the reserves of another.

Status: planned, targeting Testnet first. Everything on this page is on the Roadmap. The network any deployment operates comes from its catalogue and its provider credential.

Network

Roadmap Stellar arrives on its public test network, which is where a Partner can send and receive with no funds at risk and check every transaction in a public explorer. Mainnet comes later, as a deployment and manifest decision taken after the custody, security and operational capabilities are finished — the same path Arbitrum, Base, Bitcoin and Cardano follow.

Accounts and addresses

Roadmap A Stellar account is a classic G... account, and its address exists as soon as the key exists. A recipient is therefore resolved and can receive funds with nothing written on chain and at no cost, the same property Cardano gives and the one EIP-7702 has to build in the EVM family.

An account keeps a minimum reserve in XLM that stays locked while the account and its entries live, and every entry it adds — a trustline among them — raises that reserve. The platform reports the reserve beside the available balance instead of folding the two into one number.

Assets

Roadmap Two assets travel in the first scope:

• XLM, the network's native asset. It needs no trustline, which is what makes it the shortest path through address → receive → observe → reconcile → send.
• USDC, the asset most B2B and person-to-person payments actually use.

On Stellar an asset is identified by its code and its issuer, and a contract address where one applies. Two assets sharing a symbol and carrying different issuers are different assets, so the platform resolves an asset by its identifier in the catalogue and never by parsing its name. Holding an issued asset requires a trustline, and a missing trustline on the destination is stated before anything is signed.

Operations

Roadmap Stellar enters through the contracts that already exist, rather than through operations with the network's name in them. A transfer carries the network, the asset, the destination and the amount; balances, addresses, networks, assets and transaction status are read the same way for Stellar as for any other network. Adding the network is a catalogue entry, not a new method.

• Address. Resolved from a wallet with no on-chain write.
• Balances. Read from the network, with the minimum reserve reported separately from the available amount.
• Transfers. Quoted with the debit, the fee and what reaches the destination as three figures, then authorized, submitted and reconciled.
• Deposits. Watched for at each wallet's address, credited once the network's finality threshold is reached, and checked against the ledger.

Custody

Roadmap ChatterPay is designed so that platform-controlled credentials alone cannot unilaterally move customer funds. What the platform does is build the operation, orchestrate it, ask for authorization, sponsor the fee, observe the network, reconcile the result, emit the webhook and expose it all through the API and the SDK.

Authorization is a step of its own between the intent and the execution, which is what keeps a payment authorized the same way whichever surface it was asked from. Stellar's own primitives are what make this practical: an account can require several signatures, and recovery schemes can be added without moving the funds to a different address.

Fee and reserve sponsorship

Roadmap Stellar lets one account pay the fee of a transaction another account signs, and lets one account put up the reserve another account's entries require. Both are used so that somebody can receive an asset, open a trustline for it and send it without first holding the network's native coin.

Payment flow

Roadmap This flow describes the adapter as it is designed, and is on the Roadmap rather than available today.

sequenceDiagram
    autonumber
    participant C as Channel or Partner backend
    participant API as B2B API
    participant PS as Payment service
    participant AU as Authorization provider
    participant A as Stellar adapter
    participant N as Stellar network
    participant R as Observer/Reconciler
    C->>API: Transfer intent (network, asset, destination, amount)
    API->>PS: Operation + reserve
    PS->>A: Prepare transaction
    A->>N: Account state, sequence, fee and reserves
    N-->>A: Sequence, base fee, trustlines
    A->>A: Build operations, time bounds, sponsorship
    A->>AU: Authorization request
    AU-->>A: Authorized transaction
    A->>N: Submit
    N-->>A: Transaction hash and result
    R->>N: Observe finality
    R->>PS: Reconcile amounts and fees
    PS-->>C: Webhook / state

What each step does

1. Channel or Partner backend → API. The intent carries the network, the asset, the destination and the amount. The surface that expressed it changes nothing else.
2. API → payment service. The Operation is persisted and the balance reserved, which is what makes the flow survive a restart.
3. Payment service → Stellar adapter. The adapter holds the rules of this family: sequence numbers, time bounds, minimum reserves and trustlines.
4. Adapter → network. It asks for the account state, the sequence number the transaction will carry, the current base fee and the reserves in play.
5. Network → adapter. The answer carries the sequence number, the base fee and which trustlines already exist.
6. The adapter builds the transaction. The payment operation, the time bounds after which it can no longer be included, and the sponsorship of the fee and of any reserve the operation needs.
7. Adapter → authorization provider. Authorization is requested rather than assumed, and it happens outside the channel the request arrived on.
8. Authorization provider → adapter. The authorized transaction comes back, and the credentials that authorized it stay where they were.
9. Adapter → network: submit. The transaction goes out authorized.
10. Network → adapter. The network answers with the transaction hash and its result.
11. Observer → network. Finality is watched for at the threshold declared for the network.
12. Reconciler → payment service. The amounts settled and the fees paid are contrasted against the ledger.
13. Payment service → channel or Partner backend. The final state travels as a signed webhook, and the same result can be read from the Operation.

Escrow and conditional payments

Roadmap Conditional and P2P payments are planned through Trustless Work smart-contract infrastructure on Stellar and Soroban. They are a capability of their own, described in Escrow and conditional payments: an ordinary Stellar transfer goes straight over this rail, and an agreement that holds funds against a condition is a different product object.

Channels

Roadmap Every capability on this page is reached from the supported surfaces alike: the API, the SDK, a conversational channel or a web interface. A channel is a way of expressing the request, and the wallet, the payment, the authorization and the network integration belong to the platform.

References

• Stellar Docs — Accounts
• Stellar Docs — Assets and trustlines
• Stellar Docs — Sponsored reserves
• Trustless Work

Capabilities in this area

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

• Transfers — Sending XLM, the network's native asset, and USDC through the same Operation model as the other families. The quote states the debit, the fee and what reaches the destination before anybody confirms, and the operation records the hash the network returned. A Stellar asset is identified by its code and its issuer, and a missing trustline is stated before signing rather than after the transfer fails.

• Swaps — Swapping one Stellar asset for another through Soroswap, which aggregates the liquidity of the network's exchanges. A quote shows what goes in, what comes out, the route, the slippage and the fees before anybody confirms, and the operation records the result the network returned. Swaps on EVM networks and between networks keep their own provider.

• Non-custodial authorization — On Stellar, no key or set of credentials under ChatterPay's exclusive control is enough to move a user's funds. The account keeps its own signers and thresholds, and authorization is its own step between the intent and the execution, so the same payment is authorized the same way whichever surface it came from.

• Fee and reserve sponsorship — Stellar lets one account pay the fee of a transaction another account signs, and lets one account put up the reserve another account's entries require. Both are used so somebody can receive and send an asset without first holding the network's native coin.

• Smart wallet and passkeys on Soroban — Soroban, Stellar's contract platform, makes programmable wallet controls possible: passkeys, spending policies, session keys and delegated authorization. It is under evaluation as another authorization variant, on top of the classic account the network already provides.

• Earn and yield on Stellar — Putting an idle balance to work through lending and yield protocols on Stellar and Soroban. It is under evaluation as a capability of its own, with the counterparty risk stated before any interface exists for it.

• Stellar Testnet via API, SDK and Sandbox — Stellar Testnet is reachable from the API, the SDK and the Sandbox, with no funds at risk. This row states that the network is integrated; the row of each operation states whether it is complete.

• Mainnet for production deployments — Stellar on the network where the funds are real, for a Partner's production deployment: its manifest enables the network, the contracts and the assets, after the security review and with limits, reconciliation, pause and rollback in place. It depends on the custody, security and operational capabilities listed in the other areas being finished first. Switching it on for a given Partner is a step of that Partner's onboarding.