William Entriken Blog

NFT/RWA资源如何帮助国资和企业实现项目？

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

研究国资现在情况和RWA现代回机会。对比西方NFT/RWA玩法和中国市场应用。

作家简介

你好，我是William Entriken（安其文）。我认为NFT和雷斯的技术可以带来更顺利、更可靠政府和企业操作。我曾参与多个政府和私立企业，帮助设计项目并提供指导。我没有可卖的平台也没有手下的员工。哪里需要我聊天、演讲或咨询，我就去哪里。

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

国内报道

国际政府报道（英文，外国网）

国资问题

国资的作用就是按照中央党国务院和省政府的计划和需求设计项目的机会。有了项目再和各个政府商量如何符合项目资本的需求。最终要负责项目成功。国资会参与多轮的项目，也会连续和各个政府和伙伴合作。

每一次项目成功，下一轮更顺利了。项目和五年计划吻合无缝对接。国资信任为重要。

我们以下举个例子，分析相关刚出的15五年计划。也可以多加雷斯细节。

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

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

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

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

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

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

国资和私资对比

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

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

剩下的算力部分更难说：

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

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

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

到这一点我们可以分析NFT/RWA资源如何帮助国资实现项目难点，还有西方的NFT/RWA和中国内应怎么不一样。

如何用NFT/RWA资源帮助项目

目前的困难是：

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

还有不要忘记国资强项：

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

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

投资	贷款/债券	⭐️ 质押
项目成功后分红	项目还在发利息	项目实现后有权合作

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

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

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

如果国资已经通过所有的面积、发电、类似的证那就可以拍卖质押券。项目建立好之后谁持有该券，就有权利入驻。

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

这些质押券可按市场价格拍卖给企业方。

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

⭐️ 通过质押资本，参与方为什么最相信项目会实现？因为政府方实现之后政府方还可以赚很多房租和电费。

通过 NFT/RWA 技术，质押方持有的权益仍有流动性。在合规的国产区块链上（如果政府允许），A 方可以在二手市场持有的位置。A 方和 B 方也可以交换位置（AI 服务器对距离和位置非常敏感）。

西方的NFT/RWA和中国内应技术怎么不一样？

西方RWA资源	中国内资源
NFT可以金融化	政府可以禁止
匿名方可以获得NFT	过链可禁止
可用去中心化金融	可绑定人民币交易

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

下一步

请与我联系。我会帮你：

分析如何利用新经济模式提高你的项目成功率。
推荐在国内怎么用国产的区块链（或者非区块链技术）实现新经济模式。
利用我10多年的经验来分析你的项目和资本方式。
就像我和美国和欧洲政府合作一样，和中国政府分析合适的法律和市场规则。

如果你的项目成功了我希望改天我可以再来上海和国资演讲如何新技术帮助企业应用。

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 zerodays 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.

Offnet: I built a darkweb inside Ethereum in 2018 (and the contract still works)

Sun, 17 May 2026 00:00:00 +0000

You want to publish a web page.

No server. No domain. No hosting bill. No one can take it down.

I solved that in 2018 with Offnet. You store the entire HTML, CSS, and JS directly on Ethereum. Anyone with a browser and a Web3 connection can load it using a special URI. The browser does the rest.

Here is the exact contract I deployed:

pragma solidity 0.5.0;

contract Offnet {
    mapping (bytes32 => bytes) files;
    
    function getFile(bytes32 contentIdentifier) external view returns (bytes memory content) {
        return files[contentIdentifier];
    }

    function addFile(bytes calldata content) external returns (bytes32 contentIdentifier) {
        contentIdentifier = keccak256(bytes(content));
        files[contentIdentifier] = content;
    }
}

Address: 0x8370f43041c98ad30b99c192e8263bcd64529c38

How it works

You publish by calling addFile with your full file. You pay only the transaction fee.
The contract returns the keccak256 hash of your content. That hash is part of your permanent URI.
You share the URI with anyone: ?offnet-35fbb6dc3891aacaf1ffa07abec2344fdbc454aab533a2a03bcf93577eb7837b
They open that URL with Offnet, the browser intercepts the URI, calls the contract on-chain, and injects the raw content.

Here is the exact service worker that does the magic:

self.addEventListener("fetch", event => {
  const url = new URL(event.request.url);
  if (url.search.startsWith("?offnet-")) {
    const newUrl = "./" + url.search.substr(9);
    event.respondWith(fetch(newUrl, { mode: 'cors' }));
  }
});

