💡 [REQUEST] - Add `block_timestamp` field to the transaction context
Summary
Use Case
Time-based Solana programs (token streaming, vesting, staking, lockups) fundamentally rely on block timestamps for their core logic. In the post_transaction hook, we need to assert that the program executed correctly by comparing the actual state changes against the expected values calculated based on the block timestamp.
The challenge
We need to know the exact block timestamp at which the transaction executed to calculate what the correct state should be for our assertions.
Basic Example
fn post_transaction(&self, client: &mut impl FuzzClient) {
// Get the block timestamp to calculate the expected state changes
let block_time = self.block_timestamp;
// Determine the expected state changes based on the tx timestamp
...
// Assert the program executed correctly
...
}
Drawbacks
None
Hello, thanks for the issue, interesting feature. As far as I know, there is no block production currently; we use the SVM API, which allows us to just process transactions, so there should not be block production in the background. Will need to think about this feature in more depth.
As far as I know, there is no block production currently; we use the SVM API
What I'm trying to achieve with this feature request is to be able to access the timestamp of the tx. In other words, the timestamp that the block including it would have if you were to create the block (and not just simulate the tx execution).
Wdyt?
Yes I see and I also find this feature interesting. Trident does not produce blocks right now. On the other hand I think what can be achievable is to have transaction timestamp accessible for each executed transaction, that imo should be possible.
Yes I see and I also find this feature interesting. Trident does not produce blocks right now. On the other hand I think what can be achievable is to have transaction timestamp accessible for each executed transaction, that imo should be possible.
As far as I'm concerned, as long as the "current" timestamp is accessible from the Tx context, it's good enough, even if there's no block production behind this 🤝