How to Deploy and Call a Contract

---

This section covers the complete workflow from compiling a contract to deploying and calling it on the Bitcoin network. UTXO_Compiler handles the compilation phase; on-chain interaction requires a transaction building tool.

---

Compilation Output

After running the compiler, the output is a JSON-formatted bytecode description:

./utxo_compiler my_contract.ct

Example output (simplified):

{
  "metadata": {
    ...
  },
  "abi": [
    {
      "type": "function",
      "name": "verify",
      "index": 0,
      "params": [
        {
          "name": "sig",
          "type": "hex"
        },
        {
          "name": "pubKey",
          "type": "hex"
        }
      ]
    }
  ],
  "lock": {
    "asm": "OP_DUP OP_HASH160 <self.pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG",
    "hex": "76a9<self.pubKeyHash>88ac"
  },
  "unlock": {
    "verify": "<sig><pubKey>"
  },
  "functions": [
    {
      "name": "verify",
      "type": "public",
      "params": [
        {
          "name": "sig",
          "type": "hex"
        },
        {
          "name": "pubKey",
          "type": "hex"
        }
      ]
    }
  ]
}

Key fields:

• lock.hex: Hex-encoded bytecode sequence, used directly as the locking script for a transaction output
• lock.asm: Human-readable opcode disassembly for inspection
• functions: Function list with their parameters, describing what data must be provided when unlocking

---

Deploying a Contract

"Deploying a contract" in the UTXO model means: constructing a transaction whose output's locking script contains the compiled contract bytecode.

Deployment Transaction Structure

Deployment transaction
├── Input: some existing UTXO (provides funds)
└── Output:
    ├── value:          number of satoshis to lock in the contract
    └── locking script: bytecode compiled by utxo_compiler

Locking Script and SuffixData

...

Deployment Example (pseudocode)

...

---

Calling a Contract

"Calling a contract" means constructing a transaction that spends the contract UTXO. The caller provides the required data in the input's unlocking script, in order according to the contract's public function parameter list.

Unlocking Script Structure

The unlocking script is constructed by the caller; its content is the public function's input parameters, pushed onto the stack in order:

# Example: P2PKH contract's unlock(sig: hex, pubKey: hex)
Unlocking script = <sig> <pubKey>

During BVM execution, the contents of the unlocking script are first pushed onto the main stack (sig at the bottom, pubKey at the top), then the locking script (contract bytecode) is executed, consuming these parameters from the stack.

Public Function Execution Order

For contracts containing multiple public functions, the public functions execute in sequence in the order they are declared in the source code. The order is determined by the definition position; there is no need to specify "which function to select" at call time.

The caller only needs to provide the unlocking parameters in the agreed order; the execution flow will consume and verify these parameters step by step according to the order of public functions.

Call Example (pseudocode)

...

---

Notes

...

---

Next Steps

• How to Test a Contract — Local validation before deployment

---

🇨🇳 中文版