Allowance viewer

SEP-41 is Stellar's standard for fungible tokens on Soroban. Like the ERC-20 approve model, holders can grant a spender (often a router or a contract) permission to move a specified amount of a token on their behalf. Forgotten approvals are a real attack surface: a malicious or compromised spender can drain whatever the allowance authorizes.

The allowance viewer is a standalone tool in the same app at /allowances. You don't have to close anything to use it.

What it shows

Paste a Stellar G-address (your own or someone else's) and click Scan. The viewer reads the network for the last 30 days of approve events from any SEP-41 token the address has interacted with, deduplicates them per (token, spender) pair, and shows the current state.

Each row shows:

• The token symbol (lazy-loaded from the token contract)
• The spender address, with a human label if it is a known contract (Soroswap router, Blend pool, Aquarius router, etc.), or a yellow Unknown, verify flag if not
• The current approved amount, formatted with the token's own decimals
• The expiry ledger (if the approval is bounded)

A Show expired toggle controls whether expired approvals are listed.

Why the scan window is 30 days

Soroban RPC providers retain events for a finite window. Testnet typically retains 7 days. Mainnet providers vary. The viewer asks for 30 days; if the RPC reports the start point as outside retention, the scan clamps to whatever is available and surfaces a note.

For a complete history beyond retention, you would need to ingest events into your own store. Within the retention window, the scan is comprehensive.

Revoking an approval

Click Revoke on any row. The app builds a SEP-41 approve(spender, 0, current_ledger) envelope, hands it to your connected wallet, submits the signed tx, and refreshes the row.

You need to be connected with the wallet that owns the address being audited to revoke. Revocation is a state-changing op; the connected key has to match the address whose allowances are being changed.

Why this matters

Stellar allowances are persistent. They survive the spender contract being upgraded. They survive the token issuer being rotated. They do not expire automatically unless you set a live_until_ledger. A token approval granted to a DEX router three months ago is still active today unless you revoked it.

If the router contract is compromised (a known attack vector across networks), every account with an active approval to that router is exposed up to the approved amount. Routinely auditing and pruning your approvals is the same hygiene that revoke.cash promotes for Ethereum. The viewer is the Stellar equivalent.

Spender registry

The known-spender labels are derived at module load from the mainnet allow-list (MAINNET_ALLOWLIST in src/lib/config/contracts.ts). The 25 mainnet entries (Soroswap router and factory, Blend pools and infrastructure, Aquarius AMM router, FxDAO vaults and synthetic SACs) drive the labels.

A spender that isn't in the mainnet registry is shown with the yellow Unknown, verify flag. This includes any testnet spender, since the registry only carries mainnet ids. The contract id is shown verbatim so you can look it up on the explorer before deciding whether to revoke.