9 August 2026
A Zucoin transfer code carries instructions or transaction data between people, wallets, websites, and services. A transaction contains the signed change between the sender and receiver.
The transfer code helps a wallet start or continue a transfer. It is not, by itself, proof that a transaction is complete.
Transfer Code v1 is an encoded JSON object. Its type tells the wallet what action to prepare, and its incoming_data contains the data for that action.
A sender-create transfer code asks a wallet to prepare a transfer. This unencoded example requests 0.005 Zucoin for a receiver:
{
"version": "1",
"type": "sender_create_transaction",
"incoming_data": {
"receiver_key_public__base64urlsafe": "RECEIVER_PUBLIC_KEY...",
"inner_state_amount": "0.005",
"message": "Invoice #1042",
"user_share_message": "Check the invoice before you continue"
}
}
The Transfer Code v1 action types used here are:
sender_create_transaction: prepare a transfer from the wallet that opens the code.sender_create_transaction_explicit: prepare a transfer from the exact sender wallet address supplied in the code.receiver_confirm_partial_transaction: give the receiver a sender-signed partial transaction to inspect and confirm.The sender must review and confirm a transfer prepared by a sender-create code. A transfer code cannot silently complete the transfer.
The wallet copies the optional message value into inner.message when it prepares Transaction v2. The optional user_share_message is for instructions shown around the transfer flow. It stays in the transfer code and is not copied into the signed transaction.
A current Zucoin transaction uses Transaction v2. The inner object contains the transaction data that the wallets validate and sign. The sender adds step_1_signature. The receiver checks that partial transaction and adds step_2_signature.
This simplified example shows the current Transaction v2 structure. The public keys and signatures are placeholders. Optional fields are included to show where they belong.
{
"inner": {
"type": "unique_combinable",
"version": "2",
"unix_time_secs": "1786255200.123456",
"signer_steps": 2,
"step_1_signer": "sender",
"step_2_signer": "receiver",
"step_1_key_public__base64urlsafe": "SENDER_PUBLIC_KEY...",
"step_2_key_public__base64urlsafe": "RECEIVER_PUBLIC_KEY...",
"step_1_state": {
"amount": "94.995"
},
"step_2_state": {
"amount": "5.005"
},
"previous_step_1_state_signature": "PREVIOUS_SENDER_TRANSACTION_SIGNATURE...",
"previous_step_2_state_signature": "PREVIOUS_RECEIVER_TRANSACTION_SIGNATURE...",
"expiry__unix_time_secs": "1786258800",
"message": "Invoice #1042"
},
"step_1_signature": "SENDER_SIGNATURE...",
"step_2_signature": "RECEIVER_SIGNATURE..."
}
The state amounts and time values are text strings. This preserves the required decimal precision. The two previous-state signature fields connect each wallet state to its latest applicable settled transaction.
expiry__unix_time_secs and message are optional. Omit an optional field when it is not needed.
A partial Transaction v2 contains the transaction inner data and the sender's step_1_signature. A complete Transaction v2 also contains the receiver's step_2_signature.
The receiver confirms the exact sender-signed data. If important transaction data changes, the signatures must be created again for that data.
Create a pre-formed sender transfer code with JavaScript DOM
Create a pre-formed sender transfer code with PHP
How do Zucoin transactions work?
Inspect a Zucoin transfer code
Disclaimer: Of course, this is not advice, financial or otherwise. It’s also important to consider the risks and challenges associated with any potential benefits.
Get periodic insights, news, offers + more, trusted by 1,000+ readers.
(By subscribing you agree to receive news + marketing emails, but we won't spam or sell your data!)