The full index.html (the entry point users visit) is still live and works today. It gives you the “Load” and “Publish” forms, a list of cool pages, and the security warning.

What you get

Zero hosting: Tor, no IPFS, no AWS, no Vercel, no domain registrar.
True offline mode: sync a local Ethereum node, disconnect the internet, and keep browsing forever. Save the page as a web archive and you literally have the entire site on your laptop.
Censorship resistance: the content lives in the blockchain. No single company can delete it.
Privacy: you can access the entire Offnet offline if you have a full node.

Why nobody scaled it

Gas was expensive in 2018–2022. Storing even a medium-sized HTML file cost real money. Service workers have quirks (Firefox and Safari hide them in private browsing).

2026 update — it is viable now

Dencun blobs and cheap L2s (Base, Arbitrum, Optimism) changed everything. Storage is no longer insane. You can host entire real sites for pennies now. The service-worker pattern still works perfectly.

I still have the full original files: the two versions of index.html, the service worker, and the exact contract. The demo still loads today.

Try it yourself

Visit the live index.html (or save it locally).
Connect any Web3 wallet.
Load one of the published pages using the ?offnet- URI format.
Publish your own tiny page and share the hash.

This was never meant to replace the normal web. It was a proof that we could build a parallel, serverless, censorship-resistant web using only the tools we already had.

I built it because I wanted to see if it was possible. It was.

What are you going to host first?

Full index.html

<!doctype html>
<html>
  <head>
    <meta charset="utf-8">
    <title>Offnet</title>
    <script>
const offnetUri = new URLSearchParams(window.location.search).get('offnet');
if (offnetUri) {
  const request = new XMLHttpRequest();
  request.open("GET", "jsonrpc/" + offnetUri, true);
  request.onreadystatechange = function () {
    if (request.readyState != 4 || request.status != 200) return;

// APPROACH 1 -- keeps existing HEAD
//    document.body.innerHTML = request.responseText;

// APPROACH 2 -- replace whole document
document.open("text/html", "replace");
document.write(request.responseText);  // htmlCode is the variable you called newDocument
document.close();
  };
  request.send();
}
    </script>
  </head>
  <body>
    <nav class="navbar navbar-light bg-light d-flex align-items-center">
      <h1 style="background-image:linear-gradient(to right, orange, pink, purple);background-clip:text; -webkit-background-clip:text;color:transparent">Offnet&trade;</h1>
      <form class="ml-auto form-inline my-0">
        <label class="mr-3" for="network">Network:</label>
        <select class="form-control" id="network">
          <option>Ethereum Mainnet (Infura)</option>
          <option>Local node, port 8456</option>
        </select>
      </form>
    </nav>
    <div class="container mt-5 lead">
      <img id="animage" src="">
      <p><em>Offnet URIs</em> are qualified to a specific network (set at top) and look like:</em></p>
      <p><code>?offnet=35fbb6dc3891aacaf1ffa07abec2344fdbc454aab533a2a03bcf93577eb7837b</code></p>
  
      <div class="row mt-5">
        <div class="col">
          <h2>Visit any page</h2>
          <form>
            <input class="form-control mb-2" name="offnet" placeholder="Offnet URI">
            <button id="visit" class="btn btn-primary mb-2">Visit</button>    
          </form>
        </div>
        <div class="col">
          <h2>Publish a page <span class="badge badge-info">only pay TX fee</span></h2>
          <form>
            <input type="file" class="mb-2 form-control-file" id="exampleFormControlFile1">
            <button type="submit" class="btn btn-primary mb-2">Publish</button>
          </form>
        </div>
      </div>
  
      <h2 class="mt-5">Some cool pages</h2>
  
      <ul>
        <li><strong>Style.css</strong> &mdash; the stylesheet for this page<br><a href="">?offnet=35fbb6dc3891aacaf1ffa07abec2344fdbc454aab533a2a03bcf93577eb7837b on Ethereum Mainnet</a></li>
        <li><strong>dogs</strong> &mdash; the stylesheet for this page<br><a href="?offnet=123456">?offnet=123456 on Ethereum Mainnet</a></li>
        <li>Share other cool pages <a href="mailto:">with us</a></li>
      </ul>
  
      <h2>Street smarts 💡</h2>
      <p>If you're reading this page, you might be a crypto billionaire. Before you visit anywhere with Offnet, use a private browsing mode and be extra skeptical of anything you click, lest you be tricked by someone that wants your billions.</p>
      <p class="text-danger"><strong>WARNING:</strong> If you are reading this page at XXX.NET or your own downloaded copy, then that's cool. Anything else claiming to be Offnet is unofficial and is a scam.</p>


      <h2 class="mt-5">How does this work?</h2>
      <p>Offnet works by intercepting Offnet URIs on web pages you visit, silently fetching and injecting the referenced content.</p>
      <p>
        Offnet does not store any documents or link to any documents. An Offnet URI is an <em>identifer</em> which uses the contents of a file to succinctly describe that file. In order to retrieve a web page or other file using Offnet you must be connected to a blockchain, such as Ethereum Mainnet. Offnet will retrieve and display requested files from the connected network.
      </p>
  
      <h2 class="mt-5">Maximum security</h2>
      <p>
        STEP 1: LOCAL NODE &mdash; Run your own local synchronized blockchain node and choose NETWORK at the top of this page to connect to it.
      </p>
      <p>
        STEP 2: OFFLINE &mdash; Disconnect from the Internet and all communications services on your device. You can still access all content on Offnet. Yes really.
      </p>
      <p>
        DONE &mdash; If you destroy your computer now, there will literally be no record on Earth of what you have done with Offnet. No "anonymized" records. No "we promise we don't keep logs." Welcome to privacy.
      </p>
    </div>
    <footer class="bg-dark py-5 mt-5">
      <div class="container text-light text-center">
        <div class="row">
          <div class="col">
            <strong>Offnet&trade;</strong>
            version 1.0-a1
          </div>
          <div class="col">
            Created by <a class="text-light" href="https://phor.net">William Entriken</a>
          </div>
          <div class="col">
            <a class="text-light" href="mailto:infura?Requesting to delete content from your local copy of the Ethereum blockchain/standard DMCA form fields">DMCA requests</a>
          </div>
        </div>
      </div>
    </footer>
  </body>
