Configure a shared template

Sailor can register a shared template — a permission deployed once and configured per account — instead of authoring a permission from scratch.

Note

Templates are examples, not the protocol. The shipped Shared* templates and the standalone clone templates are reference implementations that demonstrate the IPermission pattern. They are illustrative, not a fixed part of the trusted core — anyone can deploy their own. You are responsible for the correctness of any permission you register (see permission correctness is the author’s responsibility). Treat them as starting points to read, adapt, and verify and test before any production use — not audited, drop-in contracts.

The seven shared templates

Sail Protocol’s seven shared permission templates are deployed today — multi-tenant singletons at the same CREATE2 address on all 12 supported chains, registered as knownTemplates in the SDK deployment registry. You don’t deploy them; you register one on your SMA and configure your own bounds:

Template	Bounds
SwapPermission	DEX swaps: router + token allowlists, per-tx cap, mandatory oracle slippage band
SwapPermissionNoOracle	Swaps for tokens without an oracle: allowlists + cap + live-pool sanity band
BorrowPermission	Borrowing: protocol + asset allowlist, cap, on-chain LTV check
DepositPermission	Deposits into ERC-4626 vaults / Aave: target + token bounds, cap
WithdrawPermission	Bounded position exits — ERC-4626 vault withdraw/redeem and Aave v2/v3 pool withdraw — with proceeds paid only to the account itself (target allowlist + per-tx cap)
TransferPermission	Moves ERC-20 tokens the SMA already holds out to a pinned recipient: token + recipient allowlists, per-transfer caps
ApproveAndCallBatchPermission	Atomic approve → call → reset-to-zero batches

See what’s live on your chain:

sailor mandate templates           # deployed template addresses + how to author your own
sailor capabilities                # chains, kernel model, mandate templates, strategy primitives (read-only)

Their addresses are in the Protocol → Deployment addresses, and each template has a dedicated skill that carries its exact parameter schema and the safe order of operations.

Register, then configure

sailor mandate register only registers a template — you must also configure the per-account bounds:

# 1. Register (owner signs an EIP-712 RegisterPermission in the browser):
sailor mandate register --address <templateAddress> --sma <yourSMA>

# 2. Configure your bounds (tokens, caps, venues) for that template:
sailor mandate configure --address <templateAddress> \
  --template SwapPermission --args-file swap-config.json

The sailor-template-* skills drive this conversationally with the correct schema per template. --simulate-only on configure gives a gas-free preflight.

Note

sailor mandate deploy-clone is currently unavailable — no clone templates are deployed. For a single-account, bespoke permission, author your own IPermission and use sailor mandate deploy --contract <Name> --attach (see Build & register a mandate).

Always simulate first

Prove the configured template accepts and rejects the right calls before authorizing:

sailor mandate simulate --address <templateAddress> --sma <yourSMA> --calls ./samples.json

See Simulate before going live. Then register/confirm exactly as in Build & register a mandate.

WithdrawPermission vs TransferPermission — which one?

These two are easy to confuse; they do opposite things:

• WithdrawPermission exits a position — it redeems from an ERC-4626 vault or an Aave v2/v3 pool, and the proceeds land in the SMA itself. It cannot send funds to any other address.
• TransferPermission moves tokens out — it sends ERC-20 tokens the SMA already holds to a pinned external recipient.

So: “exit this vault position” → WithdrawPermission. “get my money out of the SMA” / “send held tokens to my wallet” → TransferPermission (with a one-entry recipient allowlist). An exit and a payout are two permissions, not one.

WithdrawPermission carries a few non-obvious rules — the redeem cap counts shares, not assets; the token allowlist binds only the Aave path; and Compound / Aave v4 are deliberately unsupported. The sailor-template-withdraw skill has the exact schema.