🔢Transaction Data Structure

1. Transaction

Index	Field	Type	Introduction
1	Version	byte	Transaction version 1. May be empty: If Version < 0x09, the first byte of transaction is the second field 'TxType' and the ‘Version’ is empty 2. If transaction type >= 0x09, must have 'Version' and the value must >= 0x09
.2	TxType	byte	Transaction type
3	PayloadVersion	byte	Transaction payload version: Multiple payload versions can exist for the same transaction
4	Payload	Payload	Transaction payload: Different transactions have their own payloads to record unique information, generally used for transaction verification. There are many types of payloads for transactions, which are described separately in the following sections
5	Attributes	[]*Attribute	Transaction attribute: Used to fill in nonce and user data, now only 'Nonce' and 'Memo' are commonly used
6	Inputs	[]*Input	Transaction inputs: UTXOs used by current transaction
7	Outputs	[]*Output	Transaction outputs: New UTXOs of current transaction
8	LockTime	uint32	The lock time of this transaction
9	Programs	[]*Program	Transaction signature; includes code and parameter

2 Attribute

Index	Field	Type	Introduction
1	Usage	byte	The usage type of this attribute
2	Data	[]byte	The data of this attribute

3 Input

Index	Field	Type	Introduction
1	TxID	uint256	Reference transaction hash of this input
2	Index	uint16	Reference outpoint index of this input
3	Sequence	uint32	Sequence number

4 Output

Index	Field	Type	Introduction
1	AssetID	uint256	Asset type: Currently there is only one asset type in the mainchain: elaAsset
2	Value	int64	Output amount
3	OutputLock	uint32	Output lock of this output
4	ProgramHash	uint168	Output address
5	Type	byte	Output type, some output types may have output payload
6	Payload	OuputPayload	Output payload: Different outputs have their own payload to record unique information; currently, there are six types of outputPayloads : OTNone, OTVote, OTMapping, OTCrossChain, OTWithdrawFromSideChain and OTReturnSideChainDepositCoin OutputPayload is described in detail in the following sections

5 Program

Index	Field	Type	Introduction
1	Code	[]byte	Redemption script: The contract program code which will be run on VM or a specific environment
2	Parameter	[]Byte	Unlock script: The program code's parameter is the signature of this transaction

6 Payload

6.1 Coinbase Transaction

Coinbase transaction is the first transaction in the block created by miners, which is used to distribute miners’ rewards and DPoS profits. Coinbase transactions can only be spent after at least 100 blocks are confirmed. Miners can add additional information in the payload in Coinbase.

Coinbase structure is as follows：

Field	Type	usage
Content	[]byte	coinbase tx extra data

notice:

	Type	Description	code location
transaction payload	coinbase	coinbase transaction paylaod	core/types/payload/coinbase.go
output payload	OTNone/null	tx version bigger than 9 then OTNone，otherwise null	core/types/outputpayload/default.go

6.2 RegisterAsset Transaction

The mainchain only supports the ELA token - you can use this transaction to issue your own token on the Elastos chain. Each asset has a controller and total issued amount, which is somewhat similar to ERC-20 tokens on Ethereum. At present, the maichain only supports ELA as an asset, and this transaction is only used as an extension transaction of the asset.

6.2.1 RegisterAsset payload

Field	Type	usage
Asset	Asset	asset details
Amount	Int64	total asset amount
Controller	[21]Uint8	asset controller

6.2.2 Asset

Field	Type	usage
Name	String	asset name
Description	String	asset description
Precision	byte	asset precision
AssetType	byte	asset type
RecordType	byte	asset record type

notice:

	Type	Description	code location
transaction payload	RegisterAsset	RegisterAsset transaction payload	core/types/payload/registerasset.go
output payload	OTNone/null	tx version bigger than 9 then OTNone，otherwise null	core/types/outputpayload/default.go

6.3 TransferAsset Transaction

This is the most basic and commonly used transaction on the mainchain and can be used to transfer ELA assets. The voting transaction of DPoS and CR are also based on this transaction by changing the transaction output structure. The last section will introduce the structure of the transaction output payload.

payload is NULL

notice:

	Type	Description	code location
transaction payload	TransferAsset	TransferAsset transaction payload	core/types/payload/transferasset.go
output payload	OTNone/OTVote/null	tx version bigger than 9 then OTNone，otherwise null	core/types/outputpayload/vote/mapping/crosschain/withdraw/returnsidechaindeposit.go

6.4 SideChainPow Transaction

SideChainPow transaction, created by the cross-chain arbiter on duty and sent to the mainchain through RPC, aims to transfer the consensus of the mainchain to the sidechain of PoW to generate block: save the information of the sidechain in the mainchain, and record the information of the sidechain to the chain through the consensus of the mainchain.

In turn, this ensures the irreversibility of the sidechain, or transferring the computing power of the mainchain to the sidechain. The mainchain will verify whether the initiator of the SideChainPow transaction is the current cross-chain arbiter on duty. If the transaction is not packaged in time due to network and other problems, the old SideChainPoW transaction will be deleted from the trading pit because the verification fails, which means that the sidechain generating speed of PoW will be less than or equal to that of the mainchain and will not exceed that of the mainchain. At present, the realization of the sidechain is also changing to non-PoW sidechain, including the only PoW side chain that will be abandoned later.

The SideChainPoW structure as following：

Field	Type	usage
SideBlockHash	[32]uint8	side chain block hash
SideGenesisHash	[32]uint8	side chain genesis hash
BlockHeight	uint32	side chain block height
Signature	[]byte	arbiter signature

notice:

	Type	Description	code location
transaction payload	SideChainPow	SideChainPow transaction payload	core/types/payload/sidechainpow.go
output payload	OTNone/null	tx version bigger than 9 then OTNone，otherwise null	core/types/outputpayload/default.go

6.5 RechargeToSideChain Transaction

This is sent by the cross-chain arbiter on duty to the sidechain when it senses that there is a cross-chain transaction in the mainchain, which contains Merkel Proof, the mainchain transaction hash, and other information. After receiving this transaction, the sidechain will create the corresponding sidechain currency. This transaction doesn'texist in the mainchain but is used by the sidechain of the old version of PoW.

The PayloadRechargeToSideChain structure is as follows：

Field	Type	usage
MerkleProof	[]byte	mainchain merkle proof
MainChainTransaction	[]byte	mainchain transaction details
MainChainTransactionHash	uint32	mainchain transaction hash

notice:

	Type	Description	code location
transaction payload	PayloadRechargeToSideChain	PayloadRechargeToSideChain transaction payload	Elastos.ELA.SideChain/types/payloadrechargetosidechain.go

6.6 WithdrawFromSideChain Transaction

This therefers to the transaction created by cross-chain arbiter and sent to the mainchain when it monitors the request of sidechain withdrawal. This transaction must be signed by 2/3 or more arbiters to ensure the reliability of withdrawal. Recharge and withdrawal are the implementation of two-way anchoring. The cross-chain arbiter obtains the transaction information of the sidechain through RPC. When it's found that there's a need to withdraw, the cross-chain arbiter on duty creates a multi-signature transaction and initiates a multi-signature withdrawal request. Other cross-chain arbiters verify this transaction and return signatures. When 2/3 of signatures are collected, the transaction will be sent to the main chain through RPC.

The WithdrawFromSideChain structure is as follows：

Field	Type	usage
BlockHeight	uint32	withdraw sidechain height
GenesisBlockAddress	string	sidechain genesis block hash
SideChainTransactionHashes	[][32]uint8	side chain transaction hashes

notice:

	Type	Description	code location
transaction payload	WithdrawFromSideChain	WithdrawFromSideChain transaction payload	core/types/payload/withdrawfromsidechain.go
output payload	OTWithdrawFromSideChain	output payload type	core/types/outputpayload/withdraw.go

6.7 TransferCrossChainAsset Transaction

This is created by the user when the mainchain transfers money to the sidechain. It's two-way anchored with the WithdrawFromCrossChain transaction. When users need to recharge ELA to the sidechain, they need to build this transaction to transfer ELA to the frozen address beginning with X. Cross-chain arbiter will monitor this transaction and then send the transaction information to the sidechain. When making cross-chain transfer, you need to fill in the correct X-start address generated by genesishash of the sidechain and transfer the coins to the X-start address on the mainchain. The address starting with X can only be retrieved by a cross-chain arbiter with multiple signatures - thus, if the address is wrong, the money can’t be retrieved.

The TransferCrossChainAsset structure is as follows：

Field	Type	usage
CrossChainAddresses	[]string	deposit sidechain address
OutputIndexes	[]uint64	spend mainchain output index
CrossChainAmounts	[]int64	deposit cross chain amount

notice:

	Type	Description	code location
transaction payload	TransferCrossChainAsset	TransferCrossChainAsset transaction payload	core/types/payload/transfercrosschainasset.go
output payload	OTCrossChain	output payload type	core/types/outputpayload/default.go

6.8 RegisterProducer Transaction

This is created by the user who needs to run for the supernodes. It's used to register a node as a DPoS node to participate in the main chain block generation consensus and obtain the block and voting profits - it needs to deposit at least 5000 ELA. The public key and nickname of the registered DPoS nodes are not allowed to be duplicated. After registering the DPoS nodes, the first 108 DPoS nodes can get the voting profits, and the top 23 DPoS nodes (as well as a random DPoS node) will be the elected nodes to generate block on consensus and can get the block generation profits.

Field	Type	usage
OwnerPublicKey	[]byte	Owner public key
NodePublicKey	[]byte	Public key nodes
NickName	string	NickName
Url	string	Url to show detail information of DPoS node
Location	uint64	The location of DPoS node
NetAddress	string	The network address
Signature	[]byte	Signature

notice:

	Type	Description	code location
transaction payload	ProducerInfo	RegisterProducer transaction payload	core/types/payload/producerinfo.go
output payload	OTNone/null	tx version bigger than 9 then OTNone，otherwise null	core/types/outputpayload/default.go

