Subscriptions & payments
Payment authorization
Paid access uses standard ERC-20 approvals followed by a separate subscription transaction. Allowances are finite but deliberately exceed the immediate payment; the exact formulas are disclosed below.
Payment flow
- Approval method
- ERC-20 approve(address,uint256)
- Payment methods
- subscribe(...) or createAccountAndSubscribe(...)
- Native ETH value
- 0; ETH is needed only for Base network fees
- Billing period
- 31 days per contract month
The core calculates the current price again during execution and reverts if it exceeds the maximum passed by the user's transaction. The payment transfer uses SafeERC20.safeTransferFrom and rejects fee-on-transfer behavior by checking the amount actually received.
ERC-20 approvals
Approval is required because the core contract pulls the selected stablecoin only when the subscription transaction executes. The token contract, not SEICHO, stores the allowance. The approval is finite; the frontend never requests uint256.max or an unlimited amount.
Allowance formulas
buffer(amount) = max(0.5% of amount, 1 whole payment token)
Without auto-renew:
approval = immediate payment + buffer(immediate payment)
With auto-renew:
base = immediate payment + (12 x current one-month price)
approval = base + buffer(base)| Example | Immediate payment | Requested approval | Immediate transfer |
|---|---|---|---|
| 250 USDC, no auto-renew0.5% buffer | 250 USDC | 251.25 USDC | 250 USDC |
| 250 USDC, auto-renew enabled12 renewal periods plus buffer | 250 USDC | 3,266.25 USDC | 250 USDC |
The minimum one-token buffer matters for small payments. The values above use the production Sovereign monthly price observed on September 9, 2026 at 20:25:23 UTC. Pricing is owner-configurable and should be read live before evaluating a transaction.
Auto-renewal
Auto-renewal is disabled by default. The user opts in by selecting the checkbox before the subscription transaction. If selected, the core configures the dedicated auto-renew module after the initial payment succeeds.
- Default
- Off
- Allowance coverage
- Immediate payment plus 12 current monthly prices, then the standard buffer
- Renewal unit
- One 31-day period per execution
- Execution window
- Only within 3 days before paid subscription expiry
- Who may trigger
- Any address may call renewFromAllowance(accountId)
- Who pays
- The current owner wallet of that account
- Price cap
- The one-month price stored when auto-renew is configured
A third party can trigger an eligible renewal, but cannot select the payer, recipient, tier, token, duration or amount. Execution fails if the core is paused, the account is suspended, auto-renew is disabled, the token or tier is inactive, the subscription is expired or the current one-month price exceeds the stored maximum.
Disable and revoke
The subscription form leaves auto-renew disabled by default. Selecting auto-renew when subscribing opts the account into the on-chain renewal configuration.
Wallet simulation
ERC-20 and ERC-721 both use the selector 0x095ea7b3 forapprove(address,uint256). A wallet decoder that does not correctly resolve the target contract can therefore confuse an ERC-20 amount with an ERC-721 token ID. Users should verify the target token contract, spender and raw calldata instead of relying on a decoded label alone.
The subsequent subscription transaction should simulate the exact stablecoin debit. If the payer is also the configured treasury, outgoing and incoming effects may net to zero in a wallet simulation.