</html>

The antitrust case against Apple

Mon, 11 May 2026 00:00:00 +0000

Apple, Inc. has built the largest private infrastructure project in human history. They use it to deny competition across multiple valuable markets.

The largest infrastructure project in human history

With over 2.5 billion active devices from an estimated USD 2.5 trillion in customer investment, Apple’s products are the single largest infrastructure project in human history.

This surpasses every other great infrastructure project in human history controlled by a single organization:

The Chinese Belt and Road Initiative with USD 1.4 trillion in investment.
The Chinese high-speed rail network with USD 1 trillion in investment.
The US Interstate Highway System with USD 700 billion in investment [2026 dollars].

Here is a very brief size-up to illustrate.

Apple announced in 2026 that it had exceeded an installed base of 2.5 billion active devices. And Apple products have an average selling price about USD 1,000. So that is at least USD 2.5 trillion in investment.

That is one third of earth’s human population. And the amount of time per day each person uses with these devices is obscene. I’m sure you know it, but I don’t have a reliable number to cite across earth.

This is infrastructure because it is the basis of commerce and leisure which other people can use directly or build on (with apps). And it is a single project because Apple, Inc. controls the entire thing. (Unlike “the internet” which is actually multiple separate infrastructure projects controlled by many entities.)

But here’s the real story: Apple uses this unprecedented infrastructure position to systematically deny competition across multiple high-value markets.

iCloud: the default trap

When you first setup you iPhone, iCloud is enabled by default.

More importantly, iCloud is stored in a way that by default Apple has access to every photo you take.

As your iPhone fills up, you can’t use features until you address this issue. iPhone shows you an upgrade path to pay monthly for iCloud. This is the exact moment of maximum user pain — and only Apple gets to appear there. Third-party apps are not allowed know this moment of pain, or to show up in this upgrade path.

This is an engineered advantage.

Apple Music: the unremovable default

Apple Music is the default music app on iOS and macOS. You cannot remove it. Press the music button on your keyboard or in CarPlay, and it opens Apple Music — even if you pay for a competing music service and never use Apple Music.

Oh, and third party music services had to pay 30% of their revenue to Apple, where Apple Music have relatively high cost of goods sold.

This is an engineered advantage.

The browser: $20 billion for your thoughts?

Apple’s Safari browser is the default browser on iOS and macOS. You cannot remove it. On iOS, competing browsers cannot improve on the rendering speed by making a competing rendering engine.

Apple doesn’t let them. And Google pays Apple USD 20 billion per year for the search traffic from Safari.