6.9 CancelProducer Transaction

This needs to be created by the user who registered the DPoS nodes, and is used to cancel the existing DPoS nodes. The deposit can only be retrieved after the cancellation is successful.

Field	Type	usage
OwnerPublicKey	[]byte	Owner public key
Signature	[]byte	Signature

notice:

	Type	Description	code location
transaction payload	ProcessProducer	CancelProducer transaction payload	core/types/payload/processproducer.go
output payload	OTNone/null	tx version bigger than 9 then OTNone，otherwise null	core/types/outputpayload/default.go

6.10 UpdateProducer Transaction

It needs to be created by the user who has registered the DPoS nodes and is used to modify the DPoS nodes information, including modifying the NodePublicKey to change the current node publickey and other information. After changing the NodePublicKey, the DPoS nodes participating in consensus will not be updated until the second round - that is, after the operating DPoS node is switched, the DPoS node will not be elected until the second round.

Field	Type	usage
OwnerPublicKey	[]byte	Owner public key
NodePublicKey	[]byte	Public key nodes
NickName	string	Nick name
Url	string	Url to show detail information of DPoS node
Location	uint64	The location of DPoS node
NetAddress	string	The network address
Signature	[]byte	Signature

notice:

	Type	Description	code location
transaction payload	ProducerInfo	UpdateProducer transaction payload	core/types/payload/producerinfo.go
output payload	OTNone/null	tx version bigger than 9 then OTNone，otherwise null	core/types/outputpayload/default.go

6.11 ReturnDepositCoin Transaction

This is created by a user who has registered with DPoS nodes and is used to retrieve the deposit of DPoS nodes. At present, there are two situations in which this transaction can be sent to retrieve the deposit. The first is that the deposit higher than 5000 ELA, then the exceeding part can be retrieved at any time. The second is that part of the deposit (without the fine part) can be retrieved after the DPoS node is canceled. It's not limited to retrieve all the deposit at once, and it can be operated several times. But a small amount of service charge will be deducted from the user’s available funds for each operation.

payload is NULL

notice:

	Type	Description	code location
transaction payload	ReturnDepositCoin	ReturnDepositCoin transaction payload , it is a empty struct	core/types/payload/returnpledgecoin.go
output payload	OTNone/null	tx version bigger than 9 then OTNone，otherwise null	core/types/outputpayload/default.go

6.12 ActivateProducer Transaction

This is a transaction of activating the DPoS nodes, which is created by the user who has registered the DPoS nodes - however, the nodes have become inactive. It's used to activate the current DPoS nodes to continue to participate in consensus and obtain the block generation and voting profits. When a node participates in the consensus abnormally, it will be set to inactive state, which doesn’t allow the nodes to block generation and voting profits. Thus, it's necessary to adjust the configuration or check the node state to ensure that it can run normally and stably, then send an activation transaction to activate the nodes.

The ActivateProducer Structure is as follows：

Field	Type	usage
NodePublicKey	[]byte	Public key nodes
Signature	[]byte	The signature

notice:

	Type	Code	Description	Code position
transaction payload	ActivateProducer	0x0d	Activate INACTIVE or illegal DPOS to receive orders	core/types/payload/activateproducer.go
output payload	OTNone/None		Transaction version greater than 9 type 'OTNone', otherwise 'none'	core/types/outputpayload/default.go

6.13 IllegalProposalEvidence Transaction

Illegal proposal evidence is confirmed by the block. The transaction is automatically generated by the mainchain. When the DPoS nodes participate in consensus, and the same consensus view initiates a proposal to confirm the block for different blocks, other nodes will automatically generate IllegalProposalEvidence transaction when they discover the illegal actions, and the illegal information of the DPoS nodes will be on the chain. After that, the illegal DPoS will be set to illegal state, and a certain deposit will be deducted.

DPOSIllegalProposal

Field	Type	usage
Evidence	ProposalEvidence	evidence
CompareEvidence	ProposalEvidence	Evidence for reference
hash	common.Uint256	The hash

ProposalEvidence

Field	Type	usage
Proposal	DPOSProposal	The proposal
BlockHeader	[]byte	Block head
BlockHeight	uint32	Block height

DPOSProposal

Field	Type	usage
Sponsor	[]byte	The originator
BlockHash	common.Uint256	Block the hash
ViewOffset	uint32	ViewOffset
Sign	[]byte	The signature
hash	common.Uint256	The hash

notice:

	Type	Code	Description	Code position
transaction payload	IllegalProposalEvidence	0x0e	Activate INACTIVE or illegal DPOS to receive orders	core/types/payload/dposillegalproposals.go
output payload	OTNone/OTNone		Transaction version greater than 9 type 'OTNone', otherwise 'none'	core/types/outputpayload/default.go

6.14 IllegalVoteEvidence Transaction

Illegal vote evidence is confirmed by the block and automatically generated by the mainchain. When the DPoS nodes participate in consensus, and the same consensus view both agrees and rejects the block confirmation proposal, other nodes will automatically generate IllegalVoteEvidence transaction when they discover the illegal actions. The illegal information of the DPoS nodes will be on the chain. After that, the illegal DPoS will be set to illegal state, and a certain deposit will be deducted.

