Skip to content

IFP-103.md

Latest commit

 

History

History
executable file
·
408 lines (241 loc) · 6.15 KB

IFP-103.md

File metadata and controls

executable file
·
408 lines (241 loc) · 6.15 KB
Raw

IFP-103

Inference Receipt Protocol

Status: Draft v1.0
Category: Intelligence Fabric Protocol

1. Purpose

This specification defines how inference execution is acknowledged, committed, and economically settled within the Intelligence Fabric Protocol (IFP).

It governs:

  • Receipt structure
  • Output commitment
  • Token and compute reporting
  • Operator authentication
  • Escrow settlement logic

This document defines Phase 2 of the inference lifecycle.

2. Conceptual Model

Inference lifecycle:

  1. SubmitPrompt → Escrow locked
  2. Off-chain execution
  3. SubmitReceipt → Settlement

Receipt is the cryptographic and economic bridge between off-chain execution and on-chain settlement.

3. SubmitReceipt Transaction

SubmitReceipt is a consensus-recognized transaction type defined in TET-004.

3.1 Canonical Payload

SubmitReceiptPayload = { prompt_tx_hash: Hash32, output_commitment: Hash32, input_tokens: u32, output_tokens: u32, compute_units: u64, operator_address: Address }

4. Field Definitions

4.1 prompt_tx_hash

References the original SubmitPrompt transaction.

Validation requires:

  • PromptEntry exists
  • PromptEntry.status == Pending
  • current_height ≤ deadline_height

4.2 output_commitment

Cryptographic commitment to generated output.

Defined as:

output_commitment = SHA256(output_bytes || salt)

Salt generated by operator or client agreement.

Output plaintext MUST NOT appear on-chain.

4.3 input_tokens

Number of input tokens processed.

Used for:

  • Fee calculation
  • Reporting
  • Analytics

4.4 output_tokens

Number of tokens generated.

Must satisfy:

output_tokens ≤ max_output_tokens from SubmitPrompt

4.5 compute_units

Abstract measure of compute usage.

Defined by governance as:

ComputeUnits = deterministic cost metric

Used for:

  • Market pricing
  • Hybrid pricing
  • Reporting

4.6 operator_address

Must match:

  • Registered inference operator (if required)
  • Valid cryptographic signature

5. Operator Signature

Receipt must be signed by:

operator_private_key

Signature must verify:

Ed25519_Verify(operator_pk, hash(receipt_payload), signature)

If signature invalid:

Transaction rejected.

6. Deterministic Settlement Rules

Upon valid receipt:

  1. Compute actual_fee F
  2. Ensure F ≤ escrow_amount
  3. Distribute F per revenue split
  4. Refund remainder to sender
  5. Mark PromptEntry.status = Settled

7. Fee Computation

Fee calculation depends on:

pricing_mode defined in SubmitPrompt.

7.1 Owner Pricing

F = base_price + α × input_tokens + β × output_tokens

Parameters defined in model metadata.

7.2 Market Pricing

F determined by:

  • Operator bid
  • Compute units reported
  • Market multiplier

Must remain ≤ escrow.

7.3 Hybrid Pricing

F = max(owner_minimum, market_bid)

8. Escrow Settlement

Let:

E = Escrow[prompt_tx_hash]

Upon settlement:

  • Deduct F from E
  • Route F to participants
  • Refund (E - F) to sender

Escrow entry then removed or marked closed.

9. Revenue Routing

Revenue split defined in model metadata:

S = { operator_bp, owner_bp, validator_bp, vault_bp }

Where sum(bp) = 10000.

Distribution:

operator_share = F × operator_bp / 10000 owner_share = F × owner_bp / 10000 validator_share = F × validator_bp / 10000 vault_share = F × vault_bp / 10000

All integer arithmetic with fixed rounding rules.

10. Rounding Rules

To ensure conservation:

Compute shares sequentially:

  1. operator_share
  2. owner_share
  3. validator_share
  4. vault_share = F - sum(previous)

Guarantees:

Sum(shares) = F

11. Receipt Validation Rules

SubmitReceipt must satisfy:

  • Prompt exists
  • Not expired
  • Not already settled
  • Operator authorized
  • output_tokens ≤ max_output_tokens
  • F ≤ escrow

Otherwise rejected.

12. Expiry Handling

If receipt submitted after:

current_height > deadline_height

Transaction rejected.

Escrow refunded per IFP-102 rules.

13. Fraud & Dispute Window

After receipt submission:

PromptEntry enters:

status = SettledPendingChallenge

For:

challenge_window_blocks

During this window:

  • Fraud proofs may be submitted
  • Settlement may be reverted if fraud proven

After window:

status = Finalized

14. Fraud Proof Model (Optional Extension)

Future versions may allow:

  • ZK proof of execution
  • Deterministic inference proofs
  • Commitment consistency proofs

Current version relies on economic incentives.

15. State Mutation

On valid receipt:

State transitions:

Escrow removed
Balances updated
PromptEntry.status updated
Receipt record stored in prunable ledger

All mutations must be atomic.

16. Determinism Requirements

Settlement must:

  • Use integer arithmetic only
  • Use canonical rounding
  • Produce identical state root on all nodes
  • Not depend on external computation

Receipt validation does NOT verify output correctness.

17. Invariants

After settlement:

  • Escrow fully accounted
  • PromptEntry not reusable
  • Revenue conserved
  • No negative balances

18. Security Model

Receipt protocol guarantees:

  • Operator accountability
  • Fee enforcement
  • Escrow safety
  • Deterministic revenue routing

It does NOT guarantee:

  • Output correctness
  • Model fairness
  • Output safety

19. Formal Definition

Let:

SR = SubmitReceipt(S, Tx)

If valid:

S' = distribute(F) refund(E - F) update(PromptEntry.status)

Else:

S' = S

20. Conclusion

IFP-103 defines:

  • Output commitment structure
  • Token usage reporting
  • Operator authentication
  • Deterministic settlement
  • Revenue distribution

It completes the economic inference cycle:

Commit → Execute → Receipt → Settle

This transforms inference into a protocol-native economic state transition.

End of IFP-103.