SEP support
Which Stellar Ecosystem Proposals the app implements, and what each one is used for.
The app touches a small, specific set of Stellar Ecosystem Proposals. Being precise about which matters, because most anchor-oriented SEPs are deliberately not part of an account closer.
Implemented
SEP-1, stellar.toml
public/stellar.toml is an origin declaration for the deployment: organization details, a
canonical URL, and a responsible principal.
The canonical SEP-1 location is /.well-known/stellar.toml. Next.js publishes anything
under public/ at the matching path, so the app ships a rewrite mapping the well-known path
to the served file, plus headers setting Access-Control-Allow-Origin: * and a plain-text
content type. Both paths resolve.
The file declares no SIGNING_KEY and no SIGNERS, by design. The mediator co-signs
with a per-flow ephemeral key derived fresh for every close, so there is no long-lived
account a SEP-1 signing block could name. All user-side signing happens client-side and is
never transmitted to the server. Declaring a fixed key would be misleading, so it is omitted
rather than filled with a placeholder.
No [[CURRENCIES]] entries: the app issues no assets. No [[VALIDATORS]] entries: it runs
no validation nodes.
Self-hosters replace the organization details and canonical URL with their own and serve the file from their domain.
SEP-41, Soroban token interface
The allowance viewer and every revoke work against SEP-41 tokens.
Allowances are enumerated from on-chain approve events, read back from the token's own
allowance(from, spender) to confirm the event was not fabricated, and revoked by building
approve(from, spender, 0, ledger).
Standalone token balances are read and moved through the same interface.
See SEP-41 allowances.
SEP-43, wallet interface
Used through Stellar Wallets Kit. The app calls exactly getAddress, signTransaction, and
signAuthEntry.
See Wallet integration.
Not implemented
These are listed because integrators reasonably ask, and the answer is architectural rather than incidental: an account closer is not an anchor.
| Proposal | Why it is not here |
|---|---|
| SEP-10, web authentication | There is no challenge flow. Authentication is holding the key and signing a real closure transaction. public/stellar.toml reuses the WEB_AUTH_ENDPOINT key only to record the canonical URL; no SEP-10 server runs |
| SEP-6, SEP-24, deposit and withdrawal | The app is not an anchor and runs no interactive or programmatic deposit flows. Exchange interoperation is the mediator payment path, not an anchor protocol |
| SEP-31, cross-border payments | Not applicable. The app moves an account owner's own balance to a destination they chose; it is not a payment corridor |
If you are integrating an anchor, none of those endpoints exist here to call.
The complete server surface
Three route groups, all documented:
- The mediator co-signer
- The multisig signing relay
- The Soroswap aggregator proxy, covered in Security model