DPOSIllegalVote

Field	Type	usage
Evidence	VoteEvidence	Polling evidence
CompareEvidence	VoteEvidence	Voting evidence reference
BlockHeight	uint32	Block height
hash	common.Uint256	The hash

VoteEvidence

Field	Type	usage
ProposalEvidence	ProposalEvidence	Bill evidence
Vote	DPOSProposalVote	vote

ProposalEvidence

Field	Type	usage
Proposal	DPOSProposal	The proposal
BlockHeader	[]byte	Block head
BlockHeight	uint32	Block height

DPOSProposalVote

Field	Type	usage
ProposalHash	common.Uint256	Proposal to hash
Signer	[]byte	The signer
Accept	bool	Confirm the status
Sign	[]byte	The signature
hash	common.Uint256	The hash

notice

	Type	Code	Description	Code position
transaction payload	IllegalVoteEvidence	0x0f	Blocks identify evidence of wrongdoing in consensus voting on proposals	core/types/payload/dposillegalvotes.go
output payload	OTNone/None		Transaction version greater than 9 type 'OTNone', otherwise 'none'	core/types/outputpayload/default.go

6.15 IllegalBlockEvidence Transaction

Illegal forking evidence is confirmed by the block. The transaction is automatically generated by the mainchain. When the nodes receive different confirmation blocks at the same height and the view in the confirmation information are the same, it's considered that most of the on-duty DPoS nodes are trying to jointly commit to build forked blocks illegally, and the nodes will automatically generate IllegalBlockEvidence transaction, and the illegal information of the DPoS nodes will be on the chain. After that, the illegal DPoS will be set to illegal state, and a certain deposit will be deducted.

DPOSIllegalBlocks Structure is as follows：

Field	Type	usage
CoinType	CoinType	Currency type
BlockHeight	uint32	Block height
Evidence	BlockEvidence	The Evidence
CompareEvidence	BlockEvidence	Evidence for reference
hash	common.Uint256	The hash

BlockEvidence

Field	Type	usage
Header	[]byte	Block head
BlockConfirm	[]byte	Confirm the block
Signers	[][]byte	The signature
hash	common.Uint256	The hash

notice:

	Type	Code	Description	Code position
transaction payload	IllegalBlockEvidence	0x10	Block block consensus bifurcation block evil evidence	core/types/payload/dposillegalblocks.go
output payload	OTNone/None		Transaction version greater than 9 type 'OTNone', otherwise 'none'	core/types/outputpayload/default.go

6.16 InactiveArbitrators Transaction

Batch Inactive DPoS nodes transaction, which is a multi-signature transaction automatically constructed by the on-duty DPoS nodes, is used to put some DPoS nodes into inactive state according to the consensus participation, so as to improve the service quality of super nodes. This transaction has been obsolete and no longer used in the latest version.

InactiveArbitrators payload：

Field	Type	usage
Sponsor	[]byte	the public key of sponsor.Must be one of the CR.
Arbitrators	[][]byte	the public keys of Arbitrators who will be inactived.
BlockHeight	uint32	main chain height.

notce:

	Type	Description	Code position
transaction payload	InactiveArbitrators	InactiveArbitrators transaction payload	core/types/payload/inactivearbitrators.go
output payload	OTNone/无	tx version bigger than 9 then OTNone，otherwise null	core/types/outputpayload/default.go

6.17 NextTurnDPOSInfo Transaction

This is automatically built by the on-duty DPoS nodes, is used to record which super nodes are working at a certain height of the mainchain, including CR list and ordinary DPoS node list. Because the sidechain needs to know which supernodes are working at a certain height of the mainchain. This transaction is used to record super node information on the mainchain.

NextTurnDPOSInfo payload：

Field	Type	usage
WorkingHeight	uint32	the effective height
CRPublicKeys	[][]byte	the node public keys of CR node
DPOSPublicKeys	[][]byte	the node public keys of DPoS node

notice:

	Type	Description	代码位置
transaction payload	NextTurnDPOSInfo	NextTurnDPOSInfo transaction payload	core/types/payload/nextturndposInfo.go
output payload	OTNone/none	tx version bigger than 9 then OTNone，otherwise null	core/types/outputpayload/default.go

6.18 RecordProposalResult Transaction

This is automatically generated on the chain and used to record the final consensus result of the proposal. For the side chain gets the status of the proposal through spv. At present, it is mainly used for DID short name reservation, activation and change proposal result record of short name rate. The purpose is to facilitate side-chain SPV to obtain proposal results and provide query interface.

RecordProposalResult payload：

Field	Type	usage
RecordProposalResult	[]ProposalResult	The results of proposals

ProposalResult:

Field	Type	usage
ProposalHash	common.Uint256	proposal hash
ProposalType	[][]CRCProposalType	proposal type
Result	[][]bool	result of proposal

notice:

	Type	Description	Code position
