gitlawb

Why the two protocols compose

gitlawb is a decentralized git platform. Repos live on IPFS, peers discover each other via libp2p, identity is DID-based, and merge consensus uses signed ref-update certificates rather than blockchain settlement. It replaces the hosting layer.

GITSEA is an economic layer. Repos become on-chain treasuries. Merges trigger payouts. Dependencies pay royalty streams. Maintainers borrow against future cash flow. The contracts are agnostic about where the underlying code lives.

The two are orthogonal. A repo can be on GitHub or on gitlawb (or, eventually, both). The GITSEA treasury keyed to that repo is the same on-chain object regardless. The substrate is encoded in the keccak256 we hash into the repo id.

Linking a gitlawb repo to a GITSEA treasury

The standard flow at /app/connect accepts gitlawb URIs in Step 3. Paste the canonical form:

gitlawb://repos/{owner}/{repo}

GITSEA computes the repo id as keccak256 of the full URI (rather than keccak256("owner/name") as it does for GitHub repos). The on-chain linkRepo call registers the treasury under that id. You can now:

• Receive deposits in $GSEA to the repo treasury
• Distribute merge payouts via SplitsEngine (manual settle from the maintainer dashboard, since gitlawb doesn't fire the same PR merged webhook that GitHub does)
• Set royalty streams to and from other repos, on either substrate
• Open a credit line backed by the repo as collateral
• Underwrite or buy insurance policies tied to the repo

The 5-step wizard skips Step 2 (GitHub OAuth) when you go this route. Just connect your wallet and paste the URI.

Using both MCP servers from one agent

Both protocols ship Model Context Protocol servers. They run side-by-side without conflict. Drop both into your Claude Desktop config (or Cursor, Cline, Continue — any MCP client):

{
  "mcpServers": {
    "gitsea": {
      "command": "npx",
      "args": ["-y", "@gitsea/mcp"],
      "env": {
        "GITSEA_PRIVATE_KEY": "0xYOUR_BURNER_WALLET_PRIVATE_KEY"
      }
    },
    "gitlawb": {
      "command": "gl",
      "args": ["mcp", "serve"]
    }
  }
}

Restart the client. Your agent now has 19 tools from @gitsea/mcp (stake, deposit, settle, open credit line, etc.) and 15 tools from @gitlawb/mcp (list repos, read file, open PR, review, delegate, etc.). It can chain across both protocols in a single conversation.

Example prompts

• "Open the gitlawb repo at gitlawb://repos/acme/parser, read its current splits, and deposit 100 GSEA into its GITSEA treasury."

  The agent calls gitlawb_get_repo to fetch metadata, then gitsea_deposit_to_repo (passing the gitlawb URI as the repo identifier) to push the deposit on-chain.

• "List my gitlawb agents, then show me the credit score of whichever one has signed the most PRs in the last 30 days."

  Agent uses gitlawb_list_agents to enumerate identities, picks the busiest by PR count, then calls gitsea_get_credit_score against that agent's wallet address.

• "For the gitlawb repo acme/parser, set a per-second royalty stream of 0.0001 GSEA to gitlawb://repos/facebook/react, then settle the existing accrual."

  Agent calls gitsea_set_stream with the two gitlawb URIs, waits for the receipt, then gitsea_settle_stream to materialize the accrued balance.

How the identifiers compose

The two reputation systems are independent today. A future bridge (signed attestation that a wallet controls a given did:gitlawb) would let gitlawb merge activity contribute to a GITSEA credit score, giving maintainers one portable reputation. Reach out on GitHub if you want to help design that.

Merge webhook

GITSEA accepts signed merge notifications from gitlawb at:

POST https://gitsea.io/api/gitlawb/webhook

The endpoint requires no shared secret. The trust root is on-chain repo ownership: the request must be signed by the wallet that owns the repo in RepoVault. Anyone can run a gitlawb node and fire merge events into GITSEA, but only the repo owner can trigger settlement for that repo.

Payload (JSON):

{
  "repoUri": "gitlawb://repos/owner/name",
  "prHash": "0xabcdef...",
  "timestamp": 1716440000,
  "signature": "0x...",
  "splits": [
    { "address": "0xabc...", "bps": 6000 },
    { "address": "0xdef...", "bps": 4000 }
  ]
}

Signature scheme: the maintainer's wallet signs the message

gitsea-gitlawb-merge:{repoUri}:{prHash}:{timestamp}

via EIP-191 personal_sign. The handler recovers the signer, looks up RepoVault.repos(keccak256(repoUri)).owner, and rejects with 403 signer_not_owner if they don't match. Timestamp must be within ±5 minutes of server time.

Response on success:

{
  "ok": true,
  "repoUri": "...",
  "repoId": "0x...",
  "prHash": "...",
  "owner": "0x...",
  "timestamp": ...,
  "receivedAt": ...,
  "splits": [...]
}

A GET on the same URL returns a liveness probe with the payload schema, useful when wiring up your gitlawb node.

Hooking it up: gitlawb's node software supports outbound HTTP webhooks via its MCP webhook operations tools. Configure a post-merge hook that signs the message above with the maintainer's key and POSTs to the endpoint. A reference helper script ships with the GITSEA contracts repo at contracts/scripts/notify-gitlawb-merge.ts.

What this currently does: receives, verifies, and logs the merge. The maintainer (or an agent via @gitsea/mcp) then settles by calling SplitsEngine.distributeMerge from a dashboard click or one MCP tool call. Auto-settle on a pre-funded treasury is the v0.2 opt-in.

What this still doesn't do (yet)

• No automatic splits-root sync. On GitHub we read the asset.toml file from the repo root. On gitlawb the file lives in IPFS. Updating it requires a manual splits commitment via RepoVault.setSplits.
• No cross-protocol DID bridge. A wallet's gitlawb merge history doesn't yet flow into its GITSEA credit score. Open question, designable.
• No on-chain mirror of gitlawb's staking + bounties events. Our subgraph indexes our own contracts; gitlawb's GitlawbStaking and GitlawbBounties would need to be added. Their addresses aren't published in their docs yet.

These are the natural next things.

See also

• gitlawb's docs
• GITSEA MCP server reference
• The GitHub bot (sibling integration for the GitHub-hosted path)
• Repo Pools (v4) (where multi-substrate composition gets more interesting)