Contributed compute
Lend your CPU to other people's computations and be paid in ZEQ coin — one coin per CPU-hour supplied, settled every hour from the issuer's 95% contributors' budget (ECON v5).
To take network jobs you bond 1,000 envelopes. Bonding is not a deposit: the envelopes stay in your vault, owned by you, for the whole time. Bonding marks them immovable and records an attestation naming exactly which ones.
There is no pool. Nothing is transferred to the Foundation, there is no escrow, and releasing your bond is a state change rather than a withdrawal — there is nothing to withdraw from.
Read the rules before you join
curl https://zeqsdk.com/api/contribute/policy
Open, unauthenticated, on every node. You should be able to read exactly what is required, what it secures and what you lose if you cheat before deciding to stake anything — and an SDK needs these numbers to render a staking screen before the user has signed in.
What 1,000 envelopes costs you
About 1,000 Zeqonds of compute — a quarter of the free hour — and the framework tells you exactly how much.
| free hour | one compute-hour every 30 days (ECON v5; no daily claim, no welcome grant) |
| contributor pay | one ZEQ coin per CPU-hour supplied (1/4,633.2 coin per Zeqond), from the 95% budget |
| time to earn a Starter cycle | ≈ 9.8 CPU-hours of reproduced compute — the 9.764 h a $29 seat bonds, since 1 coin = 1 hour |
| what a coin becomes | 1 hour of compute by burning (POST /api/credits/from-coin), or a cycle bond (bond_tier) |
No payment is required to join the network: the bond is 1,000 envelopes, one per charged compute, and the cheapest compute costs one Zeqond — about 13 minutes of the free hour (4,633.2 Zeqonds every 30 days). A sybil farm, by contrast, needs one identity per bond, each behind a Landauer proof-of-work at registration and each limited to one free hour per 30 days. That is the balance: reachable by one real person in an afternoon, expensive to fake in bulk.
Every computation mints exactly one envelope, with face value equal to what the computation cost — 1:1, no multiplier.
What the bond secures
A contributor who fabricates a result gains the job's value V and risks the
bond B. Cheating must not pay:
(1 − p)·V − p·B < 0 ⟺ p > V / (V + B)
The audit rate is set just above that infimum, because at it the expected value of cheating is exactly zero — indifferent, not deterred:
p = clamp( (1 + 0.1)·V / (V + B), 0.001, 1 )
| job | value (× the cheapest job, V₀ = 1 Zeqond) | audit rate | jobs before expected detection |
|---|---|---|---|
| minimal | 1 | 0.110 % | 910 |
| typical (3 operators) | 2 | 0.220 % | 455 |
| heavy (10 operators) | 4.3 | 0.475 % | 211 |
Detection is never slower than earning the bond honestly. 910 minimal jobs cost 910 Zeqonds of compute, against 1,000 Zeqonds to stake the bond legitimately — so faking results is never the quicker way in. Both clocks run in the same unit, the Zeqond the free hour is metered in.
Two rules that bite
You cannot contribute and experiment at the same time. Switching to contributing preempts your own running work. The two states cannot both be true, which is what stops one machine selling the same cycles twice.
A proven wrong result withholds the whole bond. "Proven" is doing real work
in that sentence: the Foundation's own independent re-execution must disagree
with you and agree with the challenger. If it matches neither, the job is
not_reproducible and nobody is slashed.
The whole bond, rather than a fraction, because deterrence needs p·B > (1−p)·V
— at these rates the bond must be roughly 1000× a job's value, so withholding
only the job's value would make cheating profitable by construction. There is no
partial slash that works.
Endpoints
GET /api/contribute/policy
Open. The constants, the derivation and the current numbers.
{
"bond": { "envelopes": 1000, "held_not_pooled": true },
"fairness": { "note": "ECON v5: one free compute-hour every 30 days; hours bought from the Foundation at $2.97/h; coins only earned" },
"cpu_share": { "coin_per_cpu_hour": 1, "zeqonds_per_hour": 4633.2, "job_cap_zeqonds": 60, "foundation_share": 0 },
"audit": { "formula": "p = clamp((1 + margin) * V / (V + B), floor, 1)", "margin": 0.1 },
"slashing": { "fraction_of_bond": 1 },
"exclusion": { "rule": "experimenting XOR contributing" }
}
GET /api/contribute/status
Your bond: how many held, how many still needed, what is at risk, and — if you are short — how many more envelopes (charged computes) it takes.
POST /api/contribute/bond
curl -X POST https://zeqsdk.com/api/contribute/bond \
-H 'Authorization: Bearer <key>' -H 'Content-Type: application/json' \
-d '{"envelopes": 1000}'
Marks that many of your movable envelopes immovable, in place. issued_to
is untouched: after bonding they are still yours and the vault still lists them
as yours, because they are. Returns an attestation naming the set.
Returns 409 BOND_INSUFFICIENT_ENVELOPES if you do not hold enough yet —
not a 400, because the request is well-formed and you are not at fault. The
response says how many more, so a UI can show
progress rather than an error.
POST /api/contribute/release
Marks them movable again. You stop being eligible for network jobs.
POST /api/contribute/mode
idle · contributing · experimenting. Requesting contributing without a
satisfied bond returns 409 BOND_REQUIRED — with nothing at risk no audit
rate deters, so the seat would be worthless to the network and free to abuse.
In the Vault
Vault → Network shows your bond, what is at risk, how far you have to go, and the rules you are agreeing to, with buttons to bond and release.
Why holding beats pooling
The obvious design is a staking pool. It is worse here, for three reasons beyond the owner's own ("it doesn't make sense"):
- a pool is a custody problem the framework does not otherwise have;
- a pool makes every contributor's stake fungible with every other's, so slashing one means arguing about whose share was destroyed;
- a pool needs its own accounting, reconciliation and failure modes.
Holding needs strictly less machinery: movable already exists on every
token row and already defaults to false. And because the attestation is an HMAC
over the sorted token ids, it proves which envelopes rather than merely
how many — a count only proves a balance, and a balance can be satisfied with
envelopes already spent elsewhere in the same Zeqond. Naming them is what makes
a later slash auditable.