transaction payload	ProposalResult	RecordProposalResult transaction payload	core/types/payload/customidresult.go
output payload	OTNone/null	tx version bigger than 9 then OTNone，otherwise null	core/types/outputpayload/default.go

6.19 RegisterCR Transaction

It's constructed by users who need to participate in the CR campaign. After registration, they will become CR candidates. Candidates will accept users’ votes, and the top-ranked ones can become super nodes to participate in consensus. Registered CR candidates need at least 5000 ELA deposit, which will be deducted when the nodes are illegal or have abnormal consensus.

CRInfo payload：

Field	Type	usage
Code	[]byte	code of CR
CID	[][]common.Uint168	cid of CR
DID	[][]common.Uint168	did of CR
NickName	string	nickname of CR
Url	string	urlto show information of CR
Location	uint64	location of CR node
Signature	[]byte	signature of this payload by CR

notice:

	Type	Description	Code position
transaction payload	RegisterCR	CRInfo transaction payload	core/types/payload/crinfo.go
output payload	OTNone/null	tx version bigger than 9 then OTNone，otherwise null	core/types/outputpayload/default.go

6.20 UnregisterCR Transaction

It's created by a user who has registered as a CR candidate and used to cancel it, and the deposit can only be retrieved after the cancellation. After the campaign is over, the elected CR can’t be cancelled. The deposit of the elected CR can only be retrieved after the CR is impeached or the inaugural period is over. Unelected CR nodes can directly retrieve deposit without canceling CR candidates.

Field	Type	usage
CID	common.Uint168	CID of CR
Signature	[][][]byte	Signature of CR

notice:

	Type	Description	Code position
transaction payload	UnregisterCR	UnregisterCR transaction payload	core/types/payload/unregistercr.go
output payload	OTNone/null	tx version bigger than 9 then OTNone，otherwise null	core/types/outputpayload/default.go

6.21 UpdateCR Transaction

This is created by the owner of the CR nodes and used to modify the related information of the CR nodes.

CRInfo payload：

Field	Type	usage
Code	[]byte	code of CR
CID	[][]common.Uint168	cid of CR
DID	[][]common.Uint168	did of CR
NickName	string	nickname of CR
Url	string	urlto show information of CR
Location	uint64	location of CR node
Signature	[]byte	signature of this payload by CR

notice:

	Type	Description	Code position
transaction payload	UpdateCR	CRInfo transaction payload	core/types/payload/crinfo.go
output payload	OTNone/null	tx version bigger than 9 then OTNone，otherwise null	core/types/outputpayload/default.go

6.22 ReturnCRDepositCoin Transaction

The transaction of deposit retrieving of CR nodes, which is created by the owner of CR nodes and used to withdraw the deposit. On the chain, it's allowed to withdraw the deposit for many times, and the part exceeding 5000 ELA can be taken away. After losing the election or the change of CR, part of the deposit (without the fine part) can be retrieved. The status of the deposit nodes will be changed to the Returned status.

The current proposal category codes are as follows:

主类别Main Category	子类别Subclass	类别值Category Value	用途Usage
（00）Ordinary CRC proposal（00）	（00）Ordinary proposal（00）	0x0000	For general transactional proposal issuance
ELIP（01）	ELIP（00）Standards track ELIP（00）	0x0100	Used to describe the changes in the design and implementation of Elastos infrastructure. Refer to the description of ELIP types in ELIP-1.
	ELIP（01）Process ELIP (01)	0x0101	ELIP is used to describe the process definition or process change related to Elastos. Refer to the description of ELIP types in ELIP-1.
	（02）Information ELIP (02)	0x0102	Used to describe the design problems of Elastos, or to provide general guidance or information to Elastos community. Refer to the description of ELIP types in ELIP-1.
（02）Code upgrade (02)	（00）ELA main chain code upgrade (00)	0x0200	Used to upgrade the ELA main chain code.
	（01）DID side chain code upgrade (01)	0x0201	Used to upgrade the DID side chain code.
	(02)ETH side chain code upgrade (02)	0x0202	Used to upgrade the ETH side chain code.
（04）ELA main chain (04)	（00）Election of the SecretaryGeneral (00)	0x0400	Used to nominate the Secretary General of CR Committee.
	（01）Change the person in charge of the proposal (01)	0x0401	Used to realize the second method of replacing the person in charge of proposal described in section 7.7 of CRC white paper.
	（02）Proposal termination (02)	0x0402	Used to realize the termination method of proposal described in section 7.9 of CRC white paper when the proposal cannot or should not be continued.
	（10）Register the side chain (10)	0x0410	Used to register a piece of side chain information on the main chain.
（05）DID side chain (05)	（00）Reserved customized ID (00)	0x0500	Used to specify the customized ID that the DID side chain needs to reserve.
	（01）Initiate customized ID (01)	0x0501	DIDCustomized ID for initiating reservation in DID side chain.
	（02）Customized ID rate (02)	0x0502	Specify the customized ID transaction base rate for DID side chain.

payload is NULL

notice:

	Type	Description	Code position
transaction payload	ReturnCRDepositCoin	ReturnDepositCoin transaction payload, is empty	core/types/payload/returnpledgecoin.go
output payload	OTNone/null	tx version bigger than 9 then OTNone，otherwise null	core/types/outputpayload/default.go

6.23 CRCProposal Transaction

Next is the CRC proposal co-chain transaction, which is signed and launched to the chain by CR members and used for issuing proposal application. After the proposal is on the chain, it needs a 7-day CR review period and a 7-day referendum period. The CR review period is for 12 CR members to vote in order to decide whether to allow the proposal to be passed, and the referendum period is for everyone to vote, and the proposal can only take effect after passing the review period and the referendum period. The details of the proposal, budget amount, etc. can be described in the proposal. At present, there are more than ten kinds of proposal categories, and the payload structure and signature rules of different categories may be different.

6.23.1 CRCProposal

Field	Type	usage
ProposalType	uint16	type of proposal
CategoryData	string	proposal category
OwnerPublicKey	[]byte	proposal owner public key
DraftHash	[32]uint8	draft of proposal data hash
DraftData	[]byte	draft of proposal data
Budgets	[]Budget	budget info
Recipient	[21]uint8	receipt of budgets
TargetProposalHash	[32]uint8	processing proposal hash
ReservedCustomIDList	[]string	reserved custom did list
ReceivedCustomIDList	[]string	already received custom did list
ReceiverDID	[21]uint8	receiver of custom did
RateOfCustomIDFee	int64	register custom did fee
NewRecipient	[21]uint8	new recipient address
NewOwnerPublicKey	[]byte	new proposal owner public key
SecretaryGeneralPublicKey	[]byte	public key of secretary general
SecretaryGeneralDID	[21]uint8	did of secretary general
Signature	[]byte	owner signature of this proposal
NewOwnerSignature	[]byte	new owner signature of this proposal
SecretaryGeneralSignature	[]byte	Secretary General signature of this proposal
CRCouncilMemberDID	[21]uint8	cr did
CRCouncilMemberSignature	[]byte	cr signature of this proposal
UpgradeCodeInfo	*UpgradeCodeInfo	upgrade code info details
SideChainInfo	SideChainInfo	register sidechain details
hash	[32]uint8	proposal hash

Not all fields are used, different proposal type may use some fields of them, need to use this according to core/types/payload/crcproposal.go

6.23.2 Budget

Field	Type	usage
Type	byte	budget type
Stage	byte	budget execution stage
Amount	int64	budget amount

6.23.3 UpgradeCodeInfo

Field	Type	usage
WorkingHeight	uint32	upgrade code start height
NodeVersion	string	version of node
NodeDownLoadUrl	string	downloading location
NodeBinHash	[32]uint8	binary file hash
ForceUpgrade	bool	do we need force upgrade this protocol

6.23.4 SideChainInfo

Field	Type	usage
SideChainName	string	sidechain name
MagicNumber	uint32	sidechain magic
GenesisHash	[32]uint8	sidechain genesis hash
ExchangeRate	int64	mainchain sidechain coin exchange rate
EffectiveHeight	uint32	sidechain start function height
ResourcePath	string	path of resources

notice:

	Type	Description	code location
transaction payload	CRCProposal	CRCProposal tx payload	core/types/payload/crcproposal.go
output payload	OTNone/null	tx version bigger than 9 then OTNone，otherwise null	core/types/outputpayload/default.go

6.24 CRCProposalReview Transaction

This is created by CR committee members to vote on the proposal. You can choose to agree, refuse, or abstain from voting. If the CR members don't send comments on certain proposals, a certain percentage of deposit will be deducted according to the proposal handling ratio when the CR changes.

CRCProposalReview struct as following：

Field	Type	usage
ProposalHash	[32]uint8	hash of this proposal
VoteResult	byte	vote result，0 approve，1 reject ，2 abstain
OpinionHash	[32]uint8	reviewer's opinion hash
OpinionData	[21]byte	reviewer's opinion data
DID	[]byte	reviewer's did
Signature	[]byte	proposal reviewer's signature

notice:

	Type	Description	code location
transaction payload	CRCProposalReview	CRCProposalReview transaction payload	core/types/payload/crcproposalreview.go
output payload	OTNone/null	tx version bigger than 9 then OTNone，otherwise null	core/types/outputpayload/default.go

6.25 CRCProposalTracking Transaction

This is initiated by a CR committee member and the Secretary General, and is used to track the stages of the proposal, including recording the implementation progress of the proposal, confirming and paying money after the completion of the phased tasks of the proposal, and suspending the proposal, etc. The payload format of this transaction will be different for different proposal categories.

CRCProposalTracking struct as following：

Field	Type	usage
ProposalHash	[32]uint8	hash of proposal
MessageHash	[32]uint8	proposal tracking message hash
MessageData	[]byte	proposal tracking message data
Stage	byte	proposal stage
OwnerPublicKey	[]byte	owner proposal public key
NewOwnerPublicKey	[]byte	new owner proposal public key
OwnerSignature	[]byte	owner proposal signature
NewOwnerSignature	[]byte	new proposal owner signature
ProposalTrackingType	byte	tracking type ：0 Common，1Progress，2Rejected，3Terminated，4ChangeOwner，5Finalized
SecretaryGeneralOpinionHash	[32]byte	Secretary General's Opinion hash
SecretaryGeneralOpinionData	[]byte	Secretary General's Opinion info

notice:

	Type	Description	code location
transaction payload	CRCProposalTracking	CRCProposalTracking交易payload	core/types/payload/crcproposaltracking.go
output payload	OTNone/null	tx version bigger than 9 then OTNone，otherwise null	core/types/outputpayload/default.go

6.26 CRCProposalAppropriation Transaction

This is automatically constructed on the chain, and is used to transfer 10% of the funds from CR assets address to CR expenses address when the CR members change.

payload is NULL

Notice:

	Type	Description	code location
transaction payload	CRCProposalAppropriation	CRCProposalAppropriation transaction payload , it is a empty struct	core/types/payload/crcproposalappropriation.go
output payload	OTNone/null	tx version bigger than 9 then OTNone，otherwise null	core/types/outputpayload/default.go

6.27 CRCProposalWithdraw Transaction

This is created by the proposal owner and used to apply for withdrawal of funds in the proposal stage. The withdrawal of money must be consistent with the money acceptance address specified in the proposal.

CRCProposalWithdraw is as following：

Field	Type	usage
ProposalHash	[32]uint8	hash of proposal
OwnerPublicKey	[]byte	proposal owner public key
Recipient	[21]byte	withdraw address
Amount	int64	withdraw amount
Signature	[]byte	proposal owner signature of this proposal withdraw action

notice:

	Type	Description	code location
transaction payload	CRCProposalWithdraw	CRCProposalWithdraw transaction payload	core/types/payload/crcproposalwithdraw.go
output payload	OTNone/null	tx version bigger than 9 then OTNone，otherwise null	core/types/outputpayload/default.go

6.28 CRCProposalRealWithdraw Transaction

It's automatically constructed on the chain and used to send ELA from CR operation address to a specific acceptance address according to the money withdrawn by application. The reason why this transaction exists is that the chain is UTXO model, and there will be conflict of UTXO usage when many people apply at the same time, so the withdrawal is changed to two steps. The first step is user application, and the second step is automatic appropriation on the chain.

CRCProposalRealWithdraw is as following：

Field	Type	usage
WithdrawTransactionHashes	[][32]uint8	the proposal hashes which need to withdraw

notice:

	Type	Description	code location
transaction payload	CRCProposalRealWithdraw	CRCProposalRealWithdraw transaction payload	core/types/payload/crcproposalrealwithdraw.go
output payload	OTNone/null	tx version bigger than 9 then OTNone，otherwise null	core/types/outputpayload/default.go

6.29 CRCAssetsRectify Transaction

Thisis automatically built on the chain and is used to merge UTXO with scattered CRC asset addresses into one UTXO. Because the mainchain is UTXO model, each block will issue a small amount of block generation rewards to CRC asset address. This part of the rewards system will increase with the time, and excessive UTXO will bring efficiency loss to the query on the chain, so it's important to automatically sort out the UTXO of CRC asset addresses on the chain.

payload is NULL

Notice:

	Type	Description	code location
transaction payload	CRAssetsRectify	CRCProposalRealWithdraw trasaction payload it is a empty struct	core/types/payload/crcassetsrectify.go
output payload	OTNone/null	tx version bigger than 9 then OTNone，otherwise null	core/types/outputpayload/default.go

6.30 CRCouncilMemberClaimNode Transaction

This is the transaction of the operation node claim of CR committee members, which is initiated by the elected CR committee members in the claim period and used to specify the DPoS node information. Within two weeks after the election of CR members, they're required to claim the DPoS nodes. At this time, CR members need to build this transaction. If the transaction is not claimed within the specified time, after the claim period, the nodes will become inactive, and they will no longer have the block generation profits and voting rights of proposals, and it will be recovered after the CR members claim it.

CRCouncilMemberClaimNode struct as following：

Field	Type	usage
NodePublicKey	[]uint8	dpos node public key
CRCouncilCommitteeDID	[21]uint8	did of cr
CRCouncilCommitteeSignature	[]byte	cr council member signature of this struct

notice:

	Type	Description	code location
transaction payload	CRCouncilMemberClaimNode	CRCouncilMemberClaimNode transaction payload	core/types/payload/crcdposmanagement.go
output payload	OTNone/null	tx version bigger than 9 then OTNone，otherwise null	core/types/outputpayload/default.go

6.31 RevertToPOW

The transaction degenerates into block generation of PoW consensus, which is automatically built on the chain and used to change the DPoS consensus on the chain into PoW consensus. There are three reasons for the reversion of this transaction. The first one is because there is no new block of consensus for 12 hours; the second is that PPoS nodes are insufficient; the third is that there are not enough CR members to claim nodes in the claim period. After degenerating into PoW consensus, there may be more forking reorganization. Under PoW consensus, users are only allowed to create a few transactions such as voting and activation. The purpose is to prevent people from using forking to do illegal actions. After reverting to PoW, the user can create the following transactions:

