PayerReportManager uses EIP-712 signatures to guarantee a signature is valid for the current contract version.
The signed payer report commits to payersMerkleRoot (raw pico-dollar leaves), but does not commit to fee-conversion semantics applied during settlement.
The offchain service generates merkle tree leaves with picodollars which are automatically converted to microdollars during settlement. Ideally, the rounding is part of the signature so offchain and onchain agree and are aware of this mechanism.
If conversion policy changes (e.g., ceil vs exact), the same signed report/root can produce different settled micro-dollar outcomes.
This creates an intent gap between offchain report generation and onchain settlement semantics.
Brainstorm
In case we want to support different scaling factors and activation minutes, we could do something like:
uint32 activation_ = RegistryParameters.getUint32Parameter(
parameterRegistry, "xmtp.payerReportManager.leafScalingActivationMinute"
);
uint96 feesSettled_ = _settleUsage(
digest_, payerFees_, (activation_ != 0 && payerReport_.endMinuteSinceEpoch >= activation_) ? _LEAF_FEE_SCALING_FACTOR : 1);
PayerReportManager uses EIP-712 signatures to guarantee a signature is valid for the current contract version.
The signed payer report commits to payersMerkleRoot (raw pico-dollar leaves), but does not commit to fee-conversion semantics applied during settlement.
The offchain service generates merkle tree leaves with picodollars which are automatically converted to microdollars during settlement. Ideally, the rounding is part of the signature so offchain and onchain agree and are aware of this mechanism.
If conversion policy changes (e.g., ceil vs exact), the same signed report/root can produce different settled micro-dollar outcomes.
This creates an intent gap between offchain report generation and onchain settlement semantics.
Brainstorm
In case we want to support different scaling factors and activation minutes, we could do something like: