What the registry of a dying chain revealed

To answer "what do I still have on DFK Chain", you need a registry: the addresses of tokens, pools and contracts that can hold assets. We assembled one from the project's documentation and checked it against the chain — and the registry turned out to be more interesting than the tool it was built for. It shows the network in cross-section: where the money actually sits two weeks before the shutdown, and why the address owner cannot see it.

Every figure below was read from the chain on 14 August 2026 across the fourteen documented pools. Dollar amounts are estimates from the pools' own reserves: on a network being shut down, nobody arbitrages prices against the outside market, so treat them as orders of magnitude, not quotes.

The money is not where a wallet looks for it

Total liquidity across the documented pools is about $534,600. Of that, $334,200 — 62.5% — sits in the Gardens staking contract. Another $116,300, 21.75%, sits in the old MasterGardener contract. In total, 84% of the liquidity is not on people's balances but inside two contracts.

The difference is fundamental. A wallet shows the tokens held at an address. It does not show a position inside a contract: LP tokens handed over to staking are not on the balance, so a person opening their wallet before the shutdown sees nothing exactly where their money actually is. The practical consequence carries over to any shutdown: an inventory taken from wallet balances is incomplete by construction — you have to check the contracts the network lets you put things into.

A fifth of the money is in a contract the project already replaced

MasterGardener is DFK's previous staking contract. It was replaced by Gardens and the documentation lists it as deprecated. Yet it still holds 2,602,461 LP tokens, roughly $116,000.

The distribution is uneven, and that is the most curious part:

In the xJEWEL/WJEWEL pool the old contract holds thirty-five times more than the new one. That is not small change someone forgot about — it is the bulk of the pool's liquidity, left in a contract the project's interface no longer points to.

The mechanics are simple and play out the same way everywhere: migration to a new contract is voluntary, active users do it, and everyone else's positions stay where they were. While the network is alive the difference barely matters — the money just sits there. It starts to matter at shutdown: whoever looks for their positions in the current interface will not find what stayed in the previous one.

The door to the community closed before the network did

The official DeFi Kingdoms site links to the invite discord.gg/defikingdoms. It does not work: Discord's API returns Unknown Invite, code 10006. Checked on 5, 14 and again on 17 August — nothing changes.

The community itself is alive. The Discord server has 55,619 members, with about 2,700 of them online when we measured on 17 August — you just cannot get in except through a different invite, which lives anywhere but the site: in the description of the Telegram group, for example. And Telegram, which from the outside looks like a second living channel — 4,826 members — is alive only as a member count: there is no activity in the group, and the official announcements channel @defikingdomsannouncements has been silent since 22 February 2025 — a year and a half before the shutdown.

The result is a gap: the shutdown announcement is published, a live discussion exists — but the path people take from the entry point does not lead to it. A holder who comes to check their assets two weeks before the end sees the announcement, a dead link and a group where nobody answers. There is a place to ask — just not where they are being led.

The registry goes stale faster than the network dies

A registry is a snapshot. We took ours once and checked it against the chain a few days later. The divergence was larger than expected: 13% on average, and catastrophic in two pools.

People are leaving. Half the liquidity of two pools exited within days — good news about the community, bad news for any code that keeps a cache.

It caught us out in our own tool. For pools outside the documented list, the scanner read reserves live from the chain but took the total LP token supply from the snapshot. The two values are the halves of one fraction, and they turned out to come from different moments in time: fresh reserves were divided by a stale, inflated token count. The user's share came out understated by exactly the size of the drift — in the worst case by a factor of two and a half.

The error points in the most dangerous direction. A person looks at an understated amount, decides it is small change, and does not bother rescuing it. We found and fixed it — the commit is in the tool's repository, and both halves of the fraction are now read from a single snapshot.

The takeaway is wider than one bug: on a dying network, every cached number is a liability. Not because caching is bad, but because the rate of change grows as the date approaches. A snapshot taken a month out describes a different network by the final week.

What to carry over to the next shutdown

Four things that transfer to any network, service or SDK with an announced end date:

1. Count places, not balances. List the contracts the network lets you put things into, and check those. A wallet balance is the smaller part of the picture — on DFK Chain it is 16% of the liquidity against 84%.
2. Check previous contract versions, not just the current ones. Deprecated does not mean empty. Here the replaced contract still held a fifth of all the money, and in one pool nearly everything.
3. Check that the official entry point works. A dead link on a site survives for years because nobody opens it from the inside. Before counting on announcements in a community channel, make sure the channel is reachable.
4. Never mix live and cached values in one formula. If the numerator is read from the chain, the denominator must be read from the chain too. The closer the shutdown, the more that mistake costs, because the exit speeds up.

You can check a specific DFK Chain address with our tool: what is left on DFK Chain. It is read-only — no wallet connection, no signatures, the address is never stored. The contract registry and the scanner itself are open on GitHub: every figure in this article can be recomputed independently.