InferLane Exchange — Terms of Service (Marketplace Amendment)

Drafted + reviewed by Claude. This amendment supplements the
base InferLane TERMS_OF_SERVICE.md with marketplace-specific
provisions for InferLane Exchange (the three-sided marketplace
where buyers post software-engineering tasks, operators execute
them, and arbiters render attestations).

Where this amendment is silent, the base TOS controls. Where it
conflicts, this amendment controls for marketplace activities only.

1. What InferLane Exchange is, and isn't

InferLane Exchange is a facilitating marketplace. We:

Match buyers with operators who can do specific software work;
Hold escrow via Stripe (the regulated processor) for the duration

of each task;

Match independent arbiters to render attestations on operator

submissions;

Aggregate arbiter attestations via Schelling-point voting;
Settle by debiting escrow and crediting operator + arbiter

payouts when the buyer-decision window resolves.

We do not:

Employ operators or arbiters (they are independent contractors —

see EXCHANGE_OPERATOR_AGREEMENT.md §2 and EXCHANGE_ARBITER_AGREEMENT.md §5);

Custody funds in platform-controlled bank accounts during a

task's lifecycle (Stripe holds them — LEGAL-PERIMETER.md §4);

Render quality verdicts on operator work (arbiters render

opinions; we aggregate — LEGAL-PERIMETER.md §1);

Warrant the merchantability or fitness-for-purpose of any

operator submission;

Provide legal, tax, or accounting advice to any party.

2. Roles + accounts

You may use InferLane Exchange as one or more of:

Buyer: post + fund tasks, accept applications, approve / reject

attested submissions. No additional registration beyond a base InferLane account.

Operator: register via POST /api/exchange/operators, accept

the Operator Agreement, post collateral as required.

Arbiter: register via POST /api/exchange/arbiters, accept the

Arbiter Agreement, post the required bond.

The same individual may register in multiple roles; the marketplace prevents role conflicts on a per-task basis (e.g. buyer cannot apply to their own task; arbiter pool excludes the operator who submitted).

3. Acceptable use

In addition to the base TOS Acceptable Use Policy, the following marketplace-specific rules apply:

Repository targeting: tasks may target only public OSS

repositories that are not on the marketplace's denylist and whose maintainers have not opted out (see MarketplaceMaintainerOptout registry).

Buyer ownership: where you post a task targeting a repository

you do not own, you warrant that the operator's submission will be offered to maintainers as a contribution (PR), not pushed unilaterally; maintainers are free to reject.

CLA compliance: tasks targeting CLA-required repositories

require operator pre-flight confirmation that they have signed the applicable CLA.

Per-repo rate limit: maximum 5 active tasks per buyer per

target repository per 30-day window (default; raised on per-buyer basis after maintainer relationship is established).

Anti-sybil: each buyer/operator/arbiter account is tied to a

Stripe-verified identity (KYC for high-bounty tasks).

No collusion: operators and arbiters may not communicate about

pending submissions; see EXCHANGE_ARBITER_AGREEMENT.md §3.

4. Escrow + settlement

Funding: buyer funds escrow at task creation. Total escrow =

bounty + (1 + maxRotations) × N × attestationFee + disputeReserve + Stripe processing fee.

Custody: funds remain with Stripe (the regulated processor)

throughout the task lifecycle. The marketplace records ledger entries (BUYER_DEPOSIT, WORKLOAD_COMMIT, WORKLOAD_COMPLETE) but does not transfer funds to platform-controlled accounts during the lifecycle.

Settlement triggers:

- Buyer approves the attested submission within autoApproveAfterAttestationHours (default 48h) → standard payout cascade; - Buyer-decision window expires silently → auto-approve sweep fires the same payout cascade; - Buyer rejects within the window → dispute opened, funds frozen until dispute resolves.

Decoupled from merge: settlement is independent of whether

the buyer subsequently merges the operator's PR. Buyers pay for verified work product, not for application of work (LEGAL-PERIMETER.md §8.6).