1. Registering transactions of DPoS nodes

2. Voting transactions of DPoS nodes

3. Activating transactions after the DPOS nodes are inactive

4. Registering transactions of CR members

5. Voting transactions of CR members

6. Activating transactions after CR members are inactive

Certainly, automatically generated transactions on the chain are allowed.

RevertToPOW payload:

Field	Type	usage
Type	byte	Causes of degeneration to POW: NoBlock, NoProducers or NoClaimDPOSNode
WorkingHeight	uint32	Main chain height when officially in effect

notice:

	Type	Description	code location
transaction payload	RevertToPOW	RevertToPOW transaction payload, transaction type: 0x41	core/types/payload/reverttopow.go
output payload	OTNone/null	tx version bigger than 9 then OTNone，otherwise null	core/types/outputpayload/default.go

6.32 RevertToDPOS

Transaction of reverting the block generation of DPoS consensus, which is automatically built on the chain and used to change the PoW consensus to the DPoS consensus. After the chain degenerates into PoW, it will check the current number of DPoS nodes and directly connected network conditions after each block is packed to see if the conditions for reverting are met. When the conditions are met, it will automatically generate a reverting transaction, and specify that it will be reverted as DPoS block generation at a certain main chain height.

Field	Type	usage
WorkHeightInterval	uint32	Revert to DPoS when this transaction has more than WorkHeightInterval confirms
RevertToPOWBlockHeight	uint32	Record the height of last RevertToPOW transaction

notice:

	Type	Description	code location
transaction payload	RevertToPOW	RevertToDPOS transaction payload, transaction type: 0x42	core/types/payload/reverttodpos.go
output payload	OTNone/null	tx version bigger than 9 then OTNone，otherwise null	core/types/outputpayload/default.go

6.33 ReturnSideChainDepositCoin

The return transaction of cross-chain recharge, which is generated by multi-signature of cross-chain arbiter and sent to the mainchain through RPC, is used to return the amount of cross-chain recharge transaction that fails to recharge under special circumstances to the user to prevent the loss of funds. Here, we mainly focus on the ESC sidechain recharge transaction. When the execution of the sidechain contract fails due to the error information written by the user in the DATA field of the transfer data in the transaction, the cross-chain arbiter will generate this transaction by multiply signatures.

payload is NULL

Notice:

	Type	Description	code location
transaction payload	ReturnSideChainDepositCoin	ReturnSideChainDepositCoin transaction payload , it is a empty struct, transaction type: 0x51	core/types/payload/returnsidechaindepositcoin.go
output payload	OTNone/null	tx version bigger than 9 then OTNone，otherwise null	core/types/outputpayload/default.go

7 OutputPayload

7.1 OTNone

OTNone indicates there is no payload for this output.

output payload is NULL

7.2 OTVote payload

OTVote indicates the output payload is a vote.

7.2.1 VoteOutput

Field	Type	usage
Version	byte	VoteOutput version
Contents	[]VoteContent	VoteOutput content

7.2.2 VoteContent

Field	Type	usage
VoteType	byte	vote type
CandidateVotes	[]CandidateVotes	candidate votes details

7.2.3 CandidateVotes

Field	Type	usage
Candidate	[]byte	candidate public key
Votes	int64	candidate votes

7.3 OTMapping

OTMapping indicates the output payload is a mapping.

Mapping structure as following：

Field	Type	usage
Version	byte	Version indicates the version of Mapping payload
OwnerPublicKey	string	OwnerPublicKey is the owner public key of the main chain producer
SideProducerID	int64	SideProducerID indicates a piece of data represent the identity of the side chain producer, whether it is a public key or address etc
Signature	[]byte	Signature represents the signature of the mapping payload content

7.4 OTCrossChain payload

OTCrossChain indicates the output payload is cross chain information.

CrossChainOutput structure as following：

Field	Type	usage
Version	byte	crosschain transfer output version
TargetAddress	string	crosschain transfer output target address
TargetAmount	int64	crosschain transfer output amount
TargetData	[]byte	rosschain transfer extra info data

7.5 OTWithdrawFromSideChain payload

OTWithdrawFromSideChain indicates the output payload is withdraw from side chain information.

Withdraw structure as following：

Field	Type	usage
Version	byte	withdraw version
GenesisBlockAddress	string	withdraw sidechain genesis block address
SideChainTransactionHash	[32]uint8	side chain hash
TargetData	[]byte	transaction extra data

7.6 OTReturnSideChainDepositCoin

OTReturnSideChainDepositCoin indicates the output payload is return side chain deposit coin.

ReturnSideChainDepositCoin structure as following:

Field	Type	usage
Version	byte	withdraw version
GenesisBlockAddress	string	withdraw sidechain genesis block address
DepositTransactionHash	[32]uint8	the hash of DepositToSideChain transaction