feat(payments): EventDriven per-job billing in the service's settlement asset (native or ERC20)

[drewstone]

Summary

Generalizes EventDriven per-job billing to settle in the service's developer-declared settlement asset — native OR a manager-allowed ERC20 (e.g. Tempo's PathUSD) — instead of a native-msg.value-only hardcode. This unblocks paid jobs on chains that forbid native value transfers (Tempo bans them at the VM level), while keeping native byte-identical on Tangle L1s.

Why

PaymentLib.collectPayment already handles both native and hardened ERC20 (fee-on-transfer rejection, msgValue==0 enforced); requestService/escrow already carry a paymentToken. Only the EventDriven per-job path hardcoded address(0), and one rule forbade a token — so pay-per-job services could not exist on a value-banning chain. This is a consistency fix reusing audited primitives, not new payment machinery.

Design (the key safety decision)

The settlement asset is chosen by the developer at the blueprint level (_blueprintSettlementAsset[blueprintId], owner-gated setBlueprintSettlementAsset, allow-list-validated), and pinned to the service at activation — never chosen by the customer. This binds the asset and the per-job rate to the same party in the same units, so a decimal/asset mismatch is structurally impossible. Rate is denominated in the settlement asset's smallest unit (documented on the setter/view).

Security process — two adversarial-review rounds

• Round 1 found a real HIGH: v1 pinned the asset from the customer's request while the rate is per-blueprint → a customer could request native against a 6-dec PathUSD rate and settle every job at ~1e-12× the intended price (10^12× underpayment), with the base BSM unable to deny native.
• Fix: moved asset choice to the developer/blueprint, pinned at activation, re-closed requestService for EventDriven (customer token must be address(0)), and closed a second live path — quote-created services (createServiceFromQuotes) also never pinned the asset.
• Round 2: merge_safe: true, zero confirmed issues across collect-vs-distribute asset consistency, storage-append safety, fail-closed asset authorization (4 layers), reentrancy/CEI (global OZ guard holds across the new ERC20 callbacks; pull-pattern payouts), and native back-compat.

Verification

• New suite EventDrivenErc20Settlement.t.sol 26/26, incl. the explicit exploit test test_Exploit_SixDecimalRateCannotSettleInNative (no path lets a service settle in an asset other than its blueprint's declared one), customer-cannot-choose, ERC20-settles-via-transferFrom, native back-compat, pin-at-activation immutability, quote-path pin, setter auth/validation.
• Regression: tangle 383/383, audit 232/232, staking 266/266, security (incl. StorageLayoutSnapshot) 45/45, blueprints 97/97, scenario 10/10, Integration/E2E/subscription all green.
• Storage append-only: _serviceEventDrivenAsset@90, _blueprintSettlementAsset@91, __gap 27→25, tail pins (88/89) byte-identical to main — StorageLayoutSnapshotTest 3/3.
• FacetSize/Tempo-cap 3/3 under the optimized profile (touched facets stay < 21,500 B).
• Rust bindings regenerated (getBlueprintSettlementAsset/setBlueprintSettlementAsset/getServicePaymentAsset + event).

Rollback / compat

Default asset is address(0) (native) — a blueprint that never sets an asset behaves exactly as before. Revertable by dropping the branch.

Known minor (non-blocking, flagged for the reviewer)

• Dead code: TangleJobsRFQFacet._distributeRFQJobPayment still passes address(0) — proven unreachable (no result selector on that facet); delete for hygiene.
• LOW liveness (not security, fail-closed): setBlueprintSettlementAsset validates the asset with blueprintId context but collection re-checks with serviceId context; a manager returning different answers per context could brick billing (reverts, no theft). Optional: validate with serviceId context at activation for consistency.
• Decimals are the developer's responsibility (rate denominated in the settlement asset) — documented, and now un-exploitable since the same party sets asset + rate.

[tangletools]

✅ Auto-approved drewstone PR — e819cdca

This PR was opened by the trusted drewstone account.
The full PR reviewer audit still runs separately and will publish findings if it detects issues.

_{tangletools · auto-approval · reason: drewstone_author · 2026-07-09T04:12:28Z}

[tangletools]

🟡 Value Audit — sound-with-nits

Verdict	sound-with-nits
Concerns	2 (1 low, 1 weak-concern)
Heuristic	0.2s
Duplication	0.0s
Interrogation	227.6s (2 bridge agents)
Total	227.8s

💰 Value — sound

Generalizes EventDriven per-job billing to settle in the blueprint developer's chosen asset (native or manager-allowed ERC20), pinning it at service activation so a 6-decimal rate can never be under-paid in native; it reuses existing token-agnostic payment primitives and closes the only gap that sti

• What it does: Adds blueprint-level settlement-asset declaration (setBlueprintSettlementAsset in src/core/BlueprintsManage.sol:324) and pins it per-service at activation (src/facets/tangle/TangleServicesFacet.sol:199 and src/core/QuotesCreate.sol:245). The per-job collection path (src/core/JobsSubmission.sol:181) and RFQ job path (src/core/JobsRFQ.sol:97) then read the pinned `_serviceEventDrivenAsse
• Goals it achieves: Enables paid EventDriven jobs on chains that forbid native value transfers (e.g., Tempo) while keeping native behavior byte-identical on Tangle L1; brings EventDriven pricing in line with Subscription/PayOnce, which already carry a paymentToken and use PaymentLib/distributePayment; prevents a decimal/asset mismatch exploit where a 6-decimal ERC20 rate settles in native for a ~1e12x underpaym
• Assessment: Good. The architecture binds the asset and rate to the same party (the blueprint developer), pins the asset at activation so live services are not re-priced, and re-checks the manager allow-list at job time (fail-closed). It touches every path that can create or bill an EventDriven service: request/approve, quote-create, regular job submission, RFQ jobs, and aggregated-result submission. It reuses
• Better / existing approach: none — this is the right approach. I searched for existing generic settlement-asset storage (grep -R "paymentToken\|collectPayment\|distributePayment" src/) and confirmed PaymentLib.collectPayment already handles both native and ERC20 with fee-on-transfer rejection, distributePayment (src/facets/tangle/TanglePaymentsDistributionFacet.sol:34) already takes a token address, and `_isPaymentAs
• Model: opencode/kimi-for-coding/k2p7
• Bridge attempts: 1

🎯 Usefulness — sound-with-nits

A clean, well-tested consistency fix that generalizes EventDriven per-job billing to a developer-declared settlement asset (native OR ERC20), correctly reusing audited primitives and wiring into every reachable collection/distribution/activation path; only blemish is one stale unreachable override l

• Integration: Fully wired and reachable through all standard flows. The new storage (_serviceEventDrivenAsset / _blueprintSettlementAsset) is pinned at activation on BOTH creation paths — request/approve (TangleServicesFacet.sol:201) and quote-create (QuotesCreate.sol:240-243) — read by both collection sites (JobsSubmission.sol:178-193, JobsRFQ.sol:97-104), and threaded through all FOUR live distribution overri
• Fit with existing patterns: Excellent fit — does not compete with anything. It reuses the EXISTING PaymentLib.collectPayment (src/libraries/PaymentLib.sol:208-246), which already handled native AND hardened ERC20 (msgValue==0 enforced, fee-on-transfer/rebasing tokens rejected at ingress via balance-delta), and the EXISTING distributePayment(token,...) self-call (TanglePaymentsDistributionFacet.sol:34). Subscription and PayOn
• Real-world viability: Holds up well off the happy path. An 820-line test (test/tangle/EventDrivenErc20Settlement.t.sol) covers: ERC20 happy collection+distribution, native back-compat, no-approval revert, native-value-on-ERC20 revert, manager de-list at settle time (fail-closed), the customer-can't-choose-asset exploit, quote-created services pinning the asset, RFQ quote redemption in ERC20, and live-service-not-repric
• Model: opencode/zai-coding-plan/glm-5.2
• Bridge attempts: 1

🔎 Heuristic Signals

🟡 Cruft: magic number added test/tangle/EventDrivenErc20Settlement.t.sol

•    assertEq(tangle.getServicePaymentAsset(9999), address(0));
  

🎯 Usefulness Audit

🟡 Stale address(0) in TangleJobsRFQFacet._distributeRFQJobPayment is unreachable but now inconsistent with its live siblings [integration] ``

TangleJobsRFQFacet.sol:36 still calls distributePayment(..., address(0), ...) while the two live overrides (TangleJobsFacet.sol:52, TangleJobsAggregationFacet.sol:48) were updated to use _serviceEventDrivenAsset[serviceId]. I traced the dispatch: distribution fires only from _maybeFinalizeJob (JobsSubmission.sol:342) and the aggregation equivalent (JobsAggregation.sol:145), both reached via result-submission selectors owned by the Jobs/Aggregation facets — so the RFQ facet's override can NEVER e

---

What this audit checks

It judges the change on its merits — not whether it was tasked out in an issue. Unticketed, fast-moving work is fine; the question is whether the change is good and whether a better or existing approach should be used instead.

Pass	What it asks
Heuristic	Vague title? Whitespace-only or cruft-bearing diff? (content signals only)
Duplication	Do added function/class names already exist elsewhere in the repo?
Value Audit	What does it do? What goal does it achieve? Is it good? Better architecture or already-exists?
Usefulness Audit	Does it integrate and fit? Will it hold up in real use and actually get used?

Findings are concerns, not blocks — the human reviewer decides what to do with them.

_{value-audit · 20260709T041814Z}