Extend current Transaction class to incorporate the elements introduced in Assets 1-5 issues, created transaction abstract to form new base for transactions and :
Asset Registration/Minting Process:
To streamline asset creation/minting as well as updating asset metadata information we need to separate asset registration and update vs minting and transferring assets. This way we can have longer name chars limit while space to hold asset name and its information remain fixed in a minting and transferring. Asset registration and update process will be similar to protx registration and update as the asset metadata will be store in the ledger exactly the same way smartnode list is currently store on ledger
Transaction types:
new_asset: this transaction type is used when a new asset name is registered
update_asset: this transaction type is used when an existing asset is updating
Transaction extraPayload: transaction extra payload which will be used to store asset metadata
new_asset extraPayload structure:
Name: 1-128 chars [a-zA-Z0-9] and space
updatable: bool - if true this asset meta can be modified using assetTx update process. Otherwise these asset meta can’t be updated
Is_unique: true if this is asset can be unique identify per token
Decimal point: has to be 0 if is_unique is true.
referenceHash: hash of the underlying physical or digital assets, IPFS hash can be used here.
Distribution:
Type: unit8 - possible types are manual, coinbase, address, and schedule
targetAddress: address to be issued to when asset issue transaction is created.if type is address then whenever a transaction occurred to this address then distribution occurred. If type is scheduled this is the address where assets will be issued per schedule.
issueFrequency: uint8 - mint specific amount of token every x blocks.
Amount: CAmount - amount to distribute each time if type is not manual.
ownerAddress: wallet address that this asset is owned by. Only key holder of this address will be able to mint new tokens
collateralAddress: wallet address where collateral for minting asset fee will be in if type is not manual
Burns: similar to distribution but send asset to a burn address or future lock it forever
Requirements:
The abstract transaction class needs to have fields for all of the above mentioned points
The transaction class needs to make full use of the newly created OP_ASSET_ID
Ensure full backwards and forwards compatibility post changes. Including syncs from scratch and continuation post both graceful shutdowns and ungraceful shutdowns!
Create appropriate unit and possibly fuzz or other tests to ensure compliance and avoid unforeseen issues.
Bigpiggy01
commented
7 months ago
Extend current Transaction class to incorporate the elements introduced in Assets 1-5 issues, created transaction abstract to form new base for transactions and :
Asset Registration/Minting Process:
To streamline asset creation/minting as well as updating asset metadata information we need to separate asset registration and update vs minting and transferring assets. This way we can have longer name chars limit while space to hold asset name and its information remain fixed in a minting and transferring. Asset registration and update process will be similar to protx registration and update as the asset metadata will be store in the ledger exactly the same way smartnode list is currently store on ledger
Transaction types:
new_asset: this transaction type is used when a new asset name is registered
update_asset: this transaction type is used when an existing asset is updating
Transaction extraPayload: transaction extra payload which will be used to store asset metadata
new_asset extraPayload structure:
Name: 1-128 chars [a-zA-Z0-9] and space
updatable: bool - if true this asset meta can be modified using assetTx update process. Otherwise these asset meta can’t be updated
Is_unique: true if this is asset can be unique identify per token
Decimal point: has to be 0 if is_unique is true.
referenceHash: hash of the underlying physical or digital assets, IPFS hash can be used here.
Distribution:
Type: unit8 - possible types are manual, coinbase, address, and schedule
targetAddress: address to be issued to when asset issue transaction is created.if type is address then whenever a transaction occurred to this address then distribution occurred. If type is scheduled this is the address where assets will be issued per schedule.
issueFrequency: uint8 - mint specific amount of token every x blocks.
Amount: CAmount - amount to distribute each time if type is not manual.
ownerAddress: wallet address that this asset is owned by. Only key holder of this address will be able to mint new tokens
collateralAddress: wallet address where collateral for minting asset fee will be in if type is not manual
Burns: similar to distribution but send asset to a burn address or future lock it forever
Requirements:
The abstract transaction class needs to have fields for all of the above mentioned points
The transaction class needs to make full use of the newly created OP_ASSET_ID
Ensure full backwards and forwards compatibility post changes. Including syncs from scratch and continuation post both graceful shutdowns and ungraceful shutdowns!
Create appropriate unit and possibly fuzz or other tests to ensure compliance and avoid unforeseen issues.