Tockchain Transaction Types

Join the Tockchain public testnet and gain early access to the infrastructure powering the next generation of stablecoins

0. Overview

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:

• Unix timestamp (utime)
• Rollup index (rind)
• Transaction index (txind)

This document explains how to create and process various transaction types within Tockchain. Each transaction consists of two main parts:

1. Transaction Command: The first part describes the transaction you want to execute. This includes the specific command (e.g., maketx, multisigaddr, etc.) and its associated parameters such as sender, recipient, amount, asset type, and additional data. The command is submitted to the system for processing.
2. Transaction Result: After processing the command, the system returns the result of the transaction. This will include details such as the transaction’s status (e.g., "result": "success"), the transaction hash, and other relevant information. This output helps you verify if the transaction was successful and view any additional information, such as timestamps and potential chain lag.

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.

1. Standard Transactions

1.0. Introduction to Standard Transactions

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.

1.1. Send Transaction

1.2. Burn Transactions

Burn transactions are used to destroy (or “burn”) a specified amount of an asset, removing it from circulation.

2. Crosschain Transactions

2.1. Crosschain Transaction

3. Order Transactions

3.0. Introduction to Order Transactions

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:

• Orderbook Functionality: The orderbook allows for asset trading in a maker/taker system.
• Maker: Places an order to buy or sell an asset at a specific price. The maker creates bids and asks with a minimum value of $100 in VUSD (Tockchain’s stablecoin). This value is denominated in VUSD to 8 digits of precision (0.00000001 VUSD).
• Taker: Accepts an existing order made by the maker.
• Over-the-Counter (OTC) orders: These orders allow the maker to specify a particular taker to fill the order, ensuring that only the specified taker can fulfill the order.
• Liquidity Pool & Arbitrage: The asset’s liquidity pool operates between the high bid and low ask prices on the orderbook. Auto-arbitrage bots will ensure that the orderbook and liquidity pools maintain synchronized pricing.
• Order Address Hashing: Orders are locked and represented by hashed addresses. The specifics of an order (e.g., maker, assets, price, etc.) determine the hash for the order address.
• Basecoin Rewards: Only the maker can claim any basecoin rewards earned by an order address. The maker can also cancel or modify their orders.
• Address History: To simplify orderbook tracking, each asset has special tracking addresses associated with the maker, taker, and OTC orders. This way, users can view all open orders and the status of their trades from the respective addresses.

3.1. Order Address Transaction

3.2. Maker Order Transaction

3.3. Maker Order Cancellation Transaction

3.4. Maker Order Claim Reward Transaction

3.5. Maker Order Asset Recovery Transaction

3.6. Taker Order Transaction

3.7. Open Orders Transaction

4. Pool Transactions

4.0. Introduction to Pool Transactions

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.

4.1. Poolswap Transaction

4.2. Pooldeposit Transaction

4.3. Poolwithdraw Transaction

5. Multi-Signature Transactions

5.0. Introduction to Multi-Signature Transactions

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.

5.1. Multi-Signature Address Creation Transaction

5.2. Multi-Signature Spend Transaction

6. Coldspend Transactions

6.1. Coldspend Transaction

7. Hashlock Transactions

7.0. Introduction to Hashlock Transactions

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.

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.

7.1. Hashlock Address Transaction

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.

7.2. Hashlock Transactions

7.3. Hashlock Refund Transactions

7.4. Hashlock Refund Asset Recovery Transactions

8. Assets Transactions

8.0. Introduction to Assets Transactions

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:

1. Mintable Assets:
• Can be minted in the future by the creator’s address.
• Alternatively, minting can be controlled via multisig, requiring a specified number of signatures (up to 26 out of 52).
• Signers are defined during asset creation, providing significant flexibility in configuring multisig assets.
• To mint additional tokens: First, create the mint transaction and then use the “addsig” command to add signatures until the required number is reached to broadcast successfully.
2. Non-Mintable Assets:
• Have a fixed supply that is generated upon creation.
• No additional tokens can be created once the asset is initialized.

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).

8.1. Assets Creation Transactions

8.2. Asset Minting Transactions

9. Airdrop Transactions

9.0. Introduction to Airdrop Transactions

The airdrop transaction type distributes assets to multiple recipients based on specific criteria, such as holding a particular asset or owning pool shares.

Tockchain’s airdrop transaction supports three modes, each tailored to different distribution strategies:

