Writing

AP2 already authorizes agents ahead of time and caps cumulative spend under one reusable mandate. The open problem sits one level up: nothing bounds the principal across all the grants issued in their name.

The paper describes machine-native money in detail and machine-native authority in one clause. In its own reference workflow, the whole delegation problem sits inside the phrase 'approved payment details'.

The freedom to pick your own signature scheme is real. It is also priced. Whichever algebra the proof backend speaks becomes the algebra that applications can afford, and that choice is made by infrastructure engineers rather than by cryptographic policy.

The headline said Bitcoin became quantum-safe. What actually happened is narrower and more useful: a pre-positioned output was spent under hash-based authorization. The catch is that pre-positioned is doing all the work.

A token standard determines how an asset can move. Its price anchor, correction path, inventory economics, order flow and lifecycle determine where—and how—it should trade.

Uniswap v4 has separate designs for restricted participation and productive idle inventory. Combining them is a three-ledger settlement problem.

A pool can verify the trader. It cannot invent the price, the arbitrage path, or the balance sheet. In a permissioned AMM, the allowlist becomes market structure.

Most agentic systems do not need Web3 rails. The subclass that does is the one where authority, value transfer, and settlement can no longer be separated, and no operator can be the accepted keeper.

The mandate is the grant. Governing it over time and across organizations is a different problem, and audit inside your own walls is not accountability across someone else's.

Same model, four very different system classes. The classifier is authority, not capability, and only one of the four actually breaks the conventional stack.

Most of the stack already exists in fragments. What is missing is one object that makes machine authority portable, provable, and revocable across boundaries.

The shift isn't a new interface. It's a change in who initiates a digital action, and on what authority. That is a control problem, not a model problem.

AI compresses the labor of producing verification artifacts. It does not compress the cognitive work of deciding what to verify. The distinction is small in words and large in consequence: verified-looking output without machine-checked guarantees is the same false-confidence failure mode the previous article catalogued — now in a faster workflow.

A formal proof in DeFi is a four-place relation: implementation, specification, environment model, verifier semantics. All four have to hold for the proof to mean what the team thinks it means. The most expensive verification mistakes are not verifier bugs — they live in the other three.

Smart contract audits review artifacts. DeFi protocols are not artifacts — they are interactions between contracts, governance actions, oracles, upgrades, bridges, frontends, and transaction histories. The mismatch between unit of review and unit of attack is the reason the failures keep looking the same.

On-chain storage is for integrity, not privacy. Teams that forget this put personal data, commercial secrets, and regulator-only evidence into the one storage layer that cannot take any of it back. Data placement is the architectural decision that either holds the whole system together or quietly poisons it from day one.

The interesting architectural problem in Digital Product Passports isn't which blockchain you pick. It's what happens 200 kilometres before the blockchain — in a village with no reliable mobile coverage, a supplier who uses a button phone, and a supervisor with an Android tablet that spends half its life offline.

Digital Product Passports aren't a compliance exercise. They're an architecture audit. And the architecture most vendors are selling will fail in the one place it has to hold — the first mile, where provenance evidence is produced by people and in places the system wasn't designed for.

What if Bitcoin's governance can't move fast enough? A one-way bridge into a STARK-based environment — where the Bitcoin-side key is never revealed and the operational side runs on hash-based proofs — could serve as an interim shelter. Not a permanent solution. A structured holding pattern.

Everyone keeps asking 'when will quantum computers break Bitcoin?' That's the wrong question. The right question is what happens to the infrastructure built around Bitcoin — bridges, wrapped assets, custody models — when the signature layer can no longer be trusted.

The problem with lending against tokenized real-world assets was never the lending protocol itself. It was the architecture underneath — one that forced a choice between deep liquidity and market specialization. Aave V4 removes that tradeoff. Whether that's enough is a different question.

The startup narrative says: disruptors move first, incumbents follow. For tokenization, the sequence is reversed. Banks already hold the licenses, the compliance infrastructure, the custody capabilities, and the client relationships that startup tokenization projects spend years and millions trying to build. That's not a criticism of startups. It's a structural observation about what tokenization actually requires.

The phrase 'we tokenized an asset' means almost nothing if that asset cannot be sold, used as collateral, or embedded in a financial chain. Most of what people celebrate about tokenization — fractional ownership, global access, 24/7 trading — was already possible before blockchain. The actual upgrade is somewhere else.

Everyone talks about the token. Almost nobody talks about what sits underneath it. After working on tokenization architectures across real estate, industrial financing, and securities platforms, the pattern is consistent: the token contract is the simplest part. Everything that makes it work — or fail — lives in the infrastructure.

The technology was never the problem. From over a hundred tokenization concepts we worked through with clients, the failure pattern was consistent: projects reached the legal review stage and stopped. Not because blockchain couldn't handle the use case, but because the project couldn't satisfy the conditions that turn a token into an enforceable financial instrument.

No existing bridge supported our source chain out of the box. Custom consensus. Non-standard token. We had to evaluate four completely different architectures to move a native token to EVM destinations. This is the comparison we built for ourselves.

Every cross-chain bridge design redistributes risk. It doesn't remove it. After reviewing dozens of integrations and one $3M exploit up close, here's how the four main approaches actually behave when real money moves through them.

The CrossCurve incident didn't surprise me. What surprised me was how many teams looked at it and said 'that wouldn't happen to us' — without being able to explain why.

We built multichain account abstraction, shipped it, then discovered MPC solves entire categories of problems our smart contracts couldn't touch. Here's the production reality.

After shipping ERC-4337 to testnet, we hit a wall. Not a technical limitation — an architectural one. Standard account abstraction assumed the account was a black box. Modular accounts turn it inside out.

The moment you try to recover a smart account on a chain where it hasn't been deployed, you hit a wall. This isn't theoretical.