SEP-0058: External Account API — Provisioned Receiving Instruments for Stellar Wallets

[antb123]

Problem

SEP-6 models deposits as transactions. Each GET /deposit creates a one-time flow with its own
lifecycle. But many providers need to provision reusable receiving instruments — crypto deposit
addresses, virtual bank accounts, IBANs, CLABEs — that persist across multiple deposits and
aren't tied to a single transaction.

Some anchors work around this by returning the same address across multiple SEP-6 transactions
(#1341), but this overloads the transaction model with account semantics and creates
reconciliation ambiguity.

Proposal

SEP-58 introduces a dedicated External Account API — a single resource (account) with a clean
lifecycle (pending → active → deactivated) for provisioning inbound receiving instruments
bound to an authenticated Stellar wallet.

The API is minimal:

• GET /info — discover supported offerings (rail + country + asset combinations)
• POST /accounts — request a receiving instrument (idempotent)
• GET /accounts/:id — poll status and retrieve credentials

It reuses existing Stellar infrastructure: discovery via SEP-1, authentication via SEP-10
(G.../M...) and SEP-45 (C...), credential fields via SEP-9, and KYC remediation via SEP-12.

Key Design Choices

• Account, not transaction — the resource is reusable and user-scoped, not flow-scoped
• Idempotent creation — same parameters return the same account, no accidental duplicates
• Explicit offering matrix — clients never infer rail/country compatibility from separate lists
• Auth-protocol agnostic — consumes a valid JWT from SEP-10 or SEP-45

Why not extend SEP-6?

SEP-6 is transaction-scoped. Extending it would conflate two resource models. SEP-58 keeps both
clean: SEP-6 for transactions, SEP-58 for accounts. Providers can implement both — provision via
SEP-58, accept SEP-6 deposits into that same account. See also #1341 and #1372.

Adoption Context

Providers like Bridge (liquidation addresses) and
and on-chain ramp providers already offer reusable receiving instruments via proprietary APIs.
SEP-58 standardizes the common pattern.

Draft PR forthcoming. Looking for feedback on the API surface, offering model, and scope. We have already implemented
in an extended version of django-polaris and are in testing mode.