Valis Tockchain Execution Model

1. Introduction

Tockchain processes transactions every second ("tocks") across two complementary layers:

Transactions (TX) — A fixed set of L1 protocol operations optimized for core financial primitives: transfers, trading, liquidity, bridging, and multi-signature custody.
Dataflows (DF) — A programmable contract engine that lets developers deploy arbitrary financial logic (vaults, lending, automation, DAOs) compiled to BPF bytecode and executed at near-native speed.

Both are evaluated during the same tock. Transactions provide the high-performance financial infrastructure; Dataflows build on top of it.

2. Transactions

Every transaction is hardcoded into the L1 validator. Each has fixed semantics, minimal overhead, and is processed by the ledger's eval_tx dispatch.

Transaction	Purpose	maketx type
Standard
Send	Transfer any asset between two addresses	`standard`
Burn	Permanently destroy an amount of any asset	`burn`
Crosschain
Bridge Transfer	Move assets between Tockchain and another chain (e.g. Qubic). Includes chain ID, external symbol, and issuer metadata	`crosschain`
Orderbook (UFC)
Maker Order	Place a limit bid/ask on the protocol-level orderbook. Min lot: 100 VUSD. Supports cancel and basecoin reward claims	`makerorder`
Taker Order	Fill an existing maker order. Supports OTC (maker specifies a specific taker)	`takerorder`
Order Address	Derive the deterministic address representing a specific order entry	`orderaddr`
Open Orders	Query all open bids/asks for an address and asset	`openorders`
Pool (UFC)
Pool Swap	AMM swap between two assets via the 50/50 liquidity pool, with optional slippage protection (`mindestamount`)	`poolswap`
Pool Deposit	Add liquidity — single-asset or dual-asset deposit	`pooldeposit` / `pooldeposit2`
Pool Withdraw	Remove liquidity — single-asset, other asset, or balanced ($both$). Distributes TOCK rewards for qualifying pools	`poolwithdraw`
Multi-Sig
Multisig Address	Create an M-of-N multisig address (up to ~64 signers). Position-dependent pubkeys, optional locktime	`multisigaddr`
Multisig Spend	Spend from a multisig address after gathering the required M signatures	`multisig`
Data
Data TX	Broadcast protocol-critical data: ETH headers, mint proofs, price feeds, DF author announcements. Processed by bridge and DF subsystems	datatx variants
Lock
Lock TX	Time-lock assets at an address (used for node operator staking, Pylon cold vaults)	`locktx`
Asset
Create Asset	Register a new asset on-chain. Competes for a slot in the shared priority cache (32k assets + 16k DFs). Excess fee funds the asset's CRV	`createasset`
Other
Airdrop / Auction	Protocol-level asset distribution and auction mechanics	specialized

Key properties:

Identified by tockid (utime + rollup index + tx index), not traditional tx hashes.
All tx types use the maketx JSON command interface; the first 64 bytes of rawhex are reserved for the signature.
The Unified Fair Clearing engine (UFC) processes pool and orderbook tx at end-of-tock, blending AMM and orderbook pricing with risk controls.

3. Dataflows (DF)

A Dataflow is a user-deployed program compiled to BPF bytecode that runs deterministically inside the tockchain firmware. DFs are Tockchain's equivalent of smart contracts, but designed with a fundamentally different philosophy: firmware over software — covering 90% of use cases 100× faster and simpler.

Core properties:

State model: All persistent state is stored as balances (real assets like VUSD/BTC + synthetic assets for application logic). Each DF gets 16 int64 registers per address.
Execution model: The "matrix" — a 2D grid of [addresses × assets] that the DF reads and writes. Conservation is enforced: column sums remain constant.
Composability: Multiple DFs can be called atomically in a single TX_DF_BATCH. Pipes enable structured data flow between calls. If any call fails, everything rolls back.
No state bloat: No per-DF key-value stores. All state lives in the universal userassets[] table. Offchain servers handle large state via Merkle proofs.
Performance: 100k+ DF executions per second. 1-second finality (VIP), 5-second latency (normal).