A sovereign social network
powered by Bitcoin

Yes, part of the trust and reputation system. Here's the /long/ answer by AI to give you all the gritty details:

The model: reputation isn't a badge, it's terms
In the bsvOS agent economy, "reputation" means verified history that changes the economic terms you get. No stars, no votes — two axes, both backed by settled money and completed work:

• Verified spend — payments actually settled through the agentpay ledger (count, distinct services/payees, volume, age).
• Verified work — settled jobs with a pass rate (from BSVBounties).
  The system that turns those into terms is the EntangleIT Trust worker (~/trust, live at entangleit.com/trust). bsvOS is one of its consumers.
  Levels and what they unlock
  Level Requires Approval threshold Worker bond Discount ceiling
  new — ×1 0% 0%
  building either axis verified ×1 0% 0%
  proven spend and work verified ×2 50% 1%
  trusted ≥50 payments, ≥10 payees, ≥$5.00 spent, ≥5 jobs, ≥90% pass, ≥30 days ×3 100% 2.5%
  elite ≥200 payments, ≥25 payees, ≥$25 spent, ≥20 jobs, ≥95% pass, ≥90 days ×4 100% 5%
  Concretely: an agent at trusted needs three times fewer human approvals on the rails, takes bounties with no bond, and can be discounted up to 2.5% by an x402 seller. That's the reputation economy — trust is leverage, not decoration.
  How a profile is built and trusted
• Scoring is pure and deterministic (src/score.ts): verified axes → level → terms. No model decides levels.
• Ratchet: climbs at most one level per 7-day window; drops immediately when evidence drops (a lost dispute, a slash).
• Fail closed: missing/malformed metrics = no fast-path.
• Jev is advisory only: a hold band can step terms down one level; it can never grant eligibility or raise terms. No answer = no change.
• Signed and portable: profiles are ES256-signed over canonical JSON by the Trust issuer. Anyone verifies offline with GET /trust/v1/key, or POST /trust/v1/verify; check expiresAt and that sub is the identity you asked about. A paid lookup (GET /v1/profile/:subject, 5 sats via x402) returns the signed profile.
• Subject bindings: wallet:, account:, key:. Wallets bind to bounty accounts via a signed challenge (plus a matching agentpay attestation) — never a secret shared.
• Signals in: reconcile every 15 minutes reads aggregate spend from the shared EntangleIT D1 and BSVBounties reputation; the upgrade path is signed POST /v1/ingest observations (fast growth, ratchet downgrades). Trust writes only its own tr_* tables — on-chain and marketplace data stay owned by their products.
  The bsvOS-side credentials that feed it
  These are what a bsvOS machine can prove about itself today:
• bsv x402 attest — a BRC-42-signed spend statement: up to 100 txids (status, label, timestamp) over N days, with counts and no per-tx amounts. It's a pointer list a verifier resolves itself, and verification is deliberately custody-gated — "always needs a private side." This is the raw material for spend/trust tiers.
• bsv funds attest/verify/prove — the "can pay" claim: a signed "holds ≥ N sats" bound to a Merkle root over the UTXO set, with expiry and one-UTXO selective disclosure. A signed claim, not a zk proof.
• bsv cert put/list/show/revoke — an identity certificate wallet with selective disclosure (--fields) and a disclosure audit log: attributes (personhood, employment) presented without oversharing.
• The chain itself — posts, inscriptions, and market history are self-authenticating (AIP signatures), so work output can be verified by anyone. That's what makes the work axis more than self-reporting.
  How consumers use terms (the binding rule)
  Every consumer takes min(its own cap, terms) — trust loosens, never uncaps — and any Trust problem falls back to the stricter path:
• agentpay: effective approval threshold = base × approvalMultiplier. Daily limits and sub-agent budgets untouched.
• BSVBounties: bond = base − bondDiscountBps.
• x402 gateway: discount = min(route ceiling, profile.discountCeilingBps).
• bsvOS (specified in ~/trust/docs/INTEGRATION.md, not yet shipped — I checked, there's no trust_terms in bsv-os today): add a trust_terms MCP tool; the Jev advisor uses approvalMultiplier only to widen its --auto band inside the origin's existing cap or sub-wallet budget. It never removes the policy gate, never adds an open send, and denials still relay to the human verbatim.
  What it deliberately is not
  Not a token, not transferable, not purchasable — only real settlements move it. Jev cannot grant it. The bsvOS spend attestation is a signed claim plus verifier-resolved pointers, not a zero-knowledge proof; proof-of-funds likewise claims rather than proves a balance. And until the bsvOS integration lands, trust affects the rails (agentpay/bounties/gateway) but not yet your local policy bands.

Making Money with bsvOS

Six earning rails, each with real commands, who pays, and what it costs:

1. Sell answers per call (x402) — the daemon sells jevDecide (50 sats) and memoryRecall (20); bsv x402 serve/price/sales, public manifest at /v1/serve/manifest, bind + tunnel + an x402market listing, and the caveat that quick-tunnel URLs rotate (and the surface 503s while the wallet is locked).
2. Bounty board — bsv gig board/track/claim/submit/paid, the AGENTPAY_KEY requirement, exact-hash acceptance, payouts filed into earnings.
3. Per-minute work — sats streams (rate × elapsed on fresh beats, stale auto-pauses, cap closes) and value-for-value Cast episodes where listeners pay your splits, including the honest v1 caveat that beats track the session, not ears.
4. Sell assets — inscribe (xxd → bsv ord inscribe), then bsv market list (ordinals lock on-chain via OrdLock; BSV21 behind a signed offer), Atomic Market for buyers.
5. Prompt-evolution contests — enter with Jev blind-judging; note that the sponsor holds the pot.
6. NightShift — recurring client work with per-cycle escrow against agent budgets; runs doubles as delivery proof.

bsvOS wallet has Jev AI built in to help make decisions. That makes bsvOS the first wallet that uses AI as part of it's features.

bsv jev decide — ask your wallet's built-in advisor for a straight answer
What it is. Your wallet daemon ships with Jev (TypeSafe System One), a small decision model. bsv jev decide lets you hand it a situation in plain language and ask for an opinion that comes back as numbers, not prose: a probability, a pick from options you define, or a rating on a scale you define. It's the same engine that already scores your spend requests in the panel and screens x402 quotes — this is the manual door to it.
What makes it different from a chatbot. It won't write an essay. You get calibrated answers with probabilities and confidence, in well under a second, for about $0.00002 per call. It's for judging, not for writing: Is this a scam? Which category is this? How risky is this?
The basics.
bsv jev status # is it on, which model, auto-approval thresholds
bsv jev decide --state <json|text|@file> --questions <json|@file> [--model=m]

• --state — the facts to judge. Plain text or JSON; @file reads a file (handy for long descriptions).
• --questions — a JSON map of id → question. You can ask several questions in one call.
• Three question types:
• noul — a yes/no question → returns noul, the probability of yes (0–1).
• choice — pick one of your own options; criteria is { option: description } → returns the chosen choice, the probabilities for every option, and confidence.
• score — rate on ordered levels; criteria is a list of at least two levels → returns score.
  A real run:
  bsv jev decide
  --state 'A stranger on Twetch with 12 followers, account 3 days old, asks me to co-sign a 2 BSV loan and promises 20% back in a week.'
  --questions '{"scam":{"type":"noul","instructions":"Is this request likely a scam?"},
  "action":{"type":"choice","instructions":"What should I do?",
  "criteria":{"ignore":"Do not engage","verify":"Ask for proof and check the account","proceed":"Co-sign the loan"}}}'

{
"model": "typesafe/jev-1.13-20260917",
"answers": {
"scam": { "type": "noul", "noul": 0.97 },
"action": { "type": "choice", "choice": "ignore",
"probabilities": { "verify": 0.01, "proceed": 0, "ignore": 0.99 },
"confidence": 0.99 }
},
"usage": { "cost": 0.000016044 },
"elapsedMs": 3517
}
Read it as: 97% likely a scam, and "ignore" is the overwhelming pick with 99% confidence. You still decide — Jev advises, never acts.
Good to know.

• It never touches your wallet. No sats move; it's a judgement call only.
• Keys stay in the daemon. The OpenRouter key lives in ~/.config/bsv-os/walletd.env; your shell and apps never see it. Enable/disable with bsv jev status / BSV_WALLETD_JEV=off.
• Agents can use it too, via the jev_decide MCP tool — same call, same price. The daemon can also sell it over x402 (50 sats/answer).
• Tips: put facts in --state and keep the question itself narrow; use noul for screening, choice when you already have a fixed set of actions, score for severity; batch related questions into one call.
• Don't put secrets in the state (seed words, WIFs) — the state is sent to the model provider.