Building a new rendering engine is a huge undertaking. Probably only Google would do this on iOS. Google would surely rather invest USD 100 billion one time to make a better browser than pay this toll each year. And they could. But…

Keeping every other browser out is an engineered advantage.

The result

Across multiple markets, Apple has engineered advantages for its own products and systematically denied competition.

Apple could do this for any industry. If they wanted to make a fast food restaurant, they could ensure that no other fast food restaurant could take orders on their platform. (Fast food restaurants currently do not pay any fees or revenue share to Apple.) Fast food is out of Apple’s current appetite. But as of today, Apple has engineered maximum revenue against the following markets:

File storage
Music
Web search
Video games

And there are plenty of other examples.

Apple has the power to control prices and exclude competitors. Apple’s progress in its secondary products is primarily due to its engineered advantages in its primary products.

Why don't people rob the coat check?

Thu, 30 Apr 2026 00:00:00 +0000

A real-world lesson in custody, incentives and “trustless” systems

You hand over your $1,200 Canada Goose, your wallet and your keys to a bored college kid behind a folding table. In return you get a little paper stub with a number on it. Then you walk away.

And yet… almost nobody robs the coat check.

It’s not because the system is technically brilliant. It’s a paper ticket. It’s not because the attendant is armed or the coats are in a vault. They’re literally hanging on a rack six feet away. Physically, robbing it is laughably easy—especially for the attendant, who has unlimited unsupervised access every single night.

So why doesn’t robbery happen constantly?

Surface-level answers (all true, none sufficient)

The ticket is a crude non-fungible token: one unique claim per item, redeemable only by the rightful holder.
Bulky coats are hard to pawn.
There are bouncers, cameras, and witnesses.
The attendant is dressed differently than guests and may draw suspicion if they try to walk out with a coat.
Most humans aren’t criminals.

All correct. All incomplete.

Bear with me for a blockchain comparison

Now imagine the same setup but on a new blockchain project.

You deposit your assets into a multisig wallet. The “attendant” is able to honor redemption of your assets, or not. There is no face-to-face interaction, no venue, no reputation, no ongoing business. Just code and anonymity.

In that world, the “robbery” happens constantly. Rug pulls, drained treasuries, “lost” keys or whatever you want to call it. It’s trivial and consequence-free for the thief because there is no establishment to protect.

The technical difference is night and day:

Coat check	Anonymous multisig
Centralized custody, physical enforcement	Decentralized custody, zero real-world accountability

But the actual reason people don’t rob the coat check has nothing to do with technology or custody models.

The real reason: the establishment has too much to lose

The coat check doesn’t exist in a vacuum. It lives inside a profitable business—a nightclub, a restaurant, a theater, a wedding venue—that makes money night after night, year after year.

That establishment has:

Reputation capital it cannot afford to burn.
Repeat customers who will simply stop coming if coats start disappearing.
Staff who know they’ll be fired (and possibly prosecuted) if theft is even suspected.
Social media that amplifies any scandal instantly.

Even an unsubstantiated claim of theft can tank the venue’s Yelp score, get it dragged on TikTok and scare away high-spending customers. The business owner may rather eat the cost of a stolen coat, or fire an attendant, than let a rumor spread. This economic reality is what actually secures the coats—not the paper ticket, not the attendant’s honesty, not blockchain.

The system works because an establishment is valuable and theft is an unacceptable risk to that value.

What about pop-up events, temporary establishments?

Can we challenge the assumptions about the establishment above. What about?

A one-night pop-up event with no brand or repeat customers.
The last night of a venue that’s closing forever, where the lifelong owner is not present.
A venue which already has a reputation for theft.

Well, what you are showing are establishments that aren’t established. ⊥

So what does this mean for crypto, NFTs, and “trustless” systems?

We spent years celebrating anonymous, permissionless, trustless protocols as the future. And in many ways they are.

But the coat-check analogy reveals the simple truth: custody and other trust-based applications depend on establishment. And this includes reputation, profit motive and other incentives.

A blockchain multisig run by anonymous signers with no ongoing business can steal from customers tomorrow and the thieves disappear into the ether. You can prevent this by having any multisig or no-recourse custodian be managed by a third-party with reputation to lose. Then after you have a profit-making establishment, think about bringing it back in-house.

The paper ticket works not because it’s a sacred bond, but because it sits inside an establishment whose profits and reputation are on the line every single night.

That’s the real security model.

And it’s why your coat is probably still hanging there when you stumble back at 2 a.m. with (or without!) your little stub in hand. 🎟️

My best voice

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

