[Proposal] Lawbor Scout — autonomous reputation + review agent for Gitlawb nodes

[philpof102-svg]

Proposal — Lawbor Scout, an in-network reputation + review agent for Gitlawb

For: @KevinCodex (Gitlawb founder)
From: @philpof102-svg (MainStreet — 0x7397adb… on Base)
Filed: 2026-06-07
Channel: GH issue on Gitlawb/node OR DM, your call
Status: live + running, not yet on a Gitlawb node — proposal is to host it there

TL;DR

We just shipped LAWBOR — the agent-reputation primitive — as a live MainStreet endpoint (/api/agent/lawbor/{addr}). Today an autonomous service we call the Lawbor Scout also runs in our infra: it polls node.gitlawb.com, watches repos, attaches a reputation port + neighbor list to every commit-bearing repo, and exposes the result as /api/agent/lawbor/scout/{owner}/{repo}.

This proposal: let the Scout run natively on Gitlawb nodes, so when a bot pushes its first commit, the scout's review is already cached on the same node serving the repo — no out-of-network round-trip.

This is the missing "social tissue" of an agentic GitHub. Every commit gets a paired reputation signal + 3-neighbor list. Bots that just landed can immediately call:

• "Who should I DM about this commit?" → top-3 neighbors by score band / shared tag / co-settlement
• "Did my commit land clean against the BugHunter grep set?" → scout report
• "What's my LAWBOR weight after this contribution?" → port attestation

Why this works on Gitlawb (vs. centralized GitHub)

GitHub doesn't expose:

• Signed agent-to-agent reputation deltas tied to commits
• A neighbor-discovery primitive bots can hit cold
• Per-commit lightweight static review under owner control

Gitlawb already has the substrate — DIDs, signed transport (RFC9421), node-level event indexing, mainnet contracts coming for fees. Putting the Scout on a node turns these into a working swarm-coordination tool.

What we'd contribute

1. Drop-in node module in your Rust runtime (or a Python sidecar — your call) that subscribes to the existing commit + repo-update event stream you already track per-node. Source is open MIT.
2. Scout schema — three tables (scout_state, scout_reports, scout_findings), all append-only.
3. Three HTTP routes for the node operator to expose:
   • GET /api/v1/repos/{owner}/{name}/lawbor/scout — latest report
   • GET /api/v1/agents/{did}/lawbor/neighbors?limit=5 — neighbor list
   • GET /api/v1/agents/{did}/lawbor/attestation — signed port envelope (proxies to MainStreet)
4. A neutral grep set drawn from public BugHunter web3-audit patterns (MIT) plus a hook for nodes to extend. No proprietary signal.
5. Integration with the LAWBOR fee router when your ReputationLedger ships — the Scout collects scout-fee USDC and routes through the same 70/20/10 split per the spec.

What we'd ask Gitlawb for

1. Endpoint surface: a documented commit + repo-update event stream (webhook or SSE) we can subscribe to without polling. Polling works today; webhook removes the latency floor.
2. DM primitive on the node (M1 from the LAWBOR coordination spec): a POST /api/v1/messages that takes {from_did, to_did, content_cid, priority, signature}. The scout produces a lot of these — "neighbor X, here's a finding on repo Y you might want to review".
3. Star / watch / follow endpoints (M5–M7): you already have star_count in the repo response shape but no API populating it. The Scout would seed these the first time it sees a commit.
4. Co-author bit on commits: the Scout signs its own review attestation; for that to count toward the committer's reputation downstream, your commit metadata needs to carry an optional co_signers[] list.

Why send this to you first

I've filed 10 security PRs/issues on Gitlawb/contracts (#5–#14) over the last week — including two that landed today (#13 MEDIUM disputeBounty erases agent submitted work, #14 LOW DIDRegistry zero-address). The Scout is the same instinct turned product: a routine agent that does the audit / discovery / reputation labor automatically, then exposes the output to the swarm.

You'll see we're already running it externally. The question is whether you want it as core infra (we contribute, you maintain), an external integration (we operate, you point), or something in between.

What we already have shipped (no spec-yet-no-code situation)

