Proposal: implement a more strict checking on transactions according to the transaction type:
TRANSFER
The recipient must be filled
The amount must be non-zero
The payload must be zero bytes
CALL and FEEDELEGATION
The recipient must be an existing smart contract
The payload must be valid, a proper formatted JSON for a call
GOVERNANCE
The payload must be valid, a proper formatted JSON for a governance call
The recipient must be either aergo.system (DPoS) or aergo.enterprise (Raft)
DEPLOY
The recipient must be empty
The payload must be a valid smart contract binary code
REDEPLOY
The recipient must be a valid smart contract
The payload must be a valid smart contract binary code
PAYLOAD (new type)
The payload must be non-zero bytes
The amount must be zero
The recipient can be empty or filled
NORMAL
Currently supports any recipient, any amount and any payload
This transaction type could be deprecated
It could be supported for backwards compatibility for some time, and encourage users to migrate to other types
Proposal: implement a more strict checking on transactions according to the transaction type:
TRANSFER
The recipient must be filled The amount must be non-zero The payload must be zero bytes
CALL and FEEDELEGATION
The recipient must be an existing smart contract The payload must be valid, a proper formatted JSON for a call
GOVERNANCE
The payload must be valid, a proper formatted JSON for a governance call The recipient must be either
aergo.system
(DPoS) oraergo.enterprise
(Raft)DEPLOY
The recipient must be empty The payload must be a valid smart contract binary code
REDEPLOY
The recipient must be a valid smart contract The payload must be a valid smart contract binary code
PAYLOAD (new type)
The payload must be non-zero bytes The amount must be zero The recipient can be empty or filled
NORMAL
Currently supports any recipient, any amount and any payload This transaction type could be deprecated It could be supported for backwards compatibility for some time, and encourage users to migrate to other types