You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, each transaction in the Fuel VM can have a set of "transaction policies" attached to it. One such optional policy is "maturity," which ensures that a given transaction isn't valid until the provided block height is reached. This policy allows for delayed transaction validation.
Proposal:
To complement the "maturity" policy, I suggest adding an "expiration" policy. This new policy would specify a block height after which the transaction is no longer valid. This feature would enable developers to set both a start and end validity period for transactions, providing more granular control over transaction lifetimes.
Implementation Details:
Add a new optional field expiration to the transaction structure.
Update the transaction validation logic to check for the expiration policy.
If the current block height exceeds the expiration block height, the transaction should be deemed invalid.
Example:
A transaction with the following policies:
maturity: 1000
expiration: 2000
This transaction would be valid from block height 1000 to block height 2000. Before block 1000 and after block 2000, the transaction would be considered invalid.
The text was updated successfully, but these errors were encountered:
Background:
Currently, each transaction in the Fuel VM can have a set of "transaction policies" attached to it. One such optional policy is "maturity," which ensures that a given transaction isn't valid until the provided block height is reached. This policy allows for delayed transaction validation.
Proposal:
To complement the "maturity" policy, I suggest adding an "expiration" policy. This new policy would specify a block height after which the transaction is no longer valid. This feature would enable developers to set both a start and end validity period for transactions, providing more granular control over transaction lifetimes.
Implementation Details:
Add a new optional field expiration to the transaction structure.
Update the transaction validation logic to check for the expiration policy.
If the current block height exceeds the expiration block height, the transaction should be deemed invalid.
Example:
A transaction with the following policies:
maturity: 1000
expiration: 2000
This transaction would be valid from block height 1000 to block height 2000. Before block 1000 and after block 2000, the transaction would be considered invalid.
The text was updated successfully, but these errors were encountered: