Service Fabric

The Service Fabric release adds a per-service settlement layer on top of the lot-based contract. OEMs can now engage manufacturing partners for discrete services across the full product-development arc — EVT through Sustaining — and pay them automatically upon verified completion. Soulbound Service Validation Tokens (SVTs) accumulate as a portable factory quality credential.

What's new

Two contracts

Component	Location	Purpose
Service Fabric (types + functions)	contracts/fairfoundry/src/lib.rs	Service orders, oracle attestation, SVT minting, credit ledger
SVT Token Contract	contracts/fairfoundry-svt/	Non-transferable Service Validation Tokens (soulbound)

New data structures

• ServiceStage — EVT | DVT | PVT | MP | Sustaining. Tracks which development phase a service targets.
• ServiceRequest — description, stage, quantity, ERS version, acceptance criteria, required artifacts.
• CompletionAttestation — oracle signature, artifacts Merkle root, criteria met, report URI.
• ServiceOrder — full lifecycle tracking from Requested through Settled.
• OrderStatus — Requested → Accepted → Delivered → Validated → Settled, with Cancelled as the only off-path destination (pre-acceptance only).

New contract functions

Function	Caller	What it does
register_fairbuild_oracle	OEM	Registers the trusted FairBuild oracle address
create_service_order	OEM	Creates order, locks escrow for agreed price + OEM-side fee
accept_service_order	Factory	Factory commits to performing the service
submit_artifacts	Factory	Factory uploads deliverables (Merkle root of production images)
attest_completion	Oracle	Verifies artifacts, mints SVT, transitions to Validated
settle_service	Any	SVT triggers payment release (direct or credits)
redeem_credits	Factory	Converts accumulated credits to direct payment
cancel_service_order	OEM	Cancels pre-delivery orders, returns escrow

Plus six view functions for orders, credits, analytics, and SVTs.

The flow

1. OEM deposits escrow            → deposit_escrow(oem, amount)
2. OEM creates service order      → create_service_order(oem, id, request, price)
   (locks funds from escrow)
3. Factory accepts                → accept_service_order(factory, id)
4. Factory uploads artifacts      → submit_artifacts(factory, id, artifacts_root)
5. Oracle attests completion      → attest_completion(oracle, id, root, count, criteria, uri)
   (mints SVT, transitions to Validated)
6. SVT triggers settlement        → settle_service(id, as_credit)
   (direct payment or credits)
7. Factory redeems credits        → redeem_credits(factory, amount)
   (optional, if settled as credit)

Tests

52 tests pass (30 existing lot-based, zero regressions; 18 new service-fabric; 4 SVT contract). Full suite runs in 0.15 seconds. Both contracts compile cleanly for wasm32-unknown-unknown.

Service-fabric coverage breakdown:

• Happy path direct payment + happy path credit settlement
• Credit accumulation and redemption
• Order cancellation refund
• Multi-stage orders (EVT → MP)
• View/filter orders
• 5 negative tests on auth failures
• 3 negative tests on state-machine violations
• 2 negative tests on escrow/credit limits
• Conservation properties (escrow + credits + fees = total deposited)
• SVT monotonicity (SVT id strictly increasing)

Compatibility

Drop-in additive release. The lot-based pipeline (create_lot, qa_commit*, execute_payment) is unchanged; the Service Fabric runs alongside it on the same contract. OEMs and factories already using lots can continue without migration; new programs can adopt service orders directly.

Known follow-ups (closed in later releases)

• settle_service initially had no caller auth on the as_credit mode → closed in v0.4.1 (factory auth required for credit settlement).
• init was re-callable → closed in v0.4.1 (AlreadyInitialized guard).
• Dispute path had bypass vectors → closed in v0.4.1 (late-response and zero-bps slash now revert).

References

Source: github.com/fairb-dev/Fairfoundry. Architecture diagrams + the full contract API table are on the platform page. The technical narrative on what shipped is in the blog post The smart contract behind a 48-hour settlement.