SEP-24 vs. SEP-6: Stellar Interactive Flow Integration

introduction

SEP-24 VS. SEP-6 INTEGRATION DECISION

Choosing the Right On/Off-Ramp Standard

A technical comparison of Stellar's interactive and programmatic deposit/withdrawal standards to guide anchor and wallet integration architecture.

Stellar Ecosystem Proposals SEP-6 and SEP-24 define the two primary standards for moving value on and off the network via anchors. The core architectural decision between them hinges on where KYC/AML and user interaction are hosted: SEP-6 provides a programmatic, API-driven flow where the client wallet manages the entire user experience, while SEP-24 delegates identity verification and compliance steps to an interactive web view hosted by the anchor service. This choice directly impacts the integration complexity for wallets, the compliance liability for anchors, and the user experience for end-users.

From an operational perspective, SEP-24 anchors must implement a secure browser-based session that collects sensitive user data, handles document uploads, and returns a tokenized session to the wallet via a callback. This shifts the compliance burden to the anchor but simplifies wallet integration to opening a URL and listening for a callback. In contrast, SEP-6 requires the wallet to programmatically collect and forward user information through a sequence of API calls (/deposit, /customer, /transaction), demanding robust error handling for non_interactive_customer_info_needed and customer_info_status responses. A critical failure mode for SEP-6 integrations is a wallet mishandling the action_required or pending_transaction_info_update statuses, which can leave a user's deposit in a permanently incomplete state.

The session management models also differ significantly. SEP-24 relies on an interactive web session with a short-lived token, requiring anchors to defend against clickjacking and ensure the jwt token returned to the wallet is validated and bound to the correct Stellar account. SEP-6 uses a long-lived API session where the wallet must correctly manage id fields for repeated /customer calls. For teams building a new anchor, the choice often comes down to whether they want to own the compliance UI (SEP-24) or expose a headless API for sophisticated wallet partners (SEP-6). Chainscore Labs can review the chosen integration path for session security, correct handling of non-happy-path states, and compliance with user data handling requirements under both standards.

INTERACTIVE VS. PROGRAMMATIC INTEGRATION

SEP-6 vs. SEP-24: Quick Comparison

A side-by-side evaluation of the two primary Stellar deposit and withdrawal standards to guide integration architecture decisions.

Area	SEP-6 (Programmatic)	SEP-24 (Interactive)	Action
User Experience	Client builds the entire UI/UX for deposit/withdrawal.	Anchor hosts the KYC/AML and transaction flow in a web view.	Frontend teams must decide whether to own the UX or delegate it to the anchor.
KYC/AML Handling	Client collects and passes PII via API parameters. Client is responsible for data handling compliance.	User interacts directly with the anchor's hosted pages. Anchor bears the primary PII compliance burden.	Legal and compliance teams must assess data controller vs. processor liability for each model.
Integration Complexity	High. Requires implementing full transaction state machines, error handling, and form logic.	Lower. Client redirects to anchor URL and listens for callbacks or polls for status.	Backend teams should evaluate the cost of building and maintaining a full SEP-6 state machine.
Session Management	Client manages the entire session lifecycle via API tokens.	Anchor manages the interactive session via a token in the callback URL. Client must secure the callback endpoint.	Review SEP-10 authentication and JWT handling for both models to prevent session hijacking.
Asset Information Discovery	Client parses the /info endpoint to dynamically build forms for each asset's required fields.	Client parses the /info endpoint primarily to discover the interactive URL and supported assets.	Wallets must implement robust /info parsing to avoid hardcoding fields that may change per anchor.
Error Handling	Client must handle all API error codes and transaction statuses programmatically.	Errors are displayed to the user within the anchor's web view. Client handles top-level failures like timeout or unreachable URL.	SRE teams need to monitor for SEP-24 timeout errors and SEP-6 transaction failure codes differently.
Mobile Wallet Suitability	High control allows for a fully native UX, but requires significant development effort.	Web-based flow can feel less native. Requires secure WebView implementation and deep-link handling.	Mobile developers must weigh native UX control against the security risks of hosting third-party web content.
Non-Custodial Control	User signs all transactions in their own wallet client.	User signs a transaction from their wallet after completing the interactive flow. The anchor provides the transaction XDR.	Verify that the SEP-24 flow does not introduce a trust assumption where the anchor could substitute a malicious transaction.

