I think your confusion arises from a misunderstanding about the scope of sequence numbers. Sequence numbers start at zero and increase each time an event is emitted per event stream. An event stream can be identified by the unique combination of:
- Account from which the event is being emitted.
- Event type, which is the combination of module, address where that module is deployed, and the event itself, e.g.
0x789::my_module::MyEvent.
This means every time a function emits 0x789::my_module::MyEvent the sequence number will increase by 1.
In your example, you refer to these three event streams:
0x3::token::CreateTokenDataEvent0x3::token::DepositEvent0x3::token::MintTokenEvent
Even though these events were all emitted from the same account (0xb4e07588374bd19370de08bbb6b0537a975bf57ce755d7976e181e5f4e4d0da4) and they're all from the same module (0x3::token), these are still distinct token streams, so you should not expect anything about how they relate, there is no intrinsic order between them. The fact that they all have the same sequence number (125) is coincidental, it is just because whatever function is being called always emit these 3 events together.
To further clarify:
- Event sequence numbers are not local to transactions, they just increase every time an event is emitted, forever.
- Event sequence numbers have nothing to do with blocks.
- Events defined in the same module do not share an event stream.
- Different event types emitted from the same account do not share an event stream.
To answer part of your question:
How can we determine the ordering of those events?
You can't, it is not possible to determine the order that events were emitted within a transaction. You could figure this out by using your own counter that you share between events, but there is no real reason to do this. A transaction is an atomic unit, so there is no reason to care about the order that events were emitted, they were either all emitted or none were emitted. This document about how transactions ultimately result in changes to storage might be helpful: Transactions change ledger state.
Appendix
Here is a demonstration that sequence numbers indeed work this way.
Publish the following code: banool/move-examples.
Call the add_friend function:
aptos move run --function-id `yq .profiles.default.account < .aptos/config.yaml`::emit_events::add_friend --args 'string:Jimmy'
Get the creation number that identifies the event stream for AddFriendEvent:
$ curl https://fullnode.devnet.aptoslabs.com/v1/accounts/0x0e80c7246986f75d56c7a5a8eb12e0eeacf3536db6c0df09299cc1436c290f9f/resource/0x0e80c7246986f75d56c7a5a8eb12e0eeacf3536db6c0df09299cc1436c290f9f::emit_events::FriendStore | jq -r .data.add_friend_events.guid.id.creation_num
4
Query the event stream:
$ curl https://fullnode.devnet.aptoslabs.com/v1/accounts/ecbce66aa4b872e4c56d237311802381f8d7da0cb7ea872eaed43560a1f9118a/events/4 | jq .
[
{
"version": "2011834",
"guid": {
"creation_number": "4",
"account_address": "0xecbce66aa4b872e4c56d237311802381f8d7da0cb7ea872eaed43560a1f9118a"
},
"sequence_number": "0",
"type": "0xecbce66aa4b872e4c56d237311802381f8d7da0cb7ea872eaed43560a1f9118a::emit_events::AddFriendEvent",
"data": {
"name": "Jimmy"
}
}
]
See that because this is the first event emitted in this stream that the sequence number is 0.
Call the function again:
aptos move run --function-id `yq .profiles.default.account < .aptos/config.yaml`::emit_events::add_friend --args 'string:Alice'
See that there are now two events in this stream, and the sequence number of the latest event is 1:
$ curl https://fullnode.devnet.aptoslabs.com/v1/accounts/ecbce66aa4b872e4c56d237311802381f8d7da0cb7ea872eaed43560a1f9118a/events/4 | jq .
[
{
"version": "2011834",
"guid": {
"creation_number": "4",
"account_address": "0xecbce66aa4b872e4c56d237311802381f8d7da0cb7ea872eaed43560a1f9118a"
},
"sequence_number": "0",
"type": "0xecbce66aa4b872e4c56d237311802381f8d7da0cb7ea872eaed43560a1f9118a::emit_events::AddFriendEvent",
"data": {
"name": "Jimmy"
}
},
{
"version": "2013959",
"guid": {
"creation_number": "4",
"account_address": "0xecbce66aa4b872e4c56d237311802381f8d7da0cb7ea872eaed43560a1f9118a"
},
"sequence_number": "1",
"type": "0xecbce66aa4b872e4c56d237311802381f8d7da0cb7ea872eaed43560a1f9118a::emit_events::AddFriendEvent",
"data": {
"name": "Alice"
}
}
]
Now let's call remove_newest_friend:
aptos move run --function-id `yq .profiles.default.account < .aptos/config.yaml`::emit_events::remove_newest_friend
If we query the event stream for RemoveNewestFriendEvent, we can see that this is a separate stream. The creation number is different (indicating a different stream) and the sequence number started at 0 again:
$ curl https://fullnode.devnet.aptoslabs.com/v1/accounts/ecbce66aa4b872e4c56d237311802381f8d7da0cb7ea872eaed43560a1f9118a/events/5 | jq .
[
{
"version": "2015644",
"guid": {
"creation_number": "5",
"account_address": "0xecbce66aa4b872e4c56d237311802381f8d7da0cb7ea872eaed43560a1f9118a"
},
"sequence_number": "0",
"type": "0xecbce66aa4b872e4c56d237311802381f8d7da0cb7ea872eaed43560a1f9118a::emit_events::RemoveNewestFriendEvent",
"data": {
"new_friend_count": "1"
}
}
]
If we look at the stream of AddFriendEvent, we see that there are no new events and the sequence number of the latest event has not changed:
[
{
"version": "2011834",
"guid": {
"creation_number": "4",
"account_address": "0xecbce66aa4b872e4c56d237311802381f8d7da0cb7ea872eaed43560a1f9118a"
},
"sequence_number": "0",
"type": "0xecbce66aa4b872e4c56d237311802381f8d7da0cb7ea872eaed43560a1f9118a::emit_events::AddFriendEvent",
"data": {
"name": "Jimmy"
}
},
{
"version": "2013959",
"guid": {
"creation_number": "4",
"account_address": "0xecbce66aa4b872e4c56d237311802381f8d7da0cb7ea872eaed43560a1f9118a"
},
"sequence_number": "1",
"type": "0xecbce66aa4b872e4c56d237311802381f8d7da0cb7ea872eaed43560a1f9118a::emit_events::AddFriendEvent",
"data": {
"name": "Alice"
}
}
]
