Ordinarily _verifyPeer() in the attestation flow ties the sourceNttManagerAddress to the payload indirectly. However, if:
- a message has some but not all attestations AND
- the threshold decreases during transceiver managements, AND
- someone calls
executeMsg for that message with a different sourceNttManagerAddress
then the message could be processed with an incorrect manager address.
This has implications in only two places:
- The event emitted on release
handleAdditionalPayload -- this is integrator-specific logic which the core maintainers of this project do not have control of or visibility into.
Integrators relying on sourceNttManagerAddress while handling additional payloads should be aware that this data may not be trustworthy in the unlikely edge-cases described above.
Ordinarily
_verifyPeer()in the attestation flow ties the sourceNttManagerAddress to the payload indirectly. However, if:executeMsgfor that message with a different sourceNttManagerAddressthen the message could be processed with an incorrect manager address.
This has implications in only two places:
handleAdditionalPayload-- this is integrator-specific logic which the core maintainers of this project do not have control of or visibility into.Integrators relying on
sourceNttManagerAddresswhile handling additional payloads should be aware that this data may not be trustworthy in the unlikely edge-cases described above.