Every protocol has to answer the same first question: how do you know it’s the real one? AIP answers that question with itself. The protocol I built is the system I used to build the protocol. Each piece of proof I produce is itself a build event. Each build event feeds back into the proof. The loop is the point. AIP will forever be validated by AIP, because every act of validation is recorded the same way every act of building is recorded.

Proof of Build

I call it Proof of Build. It’s a single idea, and it has two parts.

The first part is a verifiable log of what was built and when. Every act of work on AIP gets recorded in a signed, hash-chained audit log. Every spec revision, every refactor, every release, every deployment. The chain is the receipt. The signature is the proof. The hash is the anchor that makes the next entry impossible to forge without breaking the last.

The second part is selective disclosure. The log is mine. I can show you as much or as little of it as I choose. I can show a curated subset of the development timeline, fully signed and chained, and you can verify it. I do not have to show you the rest.

Together, those two parts make the proof. Not because a third party vouched for the work, but because the work itself is the system that produces and verifies the record. The protocol is the witness. The witness is the protocol.

The loop

This isn’t a one-shot proof. It’s a loop, and it compounds.

Each release of AIP is also a build event. The build event is recorded in the log. The log is verifiable against itself. The next release adds more build events. The chain grows. Each entry references the artifacts that came before it. Each artifact references the chain entries that came before it. The system holds itself up.

When AIP gets adopted, every adopter gets the same loop. Their agent does work. The work is recorded. The record is signed. The signature is verifiable. The verifier can be any other agent running the same protocol. The protocol doesn’t need a centralized witness because the witness is distributed by design. Anyone holding a copy of the chain can verify it offline, and they all agree because the math says so.

This is the property I wanted AIP to have from the beginning. It’s the reason the audit log is locally held and signed, the reason the chain is hash-anchored, the reason the disclosure is selective. The proof belongs to the work, not to a third party.

Why “by AIP”

Three reasons.

One: using AIP to claim priority for AIP is the most honest marketing I can do. The protocol isn’t a separate thing from the proof. They’re the same mechanism, applied to the same timeline, signed by the same key.

Two: the loop is testable. Anyone who wants to evaluate AIP can look at how I used it on myself. If the proof holds for me, it’ll hold for them. If it doesn’t, the failure is in the protocol, and the fix is in the protocol. Either way, the work is the demo.

Three: it never goes stale. The proof doesn’t depend on a paper being cited, an endorser being available, a journal accepting a submission, or a platform continuing to host a link. The proof is the chain. As long as the chain exists, the proof exists. As long as someone runs the verification, the proof is current. The protocol is the system that keeps validating itself.

What this is, and what it isn’t

What it is: a way of building software where the proof of authorship is a property of the software itself, not an external artifact.

What it isn’t: a credential, a certification, or a substitute for review. AIP doesn’t claim to be correct, only to be verifiable. The protocol is what it is. The chain says what it says. A reader who runs the verification gets the same answer I do. That’s the only thing AIP promises, and it’s the only thing AIP needs to promise.

How I’ll keep doing this

Every release of AIP will be a build event. Every build event will be recorded. Every record will be verifiable. The chain will grow. The protocol will keep validating itself. The Proof of Build won’t be a feature I’ll add later. It’s the way I’ve been building AIP from the start, and it’s the way I’ll keep building it.

That’s the long version. The short version is the title. AIP by AIP. Proof of Build. The protocol used to prove itself.

Isaac Liem. ORCID 0009-0006-2476-1615.

Cite this post / the v1.1.0 release: AIP v1.1.0 reference implementation, DOI 10.5281/zenodo.21267380. The protocol itself is the deliverable; the citation points to the archived build that this post is documenting.

Verify this

The protocol doesn’t ask for trust. It asks for a timestamp. Every claim in this post — that the protocol exists, that it was built in this form at this time, that the build event itself is part of the chain — is independently checkable.

For most readers, the public archive is enough. The full v1.1.0 build is on Zenodo and on GitHub. Either one is a complete, citable record of what AIP v1.1.0 is.

For developers: the full Proof of Build chain

The chain that backs the post is anchored in Bitcoin via OpenTimestamps. Eight files, all Bitcoin-block-attested. Anyone can verify with ots verify against the on-chain block headers.

Anchored in Bitcoin blocks 957210–957217 (mined 2026-07-08, ~14:00–14:16 UTC).

The release (the deliverable)

The artifacts, each with an OTS proof (Bitcoin-block-anchored)

Verify locally

pip install opentimestamps-client
git clone https://github.com/githubscum/aip-protocol
cd aip-protocol
ots verify -f docs/AIP-whitepaper.md dev-logs/ots/AIP-whitepaper.md.ots
# Should report "Success! Timestamp complete" with Bitcoin block header attestations.

The two AIP-LAUNCH.md.ots files anchor the launch doc at two different moments — one before the Zenodo DOI line was added (block 957210), one after (block 957217). Both are valid on-chain timestamps; together they make the file’s evolution into the public record it is today.