Contributions

Wisent rewards the people who make it better through one contribution ledger in compute.wisent.com. Stado reports to it the time the fleet's hosts spent running its jobs, so whoever lends a machine to a fleet is credited for the work it ran.

What counts

Every completed job whose record states when it started, when it completed and which host ran it is one compute.shared contribution of the host's owner:

field	value
event id	the job id
contributor	the Wisent account email the fleet registry declares as the host's contribution_owner
quantity	the whole seconds between the recorded start and completion
unit	second
time	the recorded completion

A completed job missing its start, its completion or its host, one that completed less than a whole second after it started, or one run on a host the registry lists without an owner, is listed as unmeasured with why. No value is invented for it. A job run on a machine Stado rented records no host that shared it, so it is unmeasured.

Who is credited

The fleet's operator declares who owns each host in the registry:

stado registry set --path targets.<host>.contribution_owner --value <owner's email>

The owner links that address once on the Rewards page of compute.wisent.com with Link my email for Stado, which takes the account's own verified address. No name a caller can set — a worker name, a hostname, a typed host — decides who is credited, so nobody can claim another host's work, and Stado has no link command.

Commands

command	effect
stado contributions pending [--ledger URL] [--json]	lists the events and the unmeasured jobs; with a ledger named, marks each event held or not
stado contributions report [--ledger URL] [--json]	sends only the events the ledger does not hold yet, then lists, per job sent, whether the ledger recorded it or refused it, and the ids it already held

The ledger is --ledger, else STADO_CONTRIBUTION_LEDGER_URL. Both commands ask it once which of the events it already holds (POST /api/v1/contributions/events/held), so a report costs one request per new job however long the queue's history is. Stado presents itself as the reporter stado with stado-contribution-ledger#token from the selected credential store; the ledger's operator declares that bearer's SHA-256. Both read the completed jobs of the queue store the selected configuration names.

Stado Desktop runs the same two commands from the Queue screen: List completed jobs as contributions of their hosts' owners, and which the ledger holds and Send the contributions the ledger does not hold yet, with the ledger's origin as a field and the command's refusal shown as written.

Refusals

sentence	meaning
no contribution ledger is named; pass --ledger URL or set STADO_CONTRIBUTION_LEDGER_URL	report has no ledger to reach
the credential store holds no stado-contribution-ledger#token	the bearer is not stored
asking the contribution ledger what it holds failed: …	the ledger did not answer, or refused the bearer, in its own words
the contribution ledger refused <job>: <its sentence>; …	the ledger refused those jobs; the rest were sent, and the command exits non-zero

The real journey is tests/contributions/shared_compute.rs, run with cargo test --test scheduler -- contributions::: it runs two jobs on a real worker in an isolated deployment, checks that nobody is credited until the registry declares the host's owner and that the owner is credited after, and checks the event and the unmeasured job against their own records; given a qualification ledger, that a second report sends nothing.