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.