Summary: this NEP called Transfer to Transaction tries to provide a practical manner to redistribute assets during Verification time on transaction, thus allowing implementation of practical mechanisms for "free transactions".
[EDIT 1] - This doesn't affect NEP-17 in any case. At the time of writing, this is mainly intended for adoption only on GAS contract, as NEP-17 and NEP-TTT.
[EDIT 2] - Two methods are proposed in this NEP: scheduleTransfer and finalizeTransfer.
[ORIGINAL PART]
=====
Transfer to Transaction
This NEP considers a transaction as a valid (and temporary) token holder (as HASH256 identifier, not usual HASH160).
It can be done with operation "contract.scheduleTransfer(from, target_tx, value)" that launches a "promiseNotification" (consumed before actual contract invocation).
Contracts can easily extract funds from transaction, for example, in a mint operation. Neo system can also consume funds from Transaction, for example, GAS funds to cover fee for operations. User can also specify a "contract scope" or "group scope" as the temporary holder (instead of global "transaction scope") and funds are consumed according to the scope.
Example 1 (usual operation):
- User transfers its own 0.5 GAS to TxA (on tx header) - Note that this works as a
fee field on transaction and script runs directly from Witness
- User calls transfer operation for ContractY NEP17 (on tx invocation) and uses GAS stored on tx for operations
Example 2:
- User "requests" 0.5 GAS from ContractY to TxA (on tx header)
- User calls transfer operation for ContractY NEP17 (on tx invocation) and uses GAS stored on tx for operations
This "request" operation at ContractY can do some interesting thing such "redistributing" GAS for user operation, in that specific scope, with some simple rule as:
- gas_request < User_NEP17_Balance_at_ContractY / NEP17_Total_Supply * GAS_Balance_at_ContractY * (1 - RELATIVE_HOLD_TIME)
- gas_request < max_gas_request => (some contract-specific constant tighter than the constraint above)
- RELATIVE_HOLD_TIME = last_balance_change / contract_specific_hold_constant (blocks)
- last_balance_change > XYZ (blocks)
This means that giveaway operation only works after few blocks, and with limited gas supply (limited per block hold time and user shares on that contract).
Summary: this NEP called Transfer to Transaction tries to provide a practical manner to redistribute assets during Verification time on transaction, thus allowing implementation of practical mechanisms for "free transactions".
[EDIT 1] - This doesn't affect NEP-17 in any case. At the time of writing, this is mainly intended for adoption only on GAS contract, as NEP-17 and NEP-TTT.
[EDIT 2] - Two methods are proposed in this NEP:
scheduleTransferandfinalizeTransfer.[ORIGINAL PART]
=====
Transfer to Transaction
This NEP considers a transaction as a valid (and temporary) token holder (as HASH256 identifier, not usual HASH160).
It can be done with operation "contract.scheduleTransfer(from, target_tx, value)" that launches a "promiseNotification" (consumed before actual contract invocation).
Contracts can easily extract funds from transaction, for example, in a mint operation. Neo system can also consume funds from Transaction, for example, GAS funds to cover fee for operations. User can also specify a "contract scope" or "group scope" as the temporary holder (instead of global "transaction scope") and funds are consumed according to the scope.
Example 1 (usual operation):
feefield on transaction and script runs directly from WitnessExample 2:
This "request" operation at ContractY can do some interesting thing such "redistributing" GAS for user operation, in that specific scope, with some simple rule as:
This means that giveaway operation only works after few blocks, and with limited gas supply (limited per block hold time and user shares on that contract).