5. Disputes

Buyers who reject attested submissions file a structured dispute via the marketplace. The dispute opens with a buyer statement; operators have 72 hours to file a counter-statement; if both statements are present (or operator goes silent past deadline), the dispute moves to admin review. Phase 1 admin resolves with outcome=buyer (full refund + collateral release) or outcome=operator (standard settlement). Phase 1.5 will introduce proportional outcome=split.

You may not file disputes in bad faith. Repeated bad-faith disputes (established by admin pattern review) result in account suspension.

6. Fees

Platform fee: 10% of bounty, withheld at settlement from the

operator's payout.

Attestation fee: $10/arbiter (default; buyer can choose). Paid

to majority arbiters at settlement; minority forfeits.

Dispute reserve: $5 per task (default; refunded to buyer at

successful settlement; consumed if dispute resolution requires).

Stripe processing: absorbed by the platform from the bounty

margin in Phase 1; Phase 1.5 may pass through.

The fee structure is locked in commercial/DECISIONS.md and changes require notice per §10.

7. Privacy

In addition to the base Privacy Policy, marketplace-specific data includes:

Task metadata (title, description, repo URL, rubric, bounty) —

retained per buyer request, default 7 years post-settlement;

Submission diffs (PR URLs or diff blobs) — retained 30 days

post-settlement, then archived to operator's account only;

Attestation records (per-arbiter scores + reasoning) — retained

7 years for dispute audit;

Dispute evidence (statements, screenshots) — retained 7 years.

8. Intellectual property — marketplace position

The marketplace claims no intellectual property rights in:

The tasks buyers post;
The work operators submit;
The attestations arbiters render.

Operators warrant clear IP per EXCHANGE_OPERATOR_AGREEMENT.md §5; buyers warrant authority to post per §3 of this document.

9. Disclaimer of warranties

To the maximum extent permitted by law, InferLane provides the marketplace "as is" and disclaims all express and implied warranties including merchantability, fitness for purpose, and non-infringement. Operators' work product carries no marketplace warranty; the buyer's recourse for bad work is the attestation + dispute process.

10. Changes to these Terms

Same as base TOS — 30 days' notice via in-app + email; continued use = acceptance; close account to opt out.

11. Governing law + dispute resolution

Same as base TOS (Australian seat, ACICA arbitration, class waiver).

12. Compute mode amendments (Phase 1.5)

Sections 1-11 above govern the Tasks service mode of InferLane Exchange (bespoke discrete work with days-long lifecycle: post → apply → accept → submit → vote → resolve). This §12 governs the Compute service mode (per-call verified API access with sub-second lifecycle: register → invoke → debit → audit).

Compute is a distinct service mode operating under the same marketplace, the same KYC, the same arbiter pool, the same Acceptable Use Policy, the same Governing Law (§11), and the same Privacy posture (§7) as Tasks. Where Compute-specific provisions below conflict with §§1-11, the Compute provisions control for Compute invocations only.

12.1 What Compute is

Compute lets buyers invoke verified per-call API access to compute providers (including Exchange-operated "anchor providers" wrapping upstream APIs like Anthropic Claude, Voyage AI, and equivalents). Every invocation:

Routes to one or more providers in single / replicated / attested

execution modes (defined in commercial/PHASE_1_5_COMPUTE_DESIGN.md §2.1);

Is verified via the AI-tiered audit pipeline (L1 structural →

L2 semantic → L3 human Schelling vote) on a statistical basis (1-in-100 to 1-in-100,000 sampling rate by provider reputation; see commercial/COMPUTE_TRUST_POSTURE.md §4);

Returns to the buyer the provider output plus a verifiable receipt

documenting provider id, cost, audit tier, audit outcome, and (for attested mode) cryptographic attestation proof.

We do not in Compute mode:

Guarantee any specific provider's output quality (the verification

mechanism, not the provider, is what we offer);

Custody buyer funds (held in the buyer's prepaid wallet, processed

via Stripe);

