Coupon Guidance interpretation: free traffic credit, 1.0 vs 1.15 tolerance, CIP-0104 finding, and shared reference implementation

Hi everyone,

We have started running our marker controls against live MainNet activity, and working through the Coupon Guidance against real transactions has raised a few points where we would appreciate clarification from the maintainers and community.

Rather than make assumptions in our automation, we would prefer to confirm the intended interpretation.

1. Free traffic credit in Rule 2

Rule 2 states that each Featured App is credited with 0.1 MB of traffic per round in addition to purchased traffic.

However, the reference BigQuery query calculates overage as:

(marker_weight + cc_transfers) / GREATEST(usd_spent, third_party_submitted)

As we read the query, usd_spent is derived from MemberTraffic purchases, and we could not find the 0.1 MB per-round free traffic credit represented in the calculation.

This can produce different results depending on whether the prose guidance or the reference query is followed.

There is also an edge case for an app whose traffic stays entirely within the free allowance. If grouped_burn contributes no row, usd_spent can be NULL, which in turn makes the overage result NULL rather than producing a measurable compliance ratio.

So our question is:

Should the 0.1 MB per-round free traffic credit be included when calculating Coupon-to-Fee alignment, even though it does not appear in the reference query, or should the reference query be treated as authoritative?

1. Is the intended ceiling 1.0 or 1.15?

Rule 2 says that maximum coupon reward weight should not exceed net qualifying on-chain fees, which we read as a 1.0 baseline.

The Precision Tolerance section separately states that variance within ±15% is acceptable by default.

We see two possible interpretations:

A) Activity up to 1.15x qualifying fees is considered within the permitted range.

B) 1.0x remains the actual ceiling, while the additional 15% is a measurement or precision tolerance around that baseline.

These interpretations produce materially different automation at scale.

We currently implement B, as the more conservative interpretation.

Could someone confirm which interpretation is intended?

It would also be useful to know whether the ±15% tolerance is intended primarily to accommodate timing, batching, rounding, and measurement differences, rather than to serve as a target operating range.

1. CIP-0104: providersWithWrongVettingState

Separately, while reviewing the CIP-0104 dry-run batches, we noticed an implementation detail around:

providersWithWrongVettingState

We traced this through RewardAccountingV2.daml and documented what the field appears to represent.

Based on our reading, it does not appear to affect current reward minting while:

mintingVersion = FeaturedAppMarkers

We have a short one-page write-up covering the path we traced, the behavior we observed, and why we reached that conclusion.

We would appreciate confirmation from someone familiar with this part of the implementation that our interpretation is correct. We are also happy to attach the full write-up to this thread.

1. Shared Rule 2/3/5 limiter and conformance test vectors

While implementing our own controls, we ended up building an internal limiter for Rules 2, 3, and 5 together with a set of test vectors for validating the arithmetic and edge cases.

We could not find a shared reference implementation of this logic outside of Splice itself and the relevant CIPs/guidance.

That raised a broader question:

Would a shared, conformance-tested implementation of the Featured App coupon arithmetic be useful to the ecosystem?

For example, this could provide:

• Rule 2 Coupon-to-Fee calculations
• Rule 3 checks
• Rule 5 checks
• free-traffic handling
• NULL / missing-data edge cases
• round and timing behavior
• precision/tolerance handling
• standard test vectors
• expected outputs

The goal would not be to create a new interpretation of the rules, but to encode the agreed interpretation in a reusable implementation with deterministic test cases.

If this is something the Foundation and community would find useful, we would be
interested in discussing the scope here and potentially submitting a Development Fund proposal through the public GitHub process.

If a reference implementation is already planned or this logic is expected to remain Foundation-maintained, we would instead be happy to contribute our test vectors and stop there rather than duplicate work.

One related practical question: is the Coupon Guidance considered public and quotable in a public GitHub pull request or Development Fund proposal?

A proper conformance proposal would likely need to quote or map individual rules to test cases, and we do not want to assume that is permitted.

Thanks in advance. We are mainly trying to make sure the automation reflects the intended rules exactly before we increase activity, and if the work we have already done can be useful more broadly, we would be happy to contribute it.

Thanks for the detailed write-up. Happy to share my understanding on each point.

1. Free traffic credit (Rule 2)

The free traffic allowance does exist — it accumulates up to a defined limit and is consumed first before purchased traffic. It’s visible directly in the node logs, and that’s how I track it — parsing the logs rather than relying on the BigQuery query for this. If the reference query doesn’t reflect it, the prose guidance would be the intended source of truth.

2. Ceiling: 1.0x or 1.15x?

The actual ceiling is 1.0x. The ±15% is the maximum tolerable deviation — not a target range — beyond which Featured App status may be affected. Your interpretation B is correct.

3. providersWithWrongVettingState

Based on my reading of the implementation, this field does not appear to affect reward minting while `mintingVersion = FeaturedAppMarkers`. I traced the path through `RewardAccountingV2.daml` and reached the same conclusion — but haven’t had this confirmed by the core team directly

4. Shared reference implementation

Personally, I think the idea is solid — shared test vectors would definitely help the ecosystem. That said, from where I sit, the timing feels off: with the network moving away from the coupon model toward traffic-based payment, a conformance implementation of the current arithmetic may have a short shelf life. Might be worth checking what’s coming first before investing in encoding the current rules.