Account abstraction

A Botanary wallet isn't a private key you hold and sign with directly. It's a smart contract account

• specifically an ERC-7579 "Kernel" account - and that difference is what makes the rest of the platform possible: bounded authority, revocable grants, and an on-chain audit trail, instead of "the key can do anything, forever."

A contract, not a key pair

An EOA (externally owned account) is just a key pair - whoever holds the private key has total, unbounded control, with no way to scope or revoke that power short of moving funds elsewhere. A Botanary account is a deployed (or counterfactual, pre-deploy) smart contract instead. It's still self-custodial - Botanary never holds a signing key or signs on your behalf - but the account itself is programmable, which is what lets it enforce rules about what it will and won't do.

See The smart account for how that account is built: one OwnableValidator as its root validator (your owner key plus any device keys you add, under an M-of-N threshold), counterfactual until the first operation is signed, and freezable instantly as a kill switch.

Capability comes from modules, not the key

An ERC-7579 account's behavior isn't hardcoded - it comes from the modules installed on it. On a Botanary account, two kinds of module do the real work:

• Validators decide who's allowed to sign. OwnableValidator is the root validator for your own owner and device keys; SmartSessions is a separate validator for delegated session keys, each scoped to its own bounds.
• AgentGuard, an execution-phase hook, is what enforces your own account's rules - caps, allowlists, denylists, and the freeze state - on top of whatever a validator already approved.

Because authority is split across modules like this, capability itself is scoped: a chain only supports delegating, freezing, or setting rules if AgentGuard is actually deployed there. See Chains & networks for how that tiering works, and ERC-7579 modules for the module-level detail - what each one does, and how each signing lane assembles its signature.

What this buys you

Because authority lives in modules instead of a single all-powerful key, three things follow directly:

• Bounded - a delegation is a SmartSessions grant scoped to specific recipients, contracts, and a budget; it can never do more than what's encoded on-chain. See Delegations.
• Revocable - freezing is owner-signed, gasless, and instant, and a delegation can be cut off at any time without touching the account's own keys. See Rules & AgentGuard.
• Auditable - because every action still has to pass through validation and AgentGuard's execution-phase checks, there's always an on-chain (or, for a Smart Sessions decline, a clear build-time) record of what was actually attempted.

Read next