Current limitations
Stated plainly. If a thing is not on this page, it is either true or listed elsewhere as proven — not quietly assumed.
| Limitation | Detail | Status |
|---|---|---|
| Base Sepolia only | Chain 84532. Every address and transaction in these docs is testnet. There is no mainnet deployment, no production claim, and the test keys are disposable. | By decision |
| Hosted consent blocked upstream | A newly created Base Account cannot sign a spend permission on Base Sepolia: Coinbase's hosted screen refuses with “This chain is not supported.” See below. | base/account-sdk#363 |
| No fee mechanism in the router | The router forwards the full value to one recipient. Retainer cannot take a percentage without becoming custodial. Revenue must be a flat merchant fee, outside the flow. | Structural |
| No auth on the dashboard | /dashboard is public and has no authentication of any kind. Five review actions can now write — applying a transfer to an obligation, marking one not-a-payment, and linking a sender to a customer — so anyone who can reach the URL can alter matching records. No money can move: the actions only attribute transfers that already happened, and cannot charge, revoke or transfer. Acceptable only because this is testnet data whose addresses are already public. Not acceptable for a real merchant, and auth must land before any deployment that is not this one. | Not built |
| No invoices, plans, customers, tax, proration or refunds | Retainer is a charge engine. None of these objects exist. Refunds in particular cannot be executed by a non-custodial layer, only instructed. | Not built |
| No re-authorisation or usage forecasting | A cap that is too small is reported, not renegotiated. These are the next product decisions and depend on merchant conversations that have not happened. | Not built |
| Single executor | One executor key per deployment. Multiple workers are serialised by an advisory lock; multiple executors are not supported. | By design, for now |
| Reorgs are detectable, not handled | Incoming transfers are indexed at three confirmations and store their block_hash, so a reorg beneath an indexed transfer can be detected. Nothing automatically unwinds a match whose transfer no longer exists — a human would have to reverse it. | Stated, not built |
| Watch matching never guesses | Only an exact remaining amount from a sender already linked to a customer is matched automatically. Everything else — ambiguous ties, amount mismatches, unknown senders — waits in a review queue. This is deliberate, but it means a merchant with many unlinked senders does manual work until the links are learned. | By design |
| Usage metering is storage only | A usage_records table and a sum at charge time. No rating, tiers or aggregation windows. | By decision |
The hosted-consent block, precisely
Coinbase's keys.coinbase.com signing screen rejects Base Sepolia for newly created Base Accounts with the message“This chain is not supported. Base Sepolia is not supported. Please try a different chain.”The message is misleading: Base Sepolia is in the popup's supported-chains map and supplies the display name in that very error. The operative check isisTestnet inside the wallet-upgrade path — testnet delegation provisioning for EIP-7702 accounts, wearing chain-support copy.README.md:101
| Account type | On-chain code | Base Sepolia consent |
|---|---|---|
| ERC-4337 (factory-deployed contract) | 0x363d3d37… | works — every charge in these docs was made this way |
| EIP-7702 (delegated EOA) | 0xef0100… | refused |
- Open since 2026-07-10. No maintainer response as of 2026-09-09. A documentation-only PR (#390) has been open and unmerged since 2026-08-21.
- It also blocks Coinbase's own documented
pay({ testnet: true })flow, so it is not specific to Retainer. - Unknown: whether Base Accounts created before the 7702 provisioning change still pass. The issue thread reports that they do; Retainer has not been able to test it because no such account was available.
- Unknown: whether or when Coinbase will change this. No statement has been made.
Retainer deliberately did not route around it. Going to mainnet to dodge a testnet bug would have meant a permanent deployment and a real-money key set months ahead of need.
Distribution inside the Base App
Base's documentation for spend permissions carries the note that “Spend Permissions for Base App Apps are coming soon and will be supported in a future update.” That is Coinbase's statement, not Retainer's. Today the primitive is reachable only from external web apps using the Base Account SDK. When, or whether, it reaches Base App mini-apps is unknown.
Reorgs
Watch mode indexes incoming transfers at three confirmations, the same depth the charge reconciler uses, and stores each transfer's block_hash alongside its block number. That makes a reorg beneath an already-indexed transferdetectable: a later scan finding a different hash at the same height means the transfer, and any payment matched from it, may no longer exist on chain. detectReorgs
Detection is not handling. Nothing automatically unwinds a match whose underlying transfer has vanished, and nothing re-opens an expected payment that was settled by one. On Base at three confirmations this is unlikely rather than impossible, and the honest position is to say so rather than to imply a guarantee the code does not provide.
What has and has not been verified
- Verified: everything on the evidence section of the landing page, the six failure modes, both crash-recovery branches, the custody invariant in tests and on live balances.
- Not verified: behaviour under sustained load, behaviour with many concurrent permissions, Base fee spikes beyond the 30-day window sampled, or any mainnet condition.
- Not verified: the real-account browser path end to end — blocked as above. The scripted ERC-4337 path proves the state machine; the real one would prove the integration.