What The Examples Demonstrate

This chapter lists the main properties these examples are meant to exhibit.

At a high level, the two contracts play different roles:

• FungibleToken is the main example of a fungible covenant state machine with flexible ownership rules.
• FungibleTokenMinter is the main example of covenant composition, where one covenant governs the issuance policy of another.

These examples are easiest to understand as a small set of recurring stories:

• a token can be handed off, split, and merged
• non-minter branches must conserve supply
• minter branches can expand or shrink supply
• ownership can belong to a key, a script hash, or another covenant
• a separate covenant can bind itself to a token covenant and control future issuance

1. FungibleToken Behaves Like A Fungible Token State Machine

FungibleToken can:

• move a full balance from one owner to another
• split one balance into several balances
• merge several balances back into one

That means FungibleToken supports the basic transformations people expect from a fungible asset model.

2. Ordinary FungibleToken Branches Conserve Supply

Non-minter branches cannot:

• create value out of nothing
• destroy value arbitrarily
• turn themselves into minter branches

This is the ordinary-token part of the contract.

3. Minter Branches Can Expand Or Shrink Supply

When a branch is marked with isMinter = true, it can:

• mint more tokens
• burn tokens

This means mint authority is represented directly in covenant state.

4. Ownership Is Flexible

The examples demonstrate three ownership models inside one token contract:

• signature ownership
• script-hash ownership
• covenant-ID ownership

This is one of the strongest parts of the example. It shows that ownership can mean:

• “the holder of this key may spend”
• “a transaction containing this script-controlled input may spend”
• “this other covenant may spend”

That is much more expressive than a token model that only understands pubkeys.

5. Another Covenant Can Own FungibleToken

A FungibleToken branch can be owned by a covenant ID, and that ownership mode is what allows FungibleTokenMinter to control issuance.

This is the bridge from “programmable ownership” to “cross-contract policy”.

6. FungibleTokenMinter Controls Issuance, Not FungibleToken Alone

The two-contract example shows a clean split:

• FungibleToken defines token semantics
• FungibleTokenMinter defines issuance policy

This matters because it keeps the token contract reusable. Different issuance policies could be modeled by different controller covenants.

7. Initialization Can Bind Contracts Together

One of the most important properties proven by the examples is that a controller covenant can be created first, then initialize itself against an asset covenant created in the next transaction.

That is what init in FungibleTokenMinter does when it records:

• the covenant ID of the newly created FungibleToken output

The important shape is:

plain funding utxo
    |
    v
[minter genesis tx] -> C covenant id
    |
    v
[asset genesis/init tx] -> A covenant id + C binds to A

This is the mechanism that binds the minter to one specific FungibleToken instance while preserving a concrete genesis preimage for both covenant IDs.

8. Template Validation Makes Cross-Contract Checks Safer

FungibleTokenMinter does not merely inspect some FungibleToken-looking output. It validates:

• the expected template shape
• the expected template hash
• the expected state payload

This is critical because it means the minter is validating a real FungibleToken state transition, not trusting a lookalike output.

The minter reuses the template bytes from the co-spent FungibleToken input for both successor outputs. The existing input UTXO commits to its redeem script, and the minter checks the extracted template against its expected template hash.

9. The Issuance Budget Is Enforced Across Transactions

The FungibleTokenMinter flow walks through several mint transactions and shows that:

• each successful mint reduces remaining issuance allowance
• each successful mint keeps a zero-amount FungibleToken minter branch alive for the next mint
• each successful mint creates a separate ordinary FungibleToken recipient output for the newly minted amount
• those recipient outputs can later be spent like ordinary FungibleToken branches
• mint transactions continue to work while issuance allowance remains
• mint transactions fail when the requested increase would overspend the budget

This is the clearest statement of what FungibleTokenMinter is for.

10. The Whole Example Is About Covenant Composition

The biggest idea behind these files is not just “here is a token”.

It is:

• one covenant can represent an asset
• another covenant can own or govern that asset
• both can participate in the same transaction
• each contract can verify its own side of the policy

That is why these examples matter. They show how SilverScript can express systems of cooperating covenants, not just isolated spending scripts.