Skip to content

Overview

Nexa smart contracts are on-chain spend conditions expressed in Nexa Script and committed to via the Pay-to-Template (P2T) address scheme. Coins sent to a smart-contract address can only be moved by a transaction whose unlocking script satisfies the rules baked into the address — the network enforces this at consensus time, with no trusted intermediary.

This section specifies individual contract types that have been deployed on the network and are recognised by Nexa-aware wallets. Each contract type is defined entirely by its on-chain layout: the template script, the shape of the constraint script, and the visible arguments. Two implementations that follow the same specification produce the same addresses from the same inputs and can read each other's UTXOs.

How smart contracts fit into Nexa

A funding UTXO at a smart-contract address looks the same as any other P2T output: a fixed version tag, a 20-byte template hash, a 20-byte constraint hash, and any visible arguments. The full template and constraint bytecode is revealed only at spend time, in the satisfier (unlocking script). The network rehashes the revealed bytes, checks they match the committed hashes, then executes the template to decide whether the spend is valid.

This shape gives every smart contract the same three layers to specify:

  • Template script. The shared spend-logic bytecode, common to every instance of the contract type on the network. Its hash160 identifies the contract type.
  • Constraint script. A per-instance script that places contract parameters (typically pubkeys) on the alt stack for the template to consume. Its hash160 distinguishes one instance from another.
  • Visible arguments. Cleartext per-instance parameters that the template reads at spend time and that wallets can read directly from the funding UTXO during chain rescan.

Independent of the on-chain layout, each contract type usually pins a key-derivation convention (a BIP-44 path) so that any wallet restoring from seed can rediscover its instances by scanning the chain for the template hash and re-deriving the matching child keys.

Contracts specified here

  • Time lock vault — a single-party, non-interactive smart contract that locks coins to an address until a block-height or Unix-time threshold and then releases them only to a specific private key.

Compatibility

Each contract spec includes a compatibility invariants section listing the exact bytes, encodings, and derivation conventions that must never change. Anything in that list is part of the on-chain address of every existing instance: changing it would silently strand funds in vaults no wallet can reconstruct. New contract types or new versions of existing ones live under a fresh template hash, not by mutating an existing one.