Recurring revenue, fully on-chain

Why Web3 teams use AuthOnce

How it works on-chain

AuthOnce has two smart contracts on Base Network:

When a subscriber authorises a subscription:

1. If the subscriber is an EOA (regular wallet), they sign a single EIP-2612 permit off-chain — no gas, no further signing required for future cycles. If the subscriber is a smart-contract wallet (Safe, EIP-4337 account), they instead provide a fresh EIP-712 signature every billing cycle via ERC-1271 — this is not yet supported by AuthOnce's production keeper, see the AI Agents guide for current status.
2. The subscriber's vault is funded with exactly one billing cycle's worth of USDC. No more.
3. On each billing date, the keeper bot calls executePull() on the SubscriptionVault, which atomically transfers USDC from the subscriber vault to the merchant treasury (99.5%) and the AuthOnce protocol treasury (0.5%).

Treasury wallet setup

Your merchant address is where USDC lands on every successful payment. You can use:

• An EOA (regular wallet) — MetaMask, Coinbase Wallet, etc.
• A Safe multisig — recommended for DAOs (see below)
• Any EVM-compatible smart contract wallet that can receive ERC-20 tokens

Safe multisig (recommended for DAOs)

For DAOs and multi-stakeholder teams, we strongly recommend registering a Safe multisig as your merchant address. This means:

• No single key controls your subscription revenue
• Treasury transfers require M-of-N signatures from your team
• Compatible with existing DAO tooling (Snapshot, Tally, Aragon)
• AuthOnce's own protocol treasury uses a 2/2 Safe on Base Mainnet

Setup steps

Supported tokens

DAO memberships

DAOs collecting recurring membership fees from contributors or community members are an ideal AuthOnce use case. A typical setup:

• Create a "Member" product at your monthly or annual membership rate
• Share the pay link in your Discord, Notion, or governance forum
• Members connect their wallet and authorise the subscription — EOA members sign once, smart-contract wallet members see current status in the AI Agents guide
• USDC arrives in the DAO treasury wallet on each billing date
• Failed payments enter a grace period and retry automatically — no manual intervention

You receive a webhook event on every payment, cancellation, and expiry — wire these to your member management system to automatically grant or revoke access.

Tool & API subscriptions

If you sell tooling, data access, or API access to other Web3 teams or DAOs, AuthOnce is a natural fit. Your customers are already on-chain — they have wallets, they hold USDC. There is no fiat onramp friction.

Compared to collecting payment through invoice or token transfer:

• Automatic — no manual renewals, no "please top up your subscription" messages
• Verifiable — you can prove payment on Basescan without sharing internal data
• Predictable — grace period dunning recovers failed payments before cancellation

Contributor retainers

AuthOnce can also be used in reverse — a DAO paying contributors a recurring amount is a standard outgoing payment pattern, not an incoming subscription. For contributor payments going out of your treasury, you should use a tool like Superfluid, Sablier, or Parcel.

AuthOnce handles incoming recurring revenue — subscribers (or contributing DAOs) paying your DAO. If a contributor wants to pay for access to your DAO's resources or data, AuthOnce is the right tool.

Verifying payments on-chain

Every payment executed by AuthOnce has a transaction hash. You can verify any payment on Basescan:

1. Go to basescan.org
2. Search for your treasury wallet address
3. Under ERC-20 Token Txns, filter by USDC — every AuthOnce payment appears here
4. Each transaction shows: from (subscriber vault), to (your treasury), amount, timestamp, block number

This means your DAO's revenue is independently auditable by any token holder or governance participant without needing access to your internal dashboard.

No chargebacks by design

On-chain USDC transfers are cryptographically final. Once executePull() succeeds on-chain, the payment cannot be reversed, disputed, or charged back. There is no payment processor standing between the subscriber and your treasury that could freeze, reverse, or confiscate funds.

This is structurally different from custodial billing processors where chargebacks, disputes, and account freezes are a constant operational risk — especially for Web3 businesses which some processors consider high-risk.

Non-custodial architecture

AuthOnce never holds merchant or subscriber funds. The protocol operates as follows:

• Subscriber USDC stays in the subscriber's own vault address at all times until a payment executes
• On execution, USDC moves directly to the merchant treasury — AuthOnce is never an intermediary holder
• The AuthOnce keeper bot is a transaction executor only — it cannot spend subscriber funds on anything other than the agreed subscription amount

MiCA positioning

AuthOnce is designed as a software protocol, not a payment service provider. Because the protocol never holds funds and operates entirely through on-chain smart contract execution, AuthOnce does not classify as a Crypto-Asset Service Provider (CASP) under MiCA. This is a deliberate architectural choice.

The protocol contracts are licensed under BUSL-1.1 and publicly auditable. For merchants operating in the EU, AuthOnce's non-custodial design means you are interacting directly with the Base Network blockchain — not with a regulated intermediary holding your assets.