Question 1

What is TBC?

Accepted Answer

TBC is the native currency of TuringBitChain. The project describes TuringBitChain as a Layer 1 public chain based on Bitcoin's UTXO model and using proof of work, with smart-contract capabilities designed on top of that model. UTXO means “unspent transaction output”: a transaction consumes existing outputs and creates new ones. TBC aims to use this output-based transaction model for transfers and to allow contract state to be carried by related outputs; this is a key difference in data organization from chains that use global account state.

Question 2

What is TBC used for?

Accepted Answer

TBC is used to pay and receive value within the network, and it forms part of miner income when transactions are packaged and confirmed. The whitepaper's fee model links fees to transaction data size: under its design, larger transactions should bear higher fees; final payment costs are also affected by the specific transaction format and network rules. At the application layer, TBC is designed to interact with UTXO-based contracts. The whitepaper's statements on performance, low fees, and application scale are project design goals or expectations and cannot be directly treated as network performance already achieved at any point in time.

Question 3

How is TBC produced?

Accepted Answer

According to the whitepaper, TBC is produced through SHA-256 proof of work. Miners participate in block production through computational work; blocks accepted by the network can receive block rewards and obtain fees from transactions confirmed in those blocks. The whitepaper also states that its mining model requires participants to follow KYC protocols. The causal relationship in this mechanism is that miners invest computing resources to compete for block production, and the chain compensates successful block producers with newly issued tokens and transaction fees, thereby providing economic incentives for transaction confirmation and network security. Whether participation is possible and actual returns are still affected by the client, network rules, difficulty, fees, and project requirements at the time.

Question 4

What are TBC's issuance rules?

Accepted Answer

The whitepaper lists a maximum mining amount of 2.1 billion TBC, an initial block reward of 625 TBC per block, a target block interval of approximately 10 minutes, and a halving every 210,000 blocks, equivalent to about four years. Declining block rewards mean that the number of new tokens issued during the same subsequent period will be lower than before the halving; this is an issuance rule, not the current circulating supply. The whitepaper also puts approximately 195.8 million?

Question 5

What does TuringContract mean for ordinary users?

Accepted Answer

TuringContract is a contract framework proposed by the whitepaper and built on the UTXO model. Its basic idea is to place contract-related state in specific UTXOs: an execution consumes constrained old outputs and creates new outputs carrying the subsequent state. When validating, nodes check whether that state transition satisfies contract constraints rather than writing all contracts into one shared global state. The whitepaper considers different UTXO contracts capable of being validated separately; this is the framework's design logic, while practical application availability and performance should still be based on network operating conditions.

Question 6

Why wait for confirmation after transferring TBC?

Accepted Answer

Zero confirmation is the processing state in which a transaction has entered a node's mempool but has not yet been written into a block; it is not block confirmation. The whitepaper states that transactions enter the mempool after meeting the minimum fee threshold, and nodes process transactions using the same UTXO on a first-in, first-out (FIFO) basis. If a later transaction attempts to spend the same UTXO already used by an earlier mempool transaction, nodes consider the later one invalid. However, the whitepaper also explains that, in worst-case scenarios such as malicious double spending, the earlier transaction may still become invalid due to block results; therefore, waiting for block confirmations remains a more secure approach for high-value transfers.

Question 7

Why doesn't the maximum supply equal the amount of TBC immediately available for use?

Accepted Answer

Maximum mining amount and mineable quantity are not the same concept in the whitepaper. Its parameter table lists 2.1 billion TBC as the maximum mining amount, of which approximately 1.958 billion is listed as locked mining amount and approximately 142 million as mineable amount; it specifically states that TBC in blocks with a height no greater than 824188 should be permanently locked. Therefore, 2.1 billion cannot be directly understood as all entering usable supply through subsequent mining. The whitepaper also states that the remaining approximately 142 million is produced using a Bitcoin-compatible mining algorithm, and that 35% of each mined block reward goes to addresses such as the growth fund; this further distinguishes “mined rewards” from the portion actually obtained by miners.

Question 8

How does TuringContract identify and continue state?

Accepted Answer

TuringBitChain's contract identifier is not centered on a single global contract address. The whitepaper describes each UTXO contract instance as associated with a unique input and code hash; its example logic for a contract ID hashes the transaction identifier and output index that created the contract, then combines them with the code hash. The practical significance of this design is that, when a contract execution creates a new UTXO state, users or applications need to track subsequent state according to the relevant contract identifier, rather than simply treating different state transitions as the same unchanged global account balance.

TuringBitChain (TBC) Price