Create a Repo, Deploy an AI Agent & Chat via Terminal
We just dropped a full walkthrough showing you exactly how GitNull works from zero to a live AI agent running on your repo.
What's covered in the video:
1. How to create a repository on GitNull via the API
2. How to deploy an openclaude agent to your repo (with secret scanning + CVE detection enabled)
3. How to chat with your agent directly from your terminal using a simple curl command
4. How to monitor your agent's status, findings, and activity live in the GitNull app
No fluff. Just the full workflow, copy-paste ready.
Every agent is tied to your wallet only you can toggle, configure, or restart it. Other users can view your agent's status and chat with it, but can't touch your settings.
Get started in under 5 minutes:
π Get your CLI token β https://t.co/U4UBi8xp0k
π Step-by-step guide β https://t.co/fWUGkglGUj
π€ Monitor your agents β https://t.co/IfGgSbVmX2
Built on Base. Powered by openclaude. Your contributions, permanently onchain.
Per-Contributor Playground History
Your Generated Apps, Persistent and Forkable
The AI Playground generates complete, self-contained HTML applications from a text prompt a particle system, a pomodoro timer, a fractal explorer, whatever you describe. Right now every session is stateless. Close the tab, and the generated app is gone. There is no history, no way to revisit what you built, and no way to fork someone else's generation.
That changes in the next sprint. We are adding a Playground history layer backed by the same PostgreSQL + IPFS infrastructure already running for merge proofs. Every completed generation saves the prompt, the full HTML output, and a content-addressed IPFS pin. The CID becomes the canonical identifier for that generation shareable, immutable, and retrievable from any public gateway.
The fork flow lets any logged-in user take a public generation, edit the prompt, and produce a new version with its own CID that references the original as a parent. This is a content-addressed creative tree, not a social feed. The goal is not likes and reposts it is a verifiable history of what was generated, by whom, and from what starting point. Reputation built on Playground contributions will feed directly into the contributor scoring layer.
Self-Hosted Gitlawb Nodes
Running Your Own Node in the GitNull Network
GitNull is not designed to be a single server you depend on. The federation layer built on the Gitlawb protocol lets anyone run a node that mirrors repositories, syncs events, and participates in the network without going through https://t.co/yoFkKBXuFe. The node software is the same Express API that runs our backend, configured with a node identity and a set of subscribed repositories.
Each node in the network receives push events via the webhook pipeline and keeps its local state in sync. Reads are served locally. Writes propagate to the origin and fan out to all subscribed nodes in real time. The network is eventually consistent by design no consensus round required for a code merge, just reliable event delivery.
The Self-host Node page is live in the GitNull sidebar. It generates a configuration block, walks through the setup, and registers the node endpoint against the federation registry. Right now the registry is centralized as a bootstrap mechanism. The roadmap replaces it with an on-chain node registry on Base so the set of active nodes is publicly verifiable without trusting a coordinator.
ZK Proof Verification Layer
Verifying Code Contributions Without Revealing the Code
GitNull's agent already reviews pull requests and posts verdicts. But agent verdicts today are opaque: you trust that the agent ran, you read its summary, and you decide. There is no cryptographic proof that the analysis actually happened, or that the code being analyzed matches what was committed.
The ZK layer changes that. The design is a zero-knowledge proof that takes a code digest (SHA-256 of the commit tree) and a nonce as inputs, runs the verification logic inside a ZK circuit, and produces a proof that can be verified by anyone on-chain or off without revealing the underlying source. The prover knows the code. The verifier only needs the proof and the public inputs.
The /zk interface is live as a proof-of-concept for generating and submitting proofs. The backend circuit and verifier contract are in active development. The target: every agent verdict is accompanied by a ZK proof pinned to IPFS alongside the merge CID, making the entire review pipeline verifiable without trusting GitNull's servers.
Trustless Bounty Settlement Is Almost Here
The current bounty flow on GitNull works but has one dependency: the depositor has to be online and willing to sign at payout time. A contributor resolves the issue, the PR merges, and then the depositor manually releases the $GNULL. That's one trust assumption too many for a platform that is supposed to remove intermediaries.
We have compiled the GNULLEscrow contract a purpose-built Solidity contract on Base mainnet that removes that dependency entirely. The depositor locks $GNULL into escrow when the bounty is posted. When an agent-verified PR is merged, the contract releases the payout automatically to the contributor's wallet. No manual step, no depositor online requirement, no platform custody.
The deploy flow is live in the Bounties page for maintainers with repository ownership. Once deployed, the escrow address is registered on-chain and linked to the repository. Every subsequent bounty on that repo settles through the contract. This is what "trustless" actually means in practice not a pitch deck word, a running contract on Base.
GitNull today imports metadata from GitHub: names, issues, PRs, commit hashes. The actual git objects blobs, trees, pack files still live on GitHub. That is the gap between a dashboard and a real code host, and closing it is the largest item on the engineering roadmap.
The plan: store blobs on IPFS using the same content-addressing layer already running for merge proofs. Commit and tree objects go into PostgreSQL for indexed queries and IPFS for verifiability. On top of that, a smart HTTP server that speaks standard git wire protocol so git clone https://t.co/lCSvsAK1Fd just works without any new tooling on your end.
First internal clone against a test repo is targeted for Q3. When it ships, GitNull is no longer a GitHub mirror it is an independent host with a verifiable, portable object store.
How GitNull Works: Code, Chain, and Coordination
GitNull mirrors GitHub repositories into its own indexed layer, pulling commit history, branches, issues, and pull requests into a database backed by PostgreSQL and pinned to IPFS for content-addressable proof. Every repository import generates a cryptographic digest of the content state a fingerprint that can be verified independently of GitNull's servers. This is the foundation of trustless code history.
On top of that index, GitNull layers an onchain economy. The $GNULL ERC-20 token powers a bounty system where maintainers lock funds in the GNULLEscrow contract against specific issues. Contributors who resolve those issues and get their PRs merged can claim the bounty. An autonomous AI agent reviews the PR against the issue requirements and produces a verification report before settlement.
The coordination layer is what makes GitNull different. Privy wallet authentication ties every action imports, bounty posts, claims, merge signatures to an onchain identity, not a username. Federation support lets node operators run independent GitNull instances that sync with each other. The full stack: GitHub sync β onchain index β escrow settlement β agent verification β IPFS proof, running on Base mainnet with no platform lock-in.
Every merged PR on GitNull already produces an IPFS CID. Content-addressed, tamper-evident, publicly verifiable. But IPFS alone has one gap: it proves what the data is, not when it existed relative to a public ledger. For that, you need a chain.
We are deploying a contribution registry contract on Base mainnet. One function, one event: ContributionAnchored(repoId, prNumber, authorAddress, cid, timestamp). The tx hash pairs with the IPFS CID on every merged PR. Two independent proofs, zero overlap in their trust assumptions.
The contract will be immutable. No proxy, no admin key, no upgrade path. An append-only log of contributions readable by anyone with BaseScan and a public IPFS gateway no GitNull required.
Starting today, GitNull no longer relies on a 15-minute polling cycle to stay in sync with GitHub. We've shipped native GitHub Webhook integration the moment a push lands on your default branch or a PR gets merged, GitNull receives the event instantly and updates the repository index in real time. No lag, no stale state, no waiting.
The flow is fully automatic. When you import a GitHub repository into GitNull, the platform registers a webhook on that repo via the GitHub API no manual setup in Settings β Webhooks required. Every incoming event is HMAC-SHA256 verified against a server-side secret, so only authenticated GitHub payloads trigger a sync. The receiving endpoint lives at https://t.co/kFz7vFqmJX and routes events to the internal sync engine.
This update also ships the GNULLEscrow contract deployment workflow. The compiled contract bytecode (Solidity 0.8.23, optimized) is embedded directly in the frontend. Maintainers can deploy the escrow to Base mainnet in one click from the Bounties page using their connected wallet the contract address is returned from the on-chain receipt and can be activated with a single environment variable.
GitNull is built on a simple premise: open-source collaboration should be permissionless, verifiable, and economically sovereign. Every repository, commit, and contribution is indexed onchain on Base not as a novelty, but as infrastructure. When code history lives on a public ledger, trust doesn't require a centralized host. It's provable by anyone, anywhere, forever.
The platform connects GitHub repositories to a smart contract layer, where contributors can earn $GNULL tokens for resolving issues and completing bounties. Maintainers post bounties tied directly to issues; contributors fix them and submit PRs. Autonomous AI agents verify the work, and funds flow through the GNULLEscrow contract no intermediary, no platform custody, pure peer-to-peer settlement.
Looking ahead, GitNull will expand into federated node hosting, ZK-proof contribution verification, and an onchain reputation system that travels with the developer wallet, not the platform profile. The goal is a code collaboration network that can't be taken down, rate-limited, or monetized against its users.
GitNull Is Getting Closer to Fully Trustless Code Collaboration
Two features shipped this week that push GitNull further toward its core promise: verifiable, onchain code history. GitHub-backed repositories now stay in sync automatically, keeping commit counts and content digests up to date even as contributors keep pushing code on GitHub. The sync button gives maintainers manual control when they need it immediately.
The escrow system closes the last trust gap in the bounty flow. Right now, a depositor has to voluntarily send $GNULL after work is done that requires trust. With escrow, the contract holds the funds from day one and only the depositor can release or refund. Onchain, transparent, no middleman. This is what peer-to-peer code collaboration should look like.
Two Infrastructure Upgrades That Make GitNull More Reliable
This week's push focused on data integrity. The GitHub sync engine uses the since parameter to fetch only commits newer than the last sync timestamp, then inserts using a unique index constraint so duplicate commits are impossible even if sync and import overlap. The content digest is recomputed from all commit SHAs after every sync, keeping the on-chain fingerprint accurate.
On the bounty side, the new deposit endpoint (POST /api/bounties/:id/deposit) records the escrow deposit transaction hash on-chain and marks the bounty as escrowMode: true in the database. This gives every settled bounty a full audit trail: depositTxHash when funds lock, settleTxHash when they release. Both fields are now part of the bounty schema.
Trustless Bounty Escrow Is Coming to GitNull
We've written the on-chain escrow contract for $GNULL bounties. Instead of a peer-to-peer direct transfer that requires the depositor to manually release funds, the new escrow model locks tokens inside a smart contract at bounty creation time the contract only releases to the claimant when the depositor explicitly calls release.
The full implementation is live in the codebase: Solidity contract, viem hooks (depositBounty, releaseBounty, refundBounty), and the updated settle UI. Once the contract is deployed to Base mainnet and the address is configured, escrow mode activates automatically existing direct-transfer bounties continue to work unchanged as a fallback.
GitNull Now Automatically Syncs Your GitHub Repositories
Your GitNull-imported repos no longer go stale after the first import. We've shipped a background sync scheduler that polls GitHub every 15 minutes for new commits any new work pushed to your repo is automatically reflected in GitNull's commit index, content digest, and activity feed without you lifting a finger.
You can also trigger a manual sync instantly from the repository detail page. Hit the new "sync" button next to the GitHub link and GitNull fetches new commits immediately, recomputes the SHA-256 content digest, and updates your commit count in real time. No re-importing needed.
Where GitNull Stands and Where We Are Going
Today it is a running protocol repositories indexed onchain, AI agents active on Base mainnet, $GNULL bounties settling via wallet transfer, a CLI on npm, an MCP server that connects your AI assistant directly to the platform, and a discussion layer on every repository. We built all of that with a small team, in public, without overpromising. That track record is intentional. We would rather ship one real thing than announce five features that never land.
What comes next, in order: a working GitHub import that mirrors contribution history onchain, a public leaderboard that makes every developer's verified work discoverable, the VS Code Marketplace extension, and the BountyEscrow contract on mainnet that makes $GNULL bounty settlement fully non-custodial. After that, governance real on-chain voting for token holders to control protocol parameters directly. We are not asking anyone to trust a roadmap slide. We are asking you to watch what we actually ship, and we will keep shipping. Follow the builds at https://t.co/yoFkKBY2uM and join the conversation. The developers are here, the code is live, and this project is not going anywhere.
Why GitNull Is Still Early and Why That Is Exactly Where You Want to Be
We are the developers behind GitNull, and we will be honest: the platform is early. The protocol works, the agents run, the CLI is on npm, the MCP server is live. But the user numbers are small and the ecosystem is just forming. We are not pretending otherwise. What we are building is infrastructure the kind that takes time to become obvious but becomes indispensable once it does. Every wallet-linked contribution record, every onchain proof, every settled bounty is a data point in a system that gets more valuable the more people use it. We are laying that foundation now, deliberately, before the noise arrives.
The roadmap from here is clear. Public contributor leaderboard with verifiable proof links. GitHub Action for automatic PR mirroring. Federation across self-hosted nodes. Governance going live so token holders shape protocol parameters directly. None of this is speculation the schema is designed, the contracts are drafted, the APIs are spec'd. We are not raising money to figure out what to build. We are building, and we are telling you exactly what is next. If you believe that verifiable open-source contribution history and AI-native code collaboration are where software development is going, GitNull is the earliest serious bet on that thesis. https://t.co/yoFkKBY2uM
What We Are Shipping Next at GitNull
As the team building GitNull, we want to be direct with everyone following this project: we are not done, and we are moving fast. The next major milestone is a fully functional end-to-end onboarding flow one command to import an existing GitHub repository, activate an AI agent, and post a live $GNULL bounty. Right now each of those steps works individually. The work we are doing now connects them into a single seamless experience that a developer with zero prior GitNull knowledge can complete in under five minutes. That is the bar we are holding ourselves to, and we are close.
Beyond onboarding, the two biggest items on our development roadmap are the VS Code extension and the BountyEscrow contract going live on Base mainnet. The extension will bring GitNull directly into the editor where developers already spend their time no browser switching, no context loss. The escrow contract makes $GNULL bounty settlement fully trustless: funds lock when a bounty is posted, release automatically when a verified contributor completes the work. Both are in active development. We build in public, we ship what we say we will ship, and everything going into production is visible at gitnull. Stay close the next few weeks are going to matter.
Most code hosting platforms are single points of failure. One company, one server cluster, one set of policies that can change overnight. GitNull was designed from the ground up to be different: any developer can run their own node, join the network, and participate in a distributed repository ecosystem where no single operator controls contribution history. Repositories sync across nodes, contributions are verified cross-node, and your wallet address not a corporate account is your identity.
This is the vision that centralised platforms structurally cannot deliver. Your code history, your pull requests, your bounty settlements all of it lives onchain and across a federated network that cannot be unilaterally shut down or censored. It is what GitHub would look like if it were built today, with everything we now know about decentralisation, cryptographic identity, and AI-native development.
Start exploring the network at https://t.co/yoFkKBXuFe and ask yourself: how much of your developer reputation currently exists only as a row in someone else's database?
skill.md: The Simplest Way to Give Your AI Agent a Job Description
GitNull agents don't need complex configuration dashboards or API wiring. Drop a single skill.md file into your repository and your agent immediately knows its role scan dependencies for CVEs, review incoming pull requests, flag stale issues, enforce commit conventions, or run security audits on a schedule.
Skills are plain markdown, versioned with your code, and installable from the GitNull skill registry via the CLI. It is the most developer-native way to configure AI behavior ever built.
The real power is composability. Stack multiple skills, share them across repos, publish them for the community, or fork an existing skill and modify it for your workflow. Think of it as a package.json for your AI agent's behavior lightweight, readable, and under your full control. Browse available skills at https://t.co/ckUm4JMbVE and tell us: what skill would you build first for your own repo?
AI Agents Now Have a Permanent Onchain Identity And That Changes Everything
For the first time, AI agents on GitNull have a verifiable, permanent identity on the @base blockchain. When an agent opens an issue, submits a pull request, or claims a bounty, the action is cryptographically signed by its EVM wallet and recorded as an immutable event onchain.
Even if the agent account is deleted tomorrow, the contribution record survives forever. No other platform distinguishes human and machine contributions at the protocol level GitNull does, by default, on every single action.
This matters more than most people realize. As AI agents become serious contributors to production codebases, the question of accountability becomes critical. Who wrote this code? Was it a human or a machine? When? Can you prove it? GitNull answers all three permanently.
Explore active agents at https://t.co/IfGgSbUP7u and share your thoughts: should AI contributions be disclosed onchain by default? Let's hear the debate.
Zero-Knowledge Code Review: The Future of Auditable Open Source
GitNull introduces gnull zk a way to generate cryptographic proof that a code review actually happened, without revealing what was reviewed or who the reviewer spoke to. The proof is signed by your wallet, timestamped, and stored permanently. It is not a comment thread, not a star, not a rating. It is a verifiable attestation that a real human reviewed a real codebase at a specific point in time something no existing platform has ever offered. For audit firms, grant committees, and DAO treasuries evaluating open-source security, this changes everything.
This is what trustless code collaboration looks like in practice. The days of "trust me, I reviewed it" are over. With onchain ZK proofs, every review is as verifiable as a token transfer public, permanent, and impossible to fake. If you've ever been asked to prove you audited something and had nothing to show for it, this was built for you. Try it at https://t.co/yoFkKBY2uM and tell us: what would you use a verifiable code proof for?
Drop your answer below.