I have not always followed this guide. That’s fine. Progress starts from documenting what works.

This guide collects the voice and style I use when the writing feels most inspired—when it launches standards, templates, and ideas that other people actually adopt and resonate with.

We are contemplative and intentional about voice because we respect the reader. When writing for a community or project, that respect extends further: it honors their interests and proposes a thoughtful place for them in the world.

My voice is therefore direct, practical, and opinionated, always aimed at solving real problems while respecting you—the reader—as a collaborator rather than an audience. It mixes precision where it matters with conversational warmth, draws from the spare clarity and wonder of XKCD.

My style is the practical toolkit that supports this: short active sentences, liberal use of lists, tables, diagrams, and clean typography that makes complex ideas immediately usable.

The sections below lay it out in detail with high-level prose patterns, low-level typography and capitalization rules, human interface best practices, and how to apply this guide in your own work or contributions.

High-level prose patterns

My voice is direct, practical, and opinionated. I write to solve problems and to inspire others to create better things. Sentences stay short and active. I address you, the reader, directly because this is a conversation, not a lecture.

I emphasize best practices and production readiness. You will see phrases such as “awesome reusable modules” or “opinionated starting point” because I believe in setting high standards from day one. I use lists, tables, and diagrams liberally. They make complex ideas immediately usable.

I mix formality where precision matters (see the ERC-721 specification) with conversational warmth where ideas are forming. The common thread is clarity. I avoid fluff. If a sentence does not add value or move the reader forward, I delete it.

I draw inspiration from XKCD: profound wonder, analysis and humanity. When I put something to words, I want you to feel the same sense of possibility I felt when I first came at the problem.

When creating a standard, template, or invitation to adopt a specification I always start with a clear value proposition: why this particular interface deserves to exist and what real-world problem it solves for producers and consumers. Only after that do I deliver an extremely clear and valid list of behaviors.

This pattern appears throughout my work. In ERC-721 the abstract opens with the concrete benefit (“a standard API for NFTs… to track and transfer”) and immediately paints the diverse universe of use cases so readers can picture their own. The specification then uses RFC-2119 keywords (“MUST”, “SHALL”, “SHOULD”) to define exact behaviors with zero ambiguity. The same flow lives in the swift6-module-template README: value proposition first (“opinionated starting point for awesome, reusable Swift 6 modules”), followed by a bullet list of features and turnkey setup steps.

The reasoning is simple: when you invite people to plug into a community or ecosystem, you must speak in their language and give them a clear, respectful connection plan that considers their actual needs. Standards only deserve to be written when multiple people already adhere to them and others depend on the surface area of that interface. (See the full reasoning in “What kinds of things should be standardized?”.) The goal is interoperability that reduces waste, not contrived rules that nobody asked for. I therefore maintain the same disciplined documentation style I expect others to follow—precise, readable, and ready for production.

Deriving authority through references and best practices I build credibility by openly recognizing excellent work wherever I find it. I keep a consistent “references” or “best practices” section in almost every project. By naming the inspired souls whose ideas resonate with me, my voice joins a larger chorus and we become louder. You will see this in the swift6-module-template (which cites Swift project recommendations and links to its own Recipe.md), the github-pages-template, and many other repositories. The section is never an afterthought; it is how I show respect for the people who came before and invite others to stand on the same shoulders.

Examples of this full voice appear in:

The ERC-721 abstract and motivation sections, which explain non-fungible tokens with real-world analogies and invite you to dream up new use cases.
The swift6-module-template and github-pages-template READMEs, which list features immediately then give step-by-step instructions.
Blog posts that turn personal reflection or technical research into actionable advice.

Style guide

Here are the scales and chords that play in this voice.

Use active voice

❌ This report was unable to be sent.
- ❓ Did anybody specify that a report was due by a certain time?
- ❓ Does the sender recognize their prior committment to send the report?
- ❓ Did the sender actually start to send the report?
- ❓ Did the sender not send the report because they forgot or some extenuating circumstance?
- ❓ Did the sender send the report but actually the software or network failed to deliver it?
- ❌ This note does not contribute whatsoever to improving the situation in the future.
- ❌ This note is powerless, just like “it did not rain today” recognizes only God decides the weather.
✅ I failed to send this report on time.
- ✅ The sender recognizes (“on time”) that a report was due by a certain time.
- ✅ The sender confirms (“I failed”) a prior committment which they made.
- ✅ The sender acknowledges (“failed to send”) they are the reason the report was not sent on time.

