Built-in Script Templates
Exfer hard-codes the five most common "non-trivial payment patterns" as first-class CLI templates — HTLC, multisig, vault, escrow, delegation. Each is one CLI command away. No contract deployment needed.
CLI usage for each template lives on its own page under /use/. This page explains why these five and why they live at the protocol layer instead of being left for every developer to write.
The five templates
| Template | What it does | Canonical use case |
|---|---|---|
| HTLC | Hashlock + timeout — recipient claims by revealing a preimage, otherwise the sender refunds after timeout | Atomic swaps, Lightning-style payment channels |
| Multisig | N-of-M signatures required to unlock (2-of-2, 1-of-2, 2-of-3) | Corporate joint accounts, household shared funds, backup strategies |
| Vault | Primary key has a 24-hour delay; recovery key acts immediately | Defense against key theft — there's a 24-hour window to recover with the recovery key |
| Escrow | Buyer + seller + arbiter three-party escrow | Trust-minimized commerce, with arbiter intervention on dispute |
| Delegation | Owner can spend anytime; delegate can spend within a time bound | Issuing a time-limited monthly budget to an AI assistant |
Why put these at the protocol layer
The mainstream design (Ethereum) is "protocol provides a minimal VM; business logic is whatever developers deploy." That approach is flexible, but the cost is:
- Every project reimplements the same primitives — multisig and escrow have been written hundreds of times
- Quality varies widely — Ethereum has seen at least ten significant multisig wallet hacks
- Poor interoperability — project A's "multisig" and project B's "multisig" aren't the same bytecode; wallets and explorers must support each separately
- Costs are unpredictable — every contract has its own gas profile
Exfer hard-codes these five into the protocol. The benefits:
| Benefit | How it shows up |
|---|---|
| Network-wide standard | Every wallet, explorer, and CLI agrees on what "multisig" means |
| Fixed, predictable cost | Three-party escrow unlocks always cost 10,040 steps — known up front |
| No per-contract auditing | Audit the template once at protocol level; everyone benefits |
| Wallet UIs can specialize | Unlike "arbitrary contract" UIs that fall back to raw bytecode |
Why these five, not fifty
These five cover the large majority of non-trivial M2M payment patterns: atomic exchange (HTLC), shared custody (multisig), theft defense (vault), third-party guarantee (escrow), permission delegation. More elaborate scenarios (derivatives, AMMs, lending protocols) need Turing-complete contracts — Exfer deliberately opts out. This follows the Exfer Script design choice: M2M payments and DeFi require different primitives.
Composition
The five templates compose:
- Atomic swaps need HTLC
- High-frequency payment channels are HTLC + vault composed
- Corporate fund management is multisig + delegation composed
- Trust-minimized commerce is escrow + multisig composed
These compositions work by nesting multiple templates inside the script of a single transaction; no protocol-layer additions are needed.
Costs / boundaries
- The template set is fixed. Adding a new template requires a protocol upgrade (hard fork). This trades flexibility for stability
- No applications that need complex state machines. A DAO voting contract or a Uniswap-style automated market maker cannot be expressed with Exfer templates. This is intentional
- The five templates are not "advanced financial primitives." They are payment-layer infrastructure; richer logic must be assembled at the application layer or done off-chain
Further reading
CLI usage:
Design context:
- Exfer Script — what language the templates are written in
- Protocol specification — exact semantics and cost table for each template