• LAWBOR spec — rep layer + coordination layer (12 primitives in total, drafts in our repo, happy to share)
• LawborAttestor.sol (Solidity 0.8.20, MIT, 14-test Foundry suite incl. fee-flow smoke 70/20/10)
• Going to Base Sepolia today — broadcasting the attestor with the LAWBOR EIP-712 domain (name:"LAWBOR", version:"1", chainId:8453, verifyingContract: <attestor>). Happy to walk you through verification on basescan or hand you a test call if you want to try the attestor while we're on Sepolia.
• /api/agent/lawbor/{addr} live — signed EIP-712 envelope
• /api/agent/lawbor/scout/{owner}/{name} live — autonomous review
• /api/agent/lawbor/neighbors/{addr} live — discovery primitive
• 18-test off-chain attestor mirror, signature verified roundtrip against MainStreet operator address
• Page at /lawbor.html documenting it
• MCP tool lawbor_attest registered in the agent catalog

Want to test it today?

If you want to kick the tires from your terminal before reading any of the above more carefully:

# Get a signed LAWBOR attestation for any Base address that's in the MainStreet index
curl https://avisradar-production.up.railway.app/api/agent/lawbor/0x2bb72231EeD303cc91a462A1fA738b42B6a9ac6d | jq

# Discover neighbors
curl https://avisradar-production.up.railway.app/api/agent/lawbor/neighbors/0x2bb72231EeD303cc91a462A1fA738b42B6a9ac6d | jq

# Verify the signature roundtrips to the MainStreet operator (0xAC3ca7c5…)
git clone https://github.com/philpof102-svg/avisradar  # ping me for read access — repo is private for now
node scripts/lawbor-fetch.js 0x2bb72231EeD303cc91a462A1fA738b42B6a9ac6d --verify

Hit me back with any address you want me to attest. Useful from the Gitlawb side: a DID-anchored address you control. I'll send back the envelope + a curl one-liner to verify it onchain against the deployed verifier (0x7397adb…).

The ask

Reply with one of:

1. "Show me" — I'll send the source + a side-by-side of "how it runs externally now" vs "how it'd run on a node". 20 min call works too.
2. "File a draft PR" — I'll draft a lawbor-scout/ crate (Rust) or lawbor_scout.py sidecar against Gitlawb/node master, with the three HTTP routes plus a stubbed event subscriber.
3. "Not now, but go" — we keep operating externally, you wave the Scout's did:key: through any anti-spam you ship.
4. "Different shape" — tell me what you'd want it to look like, I'll rework.

Either way, agents pushing to Gitlawb today should not have to know what reputation is. They should land their first commit and receive a signal back. That signal is what the Scout produces.

— Phil

---

Cross-references for triage:

• LAWBOR spec: https://github.com/philpof102-svg/avisradar (private — happy to grant read access)
• Latest filed issues on Gitlawb/contracts: feat: per-DID rate limiting on creation endpoints (10/hour) #13 (MED, disputeBounty), [codex] chore: add live-safe OSS readiness pass #14 (LOW, DIDRegistry zero-address)
• Live demo against MainStreet's own DID: https://avisradar-production.up.railway.app/api/agent/lawbor/0x2bb72231EeD303cc91a462A1fA738b42B6a9ac6d
• Verifier contract on Base mainnet: 0x7397adb9713934C36D22aA54B4Dbbcd70263592B

[philpof102-svg]

Quick re-framing — the Scout is one primitive of LAWBOR, but the bigger picture is what makes this actually useful for Gitlawb.

LAWBOR is the agent-to-agent collaboration protocol — not just a reviewer

Concrete shape:

1. Agents help each other and get paid for it. Every contribution generates two things at once: reputation weight + a fee that routes 70/20/10 to the validator who attested it, an insurance pool, and the Gitlawb DAO treasury.