Warrant that anchor providers' upstream services (Anthropic Claude,

Voyage AI, etc.) will be continuously available at any specific latency or quality level. Those providers' own service terms govern their availability;

Render verdicts on whether a buyer's chosen use of Compute output

is appropriate for their downstream context.

12.2 Roles + accounts

You may use Compute as:

Compute Buyer: invoke calls against your prepaid wallet. No

additional registration beyond a base InferLane account with KYC at the same thresholds as Tasks (per COMPUTE_PRICING.md §6).

Compute Provider: register via POST /api/exchange/compute/providers,

accept the Operator Agreement including its §13 Compute Provider extensions, post the required bond per provider status tier (see COMPUTE_TRUST_POSTURE.md §2).

Arbiter: same as Tasks. Arbiters in the existing pool serve

both Tasks attestation and Compute L3 audit assignments.

The same individual may register in multiple roles; the marketplace prevents role conflicts on a per-invocation basis (e.g. a Compute Provider cannot serve invocations they invoked themselves).

12.3 Prepaid wallet + settlement

Funding: Compute buyers fund a prepaid wallet via Stripe

(one-shot top-up or auto-top-up on threshold). All wallet activity records to the MarketplaceWalletTransaction ledger; buyers can audit the full ledger at any time.

Custody: wallet funds are held by Stripe (the regulated

processor) during the period between top-up and invocation debit. The marketplace records ledger entries but does not transfer buyer funds to platform-controlled accounts during normal operation. This preserves the same non-custody posture as Tasks (LEGAL-PERIMETER.md §4).

Per-invocation hold: each compute.invoke call holds the

maximum possible cost in the wallet at request time; debits the actual cost at invocation completion; releases any remainder back to wallet balance.

Refund on failure: per COMPUTE_PRICING.md §9, buyers are

charged $0 when an invocation fails for any reason (provider error, L1/L2/L3 audit failure). The hold is released back to the wallet.

Withdrawal: buyers may withdraw unused wallet balance back to

their Stripe payment method at any time, subject to a 30-day cooling-off window for chargeback compliance.

12.4 Pricing

The locked Compute pricing model is documented in commercial/COMPUTE_PRICING.md and commercial/DECISIONS.md §3 (extended). At launch:

Tier curve: 3% / 2% / 1.5% / 1% platform fee by 30-day spend

threshold (starter / growth / scale / enterprise tiers);

Per-call fixed: $0.0001 USD per invocation regardless of tier;
Replicated mode: always 4% platform fee + N× provider cost;
Attested mode: always 5% platform fee + provider TEE-tier cost;
Free tier: first $10/month of Compute spend per buyer wallet

is free, resetting at month-end;

Cache hits: cached output (identical input hash within cache

TTL) is returned at provider cost only; no platform fee on cache hits.

Pricing is locked for 12 months from Phase 1.5 launch per COMPUTE_PRICING.md §14; changes require notice per §10 of this TOS.

12.5 Audit mechanism + receipts

Every Compute invocation produces a verifiable receipt including provider id, cost breakdown, audit tier, audit outcome, and (for attested mode) cryptographic attestation proof. The receipt is returned with the invocation response and is independently queryable via compute.audit_history and the public REST /api/exchange/compute/audits endpoint.

Statistical spot-audit is performed on 1-in-N invocations per provider reputation tier; the AI-tiered pipeline (L1 structural → L2 semantic → L3 human) is the verification mechanism. Buyers acknowledge that:

(a) The verification commitment is statistical, not per-call. A

receipt indicating auditOutcome: "deferred" means the invocation was not selected for audit; the verification commitment is the provider's bond + the spot-audit sampling, not per-call human review.

(b) Buyers may request immediate human L3 audit on any specific

invocation via compute.audit_request at buyer cost ($9), refunded if the audit upholds a failure.

cryptographic per-call attestation; receipts in attested mode carry independently verifiable attestation proofs.

12.6 Disputes for Compute invocations

