- Message action
- Rejection action
The Tokenized Protocol includes a rich and expressive set of messaging actions which allow issuers, operators and users the flexibility to correspond in a way that gives wallets, account management and audit software the ability to record a full set of transactional actions. Messaging actions are split into two types, the Message action and Rejection action.
Message actions are for general purpose messaging between users. The protocol has the means to support pre-defined message types allowing messaging to be used for many things including:
- Transaction templates
- Purchase Orders and Invoices
- Shipping notices
- Transaction descriptions
- Quartlery/Yearly Reports (10K, 10Q, etc)
- Collateral Calls
- Encrypted messages
- Public (cleartext) messages
- And many other types
Message actions do not, generally, involve a smart contract and only serve to record communication data to the blockchain. The message action format is standardised to ensure that any wallets which follow the Tokenized Protocol will be able to identify, parse and categorize messages. A message may be sent to many addresses at once by appending multiple outputs to the transaction which contains the Message action.
There are 6 Message types currently defined in the Tokenized Protocol:
Public message: Message #0002 - A generic public message or public announcement. Sent to an address(es). Can be used for an official issuer announcement.
Private message: Message #0003 - A generic private message. Sent to another address(es). Encryption is to be used.
Reverted Tx: Message#0004 - 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.
Offer message: Message #1001 - 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.
Signature Request message: Message #1002 - 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.
Settlement Request message: Message #1003 - 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.
As the Tokenized Protocol matures, it is expected that many more message types will be introduced which enable new and exciting functionality to be handled simply and easily.
The rejection action is the only message type sent by the smart contract. The Rejection action is used when a user has requested an action that is unable to be completed by the smart contract. All rejection messages include a rejection type, which links to a message telling the user why their request was rejected.
The following rejection messages have been defined:
Basic Rejection Codes
|Code 0||Success - No failure. This code should not be used in a reject message.|
|Code 1||Message Malformed - The OP_RETURN message is malformed. It doesn't pass data validation or something about it isn't according to protocol.|
|Code 2||Transaction Malformed - The Bitcoin tx is malformed. Incorrect inputs/outputs or something similar.|
Contract Rejection Codes
|Code 10||Contract Already Exists - The contract already exists and can't be recreated.|
|Code 11||Contract Is Not Dynamic - 'Sent when a CO is received, but the contract type is not "D" (Dynamic)'|
|Code 12||Contract Asset Quantity Reduction - Sent when a CA tries to reduce the number of assets below the number of assets the contract has.|
|Code 13||Contract Fixed Quantity - Sent when the issuer attempted to increase the quantity of assets in a contract beyond the fixed quantity permitted.|
|Code 14||Contract Auth Flags Prohibit - The contract auth flags don't permit the action requested.|
|Code 15||Contract Expired - The contract is expired so can no longer accept requests.|
|Code 16||Contract Frozen - The contract is frozen and the request is not permitted while frozen.|
|Code 17||Contract Revision Incorrect - The revision in a contract amendment is incorrect.|
Asset Rejection Codes
|Code 20||Asset Code Already Exists - The asset code specified already exists and can't be reused.|
|Code 21||Asset Not Found - The asset code is not found.|
|Code 22||Asset Auth Flags Prohibit - The asset auth flags don't permit the action requested.|
|Code 23||Asset Frozen - The asset is frozen and the request is not permitted while frozen.|
|Code 24||Asset Revision Incorrect - The revision in an asset amendment is incorrect.|
Transfer Rejection Codes
|Code 30||Transfer To Self Prohibited - Transfers with the sender and receiver addresses the same are not permitted.|
|Code 31||Transfer Expired - The transfer has expired.|
|Code 32||Holdings Frozen - Holdings are frozen, so the request can't be completed.|
Governance Rejection Codes
|Code 40||Holder Proposal Prohibited - Holders are not permitted to make proposals.|
|Code 41||Proposal Conflicts - The proposal conflicts with an unapplied proposal.|
|Code 42||Vote Not Found - The vote ID referenced is not found.|
|Code 43||Vote Closed - The vote has closed and ballots are no longer permitted.|
|Code 44||Ballot Already Counted - The ballot has already been counted for this address.|
Enforcement Rejection Codes
Funding Rejection Codes
|Code 60||Insufficient Transaction Fee Funding - Insufficient bitcoin quantities for response transaction fees.|
|Code 61||Insufficient Value - Insufficient bitcoin quantity in inputs to fund request.|
|Code 62||InsuInsufficient Quantity - Insufficient token holdings to for request.|
Address Rejection Codes
|Code 70||Requestor Is Not Issuer - The requestor is not the issuer and is required to be for this request.|
|Code 71||Requestor Is Not Operator - The requestor is not the operator and is required to be for this request.|
|Code 72||Unauthorized Address - The address specified is not permitted for this request.|
Signature Rejection Codes
|Code 80||Invalid Signature - The signature provided is not valid. This is for signatures included within OP_RETURN data. Not bitcoin transaction signature scripts.|