The Tokenized protocol features a complete messaging suite for all types of messaging including general purpose private and public messaging, as well as commercial, financial and legal messaging in accordance with a variety of established Electronic Data Interchange (EDI) standards. They are also used to allow smart contracts to share information and orchestrate multiple signature transactions, such as atomic swaps.
Public Message
Generic public message or public announcement. Sent to an address(es). Can be used for an official issuer announcement.
| Field |
Type |
Description |
|---|
| Version |
uint(1)
|
Payload Version
Example: 0
|
| Timestamp |
Timestamp
|
Timestamp in nanoseconds for when the message sender creates the transaction.
|
| Subject |
varchar(16)
|
The subject / topic of the message.
|
| Regarding |
Output
|
The output of the message that this message is regarding (responding to).
|
| PublicMessage |
Document
|
Tokenized Ltd. announces product launch.
|
| Attachments |
Document[32]
|
Documents attached to the message.
|
Private Message
Generic private message. Sent to another address(es). Encryption is to be used.
| Field |
Type |
Description |
|---|
| Version |
uint(1)
|
Payload Version
Example: 0
|
| Timestamp |
Timestamp
|
Timestamp in nanoseconds for when the message sender creates the transaction.
|
| Subject |
varchar(16)
|
The subject / topic of the message.
|
| Regarding |
Output
|
The output of the message that this message is regarding (responding to).
|
| PrivateMessage |
Document
|
Tokenized Ltd announces product launch.
|
| Attachments |
Document[32]
|
Documents attached to the message.
|
Reverted Tx
A message that contains a bitcoin transaction that was accepted by the network or an agent and then invalidated by a reorg, or zero conf double spend. This serves as on chain evidence of the sending party's signatures and approval for the given transaction.
| Field |
Type |
Description |
|---|
| Version |
uint(1)
|
Payload Version
Example: 0
|
| Timestamp |
Timestamp
|
Timestamp in nanoseconds for when the message sender creates the transaction.
|
| Transaction |
varbin(32)
|
Serialized bitcoin transaction that was reverted/invalidated after being accepted.
|
Offer
A message that contains all of the details required for an agreement to be formed. Sent to an address(es). The Offer should have all, or nearly all, of the details required for the receiving party to accept the offer. The Offer shall be in the form of a partially formed Bitcoin transaction with all of the relevent details (offer, consideration, offeror's payment/receipt details, etc.). The Offer message is different to a Signature Request message in that it is missing the offeree's payment/receipt details (eg. UTXOs). If the Offer message is well received by the offeree, then the offeree can add their relevent details (eg. inputs/outputs) and sign the transaction. If an additional signature is required from the offeror at this point, then the partially-signed transaction can be sent to the offeror by way of a Signature Request message.
| Field |
Type |
Description |
|---|
| Version |
uint(1)
|
Payload Version
Example: 0
|
| Timestamp |
Timestamp
|
Timestamp in nanoseconds for when the message sender created the offer.
|
| Payload |
varbin(32)
|
Serialized Tokenized OP_RETURN message. The message needs data added by another party upon acceptance of offer.
|
Signature Request
Partially-signed transactions (Tokenized actions, Bitcoin, Multisig, Threshold Signatures, etc.) can be passed around on-chain to the parties (including Smart Contracts) that still have to sign the transaction.
| Field |
Type |
Description |
|---|
| Version |
uint(1)
|
Payload Version
Example: 0
|
| Timestamp |
Timestamp
|
Timestamp in nanoseconds for when the message sender creates the transaction.
|
| Payload |
varbin(32)
|
Full serialized bitcoin tx with multiple inputs from different wallets/users.
|
Settlement Request
A message that contains a multi-contract settlement that needs settlement data added by another contract. Sent to another contract to request data be added.
| Field |
Type |
Description |
|---|
| Version |
uint(1)
|
Payload Version
Example: 0
|
| Timestamp |
Timestamp
|
Timestamp in nanoseconds for when the message sender creates the transaction.
|
| TransferTxId |
TxId
|
Tx Id of the transfer request transaction that triggered this message.
|
| ContractFees |
TargetAddress[8]
|
Contract fees (in bitcoin) and addresses(PKHs) where fees should be paid. Added by each contract as settlement data is added.
|
| Settlement |
varbin(32)
|
Serialized settlement OP_RETURN that needs data added by another contract.
|
Output Metadata
Metadata associated with the output. Aka Transaction details. It is used to describe the purpose of the transaction and add other relevant information. Often encrypted (DH, RSA) to make it private for one or more parties. DH for b2b where multiple parties can see the description. RSA or the like for descriptions only visible to one of the transacting parties. Optional
| Field |
Type |
Description |
|---|
| Version |
uint(1)
|
Payload Version
Example: 0
|
| OutputDescription |
varchar(32)
|
A Description that accompanies the output. A transaction description.
Can be NULL Example: eg. Invoice 3024, Pay Mike back for camping.
|
| Tags |
Tag[8]
|
Predefined values for describing the output.
|
| CustomTags |
OutputTag[8]
|
Free form text fields for describing the output. Groceries, Moomba Gas Compressor Project, Cash Register 3, Fitness, Entertainment, Special, VIP Section, North Carolina Store, Waitress: Cindy Smith, etc.
|