FARPY / f / receipt immutability caching
Tone
Facts only. No promises. Receipts are truth.
Focus
This page is specifically about: receipt immutability caching.
If you were looking for interactive GPU rentals, custom scripts, or bespoke support, you’re in the wrong place.
What Farpy does
- Runs deterministic batch jobs using sealed engines.
- Returns outputs plus an immutable receipt when the job completes.
- Uses receipts as the sole authority for accounting and payouts.
What Farpy does not do
- No interactive sessions.
- No shells / scripts / plugins / add-ons.
- No custom environments or “install my dependency.”
- No receipt means the job failed (and is handled as a failure).
When to use this
| Use it when | Reason |
|---|---|
| You can package inputs upfront | Batch-first systems require complete inputs at submit time. |
| You want verifiable completion | Receipts provide an audit artifact you can store and re-check. |
| You want boring repeatability | Sealed engines + determinism reduce “it worked yesterday” drift. |
When not to use this
| Do not use when | Why |
|---|---|
| You need live tweaking / interactivity | Farpy is batch-only by design. |
| You need custom scripts or add-ons | User-supplied code is out of scope. |
| You need negotiated SLAs or manual overrides | Receipts and hard gates replace discretionary operations. |
Constraints that matter
| Constraint | Meaning |
|---|---|
| Batch only | No interactive sessions. You submit work; you receive outputs when done. |
| Receipt required | No receipt = failed. Receipts are the authority. |
| Sealed engines | Behavior is frozen; same input + same engine → same output. |
Signals
| Signal | Meaning |
|---|---|
| Batch-only | Work is submitted up front and finishes as a unit. |
| Receipt-authoritative | Outputs and payouts are recognized only when a receipt exists. |
| Sealed engine | Execution behavior is fixed; no user-supplied code paths. |
Receipt verification
Receipts are public, immutable artifacts. Verification is intentionally boring.
curl -fsS https://api.farpy.com/ezpz-receipts/RECEIPT/<RECEIPT>.json | jq .
Mini glossary
| Term | Meaning |
|---|---|
| Receipt | Immutable job record (inputs/outputs/hashes/cost/payout eligibility). |
| Deterministic | Same input + same sealed engine produces the same output. |
| NodeMuncher | A worker that pulls jobs, executes them, uploads outputs, and is paid only when a receipt verifies. |
FAQ
| Question | Answer |
|---|---|
| What is receipt immutability caching? | It is a batch-oriented framing of receipt immutability caching inside Farpy’s constraints: deterministic execution, sealed engines, output + receipt. |
| Can I run scripts or add-ons? | No. User code, plugins, and custom environments are out of scope. |
| Do I get paid / does work count without a receipt? | No. No receipt means the job is treated as failed. |