Why this exists

The market for Web3 automation sits between two bad options. On one side, an agency that will design and build something bespoke, for a price and a timeline that assume a company has both. On the other, a repository cloned from a tutorial that works in the demo and becomes somebody's weekend problem the moment a moderator goes offline.

Neither of those is a product. A product tells you what it does, what it refuses to do, what it costs, and who fixes it when it breaks. Spellbook is an attempt to sell that third thing: a fixed-scope agent with a delivery date and a named engineer behind it.

How it works

The flow is deliberately short. You browse a catalogue that holds eleven published agents across four operational areas at the time of writing: community operations, customer and developer support, protocol and DeFi, growth and operations. You pick one and pay in USDT or USDC. An order workspace is created immediately, without an account, and it asks for the exact credentials the agent needs and nothing else. Bot tokens, read-only API keys, webhook URLs.

Then the clock starts. Forty-eight hours for a managed deployment, seventy-two for a complete source handover. What arrives includes staging verification, operational runbooks, the configuration files, and thirty days of engineer coverage after the handover.

The credential model is the part worth dwelling on. Most automation marketplaces ask for more access than they need, because asking for less is more work for the seller. Spellbook asks for scoped, revocable tokens and states plainly that private keys and seed phrases are never requested or stored. That constraint shapes the whole architecture. Anything an agent cannot do with a scoped token becomes something the buyer owns instead, which makes for a smaller product with a much smaller blast radius.

The decision that shaped the product

Two service models, one catalogue. A buyer can take the source code and run it themselves, or have it managed. Those read like pricing tiers. They are actually different products, and a lot of marketplaces blur them because blurring them closes more sales.

Blurring them produces the worst outcome in this category: a buyer who believes they purchased a maintained system and in fact purchased a zip file. So the two models are separated at the point of purchase, including the question of who pays the ongoing model and RPC bills.

That last point matters more here than in most industries. An agent that calls a language model and reads a chain has two metered bills attached to it. If the seller hides them, the buyer finds them later, and the discovery feels like a bait and switch even when it was only an omission.

What it does not do

The agents execute inside bounded parameters. They do not give financial advice, promise returns, or take any action a human has not already authorised. Buyers own their own model and RPC credentials, which means they also own the budget and can revoke access whenever they want.

This is a founder-built reference implementation, not anonymised client work. The catalogue is early, the examples are my own projects, and the early access framing is literal rather than a marketing device.

What to take from this

If you are buying automation, the questions that matter are not about features. What access does it need? Who owns the ongoing cost? What happens when it fails at three in the morning? Can any competent engineer take over from here? A vendor who cannot answer those four clearly is selling you a demo.