1. Standard Airdrop:
• Distributes an equal amount of the asset to multiple recipients holding a particular asset.
• Ideal for promotional campaigns or community rewards where every eligible holder receives the same amount, regardless of their destasset holdings.
2. Dividend Airdrop:
• Distributes assets to multiple recipients based on specific criteria, such as amount of holding a particular asset.
3. Pool Airdrop:
• Distributes assets to multiple recipients holding a particular pool share.
• This mode functions similarly to the dividend airdrop but is restricted to addresses holding pool share tokens, which represent participation in a liquidity pool.

9.1. Standard Airdrop Transactions

9.2. Dividend Airdrop Transactions

9.3. Pool Airdrop Transactions

10. Network Transactions

10.0. Introduction to System Transactions

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:

1. Issue a systemtx Command: Use the appropriate system transaction to add, remove, or replace a node.
2. Start the New Generator Node (if applicable): If a node is added or replaced, initialize the new generator node.
3. Update Existing Generator Nodes: One by one, update the other generator nodes to recognize the new configuration. This effectively hardforks the new node list into the network. Without this step, validators could mistake the new node as an imposter.
4. Sync the New Validator Node After the Change: Once the next hour begins, start the validator node. Use -fast sync mode to download the previous hour’s STATE files (an external mechanism must be implemented to support large STATE file transfers).

Special Considerations:

• Multiple of 3 Nodes: If the network has exactly a multiple of 3 nodes, removing a node is disallowed due to quorum requirements.
• Erroneous Systemtx: If a systemtx command is issued by mistake, it can be canceled using the clearupdate command.
• Caution Required: Network topology changes must be carefully planned to avoid disruptions.

10.1. Node Addition Transactions

10.2. Node Removal Transactions

10.3. Node Replacement Transactions

10.4. Update Cancellation Transactions

11. Bridge Transactions

11.0. Introduction to Bridge Transactions

These operations are automated and do not require custom transactions.

The creation of external assets and tokens is restricted to the basecoin address, ensuring centralized control over asset issuance.

11.1. External Chain Creation Transactions

11.2. External Asset Creation Transactions

Support

For troubleshooting and support, please reach out to Qsilver in the #op-tx-testing on the Valis Discord.

Thank you for contributing to Tockchain’s success!

On this Page

• Tockchain Transaction Types
• 0. Overview
• 1. Standard Transactions
• 1.0. Introduction to Standard Transactions
• 1.1. Send Transaction
• 1.2. Burn Transactions
• 2. Crosschain Transactions
• 2.1. Crosschain Transaction
• 3. Order Transactions
• 3.0. Introduction to Order Transactions
• 3.1. Order Address Transaction
• 3.2. Maker Order Transaction
• 3.3. Maker Order Cancellation Transaction
• 3.4. Maker Order Claim Reward Transaction
• 3.5. Maker Order Asset Recovery Transaction
• 3.6. Taker Order Transaction
• 3.7. Open Orders Transaction
• 4. Pool Transactions
• 4.0. Introduction to Pool Transactions
• 4.1. Poolswap Transaction
• 4.2. Pooldeposit Transaction
• 4.3. Poolwithdraw Transaction
• 5. Multi-Signature Transactions
• 5.0. Introduction to Multi-Signature Transactions
• 5.1. Multi-Signature Address Creation Transaction
• 5.2. Multi-Signature Spend Transaction
• 6. Coldspend Transactions
• 6.1. Coldspend Transaction
• 7. Hashlock Transactions
• 7.0. Introduction to Hashlock Transactions
• 7.1. Hashlock Address Transaction
• 7.2. Hashlock Transactions
• 7.3. Hashlock Refund Transactions
• 7.4. Hashlock Refund Asset Recovery Transactions
• 8. Assets Transactions
• 8.0. Introduction to Assets Transactions
• 8.1. Assets Creation Transactions
• 8.2. Asset Minting Transactions
• 9. Airdrop Transactions
• 9.0. Introduction to Airdrop Transactions
• 9.1. Standard Airdrop Transactions
• 9.2. Dividend Airdrop Transactions
• 9.3. Pool Airdrop Transactions
• 10. Network Transactions
• 10.0. Introduction to System Transactions
• 10.1. Node Addition Transactions
• 10.2. Node Removal Transactions
• 10.3. Node Replacement Transactions
• 10.4. Update Cancellation Transactions
• 11. Bridge Transactions
• 11.0. Introduction to Bridge Transactions
• 11.1. External Chain Creation Transactions
• 11.2. External Asset Creation Transactions
• Support