IOTA Rebased is a ground-up rebuild of the IOTA network, launched in May 2025, that replaced the original Tangle and UTXO model with a Move-based object ledger, delegated proof-of-stake consensus, and smart contracts at the base layer. It was one of the more significant architectural shifts a major blockchain project has undertaken: not an incremental upgrade, but a complete change in execution model, consensus mechanism, and programming paradigm.

The official developer tooling followed accordingly. The IOTA Foundation provides a TypeScript SDK (@iota/iota-sdk, part of the iotaledger/iota monorepo) and a Rust SDK, both targeting the new Rebased architecture. There is also an older Python package (iota-sdk on PyPI) – but that’s a set of Rust FFI bindings for the pre-Rebased Stardust protocol. It doesn’t speak the Rebased JSON-RPC API, doesn’t build Move-compatible Programmable Transaction Blocks, and doesn’t handle the new BCS serialization format. When we needed Python tooling for IOTA Rebased, there was nothing available – so we built our own.

In January 2016, CBS News and The New York Times reported that the Wounded Warrior Project – one of the most visible veterans’ charities in the United States, raising hundreds of millions of dollars a year – was spending around 40 percent of donor funds on overhead, including staff conferences at luxury resorts, first-class travel, and lavish team-building events, while building programs that former employees described as more useful for marketing than for actually helping veterans. After an independent audit commissioned by the board, the CEO and COO were fired that March. The story had been invisible to donors for years. It came out through investigative journalism and whistleblowers, not through any built-in accountability mechanism in how charitable giving works.

That is the structural problem. When a donor gives to a campaign, the money disappears into the charity’s internal systems. Annual reports and Form 990 filings eventually summarize what happened at an organization-wide level, but they arrive long after the fact, aggregate everything together, and are produced by the charity itself. The mechanisms that do provide independent oversight – Charity Navigator ratings, Candid’s transparency seals, BBB accreditation – evaluate organizations on an annual cycle rather than tracking where specific campaigns’ funds actually go. A donor who wants to follow their contribution to a particular relief effort and verify it was spent as promised has essentially no way to do so without the charity’s active cooperation.

We built a protocol and a working proof of concept that addresses this specifically. It uses a smart contract to hold donated funds in escrow, recording every step of the lifecycle – donation, allocation to a purpose, disbursement to a recipient – on a public blockchain. Anyone can query the contract and trace exactly where the money went, in real time, without the charity’s cooperation. We’re publishing a research paper with the full protocol design, architecture, and results, with the source code available on GitHub.

In 2023, Everledger – the most prominent blockchain provenance platform, backed by Tencent, Fidelity, and over $27 million in funding – went into administration after a funding round collapsed. The company had tracked diamonds, gemstones, wine, and luxury goods on a private Hyperledger blockchain. When the company shut down, so did the provenance records. Every certificate of authenticity, every chain-of-custody record, every proof that a diamond was ethically sourced – all tied to a single platform that no longer exists.

Everledger’s failure illustrates the core problem with proprietary provenance platforms: they create exactly the kind of single point of failure that blockchain was supposed to eliminate. But the alternative – building on public, open blockchains – introduces a different problem. In a world with multiple blockchains, different parties in an asset’s chain of custody will use different networks. An artist might anchor on IOTA. A gallery might prefer Ethereum. An auction house might use something else entirely. A practical provenance protocol has to accommodate this reality.

We built a protocol that does. It creates provenance records as chains of cryptographically signed attestations, linked by content hashes rather than on-chain pointers, allowing a single asset’s history to span any number of blockchains without bridges, relays, or cross-chain messaging. We’re publishing a research paper with the full protocol design, architecture, and results, with the source code available on GitHub.

In January 2023, the U.S. Department of Justice charged 25 people in a scheme that sold more than 7,600 fake nursing diplomas from three Florida schools. The buyers used those diplomas to sit for national board exams, obtain state licenses, and get jobs in hospitals across at least nine states – nurses who had never completed clinical training, treating real patients. The federal investigation, dubbed “Operation Nightingale,” is still active: a second wave of charges landed in 2025. The scheme only came to light through a federal enforcement action, not through any built-in safeguard in the credentialing system itself.

This is what happens when credentials live in disconnected silos, verified by manual processes that assume documents are genuine because they look genuine. Every credential issuer – every university, employer, certification body – operates its own database with its own format and its own verification mechanism (if any). There is no common standard, no universal way for a third party to independently check authenticity, and no mechanism for the holder to control where and how their credentials are shared. The result is a multi-billion-dollar background check industry built on the difficulty of doing something that should be straightforward.

We built a protocol and working proof of concept that takes a different approach. It combines W3C Verifiable Credentials v2.0 – an open web standard for machine-verifiable credentials, finalized in May 2025 – with blockchain as an accountability layer for anchoring credential hashes and managing revocation. We’re publishing a research paper with the full protocol design, architecture, cross-chain comparison, and results, alongside the source code on GitHub.

When one company hires another to build software, a familiar problem arises at the point of delivery: does the work actually meet the specification? Today, that question is answered through manual review — meetings, back-and-forth, and sometimes expensive third-party arbitration. It’s slow, subjective, and scales poorly.

We built a proof of concept that takes a different approach. It combines blockchain-based smart contract escrow with an AI agent acting as a third-party verifier. The client deposits funds into a smart contract. The contractor submits their work. An AI agent evaluates the deliverable against the agreed requirements — building it, running it, testing it, and scoring its compliance — then records the result on-chain. Depending on the score and the AI’s confidence, the contract automatically releases funds, notifies the contractor to fix and resubmit, or escalates to a human arbiter.

We’re publishing a research paper with the full concept, architecture, and results, alongside the source code on GitHub.

Modern systems run on trust. Companies trust auditors to verify their books. Regulators trust manufacturers to report accurate test data. Consumers trust certification labels to mean what they say. Most of the time, this works well enough. But when it fails, the consequences are measured in billions of dollars, irreversible environmental damage, and real harm to real people.

The failures aren’t random. They follow a pattern: an intermediary is trusted to verify something, that intermediary has insufficient incentive or ability to verify it properly, and the people who bear the consequences have no independent way to check. The result is a system that works until it doesn’t – and when it doesn’t, the damage is already done.

Blockchain technology is often pitched as a solution to these problems, but usually with more enthusiasm than precision. The honest case for trustless design isn’t that it eliminates the need for trust entirely – it can’t. It’s that it can restructure where trust is required, making certain categories of failure structurally harder to pull off. That’s a narrower claim than the typical blockchain pitch, but it’s also a more defensible one.

This post examines four real cases where trust in intermediaries failed catastrophically – across different industries, at different scales, affecting different victims. For each, we look at what specifically broke, what a trustless design could address, and what it honestly couldn’t.