Templates and Assets

Covered in this page

This page is the catalogue of what you can build, and how private it is:

• The four resource types and the privacy posture of each.
• The built-in templates shipped with the engine.
• The recurring application patterns — token, NFT, stablecoin, liquidity pool, HTLC, escrow, games — each with a one-line privacy note.
• Where to go for the mechanics.

Note

This page is about shape, not implementation detail. For authoring a template see Templates Overview; for the resource API see Resources; for the cryptography behind the private types see Privacy.

---

The four resource types

A resource’s type is the single most important decision for its privacy properties. The engine defines exactly four (crates/template_lib_types/src/resource_type.rs):

pub enum ResourceType {
    Fungible,      // public, interchangeable
    NonFungible,   // public, individually identified
    Confidential,  // amounts hidden, balances in vaults
    Stealth,       // amounts and owners hidden, funds are UTXOs
}

Type	Balances visible?	Owners visible?	Funds live in	Builder
Public Fungible	Yes	Yes	Vaults	ResourceBuilder::public_fungible()
Public Non-Fungible	Yes (per NFT)	Yes	Vaults	ResourceBuilder::non_fungible()
Confidential	No	Yes (the vault’s component)	Vaults	ResourceBuilder::confidential()
Stealth	No	No	UTXOs	ResourceBuilder::stealth()

The four types are easier to hold in the head as a two-by-two. There are two independent questions — can you see the amount? and can you see the owner? — and each type answers them:

Public Fungible

The baseline: a currency with no privacy. Balances and transfers are plaintext on-chain. It is the right choice for assets that should be transparent — governance tokens, publicly auditable treasuries — and it is cheap, because there is nothing to prove.

Public Non-Fungible

Like a fungible resource, but each unit has an identity (NonFungibleId) and can carry mutable data. Ownership and contents are public. This is the type for collectibles, receipts, and access badges — tokens whose whole point is that they can be pointed at.

Confidential

The first privacy layer: a fungible resource whose amounts are hidden. Balances sit in vaults as Pedersen commitments, so an observer can see that a vault holds funds but not how much. Ownership is still tied to the vault’s component — so confidential hides the amount, not the account. It is the natural fit for a private balance that still interacts with public components.

Stealth

The strongest layer: a resource whose outputs are UTXOs rather than vault balances. Each output carries a one-time stealth address, so neither the amount nor the owner is linkable on-chain. The native token, TARI, is stealth. Use stealth when ownership itself is sensitive — payments, bearer assets, anything where linking two transactions to the same party would be a problem.

Tip

The difference in one sentence: Confidential hides the number; Stealth hides the number and the name. A confidential vault is a known account with an unknown balance; a stealth UTXO is an unknown account with an unknown balance.

---

Built-in templates

Four templates ship compiled into the engine, always available (crates/template_builtin/src/templates.rs):

Template	Purpose
Account	The standard account component: holds vaults, gates withdrawals by owner rule.
NftFaucet	Mints a non-fungible resource and hands out NFTs.
XtrFaucet	The testnet TARI faucet, used in examples to fund an account.
TwoResourceLiquidityPool	An AMM-style pool over two resources — the reference DeFi primitive.

Note

The built-in faucet keeps its historical name XtrFaucet. XTR is a deprecated alias for the native token; the current identifiers are TARI_TOKEN (the resource address constant) and TARI (the unit). XTR still resolves, but new code and manifests should use TARI_TOKEN / TARI and refer to the token as TARI (tTARI on testnet, $TARI on mainnet).

The Account template is worth singling out: it is the component most user funds actually sit in, and it is the seam between public and private funds. Depositing into an account vault is a public move; converting a bucket to stealth UTXOs is the private one. Most privacy questions reduce to which side of the account boundary a transfer happens on.

---

Application patterns

Each pattern below is a composition of the four resource types and condition trees. The “privacy posture” line is the honest summary of what leaks.

Pattern	Built from	Privacy posture
Fungible token	Public Fungible or Confidential, with a mint authority	Public type is fully transparent; confidential hides balances but not the accounts.
NFT / collection	Public Non-Fungible	Public by design — ownership is the point.
Stablecoin	Stealth, with a revealed mint/burn boundary	Holder transfers private; supply events revealed so supply is auditable. See Stablecoins.
Liquidity pool	Two resources + a vault pair (see TwoResourceLiquidityPool)	Pool reserves are public to be swappable; LP tokens inherit the underlying resources’ privacy.
HTLC / atomic swap	A stealth output with a two-leaf condition tree (hashlock + timelock)	Amount hidden; the revealed leaf discloses the preimage branch taken.
Escrow	A stealth output with a release leaf and a refund leaf; optionally covenants	Funds hidden throughout; only the exercised branch is revealed.
Guessing game	A component + a resource vault; hashed commitment to the secret	Game state is public; see Privacy for why commitments are cheap to add.
Bearer asset	A stealth resource with key-path-only outputs	Fully private: possession is the credential, no registry names an owner.

Three of those patterns — HTLC, escrow, and atomic swaps — rest on the same mechanism: a spend condition that is a tree of branches. Understanding the tree explains all three at once.

Choosing a type

A short decision path:

1. Must an outsider audit the asset? If yes, start public.
2. Must balances be hidden? Choose confidential.
3. Must the owner be hidden as well? Choose stealth.
4. Must an auditor see hidden amounts? Add a view key to a confidential or stealth resource.

Then design the boundaries: every application has a few places where value must be revealed — the fee, a mint, an interaction with a public pool. The privacy of the whole system is the privacy of its leakiest boundary, so identify those first.

---

Summary

• Four resource types: Public Fungible, Public Non-Fungible, Confidential, Stealth.
• Confidential hides amounts; Stealth hides amounts and owners.
• Four built-in templates ship with the engine: Account, NftFaucet, XtrFaucet, TwoResourceLiquidityPool.
• The Account template is the seam between public and private funds.
• The common application patterns — token, NFT, stablecoin, pool, HTLC, escrow, games — are all compositions of these types and condition trees.
• Privacy is set by the leakiest boundary, not by the asset type alone.

Next: the economics of the native token — Tokenomics.