@Gitnull_

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 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.