Microsoft Word 95 warned you (your parents?) tirelessly about passive voice. But as corporate bullshitspeak takes over, passive sentence structure buries accountability and lowers our expectations of people we are talking with.

In east Asian and especially Filipino culture, people use passive voice in the example above to:

Avoid shame (this is prideful and places one’s image over the mission of the team 🙁)
Avoid confrontation and create harmony (a harmony based on polite words is less valuable that one based on polite actions 🙁)

In this light, we use active voice to be humble, promote cooperation and respect the long-term relationships with our collaborators.

Low-level typography and capitalization

Follow these rules everywhere unless a specific project (such as an academic paper) requires otherwise:

Use uppercase letters only at the start of sentences, for proper nouns, and for initialisms. Everything else stays lowercase. (This produces clean, readable prose.)
Do not use the Oxford comma.
Preserve typos when formatting chat conversations exactly as shown in the blog repository style guide.
Cite US court cases in Bluebook style.

Markdown usage follows these conventions:

Headings use sentence case.
Bold for emphasis.
Italics for gentle stress, sarcasm and introduction of words with added baggage.
Bullet lists and numbered lists for any sequence of actions or features.
Code blocks and inline code for every technical element.
Tables for comparisons or configuration variables.
Emojis used sparingly (✅ for status, ℹ️ for notes) to add visual cues without clutter.
Margin notes on the right side of blog pages when useful (via the .margin-note class).

For web documents, I maintain consistent notes about how to create slugs and images (here is an example for this blog).

HIG best practices (in brief)

Human interface guidelines here mean making documentation and interfaces instantly usable. The principles appear throughout my templates and standards work:

Provide turnkey working code or examples immediately.
Include testing, linting, and CI from day one.
Use semantic versioning, changelogs, and clear folder structures.
Make setup reproducible with environment variables or Docker containers.
Test hyperlinks, structured data, and accessibility as part of every build.
Prefer permanent, stable URLs even when content evolves.

These practices come from real-world experience shipping Swift modules, Ethereum standards, and Jekyll sites. They reduce friction for contributors and end users alike.

How to use this guide

Every person has a voice. Document it somewhere, preferably online.

Communities and organizations (if we shall anthropomorphize them) have voices too. Document it somewhere, preferably online.

At a minimum, your copy editor will then have a basis for holding you accountable. And better, they can find if your voice has grown, and distill that insight into… a pull request against that documentation!

TRON VM storage collision vulnerability

Tue, 24 Mar 2026 00:00:00 +0000

Critical TVM storage key truncation to 128 bits leading to arbitrary slot overwrites, birthday attacks, and potential network fork.

Executive summary

The execution layer of TRON Virtual Machine (TVM) incorrectly mangles the location of contract storage slots. Specifically, storage keys that differ only in their upper 128 bits will collide and overwrite each other. Also, storage from one smart contract can overwrite storage from another contract if the addresses are similar enough. This is a fundamental error in the official java-tron implementation where it fails to implement the specification advertised on the official TVM documentation, and it breaks advertised compatibility with Ethereum Virtual Machine (EVM).

The impact is severe: Attacker-controlled contract deployment + birthday collision is now feasible in 2^64 operations instead of the 2^128 operations advertised. This order of birthday collisions are already demonstrated in the wild and are likely to be deployed on TRON someday even unintentionally. Stealing tokens from any contract on TRON is possible with 2^128 hash difficulty instead of the advertised 2^256. If multiple diverse clients are running on the network, it is possible to cause a network fork.

Technical background

Ethereum Virtual Machine treats every contract’s storage as a map of 2^256 independent 256-bit keys. Each slot is completely isolated. And the TRON Virtual Machine specification also provides this same guarantee:

TVM opcodes are the same as EVM except for TRON-specific opcodes.

SSTORE: storage[key] := val

SLOAD: val := storage[key]

However, the TRON Virtual Machine implementation (java-tron) does something very different:

private static final int PREFIX_BYTES = 16;
private byte[] compose(byte[] key, byte[] addrHash) {
  if (contractVersion == 1) {
    key = Hash.sha3(key);
  }
  byte[] result = new byte[key.length];
  arraycopy(addrHash, 0, result, 0, PREFIX_BYTES);
  arraycopy(key, PREFIX_BYTES, result, PREFIX_BYTES, PREFIX_BYTES);
  return result;
}

Here is the bit layout:

---
config:
  packet:
    showBits: false # Cheating because Mermaid too small with 256 bits
