SEP support
Which Stellar Ecosystem Proposals the app implements, what each one is used for, and the full server surface.
The app implements the Stellar Ecosystem Proposals an account closer needs. Most anchor-oriented SEPs are not part of an account closer, and this page says which ones are and are not here.
Implemented
SEP-1, stellar.toml
public/stellar.toml declares the deployment's origin: organization details, the canonical URL,
the GitHub repository and a responsible principal.
The canonical SEP-1 location is /.well-known/stellar.toml. next.config.ts rewrites that path to
the served file and sets Access-Control-Allow-Origin: * and a text/plain content type on it, so
both /stellar.toml and the well-known path resolve.
The file declares no SIGNING_KEY, no SIGNERS and no WEB_AUTH_ENDPOINT. The mediator
co-signs with a key derived for each close from a server-held master, so there is no long-lived
account a signing entry could name, and no SEP-10 server runs. The account owner signs in their own wallet or
with a key pasted into the page, and that key never reaches the server.
There are no [[CURRENCIES]] entries, because the app issues no assets, and no [[VALIDATORS]],
because it runs no validator. ORG_LOGO points at https://demolisher.app/logo.png, served from
public/logo.png.
When you self-host, replace the organization details and the canonical URL with your own and serve the file from your domain.
SEP-29, account memo requirements
Before a close starts, the Configure step reads the destination account from Horizon. When its data
entry config.memo_required is 1, the close requires a memo and routes through the mediator, the
same as a registry exchange, and accepts any well-formed memo. A destination that cannot be read
blocks the close, because it is not confirmed free of a memo requirement.
The mediator forward runs Horizon's checkMemoRequired as its own step before submitting, so a
failure there is known to have sent nothing. See
Exchange integration.
SEP-41, Soroban token interface
The allowance viewer, the revoke steps of a close, and the standalone-token steps work against SEP-41 tokens.
Allowances are found from on-chain approve events, read back from the token's own
allowance(from, spender), and revoked with approve(from, spender, 0, ledger). Standalone token
balances are found from transfer and mint events, read with balance(id), and moved with
transfer(from, to, amount).
See SEP-41 allowances.
SEP-43, wallet interface
Used through Stellar Wallets Kit. The app calls authModal to pick a wallet, getAddress, and
signTransaction, and tears sessions down itself. It does not call signAuthEntry or
signMessage: every Soroban call it builds is authorized by the source account, so the envelope
signature covers it.
See Wallet integration.
Not implemented
An account closer is not an anchor, so these are not here:
| Proposal | Why it is not here |
|---|---|
| SEP-10, web authentication | There is no challenge flow. Authority is holding the key and signing the close itself, and the toml declares no WEB_AUTH_ENDPOINT |
| SEP-6, SEP-24, deposit and withdrawal | The app runs no deposit or withdrawal flows. Exchange delivery is the mediator payment path, not an anchor protocol |
| SEP-31, cross-border payments | 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
| Route | Documented in |
|---|---|
GET, POST /api/mediator/sign, POST /api/mediator/reissue | Mediator forward protocol |
/api/plan, /api/plan/[id], /api/plan/[id]/sign, /api/plan/[id]/events | Signing relay API |
POST, GET /api/metrics | Security model |
Wallet integration
For wallet developers. The signing surface the app uses, how a wallet gets listed, how the signed envelope is checked, and what Ledger and WalletConnect do.
Security model
What the deployment can and cannot do, the trust boundaries, the adversaries the design assumes, what each party can see, and the code that defends each boundary.