Spending Paths
An application writes its rules as spending paths on a Taproot output. Each path is one way to spend the output, and it can require signatures, a time, or checks on the spending transaction. For a simple wallet, the SDK sets up standard paths for the owner. When an application needs rules of its own, it writes them in Arkade Script as a contract, such as a payout after a date or a settlement against an oracle price. All the vaults are contracts of this kind.Enforcement
The operator cosigns a spend only if it satisfies the path it uses. For a path written in Arkade Script, it first runs the script against the spending transaction. That path therefore relies on the operator running the code its enclave attests to. If a path requires no signature from whoever spends it, it checks only the transaction, so anyone who builds a transaction that passes can submit it. That is why a contract names the outputs that such a path pays.The Exit Path
Because the operator could stop cosigning, every output also keeps an exit path that its owner can use alone: once a delay passes, the owner’s signature spends it. An onchain output is spent through that path directly, whereas a virtual output has to be unrolled onto Bitcoin first (Unilateral Exit). Exit shows the path that each vault shape uses.Offchain Execution
The SDK’s wallet uses offchain execution: it holds funds as virtual outputs, which settle on Bitcoin in batches. A transaction executes as soon as the operator cosigns it and stays preconfirmed until a batch settles it. Virtual outputs also expire with their batch, which the SDK handles by renewing them automatically. The rules keep working offchain, so a contract’s own deadlines, written withcheckTime, stay in its spending paths. When the SDK renews a virtual output into a new batch, those deadlines don’t change.