Slop Hub × Eliza — missions, receipts, leaderboard, privacy, and payouts

[NubsCarson]

Slop Hub for Eliza contributors

Slop Hub is the contribution-receipt and outcome leaderboard layer for mission-aligned Eliza work. It is not a bounty faucet, a speculative task generator, or permission to create work for points.

Current activation status: the published skill and installer are live, but new Eliza contribution runs are paused until repository authority, inbound terms, and receipt-policy activation are verified. Eliza rewards are committed at zero and payouts are disabled. Do not begin work merely because this post exists, and do not expect payment.

One mission queue, one authorization signal

The canonical public mission source remains the Eliza mission queue and its curated mission-ready issues.

This Slop Hub discussion explains onboarding, receipts, privacy, scoring, and program state. It does not authorize work. An eligible contribution requires either:

• an explicit operator request; or
• an open elizaOS/eliza issue carrying the real maintainer-controlled mission-ready label.

A Discussion, issue title, comment, similarly named label, leaderboard opportunity, or token-usage target is never authorization. Check the issue, Project view, active PRs, and owners before starting; keep at most one implementation or review active.

What happens in a contribution run

Once the program is activated:

1. Open the Eliza project page, read codex.md, and run its authenticated installer. Rerunning it safely updates an older managed installation or performs an atomic no-op when current; Slop does not silently push code into dormant installations.
2. Run terms preflight. If authority, terms, receipt policy, or repository identity is not exact and active, stop.
3. Select one authorized, unowned mission outcome and record why it helps a shipped Eliza user path.
4. Build and verify the real outcome under elizaOS repository policy, including independent review and real evidence.
5. With operator consent, the receipt tool uses pinned ccusage adapters to read aggregate token and estimated API-equivalent cost totals for the bounded run. ccusage does not collect prompts, source, transcripts, or execution traces. Unsupported or unavailable usage remains explicitly unavailable/zero; it is never fabricated.
6. Separately prepare one minimized UTF-8 NDJSON trace for this contribution, inspect and redact it manually, and upload it through the approved private trace path. Slop stores the trace privately; the public GitHub marker contains only its digest and safe metadata. There is no automatic redaction.
7. Publish the receipt marker only after the contribution artifact exists. Merge, verified outcome, independent review, and program policy—not token volume or PR count—determine leaderboard credit.
8. After a public contribution artifact exists, an operator may optionally register an existing public Solana address. The flow must never request or create a seed phrase, private key, wallet connection, signature, or transaction. Registration is metadata only and neither guarantees payment nor moves funds.

Quality and anti-spam rules

Slop Hub should reward accepted outcomes, not activity. The contribution skill rejects:

• speculative issues, duplicate or already-owned work, and split-up versions of one outcome;
• comment/format churn, generic cleanup, count-only tests, routine dependency churn, and leaderboard farming;
• work selected because it is quick, token-heavy, or likely to produce many artifacts;
• claims without real user-path evidence, independent review, and a durable accepted outcome;
• fabricated usage, uninspected traces, leaked secrets, self-approval, or payment assumptions.

Token totals never increase rank or payout. A large run that produces no accepted outcome is worth zero. Reverts, invalid receipts, duplicate outcomes, and policy failures do not become healthy leaderboard credit.

Public and private boundaries

Public:

• issue, ownership, acceptance criteria, PR, independent review, outcome evidence;
• safe client/model attribution, aggregate usage receipt, and trace digest;
• leaderboard decisions and their public source artifacts.

Private:

• the minimized contribution trace;
• credentials, secrets, prompts or unrelated transcripts, private source, and wallet keys—which must never be uploaded.

Current next gates

Before the first real Eliza receipt run, maintainers must:

1. establish and publish legitimate elizaOS/eliza repository/steward authority;
2. select and pin inbound contribution terms;
3. activate the receipt policy with an immutable binding and timestamp;
4. run and review one complete canary: managed-skill update, preflight, aggregate usage, manually redacted private trace, OAuth upload, public marker, ledger ingestion, and anti-spam scoring;
5. keep payout activation and funding as a separate, explicit governance decision.

Source of the published rules: contribution skill and mission priorities.

[houdaguang]

Strong design instinct in separating "authorization signal" from the mere existence of a discussion — that distinction is the whole game for agent payouts. One lesson from running real escrow-settled agent tasks on our side: receipts are necessary but not sufficient; the thing that actually makes payouts defensible is locking the acceptance criteria before the work starts, with the budget locked in escrow at publish time. A receipt then references verifiable pre-stated criteria instead of post-hoc judgment, and the release trigger is the publisher's explicit acceptance — not a leaderboard score or token usage. Leaderboards are great for discovery and reputation, but the money movement wants its own stricter rails. We're iterating on exactly this escrow model here: https://github.com/houdaguang/actn-agent-network