Controls and limitations

Security model

User authentication relies on control of a wallet address and server-issued single-use challenges. Paid access relies on explicit Base transactions and finite ERC-20 allowances. Application access additionally depends on the SEICHO backend and its session controls.

Production chain

Base Mainnet · Chain ID 8453

Contract architecture

Non-proxy deployed contracts

Core pause control

Current owner can pause and unpause

Reentrancy controls

Payment and renewal paths use OpenZeppelin ReentrancyGuard

Token transfer wrapper

Incoming payments use OpenZeppelin SafeERC20

Current owner

0x9a7d4e92a6cC0915090eCd5209EB51CEE39d746a

User fund protections

• The login signature cannot transfer funds or set allowance.
• Payment approval is finite and names the production core as spender.
• The core recalculates price on-chain and reverts above the supplied maximum.
• Incoming payments reject fee-on-transfer behavior.
• Auto-renewal is off by default and each execution is limited to one monthly period near expiry.
• Users can prevent future pulls by revoking the token allowance to the core.

Operator can

• Pause or unpause the core contract.
• Change tier prices, discounts and active status.
• Add or remove accepted ERC-20 payment tokens.
• Change the treasury destination and claim funds retained by the core.
• Suspend or unsuspend an account.
• Create and cancel free-access grants.
• Create Bulk plan types, change their active status and suspend Bulk subscriptions.
• Initiate or cancel an account-recovery proposal.
• Change commission parameters while the core is paused.
• Start and cancel a two-step transfer of contract ownership.

These controls are concentrated in the current owner EOA. No multi-signature contract was detected at the owner address on September 9, 2026 at 20:25:23 UTC.

Operator cannot

• Sign a message or transaction on behalf of a user wallet.
• Read or recover a user's wallet private key through the documented system.
• Use an owner-only function to execute an arbitrary transferFrom from any wallet.
• Pull an ERC-20 token for which the user has not granted sufficient allowance.
• Use the auto-renew path unless the account opted in and all timing, tier, token and price checks pass.
• Replace deployed bytecode through a proxy upgrade.
• Replace the production commission, Bulk, recovery or auto-renew module after its one-time core slot has been set.
• Complete recovery immediately: execution requires the seven-day period, quorum and more yes than no votes.

These statements describe restrictions in the reviewed repository and current deployment. They do not remove risks associated with owner-controlled configuration, accepted tokens, backend operation or defects in contract code.

Known limitations

• No independent third-party smart-contract audit was found in the current repository.
• The contract owner and treasury are currently the same externally owned account.
• The frontend requests a materially larger allowance when optional auto-renewal is selected.
• The core relies on the owner to select stable-value payment tokens and uses no oracle to validate their value or peg.
• Account suspension and several economic parameters remain operator-controlled.

Audit / review status

This documentation was prepared from a repository review and live read-only checks of the production deployment. It must not be described as a security audit.

Security & support

SEICHO users can contact the operator directly through the in-app Community support channels, including Support and Bug Reports.

Never share a seed phrase, private key or authentication secret when requesting support.