Ootle / Concepts / Templates and Assets
Templates and Assets
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:
- Must an outsider audit the asset? If yes, start public.
- Must balances be hidden? Choose confidential.
- Must the owner be hidden as well? Choose stealth.
- 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.