cadenceprotocol (cadenceprotocol)

ERC-8183 handles one-shot agentic jobs cleanly. But recurring agentic services - weekly reports, continuous monitoring, periodic data feeds - don't fit the fund → submit → complete model. You'd need the client to manually recreate a new job every cycle. ERC-8191 is the missing piece: a keeper-gated subscription standard that handles recurring billing automatically, composable with ERC-8183 via hooks. One hook on fund → subscription opens → keeper collects every interval. Discussing this today on Ethereum Magicians 👇 ethereum-magicians.org/t/erc-8191-onchain-recurring-payments/27946

• 0 replies
• 0 recasts
• 0 reactions

/dev /ethereum /ercs /eips-ercs We're looking for co-authors on ERC-8191 — Onchain Recurring Payments. If you've worked on DeFi protocols, subscription products, or ERC standards before and think recurring payments onchain deserve a real standard — let's talk. DM open 👇 ethereum-magicians.org/t/erc-8191-onchain-recurring-payments/27946

• 0 replies
• 0 recasts
• 0 reactions

There's no ERC standard for recurring payments. We're writing one. ERC-8191 — Onchain Recurring Payments A minimal pull-based subscription interface for EVM: keeper-gated collection, no oracles, composable with any ERC-20. Reference implementation live on Sepolia. PR open: github.com/ethereum/ERCs/pull/1595 Would love feedback from protocol devs — especially on the keeper incentive model and interval enforcement design. ethereum-magicians.org/t/erc-8191-onchain-recurring-payments/27946

• 0 replies
• 0 recasts
• 0 reactions

First cast. Building Cadence — an on-chain subscription standard for EVM chains. The problem: subscriptions are the dominant payment model in Web2, but there's no standard way to do them on-chain. Every protocol that needs recurring payments reinvents the wheel. ERC-8191 is my attempt to fix that. Reference implementation live. Keeper automation running on Sepolia. If you've ever thought about this problem — or built around it — I'd love to hear how you approached it. cadenceprotocol.build

• 0 replies
• 0 recasts
• 1 reaction

Something I keep coming back to: subscriptions didn't emerge because businesses wanted to extract more money. They emerged because paying once for something you use continuously is genuinely awkward — for both sides. Web3 solved custody. It solved transfers. It's still largely stuck on one-time payments. Part of that is technical — there's no standard. But part of it is philosophical: "pull payments" feel wrong in a world built around user sovereignty. If a protocol can pull funds from your wallet, is that really self-custody? I spent a long time on this tension before writing the first line of ERC-8191. The answer I landed on: pull is fine if the user defines the terms on-chain and can cancel unilaterally at any moment. The contract enforces what the user signed, nothing more. Still early. But I think this is the right foundation.

• 0 replies
• 0 recasts
• 0 reactions

There's no ERC standard for recurring payments. We're writing one. ERC-8191 — Onchain Recurring Payments A minimal pull-based subscription interface for EVM: keeper-gated collection, no oracles, composable with any ERC-20. Reference implementation live on Sepolia. PR open: github.com/ethereum/ERCs/pull/1595 Would love feedback from protocol devs — especially on the keeper incentive model and interval enforcement design. ethereum-magicians.org/t/erc-8191-onchain-recurring-payments/27946

• 0 replies
• 0 recasts
• 0 reactions

/dev /ethereum /ercs /eips-ercs We're looking for co-authors on ERC-8191 — Onchain Recurring Payments. If you've worked on DeFi protocols, subscription products, or ERC standards before and think recurring payments onchain deserve a real standard — let's talk. DM open 👇 ethereum-magicians.org/t/erc-8191-onchain-recurring-payments/27946

• 0 replies
• 0 recasts
• 0 reactions