Join the Tockchain public testnet and gain early access to the infrastructure powering the next generation of stablecoins
Tockchain is a multi-asset blockchain that supports various transaction types including standard transfers, pools, orderbook trading, and cross-chain operations.
This documentation covers the essential transaction types and structures needed to leverage Tockchain transactions.
Tockchain uses a unique transaction identification system called "tockid" instead of traditional transaction hashes. A tockid consists of:
This document explains how to create and process various transaction types within Tockchain. Each transaction consists of two main parts:
Each section in this documentation follows this format: you will first find the transaction command, followed by the transaction result. This structure is consistent across all transaction types described.
To simplify the process of creating different transaction types, a maketx JSON command has been implemented for the websockets interface. This command allows you to specify the transaction type and its parameters. It then returns a hash that needs to be signed, along with the rawhex representation of the transaction.
The first 64 bytes of the rawhex will always be set to 0x00. This is where the transaction signature must be placed. When signing the transaction, the address that signs it must match the sender address specified in the transaction parameters.
Burn transactions are used to destroy (or “burn”) a specified amount of an asset, removing it from circulation.
Order Transactions provide a comprehensive orderbook trading solution on Tockchain, specifically for asset trading using a maker/taker system. It leverages hashed addresses to secure orders, incorporates basecoin rewards, and allows for OTC trades. Tracking is simplified with special address tracking for each order type.
Here’s a breakdown of the key features:
To create a new asset, a minimum deposit of 1000 VUSD is required. Additionally, before a pool can be used, the asset itself must be deposited into the pool’s address. This deposit can be made by anyone but is typically expected to be done by the asset’s creator. If the asset creator does not fund the other half of the pool, the pool will remain non-functional.
There are three primary pool functions: swap, deposit, and withdraw. Each of these functions has specific inputs and workflows, detailed below with examples.
For multisig transactions, you need to create a multisig address using the multisigaddr command. Similar to Bitcoin, you specify the number of signers, the minimum signatures required, and all the pubkeys. There is also an optional locktime, which prevents the funds from being spent until that locktime (if nonzero).
Unlike Bitcoin's multisig, the position of the pubkeys matters, as the signatures will be prefixed with the pubkey index, starting from 0.
Regarding size limits, there is approximately 2 KB of space available for both pubkeys and signatures, and any combination that fits within that space is acceptable. The multisigaddr command will return an error if the numsigners and minsigs values exceed the available space.
To estimate if a specific combination will fit, add the number of signers to twice the number of minimum signatures. If the total is less than 64, it will fit—actually, a few more could be squeezed in. For example, a 16 of 32 multisig setup would be close to the size limit, as would a 1 of 64 setup.
The hashlock transaction combines locking funds to an address until a specific time (locktime) with a hash of a secret. Currently, the supported hashing algorithms are K12 and SHA256, and more hashing types can be added if needed. This mechanism is useful for implementing features like atomic swaps.
For a detailed explanation of atomic swaps, refer to [Chainlink’s guide on Atomic Swaps](https://chain.link/education-hub/atomic-swaps#:~:text=Atomic swaps use a hash timelock contract (HTLC),of tokens has been deposited to the contract.).
The first step in creating a hashlock transaction is to define the locking parameters using the “hashlockaddr” command. This calculates the address where funds will be locked based on the specified parameters. After generating the address, funds can be sent to it and will remain locked until the conditions are met.
{
"command": "hashlockaddr",
"locktime": 0,
"lockedasset": "QUBIC",
"hashalgo": 1,
"locker": "COINLIBPCMZHFABKWAFYZLFVNFTBOIVGRSLQPLFTUBKIEMSDVKAXHLEGIMEI",
"unlocker": "TESTINKCOUDNIHYZBBOGWJSCHFPCZIUDAHQIXYARXEXFYSBYEXHVSALAFNBN",
"lockhash": "ac618b56e058f928d0c0f5657af041be90b42da3b137dc2ea62e7f8f257036dd"
}
Note that any asset can be locked (lockedasset).
Setting the locktime to 0 disables time-lock functionality and does not support atomic swap protocols. Ensure the lock parameters are configured correctly for your use case.
The unlocker field can be left blank to allow anyone to claim the funds if they know the secret. However, this allows the locker (who knows the secret) to reclaim the funds at any time, limiting its use to specific cases like contests or challenges.
Once funds are locked, they can only be unlocked and spent by someone who knows the secret that hashes to the specified lockhash. If locktime is set, the locker cannot reclaim funds until after the locktime. If the secret is known, the funds can be unlocked at any time before or after the locktime.
Assets are a fundamental part of Tockchain. While up to 32,000 assets can exist, there needs to be a mechanism for their creation. Creating an asset requires 1,000 VUSD, and some initial amount of the created asset must be allocated for the liquidity pool. The 1,000 VUSD is added to the liquidity pool and serves a vital role in connecting all tokens through feeless VUSD pools. This design allows users to swap between assets (e.g., from A to B and back to A) with a minimal loss of approximately 0.0001%.
Tockchain supports mintable and non-mintable assets:
After an asset is created and the liquidity pool is funded, the initial price of the asset is determined by the reserves in the pool. It is highly recommended that asset creators set an initial price close to the current market value. If there is no pre-existing market, the initial balance provided becomes the starting market price. All Tockchain assets use 8 decimal precision (e.g., 1,000 VUSD = 1,000 × 10⁸ satoshis).
These are special commands reserved for critical network-level operations such as adding, removing, or replacing nodes. The primary purpose is to maintain synchronization and avoid confusion among validators about network changes.
Process to Change Network Configuration:
Special Considerations: