An unofficial map of what 6529 actually runs, written for developers approaching the project from the outside. Everything in it is public; assembling it into a shape you can hold in your head is what takes the time. It is also a record of what happened when I did exactly that, over two days, and what I decided to build as a result.
This is my interpretation of what I found — one outsider's reading, not an official account, and it can be wrong. You are encouraged to go to the source: the official FAQ, the code, and the team themselves. The most direct way to do that is to join the community and ask.
The sixty-second version, for someone who has read none of it
6529 runs 6529.io — a web3 social, collecting and governance application built around The Memes, an NFT collection that has dropped a card every Monday, Wednesday and Friday since June 2022.
Underneath the social product there is a network-state layer: every
identity accumulates TDH (a time-weighted measure of what NFTs you have held,
for how long), plus rep, cic and a derived level.
Those numbers are not cosmetic — they are the permission system. Groups are defined by
rules over them, and waves (the conversation surfaces) attach up to six groups each:
who can see, chat, submit, vote, administer and curate.
So the interesting engineering is not the chat app. It is that a social platform's entire authorization model is computed from on-chain holdings, and the stated goal is for that computation to eventually run on independent nodes rather than on 6529's servers.
The stack that actually serves 6529.io
6529seize-frontend — Next.js 16 (App Router), React 19, TypeScript, Tailwind 4.
Wallet stack is wagmi / viem / ethers / Reown AppKit. Deployed to AWS Elastic Beanstalk.
Apache-2.0.
6529seize-backend — TypeScript, ~56 serverless packages on AWS Lambda
(nodejs22.x), MySQL/Aurora, Redis. Contains the computation loops:
tdhLoop, transactionsLoop, delegationsLoop and
others. Apache-2.0.
6529-core — Electron app, ships its own releases.
com.core6529.app) whose WebView loads the production site,
so most mobile coverage is web coverage.
nftdelegation holds the
delegation contract. 6529Stream is a new, much more complex contract still
in review.
6529reviewbot — an AI reviewer that runs against the org's pull requests,
including its own.
Both main repositories are public and the API is open: api.6529.io answers
unauthenticated reads with access-control-allow-origin: *. You can query
identities, groups, waves and drops without a key.
It is also formally specified. There is an OpenAPI 3.0.3 document at
api.6529.io/openapi.json —
289 paths under the /api base — with a Swagger UI at
/docs/ and a walkthrough at
6529.io/tools/api. Three things are worth knowing
before you read it. It declares a global bearerAuth and documents a session-v2
wallet flow to obtain one, but that is broader than what is enforced —
/api/blocks, /api/nfts, /api/memes_extended_data,
/api/transactions and /api/tdh/consolidation/:identity each
answered 200 with no credentials when checked on 4 August 2026. The ten
/oracle/* routes that serve TDH do not appear in it at all. And it documents
/api/xtdh/*, a grant system where a holder assigns an xtdh_rate
to another contract's tokens on a target chain — a real extension of TDH beyond the three
contracts, running in its own loop. More in part 2.
All 18 public repositories, by last push · snapshot 1 Aug 2026
| Repository | Lang | What it is | Last push |
|---|---|---|---|
6529seize-frontend | TS | The site. Everything user-facing. | today |
6529seize-backend | TS | API + the TDH / transactions / delegation loops. | today |
6529networkmuseum | Py | System of record for the Network Museum — policies, governance decisions, accession register. Explicitly transitional until on-chain storage exists. | today |
6529Stream | Py/Sol | The new flagship contract + its very large spec set. | 2d |
6529-core | TS | Desktop app. | 2d |
6529reviewbot | JS | AI PR reviewer used across the org. | 2d |
thememecards | — | Documentation of Meme Card distribution mechanics. | 1d |
allowlist-api / allowlist-lib | TS | Allowlist creation from criteria — the mint phases run on this. | 1d |
6529seize-admin | TS | Admin panel. | 171d |
nextgen | Sol | On-chain long-form generative art contracts. | 347d |
ai-code-review-action | TS | GitHub Action for AI review; superseded by 6529reviewbot. | 383d |
6529-Prenode | TS | Self-hostable TDH provider. The subject of part 2. | 395d |
bayc-zk | Go | Described in-repo as "just a test project". | 400d |
6529node | Go | A peer-to-peer node. The subject of part 2. | 509d |
nftdelegation | Sol | The delegation contract. Deployed and in use; the repo is simply finished. | 662d |
Janus | — | No description. | 832d |
gradient | — | The 6529 Gradient collection. | 1460d |
Ages above are baked in from the snapshot date. This page tries to refresh them live from the public GitHub API when you open it; if that fails, you are reading the snapshot.
"Dormant" means no pushes, not abandoned intent — nftdelegation is dormant
because a deployed contract does not change. The two that matter for understanding the
project's direction are 6529-Prenode and 6529node, and they are
where part 2 begins.
The archaeology, and why it was worth doing
Orientation gets you the map. It does not tell you whether the numbers on it are right. I went looking for a specification of TDH — the value that decides who can see, post and vote across the whole platform — expecting to find a document and some test vectors. There is neither. TDH is defined by what one program does.
Following that thread produced the rest: three separate attempts at decentralizing the calculation, only one of which ever served traffic; a registry of thirty-seven independent operators who volunteered and self-funded; and a divergence between the two implementations, verified by diffing them, that neither repository would detect.
It also produced the thing that made part 3 obvious — a comparison. One layer of this system does have a specification, with golden vectors and a conformance harness. When those vectors were first run against two implementations by the same team, in the same language, in the same repository, they disagreed in nine reproducible cases.
6529-tdh-node — an independent TDH provider
A calculation that exists in exactly one codebase is an implementation. A calculation that two independent codebases agree on is a protocol. Today there is no independent way to answer "is this TDH number right?" — only "is it the same one 6529 published?", which is the same question asked twice.
So I started a second implementation, written from scratch rather than forked, aimed
at the outcome the Prenode's own README describes but stops short of. The pass/fail
test is not a matter of opinion and already exists in the public API: every
/oracle/* response carries the block it was computed at and a Merkle root
over the result set. Two implementations conform when they produce the
same root at the same block. One hash decides, and anyone can check
it with curl.
Nothing is implemented yet, and the order is deliberately inverted: the specification first, then a conformance harness that can judge any implementation, then the implementation itself. The harness is useful before this node computes anything — it answers a question no one can currently answer.