Context
The original description referenced rate_num = 0 ambiguity from earlier design discussions. The current contract is now amount-quote based, not rate-quote based.
Today FPC.fee_entrypoint(...) verifies a signed payload containing:
accepted_assetfj_fee_amountaa_payment_amountvalid_untiluser_address
The contract does not currently expose a dedicated sponsored entrypoint.
Problem
Standard quoted payments and sponsorship are still conflated in the current contract semantics.
While the default attestation service config now requires positive pricing inputs, the contract itself does not enforce that aa_payment_amount > 0. If a signer intentionally or accidentally issues a valid quote with aa_payment_amount = 0, fee_entrypoint(...) can still succeed and FPC will pay Fee Juice. That means sponsorship is still possible through the standard quote path, with no explicit on-chain separation of intent or authorization model.
This is a contract-level policy and security clarity issue:
- paid quotes and sponsored quotes share the same entrypoint shape,
- paid vs sponsored intent is not domain-separated,
- sponsorship is not explicitly authorized on-chain as a distinct flow.
Goal
Introduce an explicit sponsorship path with separate authorization semantics, while keeping normal quoted fee payments strict and unambiguous.
Required changes
- Add a new dedicated private entrypoint in FPC for sponsored transactions (name TBD, e.g.
fee_entrypoint_sponsored).
- Keep standard
fee_entrypoint for paid quotes only.
- Define a separate authwit domain separator / payload schema for sponsorship quotes so they cannot be replayed as normal paid quotes.
- Include explicit sponsored intent fields in the signed payload (at minimum:
fpc_address, accepted_asset, valid_until, user_address, plus a sponsored marker).
- Add on-chain guards for the sponsored path (minimum one of):
- dedicated sponsor signer identity, or
- explicit allowlist check, or
- configurable per-window cap if stateful approach is accepted in follow-up.
- Ensure the standard paid path rejects sponsored-style payloads and preserves its existing payment semantics.
- Add tests to cover:
- sponsored happy path
- sponsored quote replay rejection in standard entrypoint
- standard quote replay rejection in sponsored entrypoint
- expired sponsored quote rejection
- unauthorized sponsor signature rejection
- zero-charge quote rejection in the standard paid entrypoint (directly or by construction)
- Update
docs/spec.md with a dedicated sponsorship section and threat model notes.
Files likely affected
contracts/fpc/src/main.nrcontracts/fpc/src/test/fee_entrypoint.nrdocs/spec.md- optional: attestation service docs/config if sponsorship signing is exposed there
Acceptance criteria
- Sponsorship is impossible through the standard paid quote path.
- Sponsored flow requires explicit sponsor authorization and cannot be confused with normal paid quotes.
- Paid vs sponsored payloads are domain-separated and non-replayable across entrypoints.
- Tests clearly demonstrate domain separation and replay resistance between paid vs sponsored paths.
- Spec documents exact quote/authwit schemas for both paths.
Validation
aztec test --package fpc- Add/execute targeted tests for domain-separation failures, signer authorization failures, and standard-path zero-charge rejection.
Non-goals
- No service-side sponsor API rollout in this issue unless required for contract test harness.
- No broad token-economics redesign.
Context
The original description referenced
rate_num = 0ambiguity from earlier design discussions. The current contract is now amount-quote based, not rate-quote based.Today
FPC.fee_entrypoint(...)verifies a signed payload containing:accepted_assetfj_fee_amountaa_payment_amountvalid_untiluser_addressThe contract does not currently expose a dedicated sponsored entrypoint.
Problem
Standard quoted payments and sponsorship are still conflated in the current contract semantics.
While the default attestation service config now requires positive pricing inputs, the contract itself does not enforce that
aa_payment_amount > 0. If a signer intentionally or accidentally issues a valid quote withaa_payment_amount = 0,fee_entrypoint(...)can still succeed and FPC will pay Fee Juice. That means sponsorship is still possible through the standard quote path, with no explicit on-chain separation of intent or authorization model.This is a contract-level policy and security clarity issue:
Goal
Introduce an explicit sponsorship path with separate authorization semantics, while keeping normal quoted fee payments strict and unambiguous.
Required changes
fee_entrypoint_sponsored).fee_entrypointfor paid quotes only.fpc_address,accepted_asset,valid_until,user_address, plus asponsoredmarker).docs/spec.mdwith a dedicated sponsorship section and threat model notes.Files likely affected
contracts/fpc/src/main.nrcontracts/fpc/src/test/fee_entrypoint.nrdocs/spec.mdAcceptance criteria
Validation
aztec test --package fpcNon-goals