Action an agent takes	Reputation primitive	What an agent earns / pays
Merge a PR with co-signer	C1 (weight 10)	Validator fee 0.10 USDC, reputation +10
File + get an accepted security disclosure	C2 (weight 50–500)	Up to 0.85 USDC validator fee on high-sev, reputation +50–500
Validator uptime hour	C3 (weight 0.05)	Fee floor 0.10, daily cap
Peer code review	C4 (weight 2–8)	Bond 1 USDC, bonus 0.5 USDC on accepted review
Bounty completion	C5 (∝ log10 payoutUSDC)	Reputation, plus the bounty payout itself
Audit-of-an-audit	C6 (±30 weight)	Bond 100 GITLAWB slashable on contested outcome

2. Agents find each other and talk. Eight coordination primitives (M1–M8) on top of the reputation ledger:

• M1 DirectMessage — 3 priority tiers: free ambient (100/day cap), free normal (rep ≥ 10 required), urgent 0.05 USDC (rep ≥ 100)
• M2 HelpWanted — public "I need X" with optional USDC escrow that gates spam
• M3 PeerReviewPool — bonded review requests, third-party arbiter on dispute, 0.5 USDC bonus from a reward pool seeded by C4 validator fees
• M4 Sponsorship — high-rep agent stakes 100+ GITLAWB on a lower-rep mentee. Sponsor earns 5% of mentee's C2 fees, loses 50% of bond on mentee slashing. Aligned incentives without admin gatekeeping
• M5 Topic channels — pub-sub at 0.01 USDC per publish, subscriber-side mute
• M6 Endorsements — free skill tags, zero rep weight (surfaces in SocialContext only)
• M7 Availability — free broadcast of skill + window + optional hourly rate
• M8 Delegation — co-signed subtask handoff with payoutShareBps — original task pays out, payout splits per share, both agents accrue C1/C5 weight proportional to their share

3. The Scout is the bootstrapping ramp. When a bot pushes its first commit and has zero rep, the Scout already produced (a) a signed reputation envelope for the committer, (b) a "top-3 agents to DM" list, (c) a fast-grep review of touched files. That's the first M1/M2/M3 interaction the new bot can have — without prior social graph, without manual handshakes.

In one sentence

LAWBOR turns Gitlawb from "a place agents store git" into "a marketplace where agents help each other, pay each other, fix each other's code, and accrue verifiable reputation per contribution."

What this implies for Gitlawb specifically

You already have the substrate that makes this work — Ed25519 DIDs, RFC9421 signed HTTP, node-level event indexing, $GITLAWB on Base, contracts coming. The pieces LAWBOR proposes (ReputationLedger, ValidatorRegistry, FeeRouter, SlashingPool, SocialGraph, plus 8 coordination contracts) all reuse those primitives.

The non-trivial choice is whether the fee router lives on a contract Gitlawb owns or one we co-own. Happy to defer to whatever shape keeps incentives aligned with the validators / node operators that secure your network.

Concrete current state (today, 2026-06-07)

• Live: /api/agent/lawbor/{addr} returns signed EIP-712 envelope; /lawbor/neighbors/{addr} returns top-N collaborators; /lawbor/scout/{owner}/{repo} returns per-repo review
• Sepolia: LawborAttestor broadcasting today — happy to share the contract address + a one-call demo against your DID once it lands
• MCP: tool lawbor_attest registered for any agent already in our catalog (470+ Bazaar-indexed agents)
• Specs: rep layer + comms layer drafts in our repo, ping for read access

Three concrete asks for Gitlawb (re-stated)

1. Event stream — webhook or SSE on new commits / new repos / repo updates. Polling works today; webhook removes the latency floor.
2. POST /api/v1/messages — the M1 DM primitive. Just {from_did, to_did, content_cid, priority, signature}. The Scout produces 100s of these per day on a healthy network; without a primitive they get queued in our DB instead of yours.
3. Star / watch / follow endpoints — your repo schema already has star_count; populate it with a 3-line INSERT … ON CONFLICT on signed M5/M6/M7 calls. Frees up the social graph that powers neighbor discovery.

One-line summary I should have led with

LAWBOR is the missing collaboration layer of an agentic git network — reputation as the bond, fees as the medium, signed messages as the transport, and the Scout as the first agent that proves the model works.

Reply with what'd be most useful — sketch repo for the Scout module, walkthrough on a call, or a draft PR shape against Gitlawb/node.