𝗪𝗵𝗲𝗻 𝗰𝗼𝗱𝗲 𝗶𝘀 𝗴𝗲𝗻𝗲𝗿𝗮𝘁𝗲𝗱 𝗳𝗮𝘀𝘁𝗲𝗿 𝘁𝗵𝗮𝗻 𝗶𝘁 𝗰𝗮𝗻 𝗯𝗲 𝗿𝗲𝗺𝗲𝗺𝗯𝗲𝗿𝗲𝗱 We are entering an era where code is produced at a rate never seen before. AI systems can generate repositories, refactor large codebases, and produce entire features in minutes. The bottleneck is no longer typing — it’s understanding, coordination, and accountability. As the volume of code increases, something subtle happens: it becomes harder to answer simple questions. What exactly existed at a given moment? Who approved this release? What source state was this artifact supposed to correspond to? When did this change become authoritative? When code is generated rapidly, intent becomes easier to reconstruct after the fact. Facts do not. This is not an argument against AI. It is an argument for stronger evidence infrastructure. If software is increasingly generated, modified, and assembled at machine speed, then preserving durable, inspectable records of source states and release intent becomes more important — not less. The future may involve more automation. But automation without memory becomes noise. In an era of abundant code, what matters is not just what can be produced — but what can be preserved. Software needs memory. CodeQuill is building memory infrastructure for software.

we asked our ETHGlobal New York Spotlight teams to share advice for first-time hackers this weekend. here’s what they had to say 👇 credits: @RailBridgeAI @CodeQuillClaim @pampalodotcom @AquaZero0

🌟 ETHGlobal New York Spotlight: @CodeQuillClaim CodeQuill is onchain memory for software, preserving source states, release intent, and lineage claims. Catch the team at their booth and see it in action! ethglob.al/oxMQOTu | codequill.xyz

We are finally @ETHGlobal NY hackathon with our Spotlight booth! Come say hi and learn more 👀 #BOOELIEVE Special thanks to @Bookof_Eth of their incredible support 🙏📘

ETHGlobal New York Spotlight. 🗽✨ Book Of Ethereum will be featured alongside @CodeQuillClaim during ETHGlobal NYC. 🙏📖 Last year at @ETHGlobal NYC was the moment CodeQuill was born and first revealed. Almost one year later, @dadajuice_crypto kept building through the noise and turned the vision into something real for Ethereum’s future. 👇 CodeQuill is building an onchain memory layer for software: preserving source history, release intent and software lineage in a world where code is evolving faster than ever. This is the type of Ethereum aligned infrastructure and frontier building that deserves attention. We are grateful as BOOElievers to receive recognition from an organization like @ETHGlobal and we will take this opportunity with both hands. And NYC doesn’t stop there… Book Of Ethereum is organizing it’s own side event togheter with @strato_net during @ethconf NYC bringing together Ethereum culture, builders, memes, HardFi and community. 🍸⚡ Come meet the BOOElievers, experience the energy of Ethereum culture and be part of what we are building together in NYC. Let’s make this year’s edition Epic🙏🙏🙏📖 Sign up for our event👇 luma.com/of3zm3c5

⭐️ Introducing ETHGlobal New York Spotlight: @CodeQuillClaim An onchain memory for software — preserving source states, release intent, and lineage claims in a world where code is produced faster than it can be. ethglob.al/oxMQOTu | codequill.xyz

Nine months. Eight immutable contracts. One thesis. CodeQuill is live on @base. Source code is the most reproduced asset in the world. And the least preserved. Repos vanish. Authorship gets murky. History gets rewritten. CodeQuill writes the receipts as code is built. On-chain, immutable, verifiable by anyone. Memory infrastructure for software. codequill.xyz

𝗖𝗼𝗱𝗲𝗤𝘂𝗶𝗹𝗹 𝗰𝗼𝗻𝘁𝗿𝗮𝗰𝘁𝘀 𝗮𝗿𝗲 𝗻𝗼𝘄 𝗽𝘂𝗯𝗹𝗶𝗰 As we get closer to release, the core CodeQuill smart contracts are open. These contracts implement the on-chain primitives the system is built on: claims of authority, source snapshots, releases, attestations, preservation, and delegation. They are fully permissionless. Anyone can inspect them, reason about them, and build on top of them. Their job is narrow but critical: record durable facts. What source code existed. When it existed. Under whose authority. What claims were made about it. The application layer coordinates, through our CLI and Web interface, the workflows, surfaces evidence, and makes these primitives usable at scale. But the rules that govern the evidence live on-chain, in the open. If CodeQuill is meant to preserve evidence, the mechanisms that record that evidence must themselves be visible and understandable. Architecture diagrams, a permission matrix, and threat model notes are included to make the design legible, not just executable. Ethereum works best when infrastructure explains itself. Repository: github.com/codequill-claim/c… If this is interesting to you, starring the repo and following along on GitHub is the best way to stay close to where the work happens. Much more coming soon.

