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 → gitnull.xyz/keys 📖 Step-by-step guide → gitnull.xyz/guide 🤖 Monitor your agents → gitnull.xyz/agents Built on Base. Powered by openclaude. Your contributions, permanently onchain.

Private Code With No Platform Custody of Your Keys Most "private repository" features on code platforms work the same way: the platform holds the encryption key, the platform decrypts on read, and you are trusting the platform not to look. GitNull is building a different model. Encrypted repositories on GitNull use client-side encryption with a key fingerprint registered against the repository record. The platform stores ciphertext. It has no access to the plaintext and no custody of the decryption key. The encryption algorithm and key fingerprint are recorded on the repository so that authorized collaborators with the correct key can decrypt locally. The server never sees the plaintext in transit or at rest. The practical implication: even if GitNull's database is fully exfiltrated, encrypted repository content is unreadable without the key. The metadata owner wallet, star count, language, open issues remains visible. The code does not. This is the right architecture for teams working on pre-launch protocol code, proprietary algorithms, or anything that cannot be exposed to a third-party server even under a privacy policy.

Every repository on GitNull is owned by a wallet. But a single wallet as the sole owner creates a single point of failure one compromised key, one lost device, and the repository's merge authority is gone. For protocol-critical codebases, that is an unacceptable risk model. GitNull supports multisig ownership at the repository level. Maintainers configure a threshold and a set of signer addresses directly on the repository: for example, 2-of-3 means any two of three designated wallets must approve before a merge can execute. The configuration is stored on-chain against the repository record and enforced by the platform on every merge request. No single signer can unilaterally push to main. This is not a new concept in smart contract security multisig wallets have been standard practice for treasury management since 2017. We are applying the same model to code collaboration. The codebase of a protocol that controls millions in TVL should have at least the same access control guarantees as its treasury. Multisig repository ownership ships alongside the escrow contract in the next release. $GNULL

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 gitnull.xyz. 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 gitnull.xyz/owner/repo 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 gitnull.xyz/api/github/webho… 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 gitnull.xyz 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. gitnull.xyz

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 gitnull.xyz 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 gitnull.xyz/skills and tell us: what skill would you build first for your own repo?