---
packet
0-15: "addrHash prefix"
16-31: "lower key bits"

This means that TVM reuses storage slots across all contracts with similar addresses. And it shares storage slots where keys are similar.

Activation method (how to trigger it)

Deploy any contract on Tron (mainnet or Nile testnet).
Write to storage slot 0.
Write to storage slot 2^128.
Read back slot 0 — it now contains the value from slot 2^128.

This works in one transaction and requires no special permissions.

Proof of concept (PoC)

Here is a minimal Solidity contract that demonstrates the collision:

[!CAUTION]

Do not deploy this contract to mainnet!

If multiple diverse clients are running on the network, deploying this contract will cause a network fork.

// SPDX-License-Identifier: MIT
pragma solidity >=0.7.0 <0.9.0;

contract Storage {
    uint256[2**128+1] numbers;

    constructor() {
        numbers[0] = 3;
        numbers[2**128] = 4;
    }

    function getNumber() external view returns(uint256) {
        return numbers[0];
    }
}

Here is another implementation using inline assembly:

// SPDX-License-Identifier: MIT
pragma solidity >=0.7.0 <0.9.0;

contract StorageCollisionPoC {
    constructor() {
        // Write to slot 1 (low key)
        assembly {
            sstore(1, 0x0000000000000000000000000000000000000000000000000000000000000003)  // value = 3
        }

        // Write to slot 2^128 + 1 (high key that collides if upper 128 bits are truncated)
        assembly {
            let highKey := add(0x0000000000000000000000000000000100000000000000000000000000000000, 1)
            sstore(highKey, 0x0000000000000000000000000000000000000000000000000000000000000004)  // value = 4
        }
    }

    // Helper view function to read any slot (for testing)
    function readSlot(uint256 slot) public view returns (uint256) {
        uint256 val;
        assembly {
            val := sload(slot)
        }
        return val;
    }

    // Confirm collision: will return 2 on java-tron, but 1 on a correct implementation
    function getNumber() external view returns (uint256) {
        return readSlot(1);
    }
}

Here is another implementation of forking using 9 bytes of contract deployment bytecode.

305f55303060801b55

On a correct EVM (Ethereum, Polygon, BSC, etc.):

getNumber() returns 3

On TRON Virtual Machine:

getNumber() returns 4 — because keys 0 and 2^128 collide when the upper 128 bits are discarded

Note that in TronIDE you will see the correct value. This is because TronIDE uses a different storage implementation for testing that does not have the same bug. The bug only exists in the actual TVM execution environment on the blockchain.

You can deploy this on Nile testnet today (do not deploy to mainnet, see note above) and verify with a block explorer (TronScan). See a similar contract that is already deployed. And you can query it using the key 1 and the key 340282366920938463463374607431768211457 (2^128 + 1). Compare that to the previous transaction that set that storage value.

Forking proof of concept

In TRON Virtual Machine, unlike Ethereum, the storage root is not included in the accountStateRoot of the block header. And therefore the example above will not cause a concensus failure by way of the state root being different for two different nodes.

However, if you look closer, notice how the first storage change is at one address and the second storage change is at a different address. Well, according to the TRON energy specification, a proper consensus client would bill this energy usage twice at full rate. But the current java-tron implementation only charges the first storage change at the full rate, and the second storage change at a much lower rate (because it thinks it is overwriting an existing slot instead of writing to a new slot).

energy_cost = (oldValue == null && val != 0) ? 20000 : (oldValue != null && value == 0) ? 5000 : 5000

This means that if java-tron is running today on mainnet and a different client is also running on mainnet that is properly implemented, then the same transaction will be accepted by both clients but will have different energy costs. This results in a fork of the network!

Be very careful before attempting to deploy the above contract because it might break the entire TRON network!

Root cause (exact source)

The bug lives in the official java-tron reference client:

File: actuator/src/main/java/org/tron/core/vm/program/Storage.java

private static final int PREFIX_BYTES = 16;  // = 128 bits

private byte[] compose(byte[] key, byte[] addrHash) {
    if (contractVersion == 1) {
        key = Hash.sha3(key);
    }
    byte[] result = new byte[key.length];
    arraycopy(addrHash, 0, result, 0, PREFIX_BYTES); // ← ONLY 128 bits
    arraycopy(key, PREFIX_BYTES, result, PREFIX_BYTES, PREFIX_BYTES);  // ← ONLY lower 128 bits!
    return result;
}

