Data Insertion Mechanism

Understanding how Pay2Ingot embeds data into the Tondi network

Data Insertion Mechanism

Overview

Pay2Ingot is the common on-chain envelope for Ingot objects. The current design is no longer best understood as one fixed content container. Instead, it supports multiple state styles so different workloads can use different tradeoffs between permanence, throughput, and settlement guarantees.

Pay2Ingot Output Type

Pay2Ingot is a transaction output type identified by ScriptPublicKey.version = 2. It carries schema routing and spending rules on-chain, while the actual object semantics are interpreted by higher-level clients and indexers.

Current State Modes

State Best for High-level behavior
Commit deploys, minting, artifacts, state roots anchors a durable payload fingerprint on L1
Flow transfers, MIMO activity, application traffic keeps the on-chain footprint lean and relies on witness-carried action data
Vault settlement-oriented balances carries explicit asset balances and policy-controlled issuance intent

Shared Fields

Across these state modes, the output still keeps the same public role:

  • schema_id routes the object family or standard
  • lock defines who may spend or authorize the object
  • state decides whether the object is anchored, witness-driven, or balance-oriented
  • mast_root remains available for privacy-preserving branching when needed

Commit, Witness-Carried Data, and Settlement

The older "commit-reveal" explanation is still useful for anchored objects, but it is no longer the whole story.

  • Commit-oriented objects keep a durable payload commitment on-chain and are preferred when identity and permanence matter.
  • Flow-oriented objects move more of the action data into witness space so frequent transfers and application operations stay lightweight.
  • Vault-oriented objects focus on balances, policy control, and settlement semantics rather than large revealed payloads.

This is the main reason recent Ingot materials describe the protocol in terms of Commit / Flow / Vault, not just a single payload container.

Hash Commitment

All payload data is committed using BLAKE3 hashing:

HASH_PAYLOAD = blake3("Ingot/payload" || canonical_bytes)

Where canonical_bytes is the DAG-CBOR normalized encoding of the anchored payload when the object uses a commitment-style state.

Validation

L1 consensus layer validates:

  • blake3(payload) == hash_payload (commit-reveal integrity)
  • Payload hash must match between output and witness
  • Hash mismatch results in transaction rejection

Payload Structure

Payloads are encoded using DAG-CBOR (Deterministic CBOR) with TLV (Type-Length-Value) format:

TLV Encoding Rules

  • Type ascending: TLV types sorted by numerical value ascending
  • Same Type multiple values: Sorted by value lexicographically
  • Integer encoding: Uniformly use little-endian (LE)
  • Prohibit zero prefix: Integers cannot have leading zeros
  • String encoding: UTF-8 encoding

Payload Limits

  • L2 Recommended: ≤ 84.5 KiB payload
  • Physical Constraint: Tondi mass ≤ 100,000 (automatically limits actual size)
  • L1 Validation: Only verifies hash, doesn't enforce size limits

Resource Efficiency

Avoiding UTXO Bloat

Unlike protocols that contribute to UTXO bloat, Ingot:

  • Uses a single Pay2Ingot output per transaction (L1 consensus rule)
  • Commits to data via hash rather than storing all data in UTXO set
  • Supports commit-reveal pattern to minimize initial transaction size
  • Leverages Tondi's DAG architecture for efficient block propagation

Fee Calculation

Fees are calculated based on transaction size:

  • Default: fee = base_fee + rate * total_bytes(tx)
  • Includes header, witness, and Pay2Ingot payload bytes
  • Byte-based billing ensures fair resource allocation
  • High fees cannot bypass hard limits

Integration with Tondi

Mixed Transactions

Ingot outputs can be mixed with traditional Value UTXOs in the same transaction:

  • Pay fees using Value UTXOs
  • Create Ingot outputs for asset data
  • Support change outputs
  • Full compatibility with existing Tondi transaction model

Network Activation

Ingot activation and feature rollout are governed at the network level. The exact schedule can evolve as the protocol moves between test deployments, staged activation, and later production rollouts.

Security Considerations

Fail-Closed Principle

Ingot follows a fail-closed security model:

  • Unknown fields/enums → transaction rejected
  • Unknown version → transaction rejected
  • Reserved bits set → transaction rejected
  • Ensures security by rejecting anything unfamiliar

Hash Integrity

All payload data is protected by cryptographic hashing:

  • Payload hash committed in output
  • Witness must reveal matching payload
  • Hash verification at L1 consensus level
  • Prevents tampering and ensures data integrity

Previous: Introduction | Next: oUTXO Model