If a Compute buyer believes a verified output was actually wrong (L1/L2 audit said pass or invocation was not audited; buyer disagrees), they may file a dispute via compute.audit_request or via the Compute dispute endpoint. Disputes:

Cost $5 buyer-paid filing fee (refunded on buyer-wins outcome);
Are resolved by arbiter Schelling vote, reusing the existing

Tasks-side arbiter pool and dispute infrastructure;

Resolve in 7 days from filing (target SLA);
Result in full refund + provider bond slash on buyer-wins, or no

change on operator-wins;

Are limited to a maximum 10 active per buyer at any time.

Bad-faith Compute disputes — as established by admin pattern review or arbiter consensus — result in escalating consequences per COMPUTE_TRUST_POSTURE.md §11.5, up to and including account suspension.

12.7 Provider obligations + bond

Compute Providers (including operator-registered third parties) agree to the bond + slashing posture documented in commercial/COMPUTE_TRUST_POSTURE.md. The marketplace's right to slash a provider's bond, suspend a provider's account, or otherwise enforce provider obligations is governed by §13 of the Operator Agreement (which §12 of this TOS incorporates by reference for Compute Providers).

12.8 Anchor providers

Anchor providers operated by InferLane (e.g. il-anchor-claude, il-anchor-haiku, il-anchor-voyage) wrap upstream third-party APIs. Buyer invocations routed to anchor providers are subject to:

(a) The upstream provider's own service terms and acceptable use

policy (e.g. Anthropic Acceptable Use Policy applies to all invocations routed to anchor-Claude/anchor-Haiku).

(b) Pass-through of any upstream provider's service degradation,

outage, or rate limit. We will route to a fallback anchor where available; where no fallback exists for the requested task type, the invocation may fail with full refund.

COMPUTE_PRICING.md §4), funding anchor infrastructure + free-tier subsidy + cold-start subsidy for third-party providers.

12.9 Output ownership

The marketplace claims no intellectual property rights in:

The inputs Compute buyers submit;
The outputs Compute providers return;
The receipts produced for any invocation.

Compute Providers warrant clear IP per Operator Agreement §5 and §13 (which extends the IP warranty to Compute mode). Buyers warrant they have rights to the inputs they submit.

12.10 Compute privacy + retention

Beyond the base Privacy provisions in §7:

Input data: retained only for the duration of the invocation

plus 30 days for dispute resolution. Cryptographically hashed (SHA-256 of canonicalised input) for cache lookup; the hash is retained per the standard 7-year audit-log policy, but the underlying input data is purged after the 30-day window.

Output data: retained 30 days post-invocation for buyer

re-fetch + dispute resolution; archived to buyer's wallet history only after the 30-day window. Cryptographic hash (SHA-256 of returned output) retained per 7-year audit-log policy.

Attestation proofs (attested mode): retained 7 years (audit

log retention); the cryptographic proof is small and independently verifiable, so retention is low-cost.

Spot-audit records: retained 7 years for transparency-report

generation + dispute audit.

Providers' data-handling obligations are documented in Operator Agreement §13.5 and ACCEPTABLE_USE_POLICY.md §10.

12.11 Compute disclaimer of warranties

In addition to §9 above, for Compute invocations:

The marketplace makes no warranty as to specific anchor

provider's continued availability, performance, or quality. Anchor providers are wrappers around third-party services subject to those services' own SLAs.

The marketplace makes no warranty as to specific third-party

Compute Providers beyond the bond + audit mechanism. The bond + spot-audit + reputation curve is the warranty.

The marketplace makes no warranty that the AI audit pipeline

(L1/L2) will catch every quality failure. Statistical sampling has inherent gaps; buyers requiring per-call human verification must use compute.audit_request at additional cost or attested mode where appropriate.

Buyers explicitly acknowledge that the verification commitment is

the mechanism (consensus + bond + spot-audit + attestation), not the underlying provider output.

12.13 Third-party Compute Provider settlement (Phase 1.5.1)