𝗣𝗿𝗶𝗺𝗶𝘁𝗶𝘃𝗲 𝗩𝗜 - 𝗔𝘀𝘀𝗲𝗿𝘁𝗶𝗻𝗴 𝗮𝗿𝘁𝗶𝗳𝗮𝗰𝘁 𝗹𝗶𝗻𝗲𝗮𝗴𝗲 Once a release is defined, another question follows: What artifacts are claimed to originate from it? In CodeQuill, this is handled through attestations. An 𝗮𝘁𝘁𝗲𝘀𝘁𝗮𝘁𝗶𝗼𝗻 records a statement made by an authority: that a given artifact claims lineage from a specific release. It is a claim — not a proof. CodeQuill does not observe how the artifact was built. It does not guarantee build causality. Instead, it preserves the statement itself as evidence: who made the claim, what artifact was referenced, and which release it was associated with. That distinction matters. Attestations allow lineage claims to be examined later — compared against preserved source states and evaluated in context, even if build systems, logs, or registries are no longer available. They turn assumptions into explicit records. So trust can be reasoned about — not inferred.

𝗣𝗿𝗶𝗺𝗶𝘁𝗶𝘃𝗲 𝗩 — 𝗥𝗲𝗹𝗲𝗮𝘀𝗲 𝗜𝗻𝘁𝗲𝗻𝘁 At some point, software moves from source code to release. A specific repository state is selected and declared as the version meant to ship, govern, or be referenced. Yet this moment — the intent to release — is rarely preserved explicitly. In CodeQuill, this is where 𝗥𝗲𝗹𝗲𝗮𝘀𝗲𝘀 come in. A Release is a deterministic, human-readable record linking a repository snapshot to an explicit release intent, recorded at a point in time under a specific authority. It is: • evidence of selection • evidence of intent to release • evidence of coordination A Release declares: this source state is what we intend to release. That declaration can come directly from the repository authority or through external governance — such as DAO voting or other approval processes. This makes a release more than a technical event. It becomes a coordination point between code, governance, and infrastructure — a stable reference that other systems can rely on: governance decisions, ENS records, and downstream artifact attestations. By making release intent explicit and durable, CodeQuill turns what is usually an implicit step into a verifiable record. Releases become the point where source code and governance meet.

𝗣𝗿𝗶𝗺𝗶𝘁𝗶𝘃𝗲 𝗜𝗩 — 𝗣𝗿𝗼𝘃𝗶𝗻𝗴 𝗮 𝗳𝗶𝗹𝗲 𝘄𝗮𝘀 𝗶𝗻𝗰𝗹𝘂𝗱𝗲𝗱 Once a source state is preserved, a simple question often follows: Did a specific file actually exist in that state? This question appears during audits, after incidents, or when changes are disputed and trust becomes uncertain. CodeQuill is designed to answer it without ambiguity. From a preserved source state, an authority can produce a proof that a specific file was included — not by assertion, but by reference to preserved evidence. Producing the proof may require authority, because revealing it can disclose details. But verifying the proof does not. Once shared, anyone can independently verify it through cryptographic checks against the preserved record. The proof answers a narrow question: Was this file part of the preserved source state at that moment? It does not interpret intent or justify behavior. But that narrow question matters. Because it moves discussions from speculation to verifiable fact.

𝗣𝗿𝗶𝗺𝗶𝘁𝗶𝘃𝗲 𝗜𝗜𝗜 - 𝗣𝗿𝗲𝘀𝗲𝗿𝘃𝗶𝗻𝗴 𝘀𝗼𝘂𝗿𝗰𝗲 𝘄𝗶𝘁𝗵𝗼𝘂𝘁 𝗰𝘂𝘀𝘁𝗼𝗱𝘆 Preserving evidence is not the same thing as backing up data. Backups are operational. They assume access, recovery processes, and administrative control. Evidence preservation is different. Its purpose is not convenience or availability. Its purpose is to ensure that facts can still be inspected long after systems, organizations, or platforms have changed. In CodeQuill, preservation means preserving the complete source code associated with a snapshot — the exact files and contents that existed at that moment — bound to an already recorded piece of evidence. The source code is encrypted client-side, before it leaves the local environment, and remains unreadable without explicit authority. This is intentional. Preserving evidence should not expand custody, centralize access, or introduce recovery dependencies on CodeQuill itself. CodeQuill cannot read preserved source code, and it cannot recover it on behalf of users. Preservation exists for audits, investigations, and long time horizons — not for builds, not for deployment, and not for operational workflows. Encrypted preservation is optional. It complements provenance records It ensures that evidence can survive change.

𝗣𝗿𝗶𝗺𝗶𝘁𝗶𝘃𝗲 𝗜𝗜 - 𝗠𝗮𝗸𝗶𝗻𝗴 𝘀𝗼𝘂𝗿𝗰𝗲 𝗮 𝗳𝗮𝗰𝘁 (𝗦𝗻𝗮𝗽𝘀𝗵𝗼𝘁) Source code is often referenced indirectly. By a commit hash. By a branch name. By a repository state that is assumed, but rarely preserved. But assumptions are not evidence. To reason about provenance, the source itself must become a fact. A snapshot captures a repository at a specific moment — the exact contents that existed, under a specific authority — and turns that state into a concrete record. Not an interpretation. Not a summary. A description of what existed. 𝗦𝗻𝗮𝗽𝘀𝗵𝗼𝘁𝘀 𝘁𝘂𝗿𝗻 𝘀𝗼𝘂𝗿𝗰𝗲 𝗰𝗼𝗱𝗲 𝗳𝗿𝗼𝗺 𝗮𝗻 𝗮𝘀𝘀𝘂𝗺𝗽𝘁𝗶𝗼𝗻 𝗶𝗻𝘁𝗼 𝗮 𝗳𝗮𝗰𝘁. A concrete, verifiable record of what existed at a given moment, under a given authority. This matters because provenance cannot start from ambiguity. If the source state is unclear, everything that follows inherits that uncertainty. CodeQuill snapshots are produced locally, where the code already exists. They describe source state deterministically and preserve it as durable evidence. Once recorded, a snapshot provides a stable reference point — builds, attestations, and investigations can point back to over time. This does not prove how software was built. It makes the source state explicit. Snapshots make source code a fact. Provenance can begin from there.

𝗣𝗿𝗶𝗺𝗶𝘁𝗶𝘃𝗲 𝗜 - 𝗠𝗮𝗸𝗶𝗻𝗴 𝗮𝘂𝘁𝗵𝗼𝗿𝗶𝘁𝘆 𝗲𝘅𝗽𝗹𝗶𝗰𝗶𝘁 (𝗖𝗹𝗮𝗶𝗺) In most software systems, authority is implicit. It is inferred from access: who can push code, merge branches, or run pipelines. But access changes. Credentials rotate. Automation evolves. Over time, it becomes difficult to answer a simple question: who was actually allowed to speak for this repository at that moment? CodeQuill makes authority explicit. A 𝗰𝗹𝗮𝗶𝗺 records which authority is allowed to publish evidence for a repository. It does not describe what was built, or how. It establishes who is authorized to make statements about the source. This distinction matters. Execution can be delegated — to developer machines, CI systems, or automation — without changing who ultimately speaks for the repository. By separating authority from execution, CodeQuill reduces ambiguity about authorship and responsibility over time. Claims do not prove intent. They do not guarantee correctness. They make authority visible. In provenance systems, clarity about who can speak matters as much as clarity about what existed.

"Code is produced faster than it can be remembered" - this is the quiet crisis nobody talks about. We're building the future on foundations that could disappear from GitHub tomorrow. Durable on-chain evidence of what existed, when, and by whose authority is infrastructure that should've existed years ago. Watching this closely.

𝗖𝗼𝗱𝗲𝗤𝘂𝗶𝗹𝗹 𝗶𝘀 𝘀𝘁𝗲𝗽𝗽𝗶𝗻𝗴 𝗶𝗻𝘁𝗼 𝘁𝗵𝗲 𝗼𝗽𝗲𝗻 The landing page is now live. codequill.xyz We’ve spent months defining a simple idea: 𝘀𝗼𝗳𝘁𝘄𝗮𝗿𝗲 𝗻𝗲𝗲𝗱𝘀 𝗱𝘂𝗿𝗮𝗯𝗹𝗲 𝗺𝗲𝗺𝗼𝗿𝘆. If you’ve been following the thinking behind CodeQuill — about source as evidence, releases as intent, and durable on-chain records — this is the first complete overview of what we’re building. CodeQuill is source-centric evidence infrastructure for software. It introduces explicit authority, deterministic source snapshots, project releases, attestations, and preservation — all anchored on Ethereum. The goal is simple: Preserve durable facts about software in an era where code is produced faster than it can be remembered. Public beta on Sepolia is coming soon and will be open to everyone. You’ll be able to claim repositories, publish snapshots, create releases, and record attestations in a live environment before mainnet. If you care about long-term integrity in software, governance, or Ethereum-native coordination — take a look. This is just the beginning.

𝗘𝘃𝗶𝗱𝗲𝗻𝗰𝗲 𝘄𝗶𝘁𝗵𝗼𝘂𝘁 𝗳𝗼𝗿𝗰𝗲𝗱 𝗱𝗶𝘀𝗰𝗹𝗼𝘀𝘂𝗿𝗲 Not all evidence should be publicly inspectable by default. In many systems, verifiability is achieved by making everything visible: file paths, repository structure, internal organization. That approach maximizes transparency — but it also forces disclosure. CodeQuill takes a different stance. Its goal is to preserve durable evidence about source code 𝘄𝗶𝘁𝗵𝗼𝘂𝘁 𝗿𝗲𝗾𝘂𝗶𝗿𝗶𝗻𝗴 𝗱𝗶𝘀𝗰𝗹𝗼𝘀𝘂𝗿𝗲 𝗼𝗳 𝗿𝗲𝗽𝗼𝘀𝗶𝘁𝗼𝗿𝘆 𝘀𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗲 𝗼𝗿 𝗰𝗼𝗻𝘁𝗲𝗻𝘁𝘀. That means some forms of public verification are intentionally scoped. Snapshots preserve cryptographic facts about source state, but details that would reveal internal structure are protected. Verification is possible — but it requires explicit authority to disclose what is being proven. This is not an accident. It is a deliberate tradeoff. Preserving evidence should not require exposing private codebases, internal layouts, or sensitive project details. Evidence and transparency are related — but they are not the same thing. CodeQuill preserves evidence without forcing disclosure. Verification is possible, but intentionally scoped.

𝗣𝗿𝗲𝘀𝗲𝗿𝘃𝗶𝗻𝗴 𝗳𝗮𝗰𝘁𝘀 𝘂𝗻𝗱𝗲𝗿 𝗵𝗼𝘀𝘁𝗶𝗹𝗲 𝗮𝘀𝘀𝘂𝗺𝗽𝘁𝗶𝗼𝗻𝘀 Many software systems are designed under optimistic assumptions. That logs are accurate. That services are available. That infrastructure behaves as expected. Most of the time, those assumptions hold. But provenance systems are not built for most of the time. They are built for the moments when assumptions fail. CodeQuill is designed under deliberately hostile assumptions:   • CI pipelines can be compromised.   • Logs can be altered, lost, or selectively retained.   • Registries can disappear or change behavior.   • Organizations and platforms can change over time. Under those conditions, explanations are easy to rewrite. Facts are not. CodeQuill focuses on preserving verifiable evidence of source code state so that facts remain inspectable even when surrounding systems are no longer trustworthy. This does not prevent incidents. It does not guarantee correctness. And it does not remove the need for judgment. What it does is reduce ambiguity after the fact. When questions arise, preserved evidence matters more than reconstructed narratives.

𝗦𝗼𝘂𝗿𝗰𝗲 𝗶𝘀 𝗲𝘃𝗶𝗱𝗲𝗻𝗰𝗲, 𝗻𝗼𝘁 𝗶𝗻𝘁𝗲𝗻𝘁 Source code is often treated as a statement of intent — what the authors meant to do, what the system was supposed to be. But source code is not intent. It is evidence. At any given moment, source code exists as a concrete state: specific files, specific contents, under a specific authority. Intent lives in discussions, tickets, pull requests, and memory. Source code lives in files. When incidents occur, intent is easy to reinterpret. Source code is not. CodeQuill treats source code as evidence for this reason. It focuses on preserving verifiable, immutable records of what source code actually existed — not what it was intended to be, explained to be, or later remembered as. This does not resolve disputes. It does not assign blame. And it does not interpret meaning. It preserves facts. Provenance starts by separating evidence from intent.