technical-context

ANCHOR INTERACTION MODEL

Integration Architecture and Trust Boundaries

How SEP-24 and SEP-6 define fundamentally different trust and integration boundaries between client applications and Stellar anchors.

The core architectural distinction between SEP-24 and SEP-6 is where the user's interactive session is hosted and who controls the KYC/AML data flow. SEP-24 mandates that the anchor hosts the interactive web experience directly, typically via an embedded WebView or popup, creating a direct trust boundary between the user and the anchor. The client application (wallet or exchange) acts as a conduit, initiating the flow via a POST /transactions/interactive request and receiving a URL to render, but never touches the user's personally identifiable information (PII). This architecture cleanly separates the asset control logic of the wallet from the compliance obligations of the anchor.

In contrast, SEP-6 establishes a programmatic, API-driven integration where the client application is an active intermediary. The client collects all required KYC data from the user within its own interface and relays it to the anchor's POST /deposit or POST /withdraw endpoints. This model places the client application inside the compliance trust boundary; the anchor must trust the client to collect data faithfully and the client assumes responsibility for secure handling of PII in transit. The operational impact is significant: SEP-6 integrations require a more complex backend to manage the stateful transaction flow, poll the /transaction endpoint for status updates, and handle pending_customer_info_update statuses by prompting the user for additional data.

For builders, the choice between these standards is a decision about liability and user experience. SEP-24 simplifies the client's compliance burden but cedes control of the user experience during the critical deposit and withdrawal moments, introducing a dependency on the anchor's UI reliability. SEP-6 offers full UX control but demands that the integrator build and secure a KYC data pipeline, manage session state, and implement robust error handling for a multi-step, asynchronous API flow. Chainscore can review the chosen integration path to assess session security, validate proper handling of more_info_url responses, and ensure that the architecture correctly isolates PII from systems that do not require it.

WHO MUST ACT ON SEP-24 VS. SEP-6 DECISIONS

Affected Integration Teams

Frontend & UX Engineers

Your integration path changes fundamentally based on the SEP choice. SEP-24 requires embedding an interactive webview or redirect flow to host the anchor's KYC/AML UI, demanding careful session handoff and deep-link management. SEP-6 requires building a fully custom deposit/withdrawal UI that programmatically drives the API, placing the compliance data-collection burden on your interface.

Action items:

Audit the anchor's SEP-24 URL for mobile webview compatibility and JavaScript requirements.
Implement callback and on_change_callback handling to detect interactive flow completion.
For SEP-6, design clear error states for non_interactive_customer_info_needed and customer_info_status responses.
Validate that session tokens from SEP-10 are correctly forwarded to the interactive URL or API calls.

implementation-impact

SEP-24 VS SEP-6 TRADE-OFFS

Key Integration Decision Points

The choice between SEP-24 and SEP-6 is a critical architectural decision that shapes your compliance posture, user experience, and backend complexity. Each decision point below forces a specific operational commitment.

Interactive UX vs. API-Driven Automation

SEP-24 mandates hosting an interactive web view for KYC/AML collection, shifting the compliance burden to the anchor's UI. SEP-6 requires the client wallet to collect and relay all user information programmatically via API parameters. Choosing SEP-24 means you must build and maintain a secure, responsive web application that handles sensitive PII, while SEP-6 forces the wallet to implement complex form logic and file upload handling. This decision directly impacts your frontend team's scope and the user's drop-off rate during onboarding.

EXPLORE

Session Management and Token Security

SEP-24 relies on a long-lived interactive session token returned by POST /transactions/interactive_withdraw or deposit. This token is passed to a mobile or desktop web view. If the token is leaked via deep links, logging, or an insecure WebView implementation, an attacker can hijack the KYC session. SEP-6 uses short-lived, per-request authentication. Teams choosing SEP-24 must implement strict token binding, secure WebView configurations, and short expiry windows to prevent session hijacking and unauthorized transaction initiation.