Compute invocations may route to either anchor providers (InferLane-operated; §12.8 governs) or third-party providers (independent contractors using Stripe Connect Express, admitted via the Phase 1.5.1 application + founder eligibility check). For third-party invocations, the following additional terms apply:

Per-invocation Stripe Transfer (not daily-batched) at $0.50

minimum invocation cost. Invocations below the threshold may be declined or delayed-settled.

Audit-failure clawback: outputs verdicted as L1/L2/L3 audit

failure (per COMPUTE_TRUST_POSTURE.md objective criteria) result in (i) full buyer refund to wallet, (ii) Stripe Transfer reversal + negative-accrual against the provider's NEXT settlement.

30-day MAX hold envelope: no settlement persists in any

non-terminal state more than 30 days from RESERVED. At day 30, the buyer is refunded regardless of dispute state. Backstop per LEGAL-PERIMETER.md §4.3.

Chargeback handling: per LEGAL-PERIMETER.md §7 +

EXCHANGE_OPERATOR_AGREEMENT.md §13.13(f). Buyer chargeback refunds the buyer via Stripe; loss recovery from provider is via reversal + negative-accrual + (if necessary) deficit applied against future earnings.

Disputed auto-resolve threshold: $5. Invocations ≤ $5 that

the provider does not respond to within 30 days auto-resolve provider-favorable (deters Sybil-grief patterns). Invocations > $5 require manual founder review.

The full Compute-mode refund mechanics are documented in commercial/legal/REFUND_POLICY.md §1.5. The settlement state machine + timing windows are documented in commercial/legal/SETTLEMENT_TIMING_POLICY.md. The operative legal posture for all settlement custody questions is commercial/LEGAL-PERIMETER.md §4.

By using Compute, buyers acknowledge these third-party settlement mechanics. The wallet top-up modal surfaces a one-line summary linking to REFUND_POLICY.md §1.5.

12.12 Changes to Compute Terms

Same notice provisions as §10 above apply to Compute amendments. The pricing model (§12.4) is additionally locked for 12 months from Phase 1.5 launch per COMPUTE_PRICING.md §14; changes outside review-trigger conditions require a DECISIONS-level reversal and 30-day advance notice.

Drafting note — re-review triggers:

- §1 facilitating-marketplace framing — re-review on regulatory
developments that change platform-liability posture (DSA in EU,
any US federal platform-liability legislation that succeeds
§230 reform).
- §4 escrow + custody — re-review when CA-originated revenue
crosses $10K/mo (money-transmitter threshold trigger in
LEGAL-PERIMETER.md §4.1) or when any state passes a marketplace-
specific custody rule.
- §6 fees — re-review on changes to platform-fee structure or
if a regulator opens a fees-disclosure inquiry.
- §9 disclaimer of warranties — re-review on AU Consumer Law
§54-58 jurisprudence developments + EU Sale of Goods directive
amendments that affect B2B-platform disclaimers.
- §12.3 prepaid wallet — re-review when monthly wallet float
crosses $100K (Stripe Connect aggregate-balance thresholds) or
when any state passes a prepaid-balance-specific rule (e.g.
abandoned-property statute changes).
- §12.5 audit mechanism — re-review on each material change to
the Compute audit pipeline (L1/L2 prompt revisions, audit-tier
ratio changes), tracked in COMPUTE_TRUST_POSTURE.md §7.4.
- §12.8 anchor providers — re-review on each material change to
upstream provider service terms (Anthropic, Voyage, OpenAI),
set a quarterly Claude review.
- §12.10 Compute privacy + retention — re-review on EU AI Act
Article 6 / Article 26 obligations as applied to high-volume
compute marketplaces, GDPR developments affecting hash-based
pseudonymization, or any addition of EU jurisdiction support.
- §12.11 disclaimer — re-review on AU Consumer Law §54-58
jurisprudence (same trigger as §9) and on each material change
to the bond + slashing mechanism.