Protocol that turns every repo into a treasury: earns royalties from dependents, has a credit score, borrows against cash flow. For humans AI agents. On @base
Joined May 2026
- Tweets 45
- Following 6
- Followers 130
- Likes 5
Photos and videos
Pinned Tweet
May 23
GITSEA is now live. The sovereign credit layer for code: every repository gets an on-chain treasury, royalty streams between repos, stake-weighted governance, soulbound contributor credit, and parametric insurance.
CA: 0x4AF1627B1283c3aCC95735dD323b32EAB0e6BB07
The app at gitsea.io/app is open to anyone with a wallet. The contracts are deployed on Base mainnet and frozen at their published addresses. The event indexer is caught up. The MCP server is on npm. The GitHub App is installable. Every primitive the protocol promised is operational.
$GSEA is live too. It is the settlement currency the contracts were built around. Stake it to earn governance weight and a slice of protocol fees. Hold it in a repo treasury to receive royalty streams from dependents. Post it as collateral to open a credit line. Underwrite parametric insurance pools with it. The ten contracts that make up GITSEA all denominate value in $GSEA, and now that the token is bound, every read, write, and settlement path runs end-to-end.
This is what the protocol was designed to do, in one place, settling on the same balance sheet. A maintainer links a repo and starts receiving merge payouts the moment a contributor's pull request lands. A capital provider stakes into the protocol, earns fee share, votes on parameter changes. An underwriter opens credit lines for borrowers backed by repo cash flow. An AI agent reads its principal's credit score, opens a position, and signs the transaction in one turn.
21
3
33
7,647
May 25
A major GitSea update is now in development.
We are expanding our Gitlawb integrations and building new mechanisms designed to reward both $GSEA holders and active users of the GitSea app.
GitSea’s mission is bigger than simple repo hosting or contributor payments.
We are building the economic layer for code.
A repository should be able to hold value, distribute value, prove contribution history, route rewards, and interact with on-chain infrastructure the same way any serious digital asset can.
That means deeper Gitlawb connectivity, stronger app-level utility, more automated reward paths, and better alignment between builders, users, and holders.
Since launch, we’ve been working nonstop behind the scenes to turn GitSea into real infrastructure for developers and open-source ecosystems.
To everyone supporting $GSEA early: thank you.
2
2
4
307
GITSEA retweeted
May 24
Since launch, we’ve been working relentlessly behind the scenes to keep expanding the GitSea ecosystem.
More @gitlawb integrations are already in motion, along with new updates designed to create more value for $GSEA holders and reward the users actively building, contributing, and using our app.
We want to thank everyone who has supported us, held through the noise, tested the product, shared feedback, and believed in what we’re building from day one.
GitSea is not here for short-term hype.
We’re here to deliver real high-tech utility, connect code with on-chain value, and keep building an ecosystem where contributors, holders, and users are rewarded.
1
1
2
405
GITSEA retweeted
May 23
I created @gitsea_base and there’s something’s I want to clear out
We shipped a lot of updates through the night, kept improving the product, and I was really excited with the direction it was going.
When I tried to verify the x account, the platform said my phone number was already registered to another account, which was my personal account.
I spoke with a friend in crypto and he suggested someone he knew who could help verify it. That’s where the issue started.
Everyone knows I’m based in Mexico, so it’s sad that something I spent so much time building had this outcome just because another person logged in to verify the account.
Not gonna lie, it hurts a bit. I was putting real time and energy into GitSea, and I really liked what we were building.
But I’m not giving up.
I’ll keep building, keep improving, and keep pushing forward, exited about the future of gitsea and the upcoming updates.
3
2
8
546
May 23
What we've shipped between GITSEA and @gitlawb so far is just the start.
The two protocols solve adjacent halves of the same problem. They built the substrate layer for AI-native open source: decentralized git on IPFS, DID-based identity, signed ref-update certificates, libp2p gossip.
We built the economic layer: treasuries per repo, royalty streams, soulbound credit, parametric insurance, agent-callable primitives via MCP. The more we integrate, the more either of us is worth.
We're going to keep building bridges. Repo URLs already resolve to GITSEA treasuries on our side, and the merge-webhook receiver is live. Next: wire DID-portable reputation, surface gitlawb's contracts in our subgraph, get $GITLAWB recognition into the credit-line product, and probably contribute a small CLI subcommand that closes the loop in their own tooling.
This work matters because the projects that quietly build the underlying infrastructure (the substrate, the primitives, the open patterns nobody is forced to use but everyone benefits from when they do) are exactly the projects the developer community has historically failed to fund. Gitlawb is doing that kind of work. The vision is right, the roadmap is real, the team is delivering on it. If the OSS-AI world wants this future, the developer community has to back the people building the rails before the rails matter.
We're going to keep doing our part. Anyone else who wants to help, the door is open. Thanks for what you are bringing into the space @kevincodex
May 23
$GSEA now supports $GITLAWB
Repositories hosted on gitlawb's decentralized git network can now have a GITSEA on-chain treasury, splits table, royalty streams, credit lines, and insurance policies. Same primitives as GitHub-hosted repos. Same balance sheet. No GitHub account required.
gitlawb is a decentralized git platform built on IPFS, libp2p, and DID-based identity. Code lives across a peer network instead of on a central server. Until today, that meant gitlawb maintainers had no path to the economic primitives we ship. Their repos couldn't accept on-chain deposits, couldn't define splits, couldn't borrow against future cash flow, couldn't underwrite insurance.
That changes now. The integration ships entirely from our side. No API call into gitlawb, no coordination required with their team. Our RepoVault contract was designed substrate-agnostic. It stores treasuries indexed by bytes32, not by a hardcoded owner/name format. We just taught our hash function to recognize gitlawb's public URL convention. The contracts didn't need a redeployment. The change is in how we derive repo ids on the frontend.
What you can do today:
Link a gitlawb repo to GITSEA. Visit gitsea.io/app/connect, pick the gitlawb tab in step 3, paste your gitlawb://repos/owner/name URL, sign one transaction. The repo now has a treasury at a deterministic address on Base. Anyone can deposit $GSEA into it.
Set a royalty stream between substrates. A gitlawb-hosted parser can stream value to a GitHub-hosted library it depends on, and the dependency's contributors get paid in the same per-second $GSEA flow. The two substrates compose on a single balance sheet.
Run both MCP servers in your AI agent. @gitsea/mcp and @gitlawb/mcp co-exist in Claude Desktop, Cursor, or Cline. One agent reads code from gitlawb, opens PRs there, and settles royalties through GITSEA in the same conversation. No glue code, no proxy server, no protocol translation. Nineteen tools from us, fifteen from them, the agent picks what it needs.
Open a credit line backed by a gitlawb repo. The collateral kind is unchanged from GitHub-hosted lines. Underwriters using $GSEA don't care what substrate the collateral repo runs on, because the credit oracle scores wallets, not repos.
The thesis behind GITSEA is that the economic layer for code should be neutral about where the code lives. GitHub is where most of it lives today, but it's not the only place, and the substrate-agnostic design of our contracts means it doesn't have to be. gitlawb is the first non-GitHub substrate we explicitly support. There can be more.
The cross-protocol DID bridge that would let a wallet's gitlawb merge history contribute to its GITSEA credit score is the natural next thing to build. Reach out on GitHub if you want to help design it.
test now at gitsea.io/app
6
1
10
1,184
May 23
GITSEA has ten contracts. Most protocols have one or two and call it a day. The composition matters more than the count.
Treasuries hold value. Splits distribute it. Streams move it continuously between repos. The credit oracle scores wallets by their on-chain history. The credit-line contract opens lending positions against that score. The insurance pool prices coverage against measurable risks. The governance contract reads stake weight to shape parameters.
No one of these is novel in isolation. Every one of them exists somewhere in DeFi. What's new is that they all settle against the same balance sheet, keyed to actual work (a merged PR, a paid royalty, a borrowed credit line) instead of synthetic exposure.
A maintainer with a high credit score gets better terms on a credit line backed by their repo's future cash flow. An underwriter who stakes against merge-failure insurance earns from policies sold across the entire protocol. A capital provider voting via staked $GSEA shapes the fee parameters those underwriters and lenders interact with.
Composability isn't a feature you bolt on. It's the only reason to build ten contracts instead of one.
May 22
With gitsea your repo can have a bank account now, credit score, credit line. and a way for every library it depends on to get paid every time your code runs.
9 contracts live on @base, all source-verified. this is GITSEA.
open source has created trillions in value and captured almost none of it. maintainers burn out, dependencies go unfunded, forks make more money than the projects they were lifted from. trying to fix that.
what each contract does:
4
6
478
May 23
Asked a lot recently:
"Do I need to hold $GSEA to use GITSEA?"
No. Every tool, every dashboard view, every MCP query is free. You only need $GSEA when you want to move value: stake, deposit into a treasury, settle a stream, draw on a credit line, buy an insurance policy.
GITSEA is a protocol, not a paywall.
3
1
255
May 23
The most powerful primitive in GITSEA isn't the treasury or the credit score. It's per-second royalty streams between repositories.
Set up once. The stream accrues continuously. Settle on demand or in batches via the protocol's keeper. The upstream repo earns value from its dependent at a rate the dependent itself set when adopting the library.
The implications stack. A library with a thousand dependents and a 0.01 $GSEA per-second stream from each earns 10 $GSEA per second, perpetually, against its maintainer's wallet. No subscription tier. No Patreon. No sponsorship campaign. Just a contract that says "this dependency was useful enough to fund continuously."
Royalty streams compose across the dependency graph. A leaf library streams to its direct dependents. Those dependents stream forward to whoever consumes them. Value flows back through the chain to the foundational work.
This is the primitive GitHub Sponsors should have been. It's been technically possible for years. Nothing did it. GITSEA does it now.
2
3
287
May 23
14:23 UTC: PR #482 merges into a linked repo on GitHub.
14:23 UTC 8 seconds: the contributor's wallet pings with their split in $GSEA, distributed per the asset.toml.
14:24 UTC: receipt comment lands in the PR thread with the on-chain tx hash.
No human approval in the loop. The merge IS the payout.
1
5
562
May 23
In less than a year, every meaningful open-source repository will have a treasury, a contributor splits table, and a continuous flow of value from the dependents that consume it.
Maintainers won't ask for sponsorship. The economics will be ambient. A PR merges, a contributor gets paid in the same transaction. A new release ships, the upstream libraries it builds on earn a royalty rate set when the dependency was added. A fine-tune of a model lands, the base model's treasury accrues continuously.
The current state of open source (critical infrastructure used by everything, paid for by basically nothing) is a coordination failure, not a value failure. The value exists. It just doesn't have a substrate that lets it flow back to the work.
GITSEA is that substrate. The contracts are live on Base, the primitives compose, the substrate-agnostic design works across GitHub, gitlawb, and Hugging Face today. More substrates follow. The same economic layer underneath all of them.
1
3
326
May 23
Every repository is now a balance sheet.Once you accept that line, the rest of GITSEA is plumbing: treasuries, splits, royalty streams, credit lines, insurance pools, all keyed to whichever repo the activity originates from.
The protocol just makes the balance sheet legible to anyone who wants to fund, settle, or insure the work on it.
May 22
With gitsea your repo can have a bank account now, credit score, credit line. and a way for every library it depends on to get paid every time your code runs.
9 contracts live on @base, all source-verified. this is GITSEA.
open source has created trillions in value and captured almost none of it. maintainers burn out, dependencies go unfunded, forks make more money than the projects they were lifted from. trying to fix that.
what each contract does:
2
2
641
May 23
GITSEA now supports @huggingface.
Models, datasets, and Spaces on Hugging Face are first-class GITSEA economic objects. Same primitives we ship for code repos: on-chain treasury per artifact, royalty streams between them, credit lines backed by projected demand, parametric insurance for performance regressions. All settling in $GSEA on Base. All composing on the same balance sheet as GitHub-hosted and gitlawb-hosted repos.
Three substrates now sit equal in the connect flow: GitHub, gitlawb, Hugging Face.
The flow that doesn't exist anywhere else:
Per-derivative royalty streams. A model fine-tuned from another model can stream $GSEA back to the base, per second, continuously. Set the rate once. The base model's treasury earns from every downstream user the fine-tune attracts, automatically, with no platform sitting in the middle taking a cut.
This generalizes our existing code royalty primitive to ML lineage. Stack across the model graph (base, fine-tune, quantization, distilled variants) and you get a perpetual revenue surface for upstream creators that the open-weights ecosystem has been missing for the entire decade it has existed. Datasets work the same way: a portion of every downstream model's inflow streams back to the data that trained it.
Open-weights ML is in the same place open-source code was twenty years ago. Critical infrastructure used by everything, paid for by basically nothing. The most-downloaded base models on Hugging Face have hundreds of millions of downloads and zero direct revenue surface for their creators. Fine-tunes inherit the value; bases get the citations and the lint at best.
GITSEA's economic primitives translate directly. A model is a repo. A fine-tune relationship is a royalty stream. A creator's reputation is a credit score. The substrate doesn't care whether the artifact is Python source or a 70B-parameter checkpoint. The contracts see bytes32. The economics are the same.
Visit gitsea.io/app. Pick the Hugging Face tab. Paste any HF URL. Sign one transaction. Your model has an on-chain treasury at a deterministic Base address. Anyone can deposit. You can set royalty streams to the base model you forked from, or to the dataset you trained on, and pay forward immediately.
Proof of commit: github.com/BastianMIllan/git…
Docs: gitsea.io/docs/integrations/…
App: gitsea.io/app/
3
5
465
May 23
GITSEA is now a permanent burn destination for $GITLAWB
Burner Contract: basescan.org/address/0x11630…
The contract accepts $GITLAWB transfers and sends them to the canonical EVM dead address (0x000…dEaD) permanently. Every burn is tracked per-wallet on chain and translates to a non-decaying GITSEA credit-score boost. One whole $GITLAWB burned equals one credit-score point. Capped at 100 points per wallet so a single whale can't dominate the reputational graph.
How it works.
You hold $GITLAWB. You connect a wallet at gitsea.io/app/burner. You approve the burner contract for the amount you want to burn, then burn. The tokens leave your wallet, land at 0x000…dEaD where no private key exists, and the contract emits an event recording you as a burner. Your GITSEA credit score immediately reflects the boost. The boost lives at the wallet level, never decays, and stacks with your base CreditOracle score.
What it does for $GITLAWB holders.
Reduces circulating supply, permanently. The more burns, the more aggressive the deflation. Every wei sent to the burner is one less wei competing for demand on the open market.
What it does for GITSEA users.
Unlocks a cheaper path to credit. A wallet with a higher credit score gets better terms on credit lines, lower premiums on insurance, more voting weight per stake. Burns layer on top of the base activity score; they don't replace it. The underlying merges, royalty streams, and contract activity still drive the bulk of your reputation.
What it does for the gitlawb ecosystem.
Provides an external, contract-enforced demand sink that doesn't rely on the gitlawb team shipping additional utility. We don't issue $GITLAWB. We don't control its supply. We don't have a partnership signed. We chose, unilaterally, to make our protocol consume it.
The contract has no owner, no fees, no admin keys, no upgrade path. Every wei goes to the dead address. The alignment is contract-enforced and one-way.
We're proud to be part of the gitlawb ecosystem. The work that team is shipping (decentralized git on IPFS, DIDs as agent identity, signed ref-update certificates, libp2p gossip) is the substrate layer the open-source-AI world has been waiting on. GITSEA handles the economic layer. The two protocols solve adjacent halves of the same problem, and the more they compose, the stronger both get. This is our way of saying it out loud.
Visit gitsea.io/app/burner, hold $GITLAWB, burn for the credit boost. Every burn is publicly indexed on chain, no leaderboard gatekeeping.
$GSEA:
0x4af1627b1283c3acc95735dd323b32eab0e6bb07
$GITLAWB: 0x5F980Dcfc4c0fa3911554cf5ab288ed0eb13DBa3
App: gitsea.io/app/burner
Source: github.com/BastianMIllan/git…
7
1
10
868
May 23
GITSEA now accepts merge webhooks from @gitlawb.
POST a signed merge event to gitsea.io/api/gitlawb/webhoo… and the protocol surfaces it for on-chain settlement. The request must be signed by the wallet that owns the repo in RepoVault, verified via EIP-191 recovery against the on-chain record. There's no shared secret, no API key, no coordination with gitlawb's team. The trust root is on-chain ownership.
That closes the only documented gap between GitHub-hosted GITSEA repos and gitlawb-hosted ones. PRs merged on gitlawb now feed into the same settlement path as PRs merged on GitHub. Maintainer (or their agent via @gitsea/mcp) fires SplitsEngine.distributeMerge and contributors get paid in $GSEA on Base.
What this means for a maintainer running a gitlawb node:
Configure a post-merge hook that signs gitsea-gitlawb-merge:{repoUri}:{prHash}:{timestamp} with the same key that links the repo to GITSEA.
POST { repoUri, prHash, timestamp, signature, splits } to the endpoint.
The settlement event is queued and visible on your dashboard. One click (or one MCP tool call) and contributors are paid.
Auto-settle on a pre-funded treasury is the v0.2 opt-in. The architecture is in place; the only thing being deliberate about is whether the protocol should silently pull funds without an explicit per-merge confirmation. That's a maintainer-by-maintainer decision and we'll surface it in the dashboard next.
Docs: gitsea.io/docs/integrations/…
Endpoint (GET for schema): gitsea.io/api/gitlawb/webhoo…
The economic layer for code is one substrate-agnostic step closer to neutral. $gitlawb
May 23
$GSEA now supports $GITLAWB
Repositories hosted on gitlawb's decentralized git network can now have a GITSEA on-chain treasury, splits table, royalty streams, credit lines, and insurance policies. Same primitives as GitHub-hosted repos. Same balance sheet. No GitHub account required.
gitlawb is a decentralized git platform built on IPFS, libp2p, and DID-based identity. Code lives across a peer network instead of on a central server. Until today, that meant gitlawb maintainers had no path to the economic primitives we ship. Their repos couldn't accept on-chain deposits, couldn't define splits, couldn't borrow against future cash flow, couldn't underwrite insurance.
That changes now. The integration ships entirely from our side. No API call into gitlawb, no coordination required with their team. Our RepoVault contract was designed substrate-agnostic. It stores treasuries indexed by bytes32, not by a hardcoded owner/name format. We just taught our hash function to recognize gitlawb's public URL convention. The contracts didn't need a redeployment. The change is in how we derive repo ids on the frontend.
What you can do today:
Link a gitlawb repo to GITSEA. Visit gitsea.io/app/connect, pick the gitlawb tab in step 3, paste your gitlawb://repos/owner/name URL, sign one transaction. The repo now has a treasury at a deterministic address on Base. Anyone can deposit $GSEA into it.
Set a royalty stream between substrates. A gitlawb-hosted parser can stream value to a GitHub-hosted library it depends on, and the dependency's contributors get paid in the same per-second $GSEA flow. The two substrates compose on a single balance sheet.
Run both MCP servers in your AI agent. @gitsea/mcp and @gitlawb/mcp co-exist in Claude Desktop, Cursor, or Cline. One agent reads code from gitlawb, opens PRs there, and settles royalties through GITSEA in the same conversation. No glue code, no proxy server, no protocol translation. Nineteen tools from us, fifteen from them, the agent picks what it needs.
Open a credit line backed by a gitlawb repo. The collateral kind is unchanged from GitHub-hosted lines. Underwriters using $GSEA don't care what substrate the collateral repo runs on, because the credit oracle scores wallets, not repos.
The thesis behind GITSEA is that the economic layer for code should be neutral about where the code lives. GitHub is where most of it lives today, but it's not the only place, and the substrate-agnostic design of our contracts means it doesn't have to be. gitlawb is the first non-GitHub substrate we explicitly support. There can be more.
The cross-protocol DID bridge that would let a wallet's gitlawb merge history contribute to its GITSEA credit score is the natural next thing to build. Reach out on GitHub if you want to help design it.
test now at gitsea.io/app
8
13
1,086
May 23
$GSEA now supports $GITLAWB
Repositories hosted on gitlawb's decentralized git network can now have a GITSEA on-chain treasury, splits table, royalty streams, credit lines, and insurance policies. Same primitives as GitHub-hosted repos. Same balance sheet. No GitHub account required.
gitlawb is a decentralized git platform built on IPFS, libp2p, and DID-based identity. Code lives across a peer network instead of on a central server. Until today, that meant gitlawb maintainers had no path to the economic primitives we ship. Their repos couldn't accept on-chain deposits, couldn't define splits, couldn't borrow against future cash flow, couldn't underwrite insurance.
That changes now. The integration ships entirely from our side. No API call into gitlawb, no coordination required with their team. Our RepoVault contract was designed substrate-agnostic. It stores treasuries indexed by bytes32, not by a hardcoded owner/name format. We just taught our hash function to recognize gitlawb's public URL convention. The contracts didn't need a redeployment. The change is in how we derive repo ids on the frontend.
What you can do today:
Link a gitlawb repo to GITSEA. Visit gitsea.io/app/connect, pick the gitlawb tab in step 3, paste your gitlawb://repos/owner/name URL, sign one transaction. The repo now has a treasury at a deterministic address on Base. Anyone can deposit $GSEA into it.
Set a royalty stream between substrates. A gitlawb-hosted parser can stream value to a GitHub-hosted library it depends on, and the dependency's contributors get paid in the same per-second $GSEA flow. The two substrates compose on a single balance sheet.
Run both MCP servers in your AI agent. @gitsea/mcp and @gitlawb/mcp co-exist in Claude Desktop, Cursor, or Cline. One agent reads code from gitlawb, opens PRs there, and settles royalties through GITSEA in the same conversation. No glue code, no proxy server, no protocol translation. Nineteen tools from us, fifteen from them, the agent picks what it needs.
Open a credit line backed by a gitlawb repo. The collateral kind is unchanged from GitHub-hosted lines. Underwriters using $GSEA don't care what substrate the collateral repo runs on, because the credit oracle scores wallets, not repos.
The thesis behind GITSEA is that the economic layer for code should be neutral about where the code lives. GitHub is where most of it lives today, but it's not the only place, and the substrate-agnostic design of our contracts means it doesn't have to be. gitlawb is the first non-GitHub substrate we explicitly support. There can be more.
The cross-protocol DID bridge that would let a wallet's gitlawb merge history contribute to its GITSEA credit score is the natural next thing to build. Reach out on GitHub if you want to help design it.
test now at gitsea.io/app
May 23
I’m committing to burn $10K worth of Gitlawb for the first project under the Gitlawb ecosystem that reaches $1M market cap.
Builders win.
Holders win.
The ecosystem burns brighter.
9
3
14
5,827
May 23
Linking a repo to GITSEA is the first step. Here is everything that becomes possible the moment you do.
The repo gets an on-chain treasury at its own address. Any wallet, contract, or AI agent can deposit $GSEA into that treasury at any time. The treasury holds value the same way a bank account does, except the books are public and the maintainer is the only one who can withdraw.
You define a splits table. Who gets paid when a pull request lands, in what proportions. The default is a single recipient (yourself), but the structure supports any merkle-root distribution: co-maintainers, contributors, upstream credits, dependency credits. The basis points sum to 10,000 and the last recipient absorbs rounding.
You install the GitHub App. From that point on, every merge on that repo fires distributeMerge on-chain. Contributors get paid in their wallets within seconds, in $GSEA, automatically. A receipt comment lands in the PR thread with the on-chain transaction hash. Nobody has to remember to settle. The merge is the payout.
You can set royalty streams. Per-second flows from your repo to a dependency you rely on, or from a dependent of yours to you. Streams accrue continuously and settle on demand or in batches. The protocol's keeper does this for you every ten minutes, so you don't have to.
You can post your repo as collateral. Open a credit line, draw against your repo's projected cash flow, repay at the agreed rate. Your soulbound credit score, built from your merge history, determines how favorable the terms are.
You can underwrite insurance pools tied to your stack. Other maintainers buy policies against merge-failure or dependency-rot, and you earn the premiums for taking on the risk.
You can open prediction markets on your own pull requests. Capital allocates around which PRs will land, when, and whether they'll get reverted. The pool settles in $GSEA when the merge does or doesn't happen.
One link. Every primitive in the protocol opens up for your repo.
3
2
10
1,392
GITSEA retweeted
May 23
I built GITSEA because the economics of open source are broken and getting worse.
For years I've watched libraries with millions of dependents survive on the unpaid labor of one or two maintainers, until those maintainers burn out and the library quietly rots. I've watched companies build billion-dollar products on top of npm packages whose authors can't afford to fix the bugs they file. I've watched the most-downloaded utilities on every package registry stay free while the value they unlock compounds upstream into things they'll never see a cent of.
That asymmetry was bad when humans were the only consumers. It's about to get worse by orders of magnitude. AI agents now read, copy, and synthesize from open repositories continuously. Every coding agent in production today is, in effect, a parasitic dependency on FOSS that doesn't pay rent. The bigger that loop gets, the more brittle the underlying foundations become.
I wanted an economic layer that fixes this without asking anyone to be charitable. GITSEA is that layer.
Every repository becomes an on-chain object with a treasury and a contributor splits table. Merge a PR, contributors get paid in the same transaction. Set a royalty stream from your repo to the upstream library you depend on, and value flows continuously, per second, the same way HTTP requests do. Stake the protocol token to underwrite credit lines for maintainers borrowing against future cash flow. Insurance pools cover dependency rot. Prediction markets sit over PR resolutions. Every primitive composes on the same balance sheet.
I built it on Base because settlement is cheap there. I built the MCP server so AI agents can stake, deposit, borrow, and settle in natural language, because if AI is going to be the biggest consumer of code, AI should be a first-class economic participant in the protocol, not an externality.
Gitsea is open source btw github.com/BastianMIllan/git…
May 23
GITSEA is now live. The sovereign credit layer for code: every repository gets an on-chain treasury, royalty streams between repos, stake-weighted governance, soulbound contributor credit, and parametric insurance.
CA: 0x4AF1627B1283c3aCC95735dD323b32EAB0e6BB07
The app at gitsea.io/app is open to anyone with a wallet. The contracts are deployed on Base mainnet and frozen at their published addresses. The event indexer is caught up. The MCP server is on npm. The GitHub App is installable. Every primitive the protocol promised is operational.
$GSEA is live too. It is the settlement currency the contracts were built around. Stake it to earn governance weight and a slice of protocol fees. Hold it in a repo treasury to receive royalty streams from dependents. Post it as collateral to open a credit line. Underwrite parametric insurance pools with it. The ten contracts that make up GITSEA all denominate value in $GSEA, and now that the token is bound, every read, write, and settlement path runs end-to-end.
This is what the protocol was designed to do, in one place, settling on the same balance sheet. A maintainer links a repo and starts receiving merge payouts the moment a contributor's pull request lands. A capital provider stakes into the protocol, earns fee share, votes on parameter changes. An underwriter opens credit lines for borrowers backed by repo cash flow. An AI agent reads its principal's credit score, opens a position, and signs the transaction in one turn.
8
3
16
3,708