EXPLORE

Callback Reliability and Idempotency

In SEP-24, the anchor must call the wallet's callback URL with callback parameter upon transaction completion. If the wallet's endpoint is unreachable, the user's funds may be stuck in a 'pending' state with no client-side resolution. SEP-6 relies on the client polling GET /transaction?id= for status updates, which is simpler but can lead to race conditions. Integration teams must implement a reconciliation cron job that queries the anchor's /transaction endpoint directly as a fallback to the callback mechanism, ensuring no transaction is orphaned.

File Upload and PII Data Handling

SEP-24 anchors must handle file uploads (e.g., identity documents, proof of address) within the interactive flow and store them according to jurisdictional data residency requirements. SEP-6 pushes this burden to the wallet, which must collect binary data via POST /customer/files and manage the upload lifecycle. If you are a wallet integrating multiple anchors, SEP-6 forces you to build a generalized file handling pipeline. If you are an anchor, SEP-24 centralizes sensitive document storage under your direct control, simplifying audit trails but increasing your data breach liability.

Nonce and Transaction Integrity

SEP-24's interactive flow introduces a temporal gap between the user's intent and the anchor's on-chain transaction submission. The anchor manages the Stellar account nonce internally. In SEP-6, the wallet constructs and signs the transaction, controlling the nonce directly. A SEP-24 anchor must implement a robust nonce management system to prevent transaction submission failures under high concurrency. For SEP-6 wallets, you must handle tx_bad_seq errors gracefully if the user's account state changes between the quote and submission phases.

Chainscore Integration Review

The session token flow in SEP-24 and the error handling in SEP-6's polling loop are the most common sources of integration failure. Chainscore Labs can perform a targeted review of your SEP-24 interactive session management for token leakage risks and your SEP-6 idempotency logic to prevent double-spend or stuck transactions. We assess your callback fallback mechanisms and nonce management strategy against Stellar's eventual consistency model to ensure your integration is resilient under anchor failure scenarios.

EXPLORE

SEP-24 VS SEP-6 DEPOSIT/WITHDRAWAL FLOW SELECTION

Integration Risk Matrix

Evaluates the operational, compliance, and technical risks that integration teams must weigh when choosing between the interactive (SEP-24) and programmatic (SEP-6) standards for anchor integration.

Area	What changes	Who is affected	Action
KYC/AML Data Handling	SEP-24 shifts collection of sensitive user data to the anchor's hosted UI; SEP-6 requires the client wallet to collect and forward this data via API.	Wallets, custodians, and compliance teams	For SEP-24, audit the redirect flow and session token handling. For SEP-6, review client-side data encryption and transmission against data protection requirements.
User Experience Flow	SEP-24 introduces a browser redirect to an external interactive URL; SEP-6 is a fully in-app, API-driven experience.	Frontend and mobile development teams	Verify SEP-24 redirect behavior on all target platforms (mobile WebView vs. browser). For SEP-6, design clear UX for pending transaction statuses and required user actions.
Session and State Management	SEP-24 relies on the anchor's web session and a callback token; SEP-6 requires the client to poll a transaction endpoint to track status.	Backend integration engineers	Implement robust polling and timeout logic for SEP-6. For SEP-24, ensure the callback endpoint is idempotent and can handle delayed or duplicate anchor responses.
Error and Exception Handling	SEP-24 failures can occur inside the hosted UI (opaque to the client) or via callback failure; SEP-6 errors are explicit API responses.	SRE and operations teams	Build monitoring for SEP-24 callback failures and session timeouts. For SEP-6, map all defined API error codes to user-recoverable actions and critical alerts.
Compliance Liability	SEP-24 places the data collection burden and UI liability on the anchor; SEP-6 makes the integrating wallet a data processor in the compliance flow.	Legal and compliance officers	Clarify the data processor vs. controller relationship with the anchor for each standard. Review the SEP-6 integration for compliance with data minimization and right-to-deletion requirements.
Anchor Support and Interoperability	Not all anchors support both standards; SEP-24 is common for high-friction KYC, SEP-6 for tokenized securities or programmatic flows.	Business development and product teams	Verify the target anchor's supported SEPs and their specific field requirements by querying the stellar.toml file. Do not assume feature parity between standards.
Transaction Idempotency	SEP-6 requires the client to generate a unique idempotency key; SEP-24 manages this server-side via the interactive session.	Backend integration engineers	For SEP-6, implement a robust client-side idempotency key generator and ensure retry logic references the same key. Test for double-submission protection under network failure scenarios.
Security Review Scope	SEP-24 expands the attack surface to include the anchor's web UI and redirect manipulation; SEP-6 focuses on API authentication and input validation.	Security engineers and auditors	For SEP-24, review the redirect URI validation and post-interactive callback integrity. For SEP-6, audit the SEP-10 authentication token lifecycle and API request signing.

SEP-24 vs. SEP-6 Readiness

Integration Rollout Checklist

A practical checklist for teams preparing to launch or migrate a deposit/withdrawal integration. Each item identifies a critical readiness signal, explains why it matters, and specifies the artifact or test that confirms correct implementation before production rollout.

What to check: For SEP-24, verify that the interactive URL returned by POST /transactions/interactive is correctly opened in the user's browser or webview, and that the integration handles session expiration gracefully.

Why it matters: The interactive URL is a hosted KYC/AML flow with a finite session lifetime. If the user abandons the flow or the session expires, the anchor will stop polling. The client must detect this state and either restart the transaction or surface a clear error to the user.

Readiness signal: A test case where the interactive URL is opened, the user waits until the session expires (as defined by the anchor's interactive_deposit response), and the client correctly transitions the transaction status to error or prompts the user to re-initiate. Confirm that no orphaned incomplete transactions remain in the client's state.

resource-links

STELLAR ANCHOR STANDARDS

Canonical Resources

Official Stellar Ecosystem Proposals define the contract between wallets, anchors, compliance systems, and payment applications. Use these resources to verify current endpoint behavior, session requirements, and compatibility obligations before choosing SEP-24 or SEP-6.

SEP-24: Hosted Deposit and Withdrawal

Use SEP-24 as the canonical reference for interactive anchor flows where the wallet or application opens an anchor-hosted web experience for KYC, payment instructions, and transaction status. Integration teams should review the transaction lifecycle, callback expectations, iframe or browser handling, and how the anchor communicates pending, completed, refunded, or failed states. SEP-24 is usually the better fit when the anchor must control regulated user-data collection or provide a branded compliance workflow.

EXPLORE

SEP-6: Programmatic Deposit and Withdrawal API

Use SEP-6 as the canonical reference for API-driven deposit and withdrawal flows where the client application orchestrates most user experience and calls anchor endpoints directly. Backend teams should validate request parameters, status polling, memo or destination handling, fee disclosure, and idempotency behavior against the spec. SEP-6 can be appropriate for tightly controlled products, but it shifts more error handling, compliance UX, and state reconciliation responsibility onto the integrating application.

EXPLORE

SEP-10: Web Authentication

SEP-10 is the authentication layer commonly used before calling SEP-24, SEP-6, SEP-12, and related anchor services. Teams should verify challenge transaction validation, domain binding, nonce freshness, JWT issuance, token expiry, and replay protection before exposing deposit or withdrawal endpoints. For SEP-24, SEP-10 often gates access to the hosted interactive session. For SEP-6, it protects programmatic API calls that may trigger sensitive compliance or settlement workflows.

EXPLORE

SEP-12: KYC and Customer Information

SEP-12 defines how wallets and applications exchange customer information with anchors. It is operationally important when comparing SEP-24 and SEP-6 because SEP-24 may hide much of the KYC collection inside the anchor-hosted flow, while SEP-6 integrations may need to coordinate customer records and required fields more explicitly. Compliance and security teams should review data minimization, field validation, PII storage, consent handling, and retention controls before implementing production deposit or withdrawal flows.

EXPLORE

SEP-1: stellar.toml Service Discovery

SEP-1 defines the stellar.toml discovery file that wallets and applications use to locate anchor endpoints, supported assets, signing keys, and service metadata. Before integrating SEP-24 or SEP-6, teams should verify that the anchor's TOML advertises the correct transfer server, web authentication endpoint, KYC server, and asset information. Misconfigured discovery data can route users to stale endpoints, break wallet compatibility, or cause production clients to use the wrong compliance and settlement services.

EXPLORE

Stellar Protocol Repository

Monitor the Stellar protocol repository for changes to SEP-24, SEP-6, SEP-10, SEP-12, and related ecosystem standards. Anchor operators, wallet teams, and exchanges should treat SEP changes as integration-impact events: review pull requests, compare implemented behavior against the current text, and test compatibility before updating production flows. Chainscore Labs can help teams map proposed SEP changes to session security, compliance-data handling, wallet UX, and settlement reconciliation controls.

EXPLORE

Chains We Build On

Looking to build on a specific blockchain?

We build smart contracts, DeFi applications, wallets, tokenization platforms, and blockchain infrastructure across the major ecosystems teams choose today. That includes Ethereum, Arbitrum, Optimism, Polygon, Avalanche, Solana, Sui, Aptos, Hedera, Stellar, and NEAR, with support for additional EVM and non-EVM networks based on your product requirements.

Learn More

EVM ecosystems

Ethereum
Arbitrum
Optimism
Polygon
Avalanche
Cronos

Non-EVM ecosystems

Solana
Sui
Aptos
Hedera
Stellar
NEAR

Additional ecosystems

Polkadot
Cosmos
TON
Cardano
Algorand
Tempo

Also available for Base, appchains, custom EVM networks, and cross-chain product architecture.

INTEGRATION DECISION GUIDANCE

Frequently Asked Questions

Answers to the most common architectural and operational questions teams face when choosing between the interactive SEP-24 and programmatic SEP-6 deposit and withdrawal standards.

Choose SEP-24 when the anchor must host an interactive web-based KYC/AML or identity verification flow. This is the primary differentiator. SEP-24 allows the anchor to serve a fully branded, compliant UI within the wallet's webview, giving the anchor complete control over data collection, document upload, and session management. Use SEP-6 when the wallet or client application handles all user interaction and the anchor only needs to expose a programmatic API for deposit/withdrawal instructions. The decision hinges on who owns the user experience and the regulatory requirement for the anchor to directly interact with the end-user.

Trusted by Industry Leaders

Delivering blockchain solutions for 5+ years.

We have partnered with 50+ leading DeFi protocols, NFT ecosystems, and fintech innovators to build secure, scalable, and capital-efficient blockchain products.

Selected Partners & Clients

“I've been working with Chainscore Labs for last 3+ years, they've consistently delivered with strong ownership across multiple projects. The team is reliable and detail-oriented.”

Lee Erswell

CEO, Telos Foundation

how to get started

How to get started?

If you're looking for blockchain integration, ChainScore Labs has 5+ years of experience helping teams build and integrate exchanges, wallets, smart contracts, tokenization solutions, and protocol-connected products, we can help you choose the right path, integrate securely, and get to production faster. Our team consists of experienced blockchain developers and architects who can help you with your blockchain integration needs.

Exploration & Strategy

Define your product goals and choose the right blockchain architecture for your use case.

Architecture & Design

Design the smart contracts, tokenomics, and security parameters of your system.

Development & Integration

Build and integrate with wallets, oracles, and front-end dApps for a seamless experience.

Security & Launch

Comprehensive audits followed by a risk-managed mainnet deployment to protect your users.

Learn More

Explore More Solutions

Discover our
blockchain development services.

We build production-grade blockchain solutions for top-tier projects across DeFi and Web3.

Book a Call

DeFi Protocol Development

End-to-end development of custom DeFi protocols including core smart contracts and system architecture.

DEX & Exchange Development

Building high-performance decentralized exchanges with optimized liquidity and advanced trading logic.

Lending & Borrowing Platforms

Scalable credit markets and money protocols built for production-grade liquidity and security.

SEP-24 vs. SEP-6 Interactive Flow Integration

Choosing the Right On/Off-Ramp Standard

SEP-6 vs. SEP-24: Quick Comparison

Integration Architecture and Trust Boundaries

Affected Integration Teams

Frontend & UX Engineers