Every 256-bit storage key (DataWord) has its upper 128 bits discarded.
Only the lower 128 bits + a 16-byte address prefix become the actual database key (LevelDB/RocksDB).
A singleton storage instance is shared across all contracts, and only part of the address is used.
Cross-contract collisions are possible.

Full impact analysis

Severity: Critical

1. Birthday attack on hashed slots

Most contracts use keccak256 for mappings and dynamic arrays:

Expected entropy: 2^256 (full key uniqueness).
With java-tron: only the lower 128 bits of the key are effectively used after truncation → effective entropy drops to 2^128 per contract.
A birthday-paradox collision search now becomes feasible in ≈ 2^64 operations (feasible today with modern GPU clusters or dedicated hardware in weeks to months for a motivated attacker).

An attacker can:

Attacker-controlled deployment: An attacker deploys their own high-value contract (e.g., SunSwap pool, USDT-TRC20 bridge, token) using CREATE2 to control/predict the address and initial storage layout. They can then:
- Compute colliding key pairs offline (via birthday attack on the lower 128 bits).
- Later deploy a second malicious contract to the colliding “prefix space.”
- Use the collision to overwrite critical state in their “first” contract (e.g., set balanceOf(attacker) = totalSupply, change owner, drain funds).
Steal from an arbitrary existing high-value contract: Requires finding a colliding key for a specific existing storage slot (preimage attack) → still 2^128 difficulty (infeasible today). This is much easier than the advertised 2^256 difficulty.

If somebody else also knows this vulnerability, they may have already done the first step above and be prepared to deploy the second contract anytime and drain all the funds from an existing high-value contract.

2. Direct overwrite of fixed slots

Any contract using low-numbered slots (common in proxies, upgradeable contracts, or assembly code) can have those slots silently overwritten by anyone who knows the colliding high key.

3. Underhanded contract behavior

An attacker can deploy a malicious contract that appears to be permissionless, but actually they maintain administrative control, by using storage collisions to overwrite critical state.

This is simple, and anybody reviewing the contract source code and expecting java-tron to work as advertised would not predict the actual program behavior.

4. Unintentional cross-contract collisions

Even unintentional collisions pose a real risk when contracts share similar address prefixes (first 128 bits / 16 bytes) or when using low/predictable keys. For example, the OpenSea Seaport project uses deployment addresses with many leading zero bits (57 bits now, increasing with new versions). If Seaport (the dominant NFT marketplace protocol) deploys on Tron and reaches ~16 leading zero bytes in an address, all versions/deployments sharing that 128-bit prefix would have fully colliding storage spaces. Any write to one contract’s storage would silently corrupt or overwrite state in the others — breaking approvals, listings, or escrow logic across versions without any intentional exploit.

5. Chain fork

If there are multiple clients running on the network, then the same transaction will be accepted by all clients but will have different energy costs. This will cause a fork of the network between clients that implement the correct storage model and the java-tron clients that implement the incorrect storage model.

CVE-style impact statement

Allows an attacker to cause storage collisions across all contracts on the TRON network, enabling theft of tokens, manipulation of contract state, and potential network forks. The vulnerability arises from a fundamental flaw in the java-tron TVM implementation where 256-bit storage keys are truncated to 128 bits, resulting in predictable collisions. This can be exploited with a single transaction and requires no special permissions, making it a critical risk for all users and developers on the TRON platform.

CVSS 3.1 Score (estimated): 9.8 (Critical) - AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Recommended resolution

Tron should immediately:

Change compose() to use the full 256 bits of the key and the full address hash to compute the storage key, as per the original specification. A practical solution is to use keccak256(addrHash || key) as the storage key since it will have sensitivity to all bits and it fits in the same width that is used today.
Add a new contract version flag and enforce full 256-bit keys going forward while maintaining backward compatibility for existing contracts.
Redeploy and migrate any high value contracts to the new version.
Update TVM documentation to stop claiming full EVM compatibility until fixed.
Review all high-value contracts on Tron for evidence of collision attempts. (i.e. attacker-controlled contract deployment + birthday collision)

A fix in compose() plus a hard fork would resolve it.

Timeline & disclosure

2022-11-12 Discovery
2026-03-18 Private report to TRON DAO via HackerOne
2026-03-24 TRON responded on HackerOne: “Thank you for your report and contribution to our security program. Following a thorough evaluation, we found this report is duplicate. This report will now be closed.” They did not ask me to maintain confidentiality and closed the issue.
2026-03-24 Public disclosure on blog.phor.net