Coder Legion - Recent posts tagged web3

Understanding Gas on the Blockchain: A Practical Guide Using Real Transactions

Mon, 26 Oct 2026 13:35:40 +0000

When I first encountered the concept of gas in blockchain, I understood on the surface that it measured computational work. However, I did not fully understand what that meant in practice, how gas is actually calculated under the hood, why transactions need gas limits, or how all of those numbers come together to form a transaction fee.

Reading high-level definitions is one thing, but opening a block explorer and staring at a raw transaction receipt is another. Where does a specific number like 49,785 or 152,492 gas come from? Why does a transaction that transfers 0 ETH or 0 MON still cost money? And what actually happens to the gas you don't use?

For me, the best way to truly grasp a technical concept--to the point where you can confidently explain it to someone else--is to connect the abstract math to a physical, real-world analogy and then test it against real data.

In this article, we are going to break down how gas works from the ground up. We will build a simple physical mental model, look at how the Ethereum Virtual Machine (EVM) counts work, and then inspect two real blockchain transactions: one where I interacted directly with a smart contract on Monad Testnet, and a second transaction hash I pulled from the Ethereum Sepolia Testnet explorer to see how the two networks compare.

Separating the Five Core Concepts

When people talk about "gas," they often lump several different things into one blurry idea of "the fee I pay." To make transaction receipts easy to read, we first need to separate five distinct concepts:

Gas: The unit used to measure the computational work required to process a transaction.
Gas Limit: The maximum amount of gas a transaction is allowed to consume.
Gas Used: The amount of gas the transaction actually consumed during execution.
Gas Price: The monetary rate (in cryptocurrency) paid per single unit of gas.
Transaction Fee (Gas Fee): The final amount of cryptocurrency paid for processing the transaction, calculated according to the network's rules.

These concepts are closely related, but they do not mean the same thing.

A Relatable Analogy: The Delivery Truck
Think of executing a blockchain transaction like hiring a delivery truck to drive across town and flip a switch at a warehouse:

Gas (The Work): Driving 15 kilometers up a steep hill physically requires 10 liters of fuel. Notice that "liters" measures physical effort, not money. Whether fuel is cheap or expensive today, the engine still burns 10 liters to climb that hill.
Gas Limit (Your Fuel Cap): Before the driver leaves, you hand them a fuel card authorized for a maximum of 12 liters. You are saying: "This trip should take 10 liters, so I am allowing up to 12 liters as a safety buffer. If the road is blocked and you burn all 12 liters before getting there, stop driving immediately."
Gas Used (Actual Consumption): The driver completes the trip and the engine actually burns 10 liters.
Gas Price (Price per Liter): At the pump today, fuel costs $2 per liter. Tomorrow, during heavy traffic demand, it might cost $4 per liter. The distance and effort didn't change, only the price per unit of fuel.
Transaction Fee (The Total Bill): The final payment calculated from the fuel and the price per liter.

With that picture in mind, let's briefly look at how the blockchain measures those "liters of fuel" under the hood.

Under the Hood: How Does the Blockchain Count Gas?

When you submit a transaction on an EVM-compatible blockchain, the network doesn't guess how hard your transaction worked. Instead, every tiny instruction the computer executes--called an opcode--has a fixed cost measured in gas:

The Base Cover Charge (21,000 Intrinsic Gas): Before the blockchain even opens a smart contract, every standard transaction costs a flat minimum of 21,000 gas. This covers the basic work of verifying your cryptographic signature, checking your account nonce, and updating your account balance.
Basic Math & Memory: Inside a smart contract, simple operations like adding two numbers together (ADD) cost just 3 gas.
Reading & Writing Permanent Storage: Updating the blockchain's permanent database is the heaviest work a transaction can do, because every node on the network has to store that state change. Reading a variable from permanent storage for the first time in a transaction (SLOAD) costs 2,100 gas. Writing a brand-new non-zero value into an empty storage slot (SSTORE from 0 to 1) costs 20,000 gas, while updating an already non-zero slot (SSTORE from 1 to 2) costs 2,900 gas.

As your transaction runs, an internal meter starts at 21,000 and adds up the exact cost of every instruction executed along the way.

Now let's see how this looks on two real transaction receipts.

Case Study One: Calling `increment()` on Monad Testnet

For our first case study, I interacted directly with a smart contract deployed on Monad Testnet by calling its increment() function.

Here are the exact details from the transaction receipt:

Field	Value
Network	Monad Testnet
Function Called	`increment()`
Transaction Status	Success
Transaction Value	0 MON
Gas Limit	49,785
Gas Used (as reported)	49,785
Gas Usage	100%
Gas Price	102.82 Gwei
Transaction Fee	0.0051188937 MON

Why Did a 0 MON Transaction Still Incur a Fee?

Notice that the Transaction value is 0 MON. My transaction didn't send any MON tokens to another person or contract, yet it still charged a fee of 0.0051188937 MON. Why?

In our delivery truck analogy, Transaction value is the cash you put inside an envelope to send to someone across town. Even if you send the driver with $0 in the envelope just to flip a switch at the warehouse, the truck still has to burn fuel to drive there and flip the switch.

Look at the Solidity contract behind increment():

// SPDX-License-Identifier: MIT
pragma solidity 0.8.30;

contract Counter {
    uint256 public count;

    function increment() external {
        count = count + 1;
    }
}

This contract stores a number called count on the blockchain. Whenever someone calls increment(), the contract increases count by one (changing it from 0 to 1, or 1 to 2). Even though the code looks tiny, the blockchain still has to process the transaction, run the contract's instructions, read the current value of count, and write the updated number into permanent storage.

The transaction fee pays for that computational processing and state update, not for transferring currency.

How Was the Fee Calculated--And Why Was Gas Usage 100%?

On this receipt, the Gas limit was 49,785, and the Gas used, as reported was also 49,785:

Gas Usage Percentage = (49,785 ÷ 49,785) × 100 = 100%

And if we multiply the Gas limit (49,785) by the Gas price (102.82 Gwei):

$49,785 x 102.82 Gwei = 5,118,893.7 Gwei

Using the conversion of $10⁹ Gwei per 1 MON:

Transaction Fee = 5,118,893.7 ÷ 10⁹ = 0.0051188937 MON

This matches the displayed transaction fee down to the last digit.

But this raises an important question: Why does Monad calculate the fee using the Gas Limit, and why did the receipt report 100% gas usage?

Unlike Ethereum, which charges you based on the gas your transaction actually used after running, Monad charges based on the Gas Limit you declare upfront (and sets gasUsed equal to gasLimit on the top-level receipt).

To understand why, compare a supermarket checkout (Ethereum) with booking cargo on an airplane (Monad):

Ethereum (Supermarket Checkout): When an Ethereum validator builds a block, it runs each user's transaction on the spot before picking the next one. Because it runs the code immediately, it sees the exact Gas Used right away and knows exactly how much space is left in the block for the next person.
Monad (Booking Cargo on a Flight): To process thousands of transactions per second, Monad uses asynchronous execution: validators pack transactions into a block and lock in the order before running the smart contract code. Because the network hasn't run your code yet when packing the block, it doesn't know what your actual Gas Used will be--it only sees the Gas Limit you asked to reserve!

If Monad let users reserve massive amounts of block space using a huge Gas Limit and then only charged them for a tiny Gas Usedafterward, someone could reserve an entire block, crowd out everyone else on the network, and pay almost nothing. Just like reserving 10 seats on a bus or cargo flight where other passengers have to be turned away at the gate, on Monad you pay for the exact capacity you reserve upfront (Gas Limit).

Case Study Two: Inspecting a Transaction on Ethereum Sepolia Testnet

To see how standard Ethereum fee accounting differs, I went to the Ethereum Sepolia Testnet block explorer and pulled up a random transaction hash to inspect its receipt. In this transaction, the sender called the close() function on a smart contract.

Here are the transaction details:

Field	Value
Network	Ethereum Sepolia Testnet
Function Called	`close()`
Transaction Status	Success
Transaction Value	0 ETH
Gas Limit	156,059
Gas Used	152,492
Gas Usage	97.71%
Effective Gas Price (as reported)	0.000153611 Gwei
Transaction Fee	0.000000023424448612 ETH

Gas Limit vs. Gas Used (And What Happens to Unused Gas)

Just like the Monad transaction, this transaction sent 0 ETH in value while paying a fee to execute smart contract logic. However, look at the difference between the limit and the actual consumption.

Gas limit: 156,059
Gas used: 152,49

156,059 - 152,492 = 3,567 unused gas

Percentage Consumed = (152,492 ÷ 156,059) × 100 ≈ 97.71%

Here, the transaction consumed 97.71% of its limit and left 3,567 gas (2.29%) untouched.

What happens to that 3,567 unused gas on Ethereum?

When a transaction begins on Ethereum, the protocol temporarily locks enough ETH from the sender's balance to cover the entire 156,059 Gas Limit (just like a fuel pump pre-authorizing your card before you pump). As the code executes, the meter ticks up to 152,492. The moment execution finishes, the leftover 3,567 gas is immediately refunded back to the sender's wallet inside the exact same transaction, and that unused capacity is freed up for other transactions in the block.

How the Sepolia Transaction Fee Was Calculated

Because Ethereum refunds unused gas, the final fee is calculated strictly on Gas used:

Transaction fee = Gas used x Effective gas price

Multiplying the 152,492 gas actually consumed by the 0.000153611 Gwei effective gas price:

152,492 x 0.000153611 Gwei = 23.424448612 Gwei

Since 1 ETH = 10⁹ Gwei:

Fee = 23.424448612 ÷ 10⁹ = 0.000000023424448612 ETH

Notice that the unused 3,567 gas was never charged to the sender.

How Do You Know What Gas Limit to Set?

Looking at numbers like 49,785 on Monad and 156,059 on Sepolia, a natural question comes up: How does anyone know how much gas a contract will need before sending the transaction?

You don't have to calculate opcodes manually. In practice, gas limits are estimated automatically:

Wallet & RPC Simulation (eth_estimateGas): Before you click "Confirm" in your wallet, the wallet silently calls a method on an RPC node called eth_estimateGas. The node runs a free practice simulation (dry run) of your transaction against the current state of the blockchain in its local memory, counts the exact gas used, and reports that number back. Your wallet then adds a small safety buffer (often 10% to 20%) in case the blockchain state changes slightly before your transaction lands in a block.
Developer Tooling (Foundry): When writing smart contracts in Foundry, running forge test --gas-report or cast estimate simulates your function calls and prints out the exact gas numbers before you ever deploy to a live network.

Practical takeaway: Because Monad charges you for your declared Gas Limit, you should rely on eth_estimateGas with a modest buffer rather than manually typing in an artificially huge gas limit!

Understanding Gas Price and Gwei

Now that we've covered Gas Limit and Gas Used, let's look at Gas Price and Gwei

While gas measures the computational effort (liters of fuel), gas price is the monetary cost per single unit of gas (price per liter). Because a single unit of gas costs a tiny fraction of 1 ETH or 1 MON, we express gas prices in Gwei (short for Giga-wei) so we don't have to read strings of nine zeros:

1 ETH (or MON) = 10⁹ Gwei = 1,000,000,000 Gwei

1 Gwei = 0.000000001 ETH

When someone says "Gas price is 20 Gwei," they don't mean the whole transaction costs 20 Gwei. They mean each single unit of gas costs 20 billionths of an ETH.

Suppose a transaction consumes 50,000 gas:

At 10 Gwei per gas: 50,000 x 10 Gwei = 500,000 Gwei (0.0005 ETH).
At 20 Gwei per gas: 50,000 x 20 Gwei = 1,000,000 Gwei (0.001 ETH).

Notice that the computational work (50,000 gas) stayed completely identical--the fee doubled purely because network demand pushed the price per unit of gas twice as high.

Decoding EIP-1559: Base Fee, Priority Fee, and Max Fee

Both the Monad and Sepolia receipts identify the transaction type as EIP-1559 (Type 2). Under EIP-1559, the gas price is broken down into specific components. Let's look at the fee breakdown from the Sepolia receipt:

Fee Field	Value
Network	Ethereum Sepolia Testnet
Base Fee	0.000000015 Gwei
Max Priority Fee	0.000153596 Gwei
Max Fee	0.000153614 Gwei
Effective Gas Price	0.000153611 Gwei

Here is how these four numbers fit together:

Base fee (0.000000015 Gwei): The mandatory minimum rate per unit of gas for that block, determined automatically by the network based on how full previous blocks were. On Ethereum, the base fee is burned (destroyed) rather than paid to the block proposer.
Max priority fee (0.000153596 Gwei): The maximum tip per unit of gas the sender offers directly to the block proposer (validator) to incentivize them to include the transaction.
Max fee (0.000153614 Gwei): The absolute ceiling per unit of gas the sender is willing to pay in total (Base fee + Priority fee) in case the base fee jumps while the transaction is waiting.
Effective gas price (0.000153611 Gwei): The actual rate per unit of gas charged when the block was produced:

Effective gas price = Base fee + Effective priority fee

0.000000015 Gwei + 0.000153596 Gwei = 0.000153611 Gwei

Because 0.000153611 Gwei was safely below the sender's Max fee cap of 0.000153614 Gwei, the transaction paid the exact sum of the base fee and priority tip.

Why Do Transactions Need a Gas Limit? (And Why Gas Costs Change)

Preventing Runaway Code

Why does every blockchain transaction require a Gas Limit in the first place? Consider a contract function with a massive loop:

function expensiveOperation() external {
    uint256 total;

    for (uint256 i = 0; i < 1_000_000; i++) {
        total += i;
    }
}

If a transaction could execute without an upper bound--or accidentally hit an infinite loop--every node on the network would get stuck executing that loop forever, halting the blockchain.

The Gas Limit acts as a circuit breaker. If a transaction burns through all of its allotted gas before finishing, it stops with an Out of Gas error. When that happens, all state changes are reverted as if the transaction never happened, but the sender still pays for the gas consumed because the network already spent real computational work running the code up to that point.

Keep in mind: having plenty of gas does not guarantee a transaction will succeed. If a contract fails an internal require check or permission rule, the transaction will still revert even with gas left over.

Why Two Calls to the Same Function Can Use Different Gas

It is also easy to assume that calling the same function with the same inputs will always consume the exact same amount of gas. In practice, gas usage depends on the exact state of the contract at the moment of execution.

For example, in our Counter contract, the very first call to increment() updates count from 0 to 1. Allocating a brand-new storage slot from zero to a non-zero number costs 20,000 gas. The next call updates count from 1 to 2--and overwriting an already non-zero storage slot costs 2,900 gas. Even though both users called increment(), the first call performed heavier database work under the network's rules.

Comparing the Two Receipts: Are Fees on Monad Expensive?

Let's put our Monad Testnet interaction and the Sepolia Testnet receipt side by side

Concept	Monad Testnet: `increment()`	Sepolia Testnet: `close()`
Gas Limit	49,785	156,059
Gas Used	49,785	152,492
Gas Usage	100%	97.71%
Effective Gas Price (as reported)	102.82 Gwei	0.000153611 Gwei
Transaction Fee	0.0051188937 MON	0.000000023424448612 ETH
Fee Calculation	Gas Used x Gas Price	Gas Used x Effective Gas Price

When you look at this table, you might notice that 102.82 Gwei (0.0051 MON) looks numerically much larger than 0.000153611 Gwei (0.0000000234 ETH). Does that mean gas fees on Monad are expensive?

Not at all. In real-world dollar terms, Monad is designed so transactions cost a fraction of a cent. Those raw numbers cannot be compared directly for two reasons:

Different Native Tokens (MON-Gwei vs. ETH-Gwei): 1 Gwei on Ethereum is one-billionth of 1 ETH (an asset priced in thousands of dollars), whereas 1 Gwei on Monad is one-billionth of 1 MON. Comparing 0.005 MON to 0.00000002 ETH is like comparing 50 Naira (or 5 Japanese Yen) to 0.03 US Dollars--a bigger number in one currency doesn't mean a higher cost!
Monad's 100 Gwei Minimum Base Fee Floor: To prevent spam when blocks aren't full, Monad enforces a minimum base fee of 100 MON-gwei (which is why our transaction was 102.82 Gwei: 100 Gwei base fee + 2.82 Gwei priority tip). Sepolia Testnet has no 100 Gwei floor, so its testnet base fee had drifted down to nearly zero (0.000000015 Gwei).

Common Misunderstandings About Gas (Quick Checklist)

Gas and cryptocurrency are the same thing. They are not. Gas is a measurement of computational work; ETH and MON are the native assets used to pay for that work.
The gas limit is the exact amount of gas a transaction will use. Not necessarily. The gas limit is the maximum allowance; actual execution often consumes less.
A transaction with 0 value is free. Incorrect. Both of our transactions had a value of 0, and both required fees to pay for smart contract execution.
A higher gas limit always means a higher fee. It depends on the network's architecture! On Ethereum, you are only billed for Gas Used, and unused gas is refunded. On Monad, because blocks are packed asynchronously before execution, you are billed for the entire Gas Limit you reserve.
Enough gas guarantees a transaction will succeed. Incorrect. Even with plenty of gas, a transaction will revert if it hits a failed contract condition or permission check.

How to Explain Gas to Someone Else

If someone asks you, "What is gas on the blockchain, and how do fees work?", here is how you can break it down cleanly

Gas is the unit that measures how much computational work a transaction requires--just like liters of fuel needed for a delivery truck to complete a trip.

Every transaction sets a Gas Limit (calculated automatically by your wallet simulating the transaction), which acts as a maximum fuel cap so a bad loop can't run forever. As the transaction runs, it tallies up the Gas Used based on the exact instructions executed.

To find the Transaction Fee, you multiply the gas quantity by the Gas Price (measured in Gwei). On Ethereum, you only pay for the fuel your code actually burned (Gas Used), and any unused gas is refunded immediately. On high-speed asynchronous networks like Monad, where block space is reserved before running the code, you pay for the entire fuel limit you reserved upfront (Gas Limit).

Once you separate the unit of work, the maximum allowance, the actual consumption, and the price per unit, any transaction receipt on any EVM block explorer becomes intuitive to read.

Let's Figure Out the Rest Together

Writing this guide started with a simple realization: it is completely normal to use blockchains, deploy contracts, and still feel a bit fuzzy on what every single line of a transaction receipt is actually telling you. Moving from memorizing definitions to tracing the exact numbers is how the mental model finally clicks.

Now I'd love to hear from you: What part of Gas still feels unclear, confusing, or tricky to explain?

Is there a field on a block explorer receipt that you've always wondered about?
Have you ever run into an unexpected Out of Gas error or a strange gas estimation spike while testing a contract?
Or do you have a favorite real-world analogy of your own for explaining gas, Gwei, or EIP-1559 to someone new?

Drop your questions, edge cases, or thoughts in the comments below--no question is too basic or too far down the rabbit hole. Let's unpack them together.

BinnaDevLab
Reasoning Precedes Coding.

What the DAO Hack, Parity Freeze and Ronin Exploit Teach Us About Immutability

Mon, 12 Oct 2026 08:19:44 +0000

In 2016, an attacker discovered a bug in a smart contract called the DAO.

He didn't need to compromise Ethereum. He didn't need a zero-day exploit. He found one bad assumption in the withdrawal logic, wrote a contract that exploited it recursively, and drained $60 million. Every node on the Ethereum network confirmed every transaction. The blockchain did its job perfectly.

That's the thing about immutable code. It can't lie. But it also means it can't be fixed.

I've been sitting with this idea since I hosted Session 3 of BinnaDevLab Cohort 1. I invited Uchenna Ofoma, a software engineer of 3+ years currently focused on the distributed systems that underpin blockchain technology, to walk us through the full engineering reality of deploying code you can never take back. What followed was one of the most honest breakdowns of Web3 security I've heard.

If you'd rather watch than read, here's the full 42-minute session:

Why Trust the Code? Immutability, Hacks & Trade-offs | BinnaDevLab Session 3

What "Deploying" Actually Means

I opened the session by framing the core question: what does it actually mean that a smart contract is immutable?

Most developers have an intuition for deployment -- you push code, it runs on a server, the server can be updated or rolled back. Uchenna immediately challenged that mental model.

When you deploy a smart contract, your code gets compiled to EVM bytecode -- an intermediate representation designed specifically to run on the Ethereum Virtual Machine. From that moment, your code gets a permanent address. Every node on the network holds a copy and can execute it. Nobody owns the server. There is no centralized server.

As Uchenna put it: "Once you deploy your smart contract, just take it that it's online forever or until the blockchain inevitably goes down someday, somehow."

The reason for this is deterministic execution. The EVM guarantees that given the same inputs, every node produces the same output. This is what makes decentralization possible: no one node needs to be trusted, because they all agree on the math. But it also means your bug is their bug permanently.

Two Kinds of Trust

Before Uchenna walked us through what goes wrong, he established something I thought was fundamental and it connects directly back to what we covered in Session 1.

"If the owner can go to edit the rules, you're back to trusting a company, which is what we're trying to avoid."

The whole promise of a smart contract is that you're replacing trust in a person with trust in code. Anyone can audit it. Anyone can verify it. It runs without asking permission. But the moment you give an admin the ability to change the code, you've reintroduced a human and with it, all of human failure.

That's the foundation:

"A contract you can edit is not an agreement -- it's a promise."

When Uchenna said that, I wrote it down immediately. It cuts straight to why any of this matters.

When Forever Goes Wrong

This is the section of the session I wasn't fully prepared for. I knew Uchenna was going to cover the major hacks. I didn't expect the specific engineering detail he brought to each one.

The DAO $60 million Hack

The DAO was a decentralised fund on Ethereum. Members could pool ETH and vote on how to allocate it. A smart contract managed all the funds.

There was a bug, a re-entrancy bug. Uchenna explained it in a way that made it immediately understandable:

The contract let you withdraw your balance. But before it updated your balance, it made an external call to send you the ETH. An attacker wrote a contract that, the moment it received ETH from the withdrawal, immediately called the withdrawal function again before the balance had been marked as zero. Then again. And again.

He kept entering the vault before it could record that he'd left.

By the end, he had drained approximately $60 million. The code didn't fail. No exception was thrown. The EVM executed every call exactly as instructed.

The fix for this pattern is called Checks-Effects-Interactions: update all your state variables before you make any external calls. Mark the balance as zero first. Then send the money. If someone tries to re-enter, they find an empty account.

The aftermath is one of the most significant moments in blockchain history. The Ethereum community forked the chain -- creating a copy up to just before the hack -- so that affected users could get their money back. The old chain, where the attacker kept his funds, became what we now know as Ethereum Classic. The blockchain literally split in two over one bug.

The Parity Wallet Freeze -- $280 million

In 2017, Parity Technologies built a popular multi-signature wallet. Multiple signatures were required to move funds, no one person could act alone.

The problem was architectural. Their wallets shared a single library contract. That library had an unguarded initialization function, no access control, no guard on who could call it.

A user exploring the code called it. Then, exploring further, called the function to delete the library.

$280 million was locked. Not stolen. Just permanently inaccessible, because the code that would authorise withdrawals no longer existed.

The fix is access control: every state-changing function needs to verify who is calling it before allowing the action to proceed.

The Ronin Sidechain Exploit -- $625 million

Ronin was the sidechain powering Axie Infinity. To validate transactions, it used nine validator keys. A majority, five of nine was required to approve any action.

Attackers compromised five of them.

Uchenna's analogy during the session stuck with me: "Half of nine is 4.5. They've compromised five. Five is more than 4.5."

With majority control, the attackers could authorize anything. $625 million left. The code worked exactly as designed. It was just the wrong people holding the keys.

How Engineers Live With It

After walking through what failed, Uchenna shifted to what engineers do in response. The honest answer is that there are no perfect solutions, only trade-offs.

Proxy Contracts: You can deploy a "proxy" that users interact with, which delegates logic to an implementation contract behind the scenes. When you need to patch a bug, you deploy a new implementation and point the proxy at it. The address never changes. The logic does.
Time Locks: Any upgrade or large fund movement gets queued with a delay like 72 hours. This gives the community time to notice if something suspicious is being pushed.
Multi-sig wallets: No single person can push the button. A 3-of-5 multi-sig requires three separate private keys to sign any transaction.
Third-party audits and bug bounties: Independent firms review your code. Or you open a bounty for anyone to report a vulnerability, get paid. The goal is to maximize the number of friendly eyes before deployment, because after deployment, every eye is potentially hostile.

Every Escape Hatch Is Also an Attack Hatch

This was the moment of the session that landed hardest.

Every mechanism you build to survive a bug is also a mechanism an attacker can use against you.

Proxy contracts? An attacker who controls the admin key can push a malicious implementation.

Time locks? The attacker now has 72 hours to prepare not just a few seconds.

Uchenna's framing:

"An immutable bug is honest. An upgradeable protocol is a promise with a delay."

An immutable contract is what it is. Its failure mode is fixed and visible. An upgradeable contract introduces ongoing risk: the humans holding the upgrade keys, forever. If those humans are ever compromised or ever act against users' interests, the upgrade path becomes the exploit.

The engineer's job, as Uchenna put it, is to decide which failure they can live with.

DYOR Is Not Just a Meme

I closed the session with something I feel strongly about, and I want to say it directly here too.

DYOR (Do Your Own Research), gets thrown around in crypto circles as a joke or a liability disclaimer. But after what Uchenna walked us through, it's the only honest answer to the immutability problem.

If you're building: audit your code, run open-source tools against it, get third-party reviews, and be honest about what your protocol assumes. Know what your upgrade path actually exposes.

If you're using: don't trust a protocol because the team told you to. Find the audit report. Look at who holds the keys. Understand whether the thing you're interacting with is truly immutable or whether there's an admin somewhere with a button.

The code can't lie. But you need to be able to read it.

We're running Cohort 1 of BinnaDevLab: a structured developer program built on reasoning from first principles. Session 3 was the theory. Session 4 is the practical: actually writing smart contracts and experiencing immutability firsthand.

Missed Session 1 on trust and decentralization? Watch it here.
What Is Blockchain? History, Trust & Ethereum | Full Beginner Lecture | BinnaDevLab

Follow along on YouTube or join the community at binnadev.com

Blockchain Isn't About Crypto.It's About a Trust Problem You Didn't Know You Had

Wed, 07 Oct 2026 11:02:50 +0000

Before we started the first session of BinnaDevLab Cohorts, I knew one thing with certainty:

If we opened with the word "blockchain," we'd lose half of the room.

Not because the topic is hard. Because the word carries baggage. Crypto speculation. NFT mania. Headlines about scams and volatility. By the time most developers hear "blockchain," they've already formed an opinion and it's usually dismissive.

So we didn't start there.

We started with a question.

"Think of an app you used this morning. Name it."

That was the warm-up exercise Uchenna Ofoma, our facilitator for Session 1 put to the cohort.

The answers came quickly.

Opay. WhatsApp. Gmail. Facebook. Sporty.

Uchenna nodded at each one. Then he asked the follow-up question. The one that changed everything:

"Who were you actually trusting?"

The room went quiet.

Not the app. Not the company. When you send ₦5,000 on Opay, you're trusting:

Opay's servers to record the transaction accurately
The commercial bank Opay connects to
NIBSS to clear the interbank transfer
The KYC provider that verified both account holders
The CBN regulatory framework sitting beneath all of it

You weren't trusting one party. You were trusting a chain and you had zero visibility into any link of it.

That's not a crypto problem. That's not a web3 problem. That's a software engineering problem that exists in every application you've ever built or used.

And that is the real reason blockchain was invented.

Why We Built BinnaDevLab Around This

When I started BinnaDevLab Cohorts, the goal was simple but specific: train developers to reason at a global level not just to write code, but to understand why systems are designed the way they are.

The industry is full of bootcamps that teach you to ship fast. We wanted to build something different. A program built on the principle that reasoning comes before coding. That understanding the problem deeply is the actual skill, the code is just the output.

Blockchain was the perfect first topic. Not because it's trendy. Because it sits at the intersection of distributed systems, game theory, cryptography, and trust and most introductions to it skip all of that in favour of price charts.

We wanted to go the other way.

What Actually Happens When Trust Breaks

🎬 Prefer to watch? The full 64-minute session is on YouTube
Blockchain Fundamentals Explained | BinnaDevLab Cohort 1, Session 1

Uchenna spent the core of Session 1 on a deceptively simple question: where does the trust network fail?

The answer: single points of failure.

Every link in that chain we described: Opay, the bank, NIBSS, the KYC provider is a centralised entity. That means:

One server goes down -> transactions fail
One database is compromised -> your data is leaked
One regulatory decision -> your account is frozen without warning
One bad actor inside the organisation -> the records are altered

You have no way to verify what's happening. You're trusting the institution to be honest, competent, and well-intentioned. Usually they are. But the system requires you to trust them, you have no alternative.

Blockchain's argument is not that institutions are corrupt. It's that you shouldn't have to assume they're honest. The system should be designed so that anyone can verify the truth not just the people running the servers.

In practice, that means:

Instead of rules locked on a private server -> rules deployed as code, in public
Instead of promises -> anyone can read the code and check exactly what it does
Instead of one keeper -> everyone keeps a copy, and no single party can rewrite history

That's not magic. That's engineering. And it comes with real costs.

The Honest Trade-offs (Most Courses Skip This Part)

One of the things I'm proudest of in how Uchenna ran Session 1 is that he didn't sell blockchain. He explained it including the parts that hurt.

Distributed verification is slower than a centralised server. Always. If you need instant transaction finality, a blockchain is the wrong tool.

It's more expensive to run. Every node in the network has to process every transaction. That cost is real and it compounds at scale.

Finality works differently. On your bank app, if you send money to the wrong person, you call customer service. On a public blockchain, the transaction is final. There is no customer service. The code runs.

And perhaps the sharpest point: blockchain doesn't remove trust. It relocates it. You stop trusting institutions and start trusting code, mathematics, and the incentive structures of a decentralised network. That's a different kind of trust, more auditable, more transparent, but trust nonetheless.

Understanding those trade-offs is what separates engineers who can reason about distributed systems from developers who just know how to call a Web3 library.

Watch the Full Session

Everything I've described above is the skeleton of a 64-minute live session with audience interaction, Q&A, and a cohort working through these ideas in real time.

Uchenna also covered:

A brief history of blockchain (Bitcoin 2008 -> Ethereum 2015 -> today)
Public vs. private blockchains and why each exists
What Ethereum and the EVM actually are
What people are building on Ethereum right now
Consensus mechanisms: Proof-of-Work, Proof-of-Stake, Proof-of-History
A live Q&A: does blockchain make systems trustless, or does it just shift the trust?

If this article gave you the argument, the video gives you the full picture including the moments where the cohort pushed back and Uchenna had to defend his reasoning in real time.

That's the kind of session we wanted to build. Not a lecture. A thinking session.

Watch here 👉 Blockchain Fundamentals Explained | BinnaDevLab Cohort 1, Session 1

What's Next

Session 2 is hands-on. Obinna takes the cohort from theory into code writing and deploying a smart contract in Solidity, live.

If Session 1 answers why blockchain exists, Session 2 answers how you build on it.

Follow BinnaDevLab to catch it when it drops.

About BinnaDevLab

BinnaDevLab is a developer training community built around one idea: reason before you code.

We run structured cohorts for developers who want to build with depth not just ship fast.

🌐 binnadev.com

Web3 Architecture Explained Like You're 5 (From a Front-End Perspective)

Mon, 05 Oct 2026 06:10:09 +0000

The biggest barrier in Web3 isn't cryptography it's vocabulary. Most users bounce off dApps because interfaces speak in backend jargon instead of human experience.
If we want to build interfaces people trust, we need plain English. Here is Web3 architecture broken down into Web2 terms:
Public Address vs. Private Key: Your address is your bank account number (safe to share). Your private key is your signature/password (never share).

Blockchain: A shared database running on thousands of machines simultaneously. Once written, no single entity can edit or erase it.
Connect Wallet: Not a traditional login. It simply proves address ownership so the UI can read your balances safely.

Smart Contract: An automated ⁠if/then⁠ rule on chain. Example: IF 0.05 ETH is received, THEN mint 1 ticket instantly without a middleman.

Gas: The network execution fee paid to validators for processing your transaction.

The UI Responsibility
Our job as front-end engineers isn't to hide these concepts, it's to make them clear before a user signs anything.
When a UI explains what a contract is doing before triggering a wallet popup, anxiety drops and trust goes up. Great Web3 UX isn't about removing agency; it's about eliminating ambiguity.

MyZubster: Building a Decentralized Future

Sun, 04 Oct 2026 08:58:01 +0000

From Two Developers to a National Digital Network: Can We Build an Internet That Belongs to Its Participants?

How MyZubster is exploring independent nodes, local AI, verifiable knowledge, digital identity and a new model of technological cooperation.

By Daniel Ioni — MyZubster Open Ecosystem

An ongoing collaboration with Nicola / N4K48

What if we stopped building platforms and started connecting independent people?

For years, the technology industry has encouraged us to build bigger platforms.

More users. More data. More centralized infrastructure.

Every successful platform promises convenience, integration and a better experience.

But there is a fundamental question we rarely ask:

What happens to our independence when our entire digital existence depends on infrastructure controlled by someone else?

As developers, we have become extremely good at connecting applications to centralized services.

Perhaps our next challenge should be connecting independent applications to each other.

That is the idea behind our current MyZubster experiment.

I am Daniel Ioni, and together with an independent developer named Nicola, also known as N4K48, I am investigating how personally controlled software can become part of a wider digital ecosystem.

Our experiment began with two independent environments.

I operate the MyZubster infrastructure on a VPS.

Nicola develops his own software on a separate Windows computer.

We have built a Node Bridge designed to exchange selected information between these environments without requiring Nicola to expose his complete local application to the public Internet.

The updated Bridge is already deployed and tested on the VPS.

Our next milestone is the authenticated end-to-end connection with Nicola's actual computer.

But while building this connection, we began asking a much more ambitious question.

Could an experiment involving two developers eventually provide useful lessons for building a nationwide network of independent digital services?

Not a single platform controlling everything.

A federation connecting independently operated systems.

Here is what such a future would require.

1. Decentralization without interoperability is just fragmentation

Imagine a country with thousands of independent servers.

Every university has a node. Every association has another. Municipalities operate their own infrastructure. Developers maintain independent applications.

It sounds decentralized.

But what happens if none of these systems can communicate?

We have not built an ecosystem. We have created thousands of isolated islands.

This is why open standards must come first.

A future federated MyZubster architecture should investigate compatibility with established approaches for decentralized identity, verifiable credentials and interoperable data exchange.

Public, versioned APIs would allow third-party developers to implement compatible services without depending on our original codebase.

Existing European digital identity initiatives are particularly relevant.

Interoperability with the European Digital Identity Wallet, eIDAS and appropriate national identity systems deserves investigation.

However, our current experimental software has not demonstrated that compatibility.

Supporting a standard requires actual implementation, conformance testing and, where applicable, regulatory assessment.

The broader principle is straightforward:

An ecosystem becomes meaningful when its participants can leave, migrate and still communicate.

If users cannot move between compatible services, decentralization becomes another marketing term.

2. Our first practical experiment: the Node Bridge

Large technological transformations need small, testable beginnings.

Our beginning is a connection between two independently managed computing environments.

The MyZubster VPS runs a Docker-based broker behind Nginx and an HTTPS endpoint.

Nicola's environment contains his experimental software, local database components and AI-related services.

A lightweight Python agent is designed to initiate outbound communication with the VPS.

It retrieves authorized requests, processes them through Nicola's local application and returns limited results.

This architecture means we do not need to expose his entire local development API directly to the Internet.

But building the first version revealed an important problem.

Our broker used temporary job assignments. When an assignment expired, the request could be offered to another agent.

Unfortunately, an outdated agent could still submit a result associated with its expired assignment.

We reproduced this behavior and corrected it by requiring a unique identifier for every assignment.

An outdated result is now rejected rather than accepted as the result of the current operation.

Our corrected implementation passed automated regression tests and an integration test inside a separate Docker deployment.

We updated the production broker on the VPS and subsequently rotated its credentials.

The next step is completing the real authenticated connection with Nicola's computer.

Notice what this experience teaches us.

A distributed system is not simply an application running on multiple computers.

It must handle delays, disconnections, retries, outdated information and conflicting operations.

If we cannot solve these problems for two independent environments, we have no credible foundation for discussing thousands of nodes.

3. Local AI could change who controls information

Artificial intelligence will influence almost every digital service.

But that does not necessarily mean all information must be transferred to a remote AI provider.

Nicola's independent project explores an alternative.

His experimental MyZubster MVP uses technologies including Ollama and Qdrant to support locally executed AI and retrieval-augmented generation.

Its underlying philosophy is evidence-first development.

The application should distinguish between an exact stored observation and a plausible AI-generated answer.

This becomes especially important when AI participates in education, professional workflows or public services.

Imagine a federation in which participants maintain appropriate datasets locally.

An independent node could answer a permitted question or provide an authorized service without necessarily transferring its entire underlying database.

Some operations might still require cloud services. Others could remain local.

The important innovation would be having a meaningful choice.

However, running AI locally does not automatically establish privacy, security or regulatory compliance.

Those properties must be designed and evaluated independently.

4. What about Tor?

Our broader infrastructure experiments also include Tor.

That creates an opportunity to investigate different communication paths for independent services.

Tor onion services can provide network privacy properties that differ from conventional Internet hosting.

But we should avoid mixing concepts.

Tor is not synonymous with decentralization.

HTTPS is not equivalent to anonymity.

And an encrypted connection is not automatically an authorized connection.

Our currently verified Node Bridge communicates through conventional HTTPS.

A dedicated onion transport for the complete Nicola connection remains a possible future experiment, not a completed technical result.

In a mature federation, alternative communication methods could improve flexibility and potentially resilience.

Every method would need an appropriate threat model, security testing and clear operational documentation.

The objective should be practical autonomy, not technological mysticism.

5. Digital identity must become portable

Today's digital identity is often fragmented across commercial platforms.

People maintain different profiles, credentials and records of their achievements.

Organizations face similar problems.

A federated digital ecosystem could investigate ways to improve identity portability and selective information sharing.

Decentralized identifiers and verifiable credentials offer relevant technical approaches.

But adopting these technologies responsibly requires much more than creating a wallet or issuing a token.

Identity recovery matters.

Credential revocation matters.

Fraud prevention matters.

Privacy matters.

Legal responsibility matters.

A citizen should not be expected to become a cryptography expert merely to use a digital service.

If this model is ever to become widely adopted, its user experience must compete with the convenience offered by centralized applications.

That means accessible onboarding, appropriate recovery mechanisms, understandable permissions and reliable technical support.

It also means offering different participation models.

Some people may want to operate their own infrastructure.

Others may prefer services operated by trusted associations, cooperatives or professional providers.

Decentralization should expand people's choices rather than create a new technical barrier.

6. Can knowledge become independently verifiable?

This is one of the most interesting questions emerging from our collaboration.

When someone says they have learned a skill, how can they demonstrate their progress?

Traditional profiles rely heavily on self-description.

Repositories can provide useful evidence of development activity.

Technical reports can document methodology.

Tests can demonstrate specific software behavior.

Educational institutions can assess competence.

What if we could connect these different forms of evidence?

MyZubster is exploring a knowledge-proof approach built around inspectable records, versioned source material, cryptographic digests and acknowledged contributions.

Our work with Nicola has already contributed to a documented knowledge-transfer experiment with a recorded commitment on a blockchain test network.

That commitment can be used to verify the integrity of the corresponding evidence package.

However, this does not mean the blockchain has automatically certified someone's skills.

Cryptographic integrity and human assessment are different things.

An effective knowledge system would need both technical verification and appropriate evaluation.

Imagine a student who builds a working application, publishes its source code, documents its tests and receives an appropriate assessment from an authorized institution.

Imagine that the resulting portfolio could be accessed through compatible services without depending on a single educational platform.

That is the kind of long-term possibility worth researching.

7. Why our experiment also includes a comic

Technology is not experienced only through source code.

People understand complex ideas through stories, visual identities and creative expression.

During our collaboration, Nicola developed a series of illustrated chapters around his digital identity, N4K48.

The story follows his journey from an independent software idea toward the fictional cyberpunk environment of Neon Plaza.

Its fourth chapter is called The Bridge to Be Built.

It reflects the very real technical challenge we are currently addressing.

This creates an unusual connection.

The comic communicates the development journey.

The software repository records implementation work.

The test evidence documents verified technical behavior.

The knowledge records help connect the relevant information.

We are also exploring transparent provenance for digital creative work.

One original N4K48 comic is currently documented as a proposed NFT candidate.

It has not been minted, and relevant rights must be verified before any authorized commercial application.

The broader objective is not to tokenize everything.

It is to develop better ways of documenting creative work and connecting its history to appropriately verified records.

8. A nationwide ecosystem needs governance, not just servers

Suppose independent nodes become technically interoperable.

Who establishes common rules?

Who handles disputes?

What happens when participants publish illegal content, abuse shared services or dispute the validity of a credential?

These problems cannot be solved through server architecture alone.

A larger federation would need transparent governance.

One possible direction is a multi-stakeholder organization involving independent developers, users, educational institutions, civil society and participating service providers.

It could coordinate technical standards, develop shared policies and provide transparent processes for addressing disputes.

But governance must not become another mechanism for concentrating control.

Independent participants need meaningful representation.

Protocol decisions should be open to scrutiny.

Operators must remain accountable for their own legal obligations.

We want to investigate shared rules without recreating the same centralized dependencies that motivated the project.

9. There is no sustainable decentralization without an economy

Someone must pay for infrastructure.

Someone must maintain the software.

Someone must respond when security problems emerge.

Someone must create documentation, assist users and conduct independent assessments.

Open source is a development and licensing model, not a magical source of unlimited operational funding.

If MyZubster eventually expands beyond its laboratory stage, we will need a sustainable economic model.

Possible approaches include research grants, professional services, educational initiatives, managed infrastructure and partnerships around useful applications.

There is no requirement to launch a speculative token.

Any potential crypto-asset or payment-related feature would require a separate economic justification and appropriate regulatory analysis.

The best foundation for sustainability is demonstrable value.

If independent participants receive genuine benefits from interoperability, privacy choices and shared services, sustainable business and organizational models become easier to investigate.

10. The regulatory challenge

A national-scale ecosystem cannot operate outside legal responsibility.

Its architecture would need to account for applicable data-protection obligations, digital identity requirements, AI regulation and other rules relevant to the services it actually provides.

The GDPR, European AI Act, eIDAS framework and potentially MiCA are among the areas requiring professional assessment when their respective conditions apply.

Creative projects introduce copyright and licensing considerations.

Sensitive information requires additional protections.

Financial services may introduce further obligations.

These frameworks are not interchangeable, and no single technology establishes automatic compliance.

Our current project is experimental.

We are not claiming formal regulatory approval, institutional adoption or readiness to handle sensitive public-sector information.

Legal design must evolve alongside technical design.

11. Five stages from laboratory to possible national adoption

Here is a realistic way to structure the ambition.

Stage 1: Build and verify

Complete the authenticated test between the VPS and Nicola's independent computer.

Release reviewed Bridge code.

Publish reproducible tests.

Document security boundaries and known limitations.

This is our current stage.

Stage 2: Invite independent participants

Connect additional nodes operated by different people.

Validate onboarding, consent, access revocation and operational recovery.

Test small, non-sensitive applications with willing communities.

Stage 3: Create regional federation experiments

Move beyond a single central broker.

Develop compatible implementations and multiple independently administered coordination services.

Evaluate interoperability and resilience under realistic operating conditions.

Stage 4: Investigate institutional integration

Work with appropriate technical, academic or institutional partners where opportunities arise.

Evaluate relevant standards, accessibility, governance and compliance.

Identify applications that deliver measurable benefits.

Stage 5: Support wider adoption

If the previous stages succeed, develop the accessibility, organizational capacity and sustainable funding needed for broader participation.

National adoption should emerge from demonstrated value rather than an announcement.

We cannot declare an infrastructure ready simply because its roadmap contains the word national.

12. The most important metric is independence

Millions of registered users would make an impressive headline.

But they would not automatically prove that we had built a meaningful decentralized ecosystem.

We should measure something more important.

Can independently operated systems communicate?

Can participants leave without losing access to portable information?

Can permissions be revoked?

Can services recover from failures?

Can another developer reproduce our results?

Can people participate without advanced technical knowledge?

Can governance decisions be understood and challenged?

And can the ecosystem sustain its operations without becoming dependent on a single powerful actor?

These questions are more difficult than counting accounts.

They are also much more relevant to our stated objective.

Conclusion: The future does not need another digital empire

I do not believe that building a decentralized future means replacing today's dominant platforms with MyZubster as another dominant platform.

That would reproduce the same fundamental problem.

Our ambition is to investigate an ecosystem where independently managed applications, digital identities, creative projects and verifiable records can cooperate through open interfaces.

The collaboration with Nicola is our starting point.

His software remains independently developed.

Our VPS provides the current coordination infrastructure.

The Node Bridge establishes a limited technical connection between these environments.

Local AI helps explore how information might remain under participants' control.

The comic makes the journey understandable beyond technical documentation.

And our knowledge-proof experiments investigate how development work and learning might leave inspectable records.

We are not yet operating a decentralized national network.

We are building and testing the components that might eventually make such a network possible.

The next milestone is simple, concrete and essential:

One authenticated request. Two independent computers. A verified result.

If we can reproduce that successfully, document its limitations and allow others to build on it, we will have something more valuable than another technological promise.

We will have the beginning of an open, testable approach to digital cooperation.

And every future step will have to earn its place through evidence.

Explore MyZubster

MyZubster Open Ecosystem
https://github.com/MyZubster-Ecosystem/myzubster

Nicola / N4K48 — Independent MVP
https://github.com/nicolaususnicola-lgtm/myzubster-mvp

N4K48 Comic Series
https://github.com/nicolaususnicola-lgtm/myzubster-mvp/tree/main/docs/n4k48-comics

Knowledge-Transfer Documentation
https://github.com/nicolaususnicola-lgtm/myzubster-mvp/blob/main/knowledge/KNOWLEDGE-TRANSFER-2026-09-18-DANIEL-NICOLA.md

Our Technical Development Story on DEV Community
https://dev.to/danielioni/beyond-the-platform-building-myzubster-with-local-ai-independent-nodes-comics-and-verifiable-kcm

*Project status: October 4, 2026. This article presents a research and development vision. Institutional partnerships, national deployment,

Building Beyond Platforms: How MyZubster and N4K48 Are Connecting Independent Software, AI, Comics

Sun, 04 Oct 2026 08:29:56 +0000

Building Beyond Platforms: How MyZubster and N4K48 Are Connecting Independent Software, AI, Comics and Verifiable Knowledge

By Daniel Ioni | MyZubster Ecosystem
In collaboration with Nicola / N4K48

What if the next Internet belonged to its participants?

Most of today's digital experiences follow a familiar model.

We create an account, upload our information, develop our projects and build our identities inside someone else's infrastructure.

Platforms have made collaboration easier, but they have also created dependencies. The tools we use, the information we publish and the communities we build frequently depend on decisions made by centralized service providers.

What would happen if we approached digital collaboration differently?

What if a developer could maintain independent software on a personal computer, use local artificial intelligence and selectively connect to a wider ecosystem without exposing the entire application?

What if artists could document the history of their work, while learners could connect their achievements to inspectable technical evidence?

These questions inspired an ongoing collaboration between myself, Daniel Ioni, and Nicola, an independent developer known as N4K48.

Together, we are exploring this direction through MyZubster.

And our journey has already taken us from local AI and an experimental software product to illustrated storytelling, server infrastructure, distributed communication and cryptographically verifiable knowledge.

This is the story of what we have built so far.

1. Two developers, two independent environments, one shared experiment

Our collaboration started with a simple principle: participation in an ecosystem should not require abandoning your own project.

Nicola has been developing an independent application called N4K48 / MyZubster MVP.

Rather than creating another interface that simply asks an AI model to answer questions, he has been experimenting with structured information, local storage and evidence-based retrieval.

His application combines several technologies and ideas:

Python APIs and Docker-based development.
Persistent observations and recorded events.
Qdrant and Ollama for local artificial intelligence and retrieval-augmented generation.
An internal ledger and experimental economic simulations.
A creative catalog connected to his N4K48 identity.
Integration with Zorgax, the AI assistance concept within MyZubster.

An important principle guides this development:

An AI-generated answer should not replace an authoritative record when that record already exists.

If an application stores an exact observation, it should be capable of retrieving that observation without inventing an alternative version.

This approach becomes increasingly important when AI systems participate in education, research, economic applications or reputation systems.

Nicola's project is available as an experimental open-source MVP, including a public release candidate.

It is not presented as production-ready software.

That distinction is part of our philosophy: development should be documented through actual evidence rather than ambitious claims.

Explore Nicola's independent software on GitHub

2. When software development becomes a comic

Something unexpected happened during our collaboration.

We began connecting Nicola's technical journey to the visual universe of MyZubster.

His digital identity, N4K48, became the protagonist of an illustrated story set in an evolving cyberpunk-inspired world.

Neon Plaza represents a place where independent projects, digital identities and knowledge might eventually meet.

The comic series currently contains four chapters:

Chapter 1: From a Software Idea to the Metaverse

N4K48 begins with an independent software idea and discovers the possibility of connecting it to something larger.

Chapter 2: The Software Takes Shape

The story follows the work of development: authentication, persistent information, experiments and technical verification.

Chapter 3: Towards Neon Plaza

N4K48 approaches the creative vision of a shared digital environment.

Chapter 4: The Bridge to Be Built

The narrative returns to an unresolved engineering challenge: how can independent software establish a secure connection to the MyZubster infrastructure?

This final chapter is particularly meaningful because it connects our creative vision to the technical problem we are currently solving.

The illustrations were produced with AI assistance under Nicola's documented creative direction.

We have also recorded the provenance of the images through repository references and Git metadata. Rights relating to certain external visual elements and potential commercial uses still require verification.

One original N4K48 comic has been proposed as a possible NFT candidate. It has not been presented as an already minted NFT.

For us, creativity and technical documentation should support each other without becoming confused.

A comic can tell the story of an idea.

The corresponding code, tests and development records can show how far that idea has actually progressed.

Discover the N4K48 comic series

3. Building the bridge between two independent computers

We eventually arrived at the most practical question in our collaboration.

How could Nicola connect his locally running software to MyZubster while maintaining control of his own development environment?

We did not want to require him to expose his entire local API to the public Internet.

Instead, we began constructing a limited, authenticated communication bridge.

Our current architecture includes two separate environments.

The first is the MyZubster VPS, running Ubuntu, Docker and Nginx. It hosts a small Node Bridge broker accessible through a controlled HTTPS endpoint.

The second is Nicola's Windows computer, where his application and local catalog run independently.

A lightweight Python agent is designed to initiate an outbound HTTPS connection to the VPS.

When an authorized request becomes available, the agent retrieves it, contacts Nicola's local application and returns an appropriate response.

The important distinction is that the connection originates from the independent node.

Nicola does not have to publish his development API directly to the Internet merely to participate in the experiment.

The initial Bridge supports a deliberately restricted set of catalog operations.

This is a modest architecture, but it addresses a real problem: how to exchange selected capabilities between independently controlled systems.

The bug that changed our implementation

During testing, we discovered a problem with temporary job assignments.

Our broker could reassign a request when an earlier assignment expired. Unfortunately, the original version could still accept an outdated result from the previous assignment.

That created a risk of confusing an old response with the current result.

We reproduced the problem, corrected the assignment protocol and introduced a unique identifier for each lease.

The updated implementation requires the current lease identifier before accepting a result.

Our regression tests now verify rejection of expired, outdated and duplicate submissions.

This experience reinforced an important lesson:

Distributed software must be designed for interruptions, delays and unexpected responses—not just successful connections.

The corrected broker passed our automated tests and a separate Docker integration test using an agent and simulated catalog.

We subsequently deployed the updated Docker image on the VPS, verified its health and rotated its authentication credentials.

The previous node credential was rejected after rotation.

These are concrete achievements.

However, there is still one essential step ahead of us: validating the complete authenticated connection with Nicola's actual Windows computer.

We have prepared and independently verified his updated agent package. The live VPS-to-PC test remains our next milestone.

We prefer to report that distinction clearly rather than describe an unfinished experiment as a completed decentralized network.

4. Where Tor enters our vision

Our infrastructure experiments also involve Tor.

Tor is particularly interesting when discussing independent communication, privacy and alternatives to conventional Internet exposure.

Its onion services can provide access to applications through the Tor network without requiring the underlying service to publish its location to clients.

But Tor and decentralization are not interchangeable concepts.

Tor provides specific network privacy properties.

Decentralization concerns the distribution of control, authority and infrastructure dependencies.

And application security still requires authentication, carefully restricted operations and responsible management of credentials.

Our currently verified Node Bridge operates through conventional HTTPS. We have not yet demonstrated the complete connection over a dedicated Tor onion service.

A potential future direction is to investigate alternative communication routes, including appropriate Tor-based access.

The purpose would be to offer participants more choices regarding how their independently managed nodes connect.

It would not eliminate the need to understand and secure the underlying software.

5. Decentralization is not a switch

There is a temptation to describe any application running on multiple computers as fully decentralized.

We think this oversimplifies the challenge.

Our present system consists of independent environments communicating through a central VPS broker.

That already creates a useful degree of software and data independence.

But the VPS remains a coordination dependency.

If it becomes unavailable, the current communication path stops working.

A more decentralized future will require additional work: independent node identities, alternative brokers, stronger message verification, reliable recovery, consent management and additional communication paths.

These are difficult engineering and governance problems.

We are approaching them incrementally.

Our intention is to develop a system in which independent participants can decide what to share, retain control over their own resources and contribute to a shared ecosystem through well-defined interfaces.

That ambition is larger than our current implementation.

And we believe documenting the distance between an ambition and its demonstrated realization is part of responsible open-source development.

6. The missing piece in digital collaboration: proof of knowledge

There is another question underlying our work.

When two people collaborate, how do they document what was learned and created?

A finished application reveals something about the result.

A Git repository reveals parts of its development history.

Tests provide evidence of particular software behavior.

But the complete human story also includes research, failed experiments, mentoring, decisions, corrections and acquired understanding.

We are exploring ways to connect these elements through MyZubster's knowledge-proof approach.

The objective is to construct inspectable evidence packages containing documentation, source revisions, test results and explicitly acknowledged contributions.

A cryptographic hash can then identify a particular version of that material.

Nicola's repository already documents an earlier knowledge-transfer snapshot associated with a confirmed commitment on the Base Sepolia test network.

This demonstrates an important technical capability: the published evidence package can be checked against a previously recorded cryptographic commitment.

However, a blockchain commitment does not independently certify someone's competence, establish legal authorship or prove that every statement in a document is true.

Those questions require supporting evidence and appropriate human acknowledgment.

We see cryptographic verification as one component of a larger knowledge-provenance system—not as a replacement for critical evaluation.

Explore our documented knowledge-transfer experiment

7. What could this paradigm change tomorrow?

Imagine a world in which participating in a digital ecosystem does not automatically mean surrendering control over your software or data.

Independent developers could connect their applications through limited interfaces.

Artists could associate their work with transparent creation histories.

Students could support their knowledge records with actual projects and test results.

Researchers could share approved findings while retaining control of underlying datasets.

Communities could develop alternative forms of coordination rather than relying entirely on one company's infrastructure.

Local AI could help people work with their own information while reducing unnecessary dependence on remote processing.

These possibilities are compelling.

But they are not inevitable consequences of deploying a blockchain, installing an AI model or connecting a server to Tor.

They require open standards, interoperable implementations, responsible governance and sustained collaboration.

The most important transformation may therefore be cultural rather than purely technical.

Instead of asking people to trust an impressive announcement, we could increasingly provide them with a way to inspect the evidence behind it.

Instead of requiring every creator to abandon an independent project, we could design systems that allow carefully controlled participation.

Instead of treating learning as an invisible process, we could build better records of the work through which knowledge is acquired and shared.

This is the future we want to investigate.

8. Our next milestone

Our immediate goal is not to announce a fully decentralized Internet.

It is much more concrete.

We want to demonstrate a successful round trip between the MyZubster VPS and Nicola's independent application.

A request should originate from our VPS, travel through the authenticated Bridge, be processed by Nicola's local software and return a verifiable result.

After that, we intend to document what happens during interruptions and reconnections, and evaluate the next architectural improvements.

We will then publish a dedicated technical follow-up containing the actual results.

Meanwhile, this article, our earlier technical report and the public development history form part of our evolving knowledge record.

They document not just an idea, but the engineering process through which we are investigating it.

9. One ecosystem, independent creators

I believe the future of the Internet should create more opportunities for people to build together without requiring them to become dependent on the same centralized system.

My collaboration with Nicola demonstrates how this process can begin.

One person develops independent software.

Another maintains shared infrastructure and works on integration.

Artificial intelligence helps organize and retrieve information.

Creative storytelling communicates ideas that technical documentation alone might not convey.

Tests, source history and cryptographic commitments provide different kinds of evidence.

And an unfinished technical challenge becomes the subject of the next experiment.

Our goal is not to remove human collaboration from technology. It is to build technology that makes independent human collaboration more powerful.

That is the direction we are exploring with MyZubster.

The bridge is being built.

The next chapter will show what happens when Nicola's independent node actually crosses it.

Follow the journey

MyZubster ecosystem:
https://github.com/MyZubster-Ecosystem/myzubster

Nicola's independent software:
https://github.com/nicolaususnicola-lgtm/myzubster-mvp

N4K48 comics:
https://github.com/nicolaususnicola-lgtm/myzubster-mvp/tree/main/docs/n4k48-comics

Our detailed technical article on DEV Community:
https://dev.to/danielioni/beyond-the-platform-building-myzubster-with-local-ai-independent-nodes-comics-and-verifiable-kcm

Knowledge-transfer evidence:
https://github.com/nicolaususnicola-lgtm/myzubster-mvp/blob/main/knowledge/KNOWLEDGE-TRANSFER-2026-09-18-DANIEL-NICOLA.md

Technical status: October 4, 2026. This article describes an ongoing experimental project. The updated VPS broker and simulated integration have been verified; the authenticated end-to-end test with Nicola's independent computer is still pending.

From Technical Review to Knowledge Attestation: What We Learned from CoderLegion

Thu, 01 Oct 2026 08:19:47 +0000

Certo. Per CoderLegion lo imposterei come secondo capitolo della serie: non “abbiamo ricevuto feedback”, ma come una review tecnica può diventare conoscenza tracciabile e influenzare l’architettura senza essere confusa con una certificazione automatica.
From Technical Review to Knowledge Attestation: What We Learned from CoderLegion
Open-source knowledge does not only arrive through code.
Sometimes the most valuable contribution is a question.
A reviewer looks at an architecture and asks:
Who is actually confirming this claim?

Or:
If the same system creates the evidence and verifies it, is that really independent verification?

Those questions can change a system more deeply than another feature.
At MyZubster, feedback from Mike Dabydeen and the CoderLegion community pushed us to think more carefully about provenance, verification, blockchain finality, and what it really means to call knowledge “verified.”
This became part of the thinking behind our Contributor Knowledge Passport and Knowledge Attestation model.
The problem with verification: confirmed
Imagine a system produces a record like:
{
"contribution": "some contribution",
"verification": "confirmed"
}

It looks reassuring.
But there is an obvious question:
Confirmed by whom?
If the same pipeline creates the claim and writes:
verification = confirmed

then we have not necessarily created independent verification.
We may only have created a stronger-looking self-assertion.
That distinction matters.
A verification claim needs provenance
The feedback helped reinforce a principle that now sits at the center of our attestation design:
Do not only store:
VERIFIED

Store:
who observed it
what was observed
how it was checked
what evidence was used
when the observation happened

Conceptually:
Contribution

↓

Evidence

↓

Observer / verifier

↓

Verification method

↓

Attestation

Instead of:
claim = true

we want something closer to:
claim
+
evidence
+
observer
+
method
+
time
+
provenance

Observation is not the same as verification
This led us to another important distinction.
A GitHub pull request being merged is observable.
A test suite passing is observable.
A transaction existing on a blockchain is observable.
But an observation does not automatically mean:
independently verified knowledge

So our current model deliberately allows states such as:
OBSERVED
VERIFIED
REJECTED

That gives us room to express what actually happened.
For example:
GitHub PR merged
→ OBSERVED

does not automatically become:
Contributor is independently certified as an expert

That would be a larger claim than the evidence supports.
Knowledge should inherit the quality of its evidence
This is particularly important for the Contributor Passport we are building.
Our model is moving toward:
Contributor

↓

Contribution

↓

Knowledge

↓

Evidence

↓

Attestation

↓

Reward

↓

Reputation

But the arrow from Contribution to Knowledge should not magically create truth.
It needs provenance.
A contributor might demonstrate:
NFC API integration

through a merged pull request.
Another contributor might demonstrate the same concept through:
documentation
tests
architecture review
security analysis
technical design

The type of evidence matters.
Review itself can transmit knowledge
This is where the CoderLegion discussion became especially interesting for us.
A reviewer does not need to submit production code to contribute knowledge.
Consider an architectural review that identifies:
self-attestation
missing verifier identity
weak finality semantics
insufficient evidence provenance
privacy weakness in deterministic hashes

That review is itself a knowledge contribution.
It may demonstrate knowledge of:
verification architecture
provenance design
blockchain finality
privacy-preserving evidence
trust boundaries

The contribution is different from writing a feature, but the knowledge transfer is real.
Who verifies the verifier?
One of the hardest problems in knowledge systems is recursive trust.
If MyZubster says:
Mike demonstrated knowledge of verification architecture

you can reasonably ask:
Why should I trust MyZubster?

The answer should not be:
Because MyZubster says so.

Instead the system should preserve the underlying evidence.
Conceptually:
Knowledge claim

↓

Evidence

↓

Original technical discussion

↓

Reviewer identity

↓

Attestation method

The Passport becomes an index into evidence, rather than an authority demanding blind trust.
Blockchain evidence needs finality context
Another important lesson concerned blockchain evidence.
A transaction hash alone is useful, but sometimes incomplete.
For stronger provenance, systems may need information such as:
chain
block number
observation time
confirmation/finality state

And on layered blockchain systems:
L2 transaction
↓
batch inclusion
↓
L1 settlement

may matter.
The broader lesson is simple:
“Seen on-chain” and “finalized according to the relevant chain model” are not always identical statements.

Our current implementation does not yet encode every possible finality field.
That remains an area we want to improve.
Hashes are not automatically private
Another useful challenge concerned evidence hashes.
It is tempting to think:
SHA-256(value)

means:
value is now private

That is not necessarily true.
If the original value comes from a small or predictable set, an attacker can hash candidate values and compare them.
For low-entropy restricted data, stronger approaches may include:
salted digests
keyed hashes / HMAC
commitment schemes

depending on the threat model.
This is another example of why an attestation architecture needs more than a field called evidenceHash.
The cryptographic construction and the data being protected both matter.
What changed in MyZubster
The feedback influenced our direction toward a first explicit Knowledge Attestation model.
Conceptually, an attestation can capture information such as:
contributionId
evidenceType
evidenceReference
verifier
verificationMethod
observedAt
evidenceHash
status

This gives us something more expressive than:
verified: true

It also lets the Contributor Passport distinguish between:
knowledge demonstrated
knowledge observed
knowledge independently verified
knowledge rewarded

These should not be collapsed into a single badge.
What we have not solved yet
It is equally important to say what is unfinished.
We have not implemented every architectural recommendation that came out of these discussions.
For example, we still want to improve areas including:
richer blockchain finality metadata
stronger privacy treatment for low-entropy evidence
independent verifier models
multi-attestation consensus
reputation for reviewers

That distinction matters.
Technical feedback should not be turned into a marketing claim that everything has already been solved.
Reviewers should have a Passport too
This leads to an interesting consequence.
If contributors can build a Knowledge Passport through code, why should reviewers not build one through review?
Imagine:
Mike / CoderLegion

↓

Technical Review

↓

Knowledge Contribution

↓

Verification Architecture

↓

Evidence

↓

Attestation

↓

Reputation

A reviewer could accumulate demonstrated knowledge across projects without needing to own the project or write every implementation.
That would make review itself a first-class contribution.
A shared Knowledge Graph
Eventually we want the graph to connect contributors through shared knowledge concepts.
For example:
Contributor A

↓

Pull Request

↓

DEMONSTRATES

↓

Verification Architecture

↑

DEMONSTRATES

↑

Technical Review

↑

CoderLegion Reviewer

Now the graph is not merely recording activity.
It is recording how knowledge moved through the ecosystem.
Code is only one form of knowledge transfer
Open source traditionally measures things like:
commits
pull requests
issues
stars

Those metrics are useful.
But they leave out an enormous amount of intellectual work.
Architecture critique.
Security review.
Documentation.
Research.
Testing strategy.
Design decisions.
Questions that reveal hidden assumptions.
A useful knowledge system needs to recognize those contributions too.
What CoderLegion helped us see
The core lesson we took from the discussion was not a specific database schema.
It was a design principle:
Verification should expose its provenance.

And a second principle followed naturally:
A reviewer can contribute knowledge without contributing code.

Those ideas now influence how we think about Contributor Passports, Knowledge Attestations, and the broader MyZubster Knowledge Graph.
Where this goes next
The architecture we are exploring is moving toward:
Person
↓
Contribution
↓
Demonstrated Knowledge
↓
Evidence
↓
Attestation
↓
Reputation

where Contribution might be:
code
review
documentation
research
testing
design
architecture feedback

The objective is not to create another collection of unverifiable skill badges.
The objective is to preserve the path from:
knowledge → evidence → provenance.
Knowledge should not merely be declared.
The path through which it was demonstrated should remain visible.

Thanks to Mike and the CoderLegion community for pushing on exactly the questions that make systems like this stronger.
DEV metadata
Title
From Technical Review to Knowledge Attestation: What We Learned from CoderLegion
Description
How technical review around provenance, independent verification, blockchain finality and privacy influenced the MyZubster Contributor Knowledge Passport.

Building Evidence Systems That Know What They Cannot Prove

Wed, 30 Sep 2026 17:09:41 +0000

Building Evidence Systems That Know What They Cannot Prove
When we started building verifiable Knowledge in MyZubster, hashing seemed like the easy part.
Take some data.
Canonicalize it.
Hash it.
Optionally anchor the digest somewhere external.
Done.
Except that almost every interesting problem begins after that.
What exactly did we hash?
Can somebody reproduce those bytes?
Does a blockchain transaction prove the underlying claim?
Does a merged GitHub pull request prove that a contributor was paid?
Does a payment record need to expose the recipient's wallet publicly?
And what should the system return when evidence simply does not exist?
Those questions pushed us from a collection of hashes toward an Evidence Graph.
More importantly, they changed our definition of a successful verification system.
A good evidence system shouldn't just tell you what it can prove.
It should preserve the boundary around what it cannot prove.
The first mistake: treating a hash as a conclusion
A cryptographic digest can establish something very useful:
These exact bytes produce this digest.

But that statement is much narrower than:
The information represented by these bytes is true.

Consider a Knowledge Card describing a technical contribution.
We can serialize it and calculate SHA-256.
Knowledge Card

↓

Canonical Payload

↓

SHA-256

↓

Digest

That gives us integrity.
It does not independently establish authorship, correctness, ownership, payment, or truth.
Once we started making those distinctions explicit, a single proof object stopped being sufficient.
We needed relationships.
Moving from hashes to an Evidence Graph
Our current Evidence Graph separates concepts that are often collapsed together:
Person
↓ CLAIMS
Claim
↓ DESCRIBED_BY
Knowledge Card
↓ SUPPORTED_BY
Evidence
↓ PRODUCED
Artifact
↓ CANONICALIZED_AS
Canonical Payload
↓ HASHED_AS
Digest
↓ ATTESTED_BY
Attestation

Each relation has deliberately limited semantics.
SUPPORTED_BY doesn't mean “proven true.”
HASHED_AS doesn't mean “verified.”
ATTESTED_BY doesn't mean “certified.”
And the hash of the Evidence Graph itself only protects the integrity of that graph representation.
This may sound overly cautious.
In practice, it makes the system much easier to reason about.
Zero attestations can be the correct answer
One of our tests produced a graph containing seven nodes, seven edges and:
attestation nodes: 0

That became one of our favorite results.
There was no confirmed blockchain attestation associated with that graph.
So the system didn't create one.
It still produced a deterministic graphHash.
It still represented the evidence chain we actually had.
But it stopped there.
That gave us an architectural rule:
Missing evidence should remain visibly missing.

A verification system becomes dangerous when absence gets silently upgraded into inference.
Then someone asked the right question
After we wrote publicly about the Evidence Graph, Mike Dabydeen pointed out another reproducibility problem.
Our Proof v2 experiment contains an exact canonical payload stored in Git.
It is 3,168 bytes.
Re-hashing those stored bytes produces:
6097e05866bafceec24663d2638cb1dae5742ac78284abbfd45cc9c3b0bfb845

That's reproducible.
But Mike's question, paraphrased, was:
Can someone reproduce those same bytes starting from the Knowledge Card?
That is a different test.
And it exposed an important missing piece.
Canonicalization is part of the proof
“Hash the thing you mean” isn't enough.
We also need:
Record how you produced the thing you hashed.

If two serializers represent the same logical JSON differently, they can produce different byte sequences and therefore different hashes.
So this:
Knowledge

↓

Canonical Payload

needs to become closer to:
Knowledge

↓

CANONICALIZED_AS

│
├── scheme
└── version
↓

Canonical Payload

RFC 8785, the JSON Canonicalization Scheme, is an obvious candidate for JSON data.
But there's an important migration rule here.
We cannot simply decide that our historical payload “was RFC 8785.”
First we have to test it.
If our existing 3,168-byte payload can be reproduced byte-for-byte using that scheme, great.
If it cannot, history should remain history.
We preserve Proof v2 with its actual serialization semantics and introduce a new explicitly labelled canonicalization version.
No retroactive renaming.
We've now turned this into a tracked engineering requirement.
What does a blockchain attestation actually add?
This led to another useful boundary.
Suppose Git already contains the canonical payload.
Why anchor its digest to a blockchain?
One possible answer is ordering outside our own infrastructure.
A Git commit timestamp isn't equivalent to an ordering event produced by an external blockchain.
So we're narrowing the intended meaning of ATTESTED_BY to something approximately like:
The committed digest existed no later than the referenced block on the identified chain.

That's useful.
But notice everything it doesn't say.
It doesn't say:
the claim is true

It doesn't say:
the contributor owns the work

It doesn't say:
MyZubster certified the person

And it doesn't say:
the blockchain verified the real-world event

Therefore an attestation needs explicit metadata sufficient to check the narrow statement.
Conceptually:
{
"chainId": "...",
"blockNumber": "...",
"transactionHash": "...",
"digest": "..."
}

The blockchain becomes an evidence source with defined semantics rather than a generic “verified” badge.
Testnets taught us another lesson
We currently have an experimental Sepolia proof.
That's useful for development.
It is not the same thing as permanent evidence infrastructure.
Testnets can disappear.
So the graph shouldn't assume one attestation is the final attestation.
Instead:

             ┌─ ATTESTED_BY → testnet
             │

Digest ──────────┼─ ATTESTED_BY → L2

             │
             └─ ATTESTED_BY → another anchor

That gives us an interesting property.
A later, more durable attestation doesn't need to rewrite or erase the earlier experiment.
Evidence accumulates.
Then we applied the same model to GitHub contributors
Once the Knowledge model became stricter, we asked whether it could represent software contribution history.
That sounds straightforward:
Contributor

↓

Pull Request

↓

Merged

↓

Bounty

↓

Paid

But this representation hides several independent state transitions.
A merged pull request is not a payment receipt.
A reward record is not necessarily a blockchain settlement.
And a transaction ID alone doesn't establish that the expected settlement was independently confirmed.
So we introduced additional Evidence Graph concepts:
contribution
bounty
settlement

and relationships:
CONTRIBUTED_TO
ACCEPTED_AS
SETTLED_AS

A real merged contribution became our regression test
We're using actual GitHub contribution history rather than relying entirely on synthetic fixtures.
For a merged contribution, the graph can establish:
Person
↓ CONTRIBUTED_TO
Contribution
↓ ACCEPTED_AS
GitHub Artifact

But if we don't have confirmed settlement evidence, the graph stops there.
There is no:
SETTLED_AS

edge.
This produces another important invariant:
Merged does not mean paid.

And similarly:
A reward state does not automatically mean independently confirmed external settlement.

Our targeted Evidence Graph suite currently contains 23 passing tests around these semantics.
The contributor extension is still going through the pull-request lifecycle, so we distinguish tested implementation from merged production state.
Making payment evidence deliberately difficult to invent
For SETTLED_AS, we're enforcing stronger conditions.
Conceptually:
Bounty
↓ SETTLED_AS
Settlement
├── status: paid
├── txId
├── independent sourceReference
└── verification: confirmed

The source must actually be a bounty.
The target must actually be a settlement.
The settlement must be paid.
The relationship must represent confirmed verification.
And transaction evidence needs an independent source reference.
Why be this strict?
Because:
transaction submitted != transaction confirmed

and:
transaction ID present != bounty settlement proven

Evidence graphs are useful precisely when those distinctions survive serialization, APIs and UI layers.
Privacy changes what “verifiable” should mean
There's another trap.
If a system wants stronger evidence, it's tempting to publish more data.
Wallet addresses.
Identity information.
Full documents.
Payment metadata.
That isn't necessary.
Our evidence model distinguishes visibility classes including:
PUBLIC
RESTRICTED
PARTICIPANT_ONLY
EPHEMERAL

Unknown classification fails closed.
A settlement can internally contain information required to execute a payment without automatically exposing that information in the public Evidence Graph.
This leads to another principle:
Verification should disclose the minimum evidence required for the claim being checked.

More public data doesn't automatically mean stronger verification.
Sometimes it only means weaker privacy.
We found the same pattern while building private AI
Interestingly, we encountered almost the same problem in Zorgax's AI privacy architecture.
Calling a provider “local” wasn't enough.
If its endpoint was configurable, then “local” was only a convention.
So the boundary had to become testable:
LOCAL_ONLY

↓

must resolve to loopback

The same happened with web search.
Protecting the model request was insufficient if sensitive information had already left through a search provider.
So the decision had to move earlier:
classify
↓
policy
↓
egress decision
↓
search / model / provider

Om Yaduvanshi summarized the loopback lesson particularly well in feedback on our article:
“turns a vibe into something testable.”

That phrase describes much of what we're trying to do with Evidence Graphs too.
Turn assumptions into invariants.
Then test them.
The next experiment has to happen through the product
The next step isn't another manually assembled graph.
We want someone to create Knowledge through MyZubster and Zorgax and have the complete pipeline execute automatically.
Our target is:
Human
↓
MyZubster / Zorgax
↓
Knowledge candidate
↓
Human confirmation
↓
Independent review
↓
Verified Knowledge
↓
Versioned canonicalization
↓
SHA-256
↓
Evidence Graph
↓
GitHub provenance
↓
optional external attestations

GitHub writes need to be genuinely automated.
Paths need to be deterministic.
Retries need to be idempotent.
The resulting commit SHA needs to return to the Knowledge provenance.
And privacy classification has to survive the process.
If we manually create the final GitHub file ourselves, we haven't tested that system.
We've only tested GitHub.
Eventually: Knowledge → development → contribution
The larger architecture goes further.
Verified Knowledge can reveal a missing capability.
That can become a neutral DevelopmentRequest.
Verified Knowledge

↓

DevelopmentRequest

↓

DRAFT

↓

OPEN

↓

IN_PROGRESS

↓

SUBMITTED

↓

VERIFIED / REJECTED

GitHub materialization is optional.
Bounty attachment is optional.
Payment is separate.
That separation is deliberate.
Creating work doesn't promise money.
Verifying work doesn't prove payment.
Paying someone doesn't prove every claim associated with their profile.
What exists, and what doesn't
Today we have working foundations for verified Knowledge, provenance, deterministic hashing, Evidence Graph construction, privacy boundaries and contributor-evidence projection.
We have real regression cases.
We have a 23-test targeted Evidence Graph suite.
And we have learned to consider “zero attestations” a perfectly legitimate output.
But several things remain unfinished.
Canonicalization scheme/version metadata is our next hardening step.
Our existing payload still needs to be tested before we can claim RFC 8785 compatibility.
Blockchain attestation metadata needs explicit chain/block semantics.
The contributor Evidence Graph work still needs to complete its PR lifecycle.
The MyZubster/Zorgax → GitHub Knowledge pipeline still needs a genuine product-level end-to-end test.
And we still need a real, independently confirmed contributor settlement before we can show a real SETTLED_AS example.
Sepolia remains experimental.
Those aren't embarrassing gaps.
They are the difference between a roadmap and a claim.
The architecture we're aiming for
Eventually, we want this:
Human / Contributor

↓

MyZubster + Zorgax

↓

Knowledge

↓

confirmation + review

↓

Canonical Payload
(scheme + version)

↓

Digest

↓

Evidence Graph

↓

GitHub provenance

↓

optional attestations

↓

DevelopmentRequest

↓

Contribution

↓

Acceptance

↓

optional Bounty

↓

independently confirmed Settlement

↓

Verifiable Contributor History

Not a résumé on-chain.
Not a blockchain declaring truth.
Not an AI deciding reputation.
An evidence structure that applications can inspect without silently changing the meaning of the underlying evidence.
The rule we're converging on
After several iterations, three principles keep surviving:
Hash the thing you mean.

Then:
Record how you produced the bytes.

And finally:
Model only the relationship you actually have evidence for.

Perhaps there's a fourth:
If you can't prove something yet, preserve that uncertainty.

That's less dramatic than putting a green “VERIFIED” badge on everything.
But it's much more useful when somebody eventually asks:
“Verified by what?”
Want to contribute?
MyZubster is being developed in public, and small, reviewable contributions are useful.
You don't need to implement a blockchain protocol.
Useful contributions can be much narrower:

reproducible tests for privacy or evidence boundaries;
canonicalization test vectors;
Evidence Graph edge cases;
GitHub integration tests;
documentation;
accessibility improvements;
small focused fixes.
A particularly interesting challenge right now is trying to break one of our assumptions: find a case where the graph appears to claim more than its evidence actually supports.
That's exactly the kind of bug we want to find.
Suggested Coder Legion topics/tags: Software Architecture, Blockchain, AI, Open Source, Privacy, Node.js
Suggested subtitle:
What canonicalization, zero attestations, GitHub contributors and private AI taught us about building systems that preserve the limits of their own evidence.

From Blockchain Hashes to Evidence Graphs: What We Learned Building Verifiable Knowledge

Wed, 30 Sep 2026 04:54:31 +0000

From Blockchain Hashes to Evidence Graphs: What We Learned Building Verifiable Knowledge
When we started experimenting with verifiable knowledge in MyZubster, the first implementation looked simple:

Take a Knowledge Card.
Hash something that identifies it.
Store the hash on Ethereum.
Use the blockchain record as proof.
The implementation worked.
The model was wrong.
Not because the cryptography failed, but because we were asking a hash to represent more meaning than it actually contained.
That mistake eventually led us to build Evidence Graph v1, a small architecture for separating claims, evidence, canonical representations, cryptographic digests, and blockchain attestations.
This is the engineering path that got us there.
The real-world test case
We didn't want to design the system around purely synthetic examples.
Our test case came from an actual software contribution associated with a MyZubster Knowledge Card.
The contributor worked on a local stack involving Docker Compose, Ollama, Qdrant, an API, and Open WebUI.
During testing, a problem was identified in the document ingestion process. The chunking logic was modified to better respect paragraph and line boundaries while preserving overlap and avoiding loops.
After re-ingestion, the resulting knowledge base contained:
46 knowledge chunks loaded into Qdrant
1 empty document skipped

The contribution gave us several interesting objects:
person
software contribution
Knowledge Card
Git commit
test results
repository

The next question was how to make the resulting evidence cryptographically verifiable.
Attempt 1: Hash the URL
Our first Ethereum Sepolia experiment used a small smart contract called MyZubsterProof.
The contract stored a bytes32 digest.
For the first experiment, we calculated SHA-256 over the URL of the Knowledge Card.
Cryptographically, this worked.
But consider what was actually being committed:
Knowledge Card URL

    ↓
 SHA-256
    ↓

Ethereum Sepolia

The problem is subtle but important.
The URL identifies a resource.
It doesn't necessarily identify the exact content of that resource.
The content behind the URL could change without changing the URL itself.
Therefore the blockchain record established something closer to:
This URL string corresponds to this digest.

It did not establish:
These exact Knowledge Card contents correspond to this digest.

That distinction motivated a second implementation.
Attempt 2: Canonical content
For Proof v2 we created a canonical JSON representation of the Knowledge Card.
The payload was committed to Git as:
proofs/knowledge-card-6abaaefb3a7460c4574a45fd-v1.json

The exact file contains:
3168 bytes

We calculated SHA-256 over those exact bytes.
The result was:
6097e05866bafceec24663d2638cb1dae5742ac78284abbfd45cc9c3b0bfb845

That digest was supplied to a new immutable MyZubsterProof contract deployed on Ethereum Sepolia.
The deployed contract is:
0x21787249Df054132093FcF09bB914C0CCC539390

on:
Ethereum Sepolia
chainId 11155111

Calling:
knowledgeHash()

returns:
0x6097e05866bafceec24663d2638cb1dae5742ac78284abbfd45cc9c3b0bfb845

Now the proof had much clearer semantics.
Reproducing the hash
A cryptographic proof isn't particularly useful if only the original application can verify it.
So we tested the process independently.
We retrieved the exact payload from its Git commit and calculated SHA-256 locally.
For example:
sha256sum proofs/knowledge-card-6abaaefb3a7460c4574a45fd-v1.json

The result:
6097e05866bafceec24663d2638cb1dae5742ac78284abbfd45cc9c3b0bfb845

During our final verification we compared expected and calculated values:
expected:
6097e05866bafceec24663d2638cb1dae5742ac78284abbfd45cc9c3b0bfb845

actual:
6097e05866bafceec24663d2638cb1dae5742ac78284abbfd45cc9c3b0bfb845

RESULT: MATCH

So we now had:
Git commit

↓

exact 3168-byte payload

↓

SHA-256

↓

6097e058...

↓

Ethereum Sepolia

↓

knowledgeHash()

↓

6097e058...

This is reproducible without trusting the MyZubster application.
But it still doesn't prove that the claims inside the JSON are true.
That became the next engineering problem.
Cryptographic integrity isn't semantic verification
Imagine hashing this statement:
Alice built a distributed database.

Then storing the resulting digest on Ethereum.
What has been demonstrated?
We may be able to establish that:
these bytes
↓ SHA-256
this digest
↓
this blockchain record

But Ethereum cannot conclude:
Alice actually built the database.

The blockchain verifies its own state.
It doesn't automatically verify the external-world meaning of the data being committed.
That distinction led us to separate several concepts that we had initially treated too closely:
claim

evidence

canonical representation

cryptographic integrity

attestation

verification

And that became the basis for Evidence Graph v1.
Building Evidence Graph v1
Instead of treating “proof” as one object, we represent the evidence system as typed nodes and typed relationships.
A simplified graph looks like:
Person
│
│ CLAIMS
▼
Claim
│
│ DESCRIBED_BY
▼
Knowledge Card
│
│ SUPPORTED_BY
▼
Evidence
│
│ CANONICALIZED_AS
▼
Canonical Payload
│
│ HASHED_AS
▼
Digest
│
│ ATTESTED_BY
▼
Attestation

The key design decision is that these relationships have deliberately narrow meanings.
CLAIMS
Person
│
│ CLAIMS
▼
Claim

This tells us who is associated with a claim.
It does not tell us whether the claim has been independently verified.
For our experiment, a simplified claim was:
N4K48
↓ CLAIMS
"Contributed improvements to a knowledge ingestion workflow"

DESCRIBED_BY
The claim can be associated with a Knowledge Card:
Claim
│
│ DESCRIBED_BY
▼
Knowledge Card

Again, this isn't verification.
It tells us where the claim is represented.
SUPPORTED_BY
The Knowledge Card or claim can reference evidence:
Knowledge Card

  │
  │ SUPPORTED_BY
  ▼

Evidence

An evidence reference means:
This artifact is presented as supporting material.

It doesn't automatically mean:
This artifact proves the claim.

CANONICALIZED_AS
Eventually we reach the cryptographic layer.
Evidence

│
│ CANONICALIZED_AS
▼

Canonical Payload

This explicitly separates the semantic evidence object from the deterministic representation used for hashing.
HASHED_AS
The canonical representation produces a digest:
Canonical Payload

   │
   │ HASHED_AS
   ▼

SHA-256 Digest

This is a reproducible cryptographic relationship.
Given the same bytes, another verifier should calculate the same digest.
ATTESTED_BY
Finally:
Digest
│
│ ATTESTED_BY
▼
Blockchain Attestation

This relation has intentionally limited semantics.
It means the digest has a confirmed blockchain anchor.
It does not mean:
PROVES_TRUTH

In fact, PROVES_TRUTH is deliberately rejected by Evidence Graph v1.
Making invalid semantics harder to express
Documentation alone isn't enough for a system like this.
Some semantic constraints are enforced by the implementation.
For example, an anchor with status:
NOT_REQUESTED
NOT_CONFIGURED
SUBMITTED
FAILED

must not produce an ATTESTED_BY edge.
Only a confirmed anchor can do that.
We added tests specifically for this behavior.
Similarly, an unknown semantic relationship is rejected rather than silently accepted.
That includes:
PROVES_TRUTH

This is useful because it moves part of the trust model into code.
Deterministic graph construction
Evidence Graph itself also needs an integrity mechanism.
The graph builder therefore produces a:
graphHash

from a stable representation of the graph.
Given the same inputs:
same nodes
+
same edges
+
same metadata

we expect:
same graphHash

The test suite builds the graph twice and checks exactly that:
expect(second.graphHash).toBe(first.graphHash);

This gives us deterministic graph projection.
Evidence hash and graph hash aren't the same thing
Our real N4K48 Evidence Graph experiment produced this evidence hash:
51483fbac73ec183d2f882428fd2ec823ec88eaa82a07b3a9cd2fe3324ec618b

The graph itself produced:
7dffe770d139da4a0beaf27d0b2d7e72a03bf26c5cd2180c93e1741fa8d3625e

These values are intentionally different.
The first protects the canonical Knowledge Evidence payload.
The second protects the graph representation.
In other words:
evidenceHash

↓

integrity of evidence payload

graphHash

↓

integrity of graph representation

Conflating those two would remove useful information from the architecture.
An unexpected result: zero attestations
When we generated the Evidence Graph for the real Knowledge Card, the graph contained:
7 nodes
7 edges
0 attestation nodes

At first glance, that might look strange.
We had already created an Ethereum Proof v2.
Why wasn't it included?
Because the hashes were different.
The Evidence Graph evidence object produced:
51483fbac73ec183d2f882428fd2ec823ec88eaa82a07b3a9cd2fe3324ec618b

The earlier canonical Knowledge Card Proof v2 produced:
6097e05866bafceec24663d2638cb1dae5742ac78284abbfd45cc9c3b0bfb845

They represent different canonical objects.
Pretending that the Ethereum contract attested 51483f... would have been incorrect.
So the system produced:
attestation nodes: 0

That wasn't a missing feature.
It was the correct result.
Two valid cryptographic chains
We therefore currently have two related but separate structures.
The new Evidence Graph:
Person
↓
Claim
↓
Knowledge Card
↓
Evidence
↓
Canonical Evidence Payload
↓
51483f...

And the earlier Proof v2:
Knowledge Card

↓

canonical Knowledge Card payload

↓

6097e0...

↓

Ethereum Sepolia

The Knowledge Card connects the concepts.
The two digests aren't interchangeable.
This turned out to be one of the most useful results of the experiment.
The API is intentionally read-only
Evidence Graph v1 also exposes:
POST /api/knowledge-evidence/graph

The endpoint projects existing evidence into a graph.
It deliberately doesn't:
persist the graph
publish the evidence
send blockchain transactions
declare independent verification

A successful response explicitly contains:
{
"success": true,
"persisted": false,
"publication_performed": false,
"independently_verified": false
}

This keeps projection separate from side effects.
Generating a graph should not accidentally publish information or trigger a blockchain transaction.
Knowledge Cards are composed outside the evidence hash
We faced another design choice.
Should adding a Knowledge Card modify the original evidence payload?
We decided it shouldn't.
Instead, the Knowledge Card is composed at the graph layer:
Claim
│
├──── SUPPORTED_BY ──── Evidence
│ ▲
│ │
└──── DESCRIBED_BY ── Knowledge Card

                        │
                        └── SUPPORTED_BY

The original evidence payload and its hash remain unchanged.
This lets us enrich the graph without silently rewriting the cryptographic history of the evidence object.
Testing the semantics
At the end of this iteration, our focused regression gate contained:
3 test suites
18 tests
18 passed

The tests include cases for:
deterministic graph generation

invalid graph edges

unknown semantic relations

Knowledge Evidence projection

canonical payload construction

digest generation

confirmed blockchain anchors

unconfirmed anchors

tampered payloads

Knowledge Card composition

incomplete Knowledge Card references

full Knowledge Card → integrity-chain composition

One test explicitly attempts to use an unknown relation such as:
PROVES_TRUTH

and expects the graph builder to reject it.
Another verifies that a SUBMITTED blockchain transaction isn't treated as a confirmed attestation.
Another deliberately tampers with the canonical payload and expects integrity-chain construction to fail.
These aren't only unit tests.
They encode part of the evidence model.
What Proof v2 actually proves
After all this work, we ended up with a much narrower definition of our blockchain proof.
Proof v2 establishes:
The SHA-256 digest recorded by the Sepolia contract equals the SHA-256 digest of the exact canonical Knowledge Card payload committed to the referenced Git repository.

It does not independently establish:
the truth of every statement

ownership of every referenced artifact

professional competence

employment

authorship

the value of the contribution

Those questions require other forms of evidence and verification.
This distinction isn't a weakness of the blockchain proof.
It's what makes the proof interpretable.
Why a graph instead of a certificate?
A single credential is convenient when the thing being represented is simple.
Real software evidence often isn't.
Imagine a developer claim supported by:
Git commits
test results
code review
deployment records
Knowledge Cards
repository artifacts
external attestations

Several claims may share artifacts.
One artifact may support several claims.
One payload may have several attestations.
An attestation may come from Ethereum today and another system tomorrow.
Eventually the structure could look more like:

                Git commit
                   │
                   ▼

Person ── Claim ── Knowledge Card ── Evidence

                   │                │
                   │                ▼
                   │          Canonical Payload
                   │                │
                   │                ▼
                   │              Digest
                   │             /      \
                   │            /        \
                   ▼           ▼          ▼
               Artifact       EAS      Ethereum

Evidence Graph v1 doesn't implement all of that.
It establishes the vocabulary needed to get there.
Engineering lesson #1: hash the thing you mean
Our Proof v1 mistake was simple:
hash(resource identifier)

when what we really wanted was:
hash(canonical resource contents)

Those operations answer different questions.
If your proof concerns content, canonicalize and hash the content.
Engineering lesson #2: define edge semantics
A graph with vague relationships doesn't solve the problem.
Consider:
Person → Proof

What does that mean?
Authored?
Submitted?
Owns?
Was mentioned by?
Was independently verified by?
Evidence Graph became useful only when relationships became explicit:
CLAIMS
DESCRIBED_BY
SUPPORTED_BY
CANONICALIZED_AS
HASHED_AS
ATTESTED_BY

Engineering lesson #3: absence is meaningful
We initially could have attached the existing Ethereum proof to the new Evidence Graph because both related to the same Knowledge Card.
That would have produced a nicer-looking demo.
It would also have been wrong.
The digest didn't match the Evidence Graph evidence payload.
So:
0 attestation nodes

was more informative than a fabricated connection.
Failing closed matters in evidence systems.
Engineering lesson #4: blockchain should be one layer
The blockchain component became easier to reason about once we stopped treating it as the entire verification system.
The architecture now looks more like:
semantic layer

↓

evidence layer

↓

canonicalization layer

↓

cryptographic layer

↓

attestation layer

Ethereum occupies the last layer.
That's a much smaller responsibility.
And that's useful.
What's next
There are several possible directions from here:
persistent graph storage

interactive Evidence Graph visualization

Ethereum Attestation Service

W3C Verifiable Credentials

Open Badges

multiple attestations

independent evidence verification

richer provenance

We're deliberately not implementing all of them at once.
Evidence Graph v1 is intended to freeze the basic semantics before expanding the protocol.
Conclusion
We started by asking:
How can we put evidence of someone's work on a blockchain?

After building two proofs and an Evidence Graph, we'd phrase the problem differently:
How can we make the relationships between claims, evidence, cryptographic integrity, and attestations explicit and independently inspectable?

The blockchain transaction was the easy part.
The harder part was deciding what it was allowed to mean.
Our current model is:
Claim
↓
Evidence
↓
Canonical representation
↓
Cryptographic digest
↓
Attestation

with verification status kept explicit rather than inferred.
That's the main lesson from the experiment:
Integrity can be cryptographically demonstrated. Truth still requires evidence and interpretation.

A good verification architecture should know the difference.
Source code and reproducible artifacts
The Evidence Graph v1 implementation is available in:
MyZubster Evidence Graph v1 — PR #17
The exact canonical Knowledge Card payload used for Proof v2 was committed here:
Proof v2 canonical payload commit
Proof v2 documentation:
Sepolia Proof v2 documentation
The chunking contribution used in the experiment:
Knowledge ingestion improvement commit
The Proof v2 contract can be inspected on Ethereum Sepolia:
MyZubsterProof contract on Sepolia Etherscan
Deployment transaction:
Proof v2 deployment transaction
Per Coder Legion userei come titolo:
From Blockchain Hashes to Evidence Graphs: What We Learned Building Verifiable Knowledge
e come sottotitolo:
An engineering case study on canonical payloads, deterministic graphs, SHA-256, Ethereum attestations, and why integrity is not the same as truth.

Beyond the Hype: The Enterprise Era of Web3, Crypto, and Blockchain in 2026

Tue, 29 Sep 2026 12:57:15 +0000

The crypto industry has reached a significant shift, evolving from a space perceived as a gamble into a foundational digital infrastructure. As regulatory clarity arrives across the United States, the European Union, and multiple Asia-Pacific markets, institutional capital that previously sat on the sidelines is being unlocked. In 2026, credible projects are completely changing how they communicate, prioritizing demonstrated utility and function over financial speculation.

The transition is redefining what gets built and how value moves on-chain.

The Explosion of Real-World Asset (RWA) Tokenization

Blockchain is no longer viewed as an alternative experimental tool, but rather as an emerging operating system for the global financial system. The tokenization of real-world assets (RWAs) represents a structural overhaul of how securities are processed and how capital moves.

The total on-chain value of RWAs has surged from USD 5 billion in 2023 to more than USD 25 billion today.

This market expansion reflects a much deeper shift in trust toward blockchain as a reliable source of truth.

Private credit, government Treasury products, and tokenized realestate currently account for the majority of this on-chain value, revealing an investor preference for assets backed by real-world value that deliver stable yields.

AI-Powered Smart Contracts and Asset Valuation

Artificial intelligence is accelerating the growth of the tokenized asset market by converting RWAs into intelligent, adaptable financial instruments.

AI provides precise, real-time pricing for tokenized assets by analyzing historical performance, market trends, and external variables.

AI-enhanced smart contracts can dynamically modify terms and conditions in response to asset performance and changing market conditions.

By instantly detecting suspicious transactions and unusual activities, AI improves tokenized asset security and assists in avoiding fraud.

AI-powered systems streamline regulatory compliance processes—such as reporting, AML, and KYC—speeding up onboarding and reducing human error.

Stablecoins as Global Payment Rails

Digital assets are increasingly being treated as functional payment rails rather than speculative crypto products.

Impact programs and non-governmental organizations (NGOs) are relying on stablecoin rails for payouts, procurement, cross-border payroll, and emergency cash due to faster settlement times.

Pilots in constrained environments, such as Syria, demonstrate that stablecoins can materially improve aid delivery compared to traditional financial channels.

Stablecoins allow users to make cross-border payments for significantly less than usual.

Modular Blockchains and Rollup-as-a-Service (RaaS)

Monolithic blockchains are making way for highly tailored enterprise deployments. The rise of modular blockchain architecture lets developers build customized chains without sacrificing security, accelerating enterprise adoption at an unprecedented pace.

Fortune 500 procurement teams are leveraging Rollup-as-a-Service (RaaS) platforms, such as Conduit RaaS and Coinbase Base, to launch branded chains in a matter of days.

Traditional banks, prioritizing regulatory compliance over pure speed, are utilizing solutions like AWS Managed Blockchain and Avalanche subnets because they offer built-in audit trails and KYC-gated validator access.

Zero-knowledge proof technology has fully matured alongside these modular frameworks, making privacy-preserving transactions both affordable and fast for institutional players.

The Web3 user in 2026 is fundamentally different from the crypto trader of 2021. Investors and enterprises alike are demanding utility, regulatory compliance, and scalable architecture. As blockchain embeds itself into legacy financial systems and integrates deeply with artificial intelligence, the ecosystem is trading viral trends for permanent, institutional-grade infrastructure.

Engineering an Evidence-First Knowledge Graph: From GitHub Artifacts to On-Chain Proofs in MyZubster

Tue, 29 Sep 2026 02:03:45 +0000

Certo. Per CoderLegion lo farei più tecnico del post DEV, con più attenzione ad architettura, data provenance, canonicalizzazione, hashing e al motivo per cui dopo il test con Nicola stiamo valutando standard esistenti invece di continuare ad aggiungere smart contract custom.
Engineering an Evidence-First Knowledge Graph: From GitHub Artifacts to On-Chain Proofs in MyZubster
Building and testing a complete provenance chain with a real contributor, canonical payloads, SHA-256, Ethereum Sepolia, RAG, and a Knowledge Graph
Tonight we ran one of the most complete end-to-end experiments so far on MyZubster.
The test involved a real contributor, Nicola / N4K48, rather than synthetic fixtures.
What started as a relatively simple test of the MyZubster Knowledge Profile evolved into a much larger architecture experiment involving:
Authentication

↓

Knowledge Profile

↓

Private Knowledge Cards

↓

Publication

↓

Real software contribution

↓

GitHub evidence

↓

RAG / Qdrant

↓

Knowledge Graph

↓

Canonical payload

↓

SHA-256

↓

Ethereum Sepolia

↓

Publicly inspectable provenance

The most important result was not the blockchain transaction.
It was discovering where the boundaries of the MyZubster architecture should probably be.

The problem we are trying to solve
Most professional profiles fundamentally contain claims.
For example:
{
"person": "N4K48",
"skill": "Docker"
}

This tells us what somebody says about themselves.
It tells us very little about why another person should trust that statement.
We wanted to experiment with a different model:
Person
↓
Claim
↓
Activity
↓
Artifact
↓
Evidence
↓
Cryptographic commitment
↓
Attestation

The objective is not to magically transform a claim into truth.
The objective is to make its provenance inspectable.

Testing with a real contributor
Nicola created a MyZubster Knowledge Profile representing different parts of his real activity.
We used three Knowledge Cards during the experiment:
N4K48
│
├── Truck driving and transport organization
│
├── Docker / AI experiments on myzubster-mvp
│
└── Learning and collaboration in MyZubster

This immediately forced us to distinguish two concepts that are easy to accidentally merge:
CLAIM

and:
EVIDENCE

A professional statement is not automatically evidence.
A GitHub commit is not automatically proof of every professional statement either.
Therefore MyZubster needs to preserve the semantic boundary between them.

Authentication failed before cryptography did
The first failures had nothing to do with Ethereum.
Nicola encountered an expired JWT during the onboarding flow.
The UI indicated an authenticated state, but a subsequent request produced:
jwt expired

Another issue appeared in the conversational onboarding flow: information already supplied by the user was not always being reused correctly.
We also discovered a routing issue where the Knowledge Profile Builder URL displayed the MyZubster homepage instead of the Builder.
These problems were fixed before continuing.
The authentication behavior was changed so that an expired session could trigger re-authentication while preserving the locally prepared onboarding information.
This matters because provenance starts before hashing.
If users lose their work because authentication expires, the cryptographic layer does not save the product.

Private-first Knowledge Cards
The next test covered persistence.
Nicola created three cards and saved them privately.
The tested state transition was approximately:
NEW
↓
PRIVATE DRAFT
↓
RELOAD
↓
EDIT
↓
PREVIEW
↓
PUBLISH

The important property here is that creation does not imply publication.
A Knowledge Card can exist privately while the owner reviews:
claims
activities
sources
evidence
verification state

Only an explicit publication action makes the card public.
Published cards can also be withdrawn before being modified.
That gives us a lifecycle closer to:
DRAFT
│
▼
PUBLIC
│
▼
WITHDRAWN / DRAFT

rather than treating the knowledge database as an append-only public feed.

Turning software work into evidence
The next step was intentionally practical.
Instead of adding another manually entered skill, Nicola performed a real change in his myzubster-mvp repository.
The work involved:
scripts/ingest_knowledge.py

and improvements to the chunking/knowledge-ingestion process.
The resulting test reported:
46 knowledge chunks loaded into Qdrant
1 empty document skipped

The Git commit associated with that work could then become a source attached to the relevant Knowledge Card.
We now had something structurally different from:
N4K48
↓
"knows software development"

We had:
N4K48
↓
Knowledge Card
↓
documented software activity
↓
GitHub repository
↓
specific commit
↓
inspectable code change

This is an important distinction.
MyZubster does not need to decide that the commit proves a particular competence.
It can state something narrower:
This artifact is evidence associated with this activity and this Knowledge Card.

RAG became part of the evidence trail
The test also exercised the knowledge retrieval stack.
The local project involved:
Docker Compose
│
├── Ollama
│
├── Qdrant
│
├── API
│
└── Open WebUI

During retrieval testing, the context being returned was insufficient.
The experiment therefore changed:
AI_CONTEXT_LIMIT=1

to:
AI_CONTEXT_LIMIT=5

and repeated the retrieval tests.
That work itself became documentable evidence.
This creates a useful recursive property.
The system can represent knowledge about the process used to improve the system itself:
engineering work

↓

Git artifact

↓

Knowledge Card

↓

Knowledge Graph

Building the Knowledge Graph
Once the cards were public, we started connecting them into a graph.
Conceptually:

            N4K48
              │
 ┌────────────┼────────────┐
 │            │            │
 ▼            ▼            ▼

Transport Learning Docker / AI
Card Card Card

                             │
                             ▼
                         GitHub repo
                             │
                             ▼
                           commit

Sources become traversable relationships instead of text buried inside a profile.
During this phase we found another real-world infrastructure issue.
The visual Knowledge Graph deployment was protected by Vercel, preventing Nicola from accessing it.
After adjusting deployment accessibility, testing continued, including from mobile.
We later corrected another graph/catalog connection that produced a "Catalog unavailable" result.
These may look like small frontend/infrastructure bugs, but they matter for an evidence system.
Evidence that technically exists but cannot be navigated is significantly less useful.

Proof v1: hashing the wrong thing
Then we introduced Ethereum Sepolia.
The first MyZubsterProof experiment anchored a SHA-256 digest related to the Knowledge Card.
However, the digest represented the Knowledge Card URL.
Conceptually:
Knowledge Card URL
```
↓
```
SHA-256
```
↓
```
bytes32
```
↓
```
Ethereum Sepolia

This works cryptographically.
But semantically it proves much less than we wanted.
Suppose:
https://example.com/card/123

continues to exist while the content served at that URL changes.
Hashing the URL does not detect the content change.
The first experiment therefore became useful precisely because it exposed this weakness.
We explicitly documented it rather than treating an on-chain hash as stronger evidence than it actually was.

Proof v2: canonicalize before hashing
Proof v2 changed the architecture.
Instead of hashing a location, we created a deterministic representation of the Knowledge Card itself.
Conceptually:
Knowledge Card
↓
canonical representation
↓
exact bytes
↓
SHA-256
↓
bytes32
↓
Ethereum Sepolia

For the tested card, the resulting digest was:
6097e05866bafceec24663d2638cb1dae5742ac78284abbfd45cc9c3b0bfb845

The corresponding on-chain value was:
0x6097e05866bafceec24663d2638cb1dae5742ac78284abbfd45cc9c3b0bfb845

Reading knowledgeHash() from the deployed MyZubsterProof contract returned that same value.
The canonical payload and the verification procedure were also committed to the repository.
That gives us a reproducible verification path:
canonical payload

   │
   ▼

SHA-256(payload)

   │
   ▼

expected digest

   │
   ▼

on-chain knowledgeHash()

   │
   ▼

comparison

If all values match, we can establish that the committed canonical representation corresponds to the digest stored by the contract.

Why canonicalization matters
This is a subtle but critical engineering detail.
Consider two JSON objects:
{
"name": "N4K48",
"activity": "Docker"
}

and:
{
"activity": "Docker",
"name": "N4K48"
}

Semantically, an application may consider them equivalent.
At the byte level, they are different.
And therefore:
SHA256(payloadA) != SHA256(payloadB)

can occur even when both payloads represent the same logical information.
The same issue appears with:
whitespace
field ordering
Unicode normalization
line endings
optional values
number serialization
dates

So an evidence system cannot simply say:
hash(JSON.stringify(object))

and assume the problem is solved forever.
The canonicalization algorithm effectively becomes part of the protocol.
A durable proof therefore needs something like:
payload format
canonicalization version
hash algorithm
digest
attestation reference

Proof v2 pushed us toward that realization.

Integrity is not truth
This is probably the most important architectural rule from the experiment.
Assume the canonical payload contains:
{
"claim": "N4K48 is an expert in Docker"
}

and suppose we perfectly canonicalize it, hash it and anchor the digest on Ethereum.
We have demonstrated something about the integrity of the statement.
We have not demonstrated that the statement itself is true.
Formally:
integrity(claim) ≠ truth(claim)

Likewise:
existence(GitHub commit) ≠ proof(skill)

and:
blockchain timestamp ≠ professional certification

Different evidence supports different propositions.
MyZubster therefore needs to model not only evidence, but also what each piece of evidence is capable of establishing.

Provenance as a graph
This leads to a more interesting representation.
Instead of:
Person → Skill

we can represent:
Person
│
▼
Claim
│
▼
Activity
│
▼
Knowledge Card
│
├──────────────► GitHub artifact
│
├──────────────► external source
│
▼
Canonical Payload
│
▼
Digest
│
▼
Attestation

Each edge has semantics.
For example:
Person --DECLARES--> Claim

Claim --SUPPORTED_BY--> Evidence

Activity --PRODUCED--> Artifact

KnowledgeCard --CANONICALIZED_AS--> Payload

Payload --HASHED_AS--> Digest

Digest --ATTESTED_BY--> Attestation

This is much more expressive than simply attaching a blockchain transaction ID to a user profile.

The architectural question that emerged
After completing Proof v2, Nicola compared the experiment with existing systems and standards.
The comparison included:
- Talent Protocol / Builder Score;
- Ethereum Attestation Service;
- cheqd;
- Open Badges 3.0 and Verifiable Credentials.
  That comparison raised a very useful question.
  Why should MyZubster implement every cryptographic primitive itself?
  The ecosystem already contains mature approaches for:
  identity
  credentials
  attestations
  reputation
  issuers
  verification
  revocation
  cryptographic proofs

Creating:
MyZubsterProofV3.sol
MyZubsterProofV4.sol
MyZubsterProofV5.sol

may therefore be less valuable than making MyZubster interoperable with existing primitives.

Separating the layers
The experiment suggests that the architecture could eventually be separated into several layers.
Identity layer
Person
Wallet
GitHub identity
MyZubster account

Knowledge layer
Knowledge Card
Claim
Activity
Skill
Project

Evidence layer
GitHub commit
Pull request
Repository
Document
External source
Artifact

Integrity layer
canonical payload
hash algorithm
digest
version

Attestation layer
Potentially:
Ethereum Attestation Service

rather than a growing family of MyZubster-specific contracts.
Credential layer
Potential interoperability with:
W3C Verifiable Credentials
Open Badges

Relationship layer
This is where MyZubster's Knowledge Graph becomes particularly important.
Person
↓
Claim
↓
Activity
↓
Evidence
↓
Artifact
↓
Attestation
↓
Credential

MyZubster may be the graph, not the protocol
This was probably the biggest architectural insight of the evening.
Originally it is tempting to think:
MyZubster
=
our smart contract

But after this experiment, another model looks more interesting:
MyZubster
=
evidence/provenance graph
+
workflow
+
verification semantics
+
human-readable navigation

with standards handling lower-level primitives where appropriate.
That means MyZubster could potentially consume:
GitHub evidence
EAS attestations
Verifiable Credentials
Open Badges
blockchain transactions
traditional documents
other public evidence

without pretending that all evidence has the same meaning.

A possible future architecture
The architecture we are now exploring looks closer to this:

               PERSON
                 │
                 ▼
               CLAIM
                 │
                 ▼
              ACTIVITY
                 │
                 ▼
          KNOWLEDGE CARD
                 │
    ┌────────────┴────────────┐
    │                         │
    ▼                         ▼
EVIDENCE                   ARTIFACT
    │                         │
    └────────────┬────────────┘
                 │
                 ▼
        CANONICAL PAYLOAD
                 │
                 ▼
              SHA-256
                 │
     ┌───────────┴───────────┐
     │                       │
     ▼                       ▼

ATTESTATION CREDENTIAL
e.g. EAS VC / Badge

     │                       │
     └───────────┬───────────┘
                 ▼
         MYZUBSTER GRAPH

Notice that the blockchain is no longer the center of the system.
The relationships are.

Why this differs from a reputation score
Consider a reputation system that produces:
Score = 87

That number may be useful for ranking or filtering.
But a provenance graph asks a different question:
Why?

A MyZubster-style path could eventually allow someone to inspect:
N4K48
↓
Docker-related Knowledge Card
↓
specific development activity
↓
GitHub commit
↓
source code
↓
canonical representation
↓
cryptographic digest
↓
attestation

The user is not forced to trust only the final number.
They can inspect the path that produced the evidence.

Evidence types should not collapse into one trust score
This is another consequence of the experiment.
Imagine three pieces of evidence:
A: self-declared professional experience

B: public GitHub commit

C: credential issued by a university

All three may belong in the graph.
But they should not automatically become:
A = B = C

Their semantics are different.
A useful graph therefore needs metadata such as:
evidence type
issuer
subject
source
verification method
verification status
created timestamp
attestation reference
revocation state

The graph should preserve those differences rather than hide them behind one universal score.

What the experiment actually demonstrated
By the end of the session we had exercised a chain approximately like this:
Real contributor
↓
authenticated MyZubster account
↓
private Knowledge Cards
↓
public Knowledge Cards
↓
real software activity
↓
GitHub evidence
↓
RAG / Qdrant test
↓
Knowledge Graph
↓
canonical card payload
↓
SHA-256
↓
Sepolia Proof v2
↓
public verification information

This is more useful to us than an isolated smart-contract demo because every layer exposed different failure modes.
We encountered:
expired authentication
routing problems
deployment access restrictions
catalog/navigation problems
retrieval-context limitations
evidence-modeling questions
URL-vs-content hashing semantics
canonicalization requirements
truth-vs-integrity boundaries

That is exactly what an end-to-end proof of concept should reveal.

What we deliberately did not prove
It is equally important to document what the experiment does not establish.
Proof v2 does not prove that every statement in a Knowledge Card is true.
It does not automatically prove professional competence.
It does not establish that GitHub activity is equivalent to mastery of a skill.
It does not turn blockchain data into a trusted credential issuer.
What it does establish is a mechanism for connecting an exact representation of information with a reproducible digest and a public cryptographic reference.
That is an integrity primitive.
Trust requires additional layers.
The next engineering experiment
Instead of immediately creating another custom proof contract, the next useful experiment is likely to take the exact Proof v2 data model and map it onto existing standards.
Something like:
Knowledge Card
↓
canonical payload
↓
current Proof v2
│
├────► EAS schema mapping
│
└────► Open Badges / VC mapping

Then we can compare:
custom MyZubster contract
vs.
standardized attestation

across:
schema flexibility
revocation
references
issuer semantics
verification
interoperability
developer complexity
gas cost
long-term maintainability

Only after that comparison should we decide what belongs inside MyZubster itself.

The broader engineering lesson
Tonight's work started with a very ordinary product task:
Can a contributor create a knowledge profile?

It progressed into:
Can the profile contain inspectable evidence?

Then:
Can that evidence point to real engineering work?

Then:
Can the exact knowledge representation be cryptographically committed?

And eventually:
Should MyZubster even own the attestation protocol?

That progression matters.
A proof of concept should not merely prove that the original architecture works.
Sometimes its most valuable outcome is discovering that part of the original architecture should not exist.
For MyZubster, that may mean allowing established standards to handle credentials and attestations while concentrating our engineering effort on the part we actually care about:
human claim

↓

real activity

↓

inspectable evidence

↓

artifact

↓

verification

↓

provenance

and making that entire chain navigable.
That's the direction we're exploring next.
CoderLegion title
Engineering an Evidence-First Knowledge Graph: GitHub, SHA-256, Ethereum and MyZubster
Subtitle
How a real contributor test evolved from Knowledge Cards and RAG into canonical payloads, on-chain proofs, provenance graphs, and a rethink of our attestation architecture.
Short description / excerpt
We tested MyZubster end-to-end with a real contributor: authentication, private and public Knowledge Cards, GitHub evidence, Qdrant/RAG, a Knowledge Graph, canonical payloads, SHA-256 and Ethereum Sepolia. The most important result wasn't the smart contract—it was realizing that MyZubster may be better positioned as an evidence and provenance graph built on interoperable attestation standards.

From Service-Disabled Veteran to Building Payment Rails for AI Agents

Sun, 27 Sep 2026 17:40:13 +0000

I didn't come up through a CS program or a FAANG pipeline. I'm a service-disabled veteran who taught myself to build software with AI as my pair programmer — and somewhere along the way, I stopped just using agents and started building the economy they're going to transact in.

The starting point
A few years ago I was publishing TradingView indicators — Pine Script, one at a time. I ended up shipping 60+ of them. That taught me two things: distribution matters more than perfect code, and the people who win are the ones who ship every day.

Then the agent wave hit, and I saw what most people missed. Everyone was arguing about which model is smartest. Nobody was asking the money question: when AI agents start doing real work for each other, how do they pay?

The thesis
Agents can't carry credit cards. They can't do KYC. But they CAN sign crypto transactions. The x402 protocol — HTTP 402 "payment required," reborn for machines — lets any API charge per call in USDC, settled on-chain in seconds.

That's the whole bet behind everything I build now at ScriptMasterLabs: the agent economy needs payment rails, and the people who own the toll booths own the economy.

What I'm shipping
Decision-gated machine payments — my core pattern. A decision model's confidence score gates whether an x402 payment fires: ≥0.80 auto-pay, 0.50–0.79 ask for confirmation, <0.50 escalate. The gate is the product, not the model — any model plugs in.
An x402 pay-per-query SEO API — a fork of a 21K-star open-source SEO tool, rebuilt so every endpoint charges per call in USDC on Base. Keywords $0.10, SERP $0.01, backlinks $0.15. Agents buy data the same way they buy compute.
The $1 SEO Duel — two AI agents, $1 USDC each, racing on real keywords and backlinks with every settlement on BaseScan. Part demo, part proof that machine-to-machine commerce already works.
Claim Receipts — my answer to AI slop. Every factual claim on my site ships with a dated, sourced receipt table plus machine-readable JSON-LD, and I built an auditor that scores pages 100/100 or fails them.
What I'd tell a dev starting today
Ship in public. My best distribution has been canonical pages plus building in the open — not ads.
Price for machines, not just humans. The next billion API calls won't have a human clicking "buy."
Put receipts on every claim. In a world of generated everything, verifiability is the moat.
Don't wait for permission. I fork, I build, I ship — then I figure out whether it's 100x-able.
I'm still early. But the direction is obvious: agents are coming, and they're bringing wallets.

— Timothy Walton, Founder, ScriptMasterLabs (SDVOSB)

SML LIVE — Talk. Discover. Verify. Buy. Prove.

scriptmasterlabs.com

x402 #AIAgents #Web3 #BuildInPublic #OpenSource #VeteransInTech

🚀 MyZubster: Completing a Real Ethereum Sepolia Marketplace E2E Payment Flow

Sun, 27 Sep 2026 02:50:20 +0000

MyZubster Sepolia E2E — Technical Deep Dive: Debugging the Full Marketplace Payment Pipeline
I have just completed a full end-to-end technical validation of the MyZubster Marketplace ETH payment pipeline on Ethereum Sepolia.
This was not a simple frontend test.
The work involved debugging and validating multiple layers of the system:

React routing
React development server
Webpack Dev Server
browser runtime diagnostics
frontend bundle generation
Cloudflare CDN caching
Cloudflare Tunnel ingress rules
SPA fallback behavior
API/backend routing
authentication/JWT handling
Marketplace order state
payment-intent generation
MetaMask
Ethereum Sepolia
transaction construction
on-chain transaction verification
confirmation tracking
final Marketplace payment state
The interesting part was that several apparently unrelated browser errors were actually symptoms of infrastructure and routing problems.
1. Starting point: the Marketplace Operations route
  The target route was:
  MyZubster Marketplace Operations — Sepolia
  The React application explicitly defines:
  if (path === '/marketplace/scambi') {
  return ;
  }

and the navigation contains:
window.location.href = '/marketplace/scambi';

So the expected application architecture was:
/marketplace

↓

MarketplacePage

/marketplace/scambi

↓

MarketplaceOpsPage

The first task was proving that this code was actually reaching the browser.

Frontend development server investigation
The frontend was running through Create React App:
react-scripts start

The relevant process was:
/usr/bin/node
/root/myzubster-sepolia-e2e/frontend/node_modules/react-scripts/scripts/start.js

The application was bound to:
127.0.0.1:3010

We verified the listener with:
ss -ltnp | grep ':3010'

which returned the React process.
The process tree was also inspected:
sh
└── react-scripts

  └── node
       └── webpack/react development server

This was important because an attempted restart initially produced:
Something is already running on port 3010.

The issue was not that React could not start.
A previous React development process was already occupying the port.

Local route versus public route
We then compared:
http://127.0.0.1:3010/marketplace/scambi

against:
https://sepolia.myzubster.com/marketplace/scambi

Both returned:
HTTP 200
Content-Type: text/html

This initially suggested that the route was fine.
But an HTTP 200 response alone does not prove that the correct React application version is being served.
The next step was therefore to inspect the actual JavaScript bundle.

Runtime instrumentation
A temporary diagnostic marker was inserted into App.js:
console.log('[MYZ-APP-RUNTIME]', {
pathname: window.location.pathname,
path,
marketplaceOps: path === '/marketplace/scambi',
href: window.location.href
});

The browser then reported:
pathname: "/marketplace/scambi"
path: "/marketplace/scambi"
marketplaceOps: true

This established that the browser itself was correctly interpreting:
/marketplace/scambi

as the Marketplace Operations route.
We also inspected the DOM and confirmed that the browser was loading:
/static/js/bundle.js

Bundle-level verification
The bundle was downloaded and searched directly.
The relevant route was found in the compiled JavaScript:
if (path === '/marketplace/scambi')
return MarketplaceOpsPage;

We also searched for:
Paga ETH su Sepolia

and found it.
This was important because it proved that the Marketplace Operations component was not merely present in the source tree.
It was present in the bundle being served.

Cloudflare cache investigation
The next layer was Cloudflare.
The public bundle returned headers such as:
HTTP/2 200
content-type: application/javascript; charset=utf-8
etag: W/"2c9e23-..."
age: 582
cache-control: max-age=14400
cf-cache-status: HIT

The local bundle had a different ETag:
ETag: W/"2c9ec3-..."

This was the key observation.
The local development server had a newer bundle, while Cloudflare was still serving an older cached object.
So the situation was:
SOURCE CODE

↓

React build/dev server

↓

NEW BUNDLE

│
X

Cloudflare cache

↓

OLD BUNDLE

↓

Browser

This can be particularly confusing because:
HTTP 200

does not mean:
latest application version

Targeted Cloudflare cache purge
Instead of performing a full cache purge, the specific asset was targeted:
https://sepolia.myzubster.com/static/js/bundle.js

through Cloudflare's cache purge interface.
Cloudflare Dashboard
After the purge, a cache-busting request returned:
cf-cache-status: MISS

and the public ETag changed to the current bundle's ETag.
This established that Cloudflare was now fetching the updated asset from the origin.

WebSocket error from Webpack Dev Server
The browser was also reporting:
Firefox cannot establish a connection to
ws://127.0.0.1:3010/ws

This initially looked alarming because the public site was being accessed through:
https://sepolia.myzubster.com

while the Webpack development client was attempting to establish a WebSocket against:
127.0.0.1:3010

The important distinction is that this is development-server HMR/WebSocket infrastructure, not the Marketplace HTTP/API request itself.
The application bundle was nevertheless loading and executing.
The browser continued to report:
MYZ-APP-RUNTIME

and:
marketplaceOps: true

so the WebSocket failure was not the root cause of the Marketplace API problem.

The real API problem
The more significant error appeared when testing:
/api/marketplace/orders/mine

The browser expected JSON.
Instead, it received:
HTTP 200
Content-Type: text/html

with:
<!DOCTYPE html>

This immediately explained:
JSON.parse:
unexpected character at line 1 column 1

The frontend wasn't receiving malformed JSON.
It wasn't receiving JSON at all.
It was receiving the React application's HTML.
This is a classic SPA/API routing failure.

Why this happened
The Cloudflare Tunnel configuration originally routed:
sepolia.myzubster.com
```
↓
```
127.0.0.1:3010

But the backend API was actually listening on:
127.0.0.1:5010

Therefore:
GET /api/marketplace/orders/mine

was effectively becoming:
Cloudflare

↓

Frontend :3010

↓

React index.html

instead of:
Cloudflare

↓

Backend :5010

↓

JSON API

Correcting Cloudflare ingress
The ingress configuration was changed to explicitly separate API traffic:
- hostname: sepolia.myzubster.com
  path: /api/*
  service: http://127.0.0.1:5010

hostname: sepolia.myzubster.com
service: http://127.0.0.1:3010

The routing architecture became:

                     Cloudflare Tunnel
                            │
              sepolia.myzubster.com
                            │
                ┌───────────┴───────────┐
                │                       │
             /api/*                   /*
                │                       │
                ▼                       ▼
           Backend :5010          Frontend :3010
                │                       │
                ▼                       ▼
              JSON                  React SPA

The configuration was validated:
Validating rules from /root/.cloudflared/config.yml
OK

Discovering how Cloudflared was actually managed
An attempt to restart:
systemctl restart cloudflared

failed because:
cloudflared.service not found

We then traced the process:
systemd
└── PM2

  └── cloudflared

PM2 showed:
id: 4
name: cloudflared
status: online

and the command:
/usr/local/bin/cloudflared tunnel
--config /root/.cloudflared/config.yml
--protocol http2
run myzubster

Therefore the correct restart mechanism was:
pm2 restart 4

or:
pm2 restart cloudflared

This is another useful operational lesson: before restarting infrastructure, identify which process manager actually owns it.

API routing verification
After the Tunnel configuration was corrected, the same public endpoint:
https://sepolia.myzubster.com/api/marketplace/orders/mine

returned:
HTTP/2 401
Content-Type: application/json

with:
{
"success": false,
"message": "Token di autenticazione mancante o non valido"
}

This was exactly what we wanted from an unauthenticated request.
The important change was:
Before
200
text/html
React index.html

After
401
application/json
Backend authentication response

A 401 here was actually evidence that routing was fixed.

Authenticated Marketplace order
Using the authenticated browser session:
fetch('/api/marketplace/orders/mine', {
headers: {
Authorization:
Bearer ${localStorage.getItem('myzubster-token')}
},
cache: 'no-store'
})

the backend returned the actual test order.
The order was:
ID:
6ab870ffc33da1e61579745d

with:
status: ACCEPTED

and:
payment.status: AWAITING_PAYMENT

The order snapshot contained:
title:
MyZubster Sepolia ETH E2E Test

price:
0.0001

currency:
ETH

exchangeMode:
payment

At this stage the Marketplace order existed correctly, but the blockchain payment had not yet been made.

Payment-intent endpoint debugging
The frontend initially attempted:
/api/marketplace/orders/{id}/payment-intent

which returned:
404
Cannot GET /api/marketplace/orders/.../payment-intent

The actual endpoint was:
/api/marketplace/orders/{id}/payment/eth-intent

For the E2E order:
/api/marketplace/orders/6ab870ffc33da1e61579745d/payment/eth-intent

the backend returned:
HTTP 200
Content-Type: application/json

with the complete payment intent.

Payment intent structure
The backend returned:
{
"success": true,
"data": {
"asset": "ETH",
"network": "sepolia",
"chainId": 11155111,
"chainHex": "0xaa36a7",
"expectedSender": "0xB15707286c4dFC6f642fcDf217419b2665e1847a",
"expectedRecipient": "0x14d751a54E8617C5A9DF87972dC980827fA91e4d",
"expectedAmountWei": "100000000000000",
"expectedAmountEth": "0.0001",
"minConfirmations": 3,
"paymentStatus": "AWAITING_PAYMENT",
"txId": null,
"testnet": true
}
}

This establishes several critical properties.
Network
Sepolia

Chain
11155111

Amount
100000000000000 wei

which corresponds to:
0.0001 ETH

Required confirmation depth
3

Expected sender
0xB15707286c4dFC6f642fcDf217419b2665e1847a

Expected recipient
0x14d751a54E8617C5A9DF87972dC980827fA91e4d

MetaMask and testnet funding
When attempting to execute the transaction, MetaMask correctly identified that the wallet did not initially have enough SepoliaETH to cover the transaction and network fees.
This is an important distinction in E2E testing:
Payment amount
+
Gas fee

both require testnet funds.
The test wallet was subsequently funded using a Sepolia faucet.
Once the wallet had sufficient SepoliaETH, the transaction could be submitted.

Transaction execution
MetaMask was used to submit:
0.0001 SepoliaETH

from:
0xB15707286c4dFC6f642fcDf217419b2665e1847a

to:
0x14d751a54E8617C5A9DF87972dC980827fA91e4d

The transaction was submitted on:
Ethereum Sepolia
Chain ID: 11155111

The Marketplace immediately entered:
PAYMENT: CONFIRMING

rather than incorrectly assuming that the payment was already final.

Confirmation tracking
The UI displayed:
Confirmations: 0

immediately after transaction submission.
This is an important state distinction:
transaction submitted

≠

payment finalized

The backend continued checking the blockchain until the required confirmation depth was reached.
The configured threshold was:
3 confirmations

Server-side verification
The final payment state was not determined solely by the frontend or by MetaMask.
The verification process used the payment intent as the expected source of truth.
Conceptually:
Expected sender
│
├───────────────┐
Expected recipient │
│ │
Expected amount │
│ ▼
Expected network → Blockchain transaction
```
              │
              ▼
         Verification
              │
       ┌──────┴──────┐
       │             │
    Valid?       Confirmations
       │             │
       └──────┬──────┘
              ▼
             PAID
```

The final transaction satisfied the expected payment parameters.

Final transaction state
The Marketplace eventually showed:
PAYMENT: PAID

with:
Amount:
0.0001 ETH

Network:
Ethereum Sepolia

Confirmations:
3

and the transaction evidence:
TX:
0xae0b...5af9f94c37

The final sender and recipient matched the payment intent.

Complete state transition
The entire Marketplace payment state machine was demonstrated:
┌──────────────────────┐
│ ACCEPTED │
└──────────┬───────────┘
```
   │
   ▼
```
┌──────────────────────┐
│ AWAITING_PAYMENT │
└──────────┬───────────┘
```
   │
   │ MetaMask transaction
   ▼
```
┌──────────────────────┐
│ CONFIRMING │
│ confirmations: 0 │
└──────────┬───────────┘
```
   │
   │ blockchain
   │ confirmations
   ▼
```
┌──────────────────────┐
│ CONFIRMING │
│ confirmations: 3 │
└──────────┬───────────┘
```
   │
   ▼
```
┌──────────────────────┐
│ PAID │
└──────────────────────┘

This is substantially more meaningful than a mocked frontend payment.

Problems encountered and resolved
The E2E test exposed several independent technical problems.
Problem 1 — Existing React process
Something is already running on port 3010

Resolution: identify the existing react-scripts process and manage the correct process.
Problem 2 — Stale Cloudflare bundle
cf-cache-status: HIT
age: 582

with an outdated ETag.
Resolution: targeted Cloudflare cache purge.
Problem 3 — Webpack development WebSocket
ws://127.0.0.1:3010/ws

could not be reached from the public browser.
Resolution: identified as development-server/HMR infrastructure rather than the Marketplace API failure.
Problem 4 — API returned HTML
/api/marketplace/orders/mine

returned:
200 text/html

instead of JSON.
Resolution: separate /api/* from frontend routing in Cloudflare Tunnel.
Problem 5 — Wrong payment-intent endpoint
The frontend attempted:
/payment-intent

while the backend exposed:
/payment/eth-intent

Resolution: use the correct endpoint.
Problem 6 — Missing SepoliaETH
MetaMask reported insufficient funds for network fees.
Resolution: fund the Sepolia test wallet through a faucet.

What makes this a real E2E test?
A useful distinction is:
Mocked test
Click Pay
↓
setState(PAID)

versus:
This test
Marketplace order

↓

authenticated API

↓

payment intent

↓

MetaMask

↓

real Sepolia transaction

↓

Ethereum network

↓

transaction confirmation

↓

server-side verification

↓

3 confirmations

↓

PAID

The second flow crosses actual system boundaries.

Infrastructure architecture after the fixes
The final architecture is:

                 INTERNET
                    │
                    ▼
             Cloudflare Edge
                    │
                    ▼
          Cloudflare Tunnel
                    │
     ┌──────────────┴──────────────┐
     │                             │
 /api/*                         /*
     │                             │
     ▼                             ▼

┌──────────────┐ ┌──────────────┐
│ Backend │ │ React │
│ 127.0.0.1 │ │ 127.0.0.1 │
│ :5010 │ │ :3010 │
└──────┬───────┘ └──────┬───────┘

     │                            │
     ▼                            ▼

Marketplace API Marketplace UI

     │
     ▼

Payment Intent

     │
     ▼
  MetaMask
     │
     ▼

Ethereum Sepolia

     │
     ▼

Blockchain TX

     │
     ▼

Server Verification

     │
     ▼
    PAID

Useful debugging methodology
One of the biggest takeaways from this test is that debugging a Web3 application is not limited to the blockchain.
The actual dependency chain was:
Browser
↓
React
↓
Webpack
↓
HTTP
↓
Cloudflare
↓
Tunnel
↓
Backend
↓
JWT
↓
Marketplace
↓
Payment intent
↓
MetaMask
↓
Ethereum
↓
Verification

A failure anywhere in this chain can manifest as a completely misleading browser error.
For example:
JSON.parse error

looked like a frontend parsing bug.
The real problem was:
Cloudflare routing

↓

React index.html

↓

JSON.parse("<!DOCTYPE html>")

Likewise:
HTTP 200

looked successful.
But:
200 + text/html

was actually evidence of a routing failure.

Live demonstration
The complete Marketplace Operations interface is available here:
MyZubster Marketplace Operations — Sepolia
The public Sepolia environment:
MyZubster Sepolia Environment
The blockchain can be independently inspected through:
Ethereum Sepolia Etherscan
The completed transaction can be located using the transaction hash displayed by the Marketplace payment verification panel:
0xae0b...5af9f94c37
Final technical checklist
[✓] React frontend running
[✓] Marketplace route detected
[✓] MarketplaceOpsPage present in bundle
[✓] Runtime diagnostics verified
[✓] Public bundle verified
[✓] Cloudflare stale cache identified
[✓] Cloudflare cache purged
[✓] Frontend served current bundle
[✓] API routing issue identified
[✓] /api/* routed to backend :5010
[✓] Frontend routes remain on :3010
[✓] Cloudflare Tunnel configuration validated
[✓] PM2 cloudflared process identified
[✓] cloudflared restarted correctly
[✓] Unauthenticated API returns JSON 401
[✓] Authenticated orders endpoint works
[✓] Marketplace order retrieved
[✓] ETH payment intent generated
[✓] Sepolia chain ID verified
[✓] Sender verified
[✓] Recipient verified
[✓] Amount verified
[✓] MetaMask transaction executed
[✓] Sepolia transaction confirmed
[✓] Server-side verification completed
[✓] 3 confirmations reached
[✓] Payment transitioned to PAID

Conclusion
The most important result of this work is not simply that 0.0001 SepoliaETH was transferred.
The important result is that the entire distributed system was exercised and debugged across its real boundaries.
We started with frontend routing and a browser that was not behaving as expected.
We then traced the problem through:
React
→ Webpack Dev Server
→ browser bundle
→ Cloudflare cache
→ Cloudflare Tunnel
→ API routing
→ backend authentication
→ Marketplace order
→ payment intent
→ MetaMask
→ Ethereum Sepolia
→ blockchain confirmations
→ server-side verification

The final state was:
Marketplace Order

    │
    ▼
  ACCEPTED
    │
    ▼

Payment Intent

    │
    ▼

MetaMask / Sepolia

    │
    ▼

Blockchain TX

    │
    ▼

3 Confirmations

    │
    ▼

Server Verification

    │
    ▼
   PAID

The MyZubster Sepolia ETH Marketplace payment pipeline has therefore been successfully exercised end-to-end against a real Sepolia blockchain transaction.

MyZubster #Web3 #Ethereum #Sepolia #Blockchain #React #NodeJS #Express #MetaMask #Cloudflare #CloudflareTunnel #DevOps #E2E #IntegrationTesting #API #JWT #OpenSource #Marketplace #PaymentInfrastructure #SoftwareEngineering

Debugging 6.5 Million PM2 Restarts: Stabilizing MyZubster Sepolia and I-ECO-01

Sat, 26 Sep 2026 14:17:31 +0000

Debugging 6.5 Million PM2 Restarts: Stabilizing MyZubster Sepolia and I-ECO-01

Today I completed a significant infrastructure debugging session across the MyZubster Sepolia E2E environment and the I-ECO-01 / UrbanLab backend.

What initially looked like a few unrelated configuration problems turned into a useful example of why production debugging needs to happen layer by layer.

The work involved Node.js, PM2, MongoDB, Google OAuth 2.0, Cloudflare, Socket.IO, and a Linux VPS.

Here is what happened, what was broken, and how it was fixed.

1. Google OAuth Was Reaching the Backend — But Authentication Still Failed

The first problem appeared in the Google social-login flow.

The authorization request itself looked correct.

Google was receiving the expected client ID and redirect URI:

https://sepolia.myzubster.com/api/auth/social/google/callback

The callback also reached the backend correctly.

Debug instrumentation confirmed:

hasCode: true

hasState: true

hasError: false

So the browser redirect, public route, OAuth state and callback routing were all working.

The failure happened one step later: during the authorization-code exchange.

The backend logged:

401 invalid_client

and Google reported that the provided client secret was invalid.

That was an important distinction.

The problem was not the redirect URI.

It was not Cloudflare.

It was not Express routing.

It was not the OAuth state.

It was not the frontend.

The OAuth client credential itself was wrong.

After correcting the configuration, the backend reached:

OAUTH-CALLBACK-ENTER

followed by:

OAUTH-CALLBACK-SUCCESS

The server-side Google OAuth flow was working.

2. The `.env` File Was Correct — The Running Process Was Not

The next issue was more subtle.

The .env file contained:

FRONTEND_URL=https://sepolia.myzubster.com

and:

GATEWAY_PUBLIC_URL=https://sepolia.myzubster.com

Yet after successful OAuth authentication, the application could still redirect toward an old Vercel deployment.

This highlighted an important operational detail:

Changing .env does not automatically mean a long-running process is using the new values.

I inspected the configuration at several levels:

.env
Node + dotenv
PM2 process configuration
actual process environment
OAuth redirect generation
backend logs

The active PM2 environment was then aligned with the Sepolia deployment:

FRONTEND_URL=https://sepolia.myzubster.com

PUBLIC_APP_URL=https://sepolia.myzubster.com

GATEWAY_PUBLIC_URL=https://sepolia.myzubster.com

After that, the active process environment was verified directly.

3. Then I Found a Process With More Than 6.5 Million Restarts

While checking the rest of the VPS, another issue appeared.

The UrbanLab / I-ECO-01 PM2 process was shown as online, but its restart counter was enormous:

6,548,384 restarts

That immediately suggested a crash/restart loop.

This is one of the reasons I do not treat:

PM2 status = online

as proof that an application is healthy.

A process can start, crash immediately, restart automatically and still repeatedly appear online when inspected at the wrong moment.

4. Finding the Root Cause

PM2 was executing:

/opt/I-ECO-01/server.js

I inspected the server entrypoint and found these dependencies:

dotenv

express

cors

helmet

mongoose

http

socket.io

winston

Then I compared those requirements against package.json.

The project only declared:

cors

dotenv

express

mongoose

The logs confirmed the immediate failure:

Error: Cannot find module 'helmet'

The server crashed at:

const helmet = require('helmet');

Because PM2 automatically restarted the process, the cycle repeated continuously.

5. Fixing the Dependency Graph

Instead of installing only the first missing package and waiting for the next crash, I inspected all external imports in the server entrypoint.

Three npm dependencies were missing:

helmet

socket.io

winston

http did not require installation because it is part of Node.js itself.

The missing dependencies were installed and persisted to package.json.

The resulting application dependencies now include:

Express
CORS
dotenv
Helmet
Mongoose
Socket.IO
Winston

Each new module was then tested independently with require() before restarting the service.

All modules loaded successfully.

6. Application Startup Was Not Enough — I Tested Stability

After restarting UrbanLab, the application successfully initialized its Escrow controller.

The server reported:

Server started on port 5002

MongoDB connected successfully.

The health endpoint:

http://127.0.0.1:5002/health

returned:

status: ok

service: I-ECO-01

mongodb: connected

But I still did not consider the problem solved.

The original issue was a restart loop, so the correct test was to verify process stability over time.

Before the stability test:

PID = 1026452

restarts = 6548384

After 15 seconds:

PID = 1026452

restarts = 6548384

Same PID.

Same restart counter.

The loop had stopped.

7. Escrow Infrastructure Is Running Again

Once the dependency problem was resolved, the I-ECO-01 Escrow controller initialized with:

Threshold: 2/3

Timeout: 24 hours

Fee: 0.5%

The service also initialized its HTTP API and WebSocket infrastructure.

MongoDB remained connected and the health endpoint continued responding successfully.

So the service moved from an uncontrolled crash loop to an operational backend.

8. Old Logs Can Be Misleading

One interesting detail appeared after the repair.

Running:

pm2 logs urbanlab

still displayed:

Cannot find module 'helmet'

At first glance, that could suggest that the problem still existed.

But those entries were historical.

The current process had already successfully loaded Helmet, initialized the application, connected to MongoDB and remained alive with the same PID.

This is why timestamps, process IDs, restart counters and health checks matter when reading operational logs.

A log file can contain a real error that is no longer a current error.

9. What I Verified

By the end of the session:

Google OAuth provider: operational

Google OAuth callback: operational

OAuth authorization-code exchange: successful

OAuth state handling: verified

Sepolia public URL configuration: corrected

PM2 runtime environment: verified

I-ECO-01 Node.js dependencies: repaired

UrbanLab restart loop: stopped

MongoDB: connected

Health endpoint: healthy

Escrow controller: initialized

2-of-3 multisig configuration: loaded

Socket.IO: initialized

PM2/systemd environment: verified

10. The Main Lessons

This debugging session reinforced several useful principles.

`online` does not mean healthy

A process manager tells you about process state.

An application health endpoint tells you about application state.

You often need both.

`.env` does not equal runtime environment

Always verify what the running process actually sees.

This is especially important when using PM2, containers, systemd or other long-running process managers.

Debug OAuth one stage at a time

OAuth involves multiple independent stages:

authorization request → provider consent → callback → state verification → authorization-code exchange → profile retrieval → application session → frontend redirect.

Logging each boundary makes failures much easier to isolate.

Fix dependency problems systematically

When one require() fails, inspect the entire entrypoint instead of repeatedly installing dependencies one crash at a time.

Verify the original failure condition

The problem was a restart loop.

Therefore, successful startup alone was not enough.

The actual success condition was:

same PID + unchanged restart counter + healthy endpoint over time.

Final Result

The MyZubster Sepolia environment is now significantly more stable.

Google OAuth can successfully complete its backend authentication flow.

The Sepolia runtime URLs are correctly propagated to the active backend process.

I-ECO-01 is connected to MongoDB.

The Escrow service is initialized.

And, most importantly, a Node.js service that had accumulated more than 6.5 million PM2 restarts is now staying alive.

Sometimes the most useful development work is not adding another feature.

It is understanding exactly why the existing system is failing — and proving that the fix actually removed the failure.

Stack: Node.js · Express · MongoDB · PM2 · Google OAuth 2.0 · Socket.IO · Cloudflare · Linux · Sepolia

NodeJS #DevOps #WebDevelopment #BackendDevelopment #Debugging #PM2 #MongoDB #OAuth2 #GoogleOAuth #SocketIO #Web3 #Sepolia #Cloudflare #Linux #MyZubster #CoderLegion

The Question That Keeps Coming Back Imagine a user asks, “Where can I find the official contract

Sun, 20 Sep 2026 01:50:41 +0000

The Question That Keeps Coming Back

Imagine a user asks, “Where can I find the official contract address?” Someone on the team sends a link. A week later, another user asks the same thing.

Both people received an answer. The more interesting question is why they needed to ask.

Maybe the address is on the website but difficult to find. Maybe the page does not clearly say which network it belongs to. Maybe users encounter three similar-looking addresses before they find the official one. A support reply solves the immediate problem; it also gives the product team a clue.

I think repeated questions deserve a place in the development backlog. The useful record is small: what the person was trying to do, where they got stuck, what they could see on screen, and what support had to explain. Remove personal details before sharing it across the team.

Then look for the smallest useful change. A contract address might need a visible network label, a copy button and an explorer link at the point where someone needs it. A question about an approval might need clearer text before the wallet opens. A question about a pending action might need a status that says what has happened so far.

Some answers belong in documentation. Others belong inside the product. If users need to leave a transaction screen to learn whether the transaction worked, another help article may leave the real problem in place.

Frequency matters, but it is not the whole story. A confusing label seen by hundreds of people deserves attention. So does a question asked only once if the misunderstanding could cause someone to sign the wrong action.

After a change ships, check whether the question still appears. Ask a new user to complete the task without help. If they get stuck somewhere else, that is useful information too.

Support conversations are often the closest view a team has of its product in use. The answer someone typed yesterday might be the specification for a better screen tomorrow.

How to Authenticate Users with Solana Wallets in NestJS

Sat, 19 Sep 2026 07:40:14 +0000

Let's talk about wallet based auth in NestJS. What this is, is basically an auth system where the user is authenticated and authorized based on their web3 wallet. We'll be doing this with a Solana wallet. The process is quite straightforward:

User requests a nonce (a single-use random number that prevents replay attacks)
Backend sends the nonce
User signs the nonce with their wallet address and returns the signed nonce back to the backend
Backend verifies that the nonce was signed by the right address

From this point on it's your regular auth flow and you can hook this up to any existing JWT or session auth system you've implemented.

One thing to note is that a frontend is required for this or at least some way for the client to sign nonces with their web3 wallet. We'll be using @solana/kit SDK for this as it's the modern implementation of the @solana/web3.js SDK and recommended for production use by Anza.

Backend

The backend's job is to generate unique challenges (nonces), verify that signatures were created by the claimed wallet address, and issue JWT tokens on successful authentication.

We'll need to install @solana/kit as well as redis since we will be using that to store our nonces. Redis is ideal here because it provides fast in-memory storage with built-in TTL (time-to-live) expiration, automatically cleaning up old nonces without manual intervention.

npm install @solana/kit redis

Redis Service

Let's set up our redis client and service.

In NestJS, when you're working with non-class instances like Redis clients, you can't use the standard class-based dependency injection. Instead, you use string tokens as injection identifiers. The Redis client is created by a factory function (not instantiated via new RedisService()), so TypeScript can't use the class itself as a token. String constants provide a unique identifier that NestJS can use to register and retrieve the instance.

This is why we define REDIS_CLIENT as a constant string token that we'll use to register and inject our Redis client throughout the application.

//redis.constants.ts
export const REDIS_CLIENT = 'REDIS_CLIENT';

We need two specific methods here. The setNonce method stores the nonce with a 5-minute expiration using Redis's EX option, which automatically cleans up old nonces and prevents replay attacks.

The getAndDeleteNonce method atomically retrieves and deletes the nonce in one operation, ensuring each nonce can only be used once for verification. This pattern prevents an attacker from reusing a previously signed nonce.

//redis.service.ts
import { Inject, Injectable } from '@nestjs/common';
import { REDIS_CLIENT } from './redis.constants';
import type { RedisClientType } from 'redis';

@Injectable()
export class RedisService {
  constructor(@Inject(REDIS_CLIENT) private readonly redis: RedisClientType) {}

  // Store nonce with 5-minute expiration
  async setNonce(address: string, nonce: string): Promise<void> {
    await this.redis.set(`nonce:${address}`, nonce, { EX: 300 });
  }

  // Retrieve and immediately delete nonce to prevent replay attacks
  async getAndDeleteNonce(address: string): Promise<string | null> {
    const nonce = await this.redis.get(`nonce:${address}`);
    
    if (nonce) {
      await this.redis.del(`nonce:${address}`);
    }
    
    return nonce;
  }
}

We're using NestJS's ConfigService to manage environment variables in a type-safe way. This is better than directly accessing process.env because it centralizes configuration, provides validation, and makes testing easier. You can validate required variables at startup (fail fast), type-check them, and mock them in tests without polluting the global process object.

The @Global() decorator makes this module available throughout your application without needing to import it into every module. Make sure to set up ConfigModule in your AppModule like this:

// app.module.ts
import { Module } from '@nestjs/common';
import { ConfigModule } from '@nestjs/config';
// ... other imports

@Module({
  imports: [
    ConfigModule.forRoot({
      isGlobal: true, // Makes ConfigModule available globally
    }),
    // ... other modules
  ],
  // ... controllers and providers
})
export class AppModule {}

Now we can set up our Redis module:

//redis.module.ts
import { Global, Module } from '@nestjs/common';
import { RedisService } from './redis.service';
import { REDIS_CLIENT } from './redis.constants';
import { ConfigService } from '@nestjs/config';
import { createClient } from 'redis';

@Global()
@Module({
  providers: [
    {
      provide: REDIS_CLIENT,
      inject: [ConfigService],
      useFactory: async (configService: ConfigService) => {
        const client = createClient({
          url: configService.get<string>('REDIS_URL'),
        });
        
        client.on('error', (err) => console.error('Redis client error', err));
        
        await client.connect();
        
        return client;
      },
    },
    RedisService,
  ],
  exports: [REDIS_CLIENT, RedisService],
})
export class RedisModule {}

Auth Service

With Redis configured to handle nonce storage, we can build the authentication logic. The auth service will generate nonces, create SIWS-compliant messages, verify signatures, and issue JWT tokens. Let's implement our service logic.

We need to provide a way for the frontend to request a nonce. We also need to use our redis methods to store the nonce we provide to be used during verification later.

We use randomBytes from Node's crypto module to generate cryptographically secure random values. The 16 bytes of random data are then converted to base64url encoding, which is URL-safe and produces a string without padding characters. This encoding ensures the nonce can be safely included in URLs and JSON without escaping issues, while 16 bytes provides sufficient entropy (2^128 possible values) to prevent collision attacks. This gives us a unique, unpredictable nonce for each authentication attempt.

import { randomBytes } from 'crypto';

generateNonce(): string {
  return randomBytes(16).toString('base64url');
}

The message format follows the Sign-In with Solana (SIWS) standard, which is analogous to Sign-In with Ethereum (SIWE). This standardized format includes the domain requesting authentication, the user's wallet address, a human-readable message, the unique nonce, and a timestamp. This structure ensures the user knows exactly what they're signing and prevents phishing attacks where a malicious site might try to get users to sign messages intended for other domains.

async getChallenge(address: string) {
  const nonce = this.generateNonce();
  
  await this.redisService.setNonce(address, nonce);
  
  // Standard SIWS message format for wallet authentication
  const message = `titan-app.com wants you to sign in with your Solana account:\n${address}\n\nSign this message to authenticate.\n\nNonce: ${nonce}\nTimestamp: ${Date.now()}`;
  
  return { message, nonce };
}

The signature verification method is the heart of the authentication system. It retrieves the stored nonce, reconstructs the exact message that was signed, and uses Solana's cryptographic primitives to verify that the signature was created by the private key corresponding to the claimed wallet address. If any part of this fails, authentication is rejected.

import { getAddressFromPublicKey, getBase58Decoder, getBase58Encoder } from '@solana/kit';

async verifySolanaSignature(data: {
  address: string;
  signatureBase58: Uint8Array;
  message: Uint8Array;
  nonce: string;
}): Promise<boolean> {
  const { address, signatureBase58, message, nonce } = data;

  // Retrieve and delete the nonce to prevent replay attacks
  const storedNonce = await this.redisService.getAndDeleteNonce(address);

  if (!storedNonce || storedNonce !== nonce) {
    return false;
  }

  try {
    // Decode the signature and message from base58
    const signature = getBase58Decoder().decode(signatureBase58);
    const messageBytes = getBase58Decoder().decode(message);
    
    // Verify the signature matches the address
    const publicKey = getAddressFromPublicKey(
      getBase58Decoder().decode(address)
    );
    
    // Use Solana's signature verification
    const isValid = await verifySignature(publicKey, messageBytes, signature);
    
    return isValid;
  } catch (error) {
    console.error('Signature verification error:', error);
    return false;
  }
}

The validateUserWithWallet method either finds an existing user by wallet address or creates a new one. This is where you'd integrate with your user management system. In this example, we're using Prisma to handle database operations, but you could adapt this to any ORM or database layer.

async validateUserWithWallet(address: string): Promise<UserEntity | null> {
  // Find existing user by wallet address
  let user = await this.prisma.user.findUnique({
    where: { walletAddress: address },
  });

  // If no user exists, create one
  if (!user) {
    user = await this.prisma.user.create({
      data: {
        walletAddress: address,
      },
    });
  }

  return user;
}

The login function creates JWT tokens after successful authentication. We build a payload containing the user's ID and device information, then conditionally add email and wallet address if they exist. The function returns both an access token for immediate use and a refresh token for obtaining new access tokens when the current one expires. The refresh token is handled by a separate service that manages longer-lived tokens with different expiration rules.

async login(
  user: UserEntity,
  deviceInfo: string,
  walletAddress?: string,
): Promise<{
  access_token: string;
  refresh_token: string;
}> {
  const payload = {
    sub: user.id,
    deviceInfo,
  };

  if (user.email) {
    payload['email'] = user.email;
  }

  if (walletAddress) {
    payload['walletAddress'] = walletAddress;
  }

  const refresh_token = await this.jwtRefreshService.create(payload);
  
  return {
    access_token: this.jwtService.sign(payload),
    refresh_token,
  };
}

Wallet Auth Guard

Now we need a way to protect our login endpoint. NestJS guards intercept incoming requests before they reach the controller, making them perfect for authentication logic.

The guard is responsible for intercepting requests to protected endpoints and verifying that the wallet signature is valid before allowing the request to proceed. It extracts the signed data from the request body, verifies the signature using our auth service, finds or creates the user, and attaches both the user entity and wallet address to the request object for use in the controller.

// guards/wallet-auth.guard.ts
import { Injectable, CanActivate, ExecutionContext } from '@nestjs/common';
import { AuthService } from '../auth.service';
import { UnauthorizedException } from '@nestjs/common';

@Injectable()
export class LocalWalletAuthGuard implements CanActivate {
  constructor(private readonly authService: AuthService) {}

  async canActivate(context: ExecutionContext): Promise<boolean> {
    const request = context.switchToHttp().getRequest();
    const { address, signatureBase58, message, nonce } = request.body;

    // Verify signature first
    const isValid = await this.authService.verifySolanaSignature({
      address,
      signatureBase58,
      message,
      nonce,
    });

    if (!isValid) {
      throw new UnauthorizedException('Invalid signature');
    }

    // Find or create user
    const user = await this.authService.validateUserWithWallet(address);

    if (!user) {
      throw new UnauthorizedException('Could not validate user');
    }

    // Attach user and address to request for use in controller
    request.user = user;
    request.address = address;

    return true;
  }
}

Auth Controller

With our guard handling verification, the controller becomes simple. It just needs to provide nonces to unauthenticated users and issue tokens after the guard confirms valid signatures.

In the controller, we have two endpoints. The loginWithWallet endpoint uses our LocalWalletAuthGuard which verifies the signature and attaches both the user entity and wallet address to the request object. By the time we reach this controller method, we know the authentication is valid. We extract device information from the user-agent header, call the login service, set the refresh token as an httpOnly cookie for security, and return the access token. The getChallenge endpoint is marked with @Public() decorator since users need to request a nonce before they can authenticate. It simply returns the SIWS message and nonce for the given wallet address.

@Post('login-with-wallet')
@UseGuards(LocalWalletAuthGuard)
async loginWithWallet(
  @Request() req: RequestType & { user: UserEntity; address: string },
  @Response({ passthrough: true }) res: ResponseType,
) {
  const deviceInfo = req.headers['user-agent'] || 'Unknown Device';

  const { access_token, refresh_token } = await this.authService.login(
    req.user,
    deviceInfo,
    req.address,
  );

  // Set refresh token as httpOnly cookie for security
  res.cookie('titan_refresh_token', refresh_token, {
    httpOnly: true,
    secure: true,
    sameSite: 'strict',
  });

  return { access_token };
}

@Public()
@Get('nonce/:address')
@ApiOperation({ summary: 'Request nonce for wallet-based authentication' })
@ApiResponse({
  description: 'Nonce and SIWS message sent successfully.',
  status: 200,
  example: {
    message:
      'titan-app.com wants you to sign in with your Solana account:\n${address}\n\nSign this message to authenticate.\n\nNonce: ${nonce}\nTimestamp: ${Date.now()}',
    nonce: '1234xlrhex',
  },
})
async getChallenge(@Param('address') address: string) {
  return await this.authService.getChallenge(address);
}

Backend Summary

That covers the backend implementation. We've set up a Redis-backed nonce system that generates unique challenges for each authentication attempt, an auth service that creates SIWS-compliant messages and manages JWT token generation, a guard that verifies signatures using Solana's cryptographic primitives, and controller endpoints that handle the nonce request and login flow. The signature verification ensures that only the holder of the wallet's private key can authenticate, while the nonce system prevents replay attacks.

Frontend

The backend is now ready to issue nonces and verify signatures. The frontend's job is to request these nonces, get the user to sign them with their wallet's private key (which never leaves their browser), and send the signed message back for verification. Now let's implement the frontend of our auth system.

Now let's implement the frontend of our auth system. The user needs to sign our message with their private key. It is important this private key stays secure and never leaves the frontend. A tool that facilitates this is a wallet. Since we're using Solana we'll be using the Phantom wallet.

The setup steps are straightforward. First, install Phantom as a browser extension. Once installed, create a new wallet or import an existing one. Then navigate to Settings, go to Developer Settings, and enable Testnet mode. In Testnet mode, select Solana Devnet. You could use Localnet if you have a test validator running locally or Testnet for a shared testing environment, but Devnet provides a good balance of accessibility and realistic network conditions.

Once all this is done we can start hacking. We'll spin up a small React frontend. This is just for speed and general accessibility. You can implement this in any frontend stack as long as you understand the core steps. I used Vite to set up my React project with TypeScript and Tailwind. We should also install the @solana/kit package, which automatically includes @solana/react and other necessary dependencies, along with @wallet-standard/react-core.

npm install @solana/kit @wallet-standard/react-core

After we're done with project setup, the first thing we want to do is define our Solana client instance. This will be used to communicate with the Solana chain via its RPC endpoints.

// lib/solana-client.ts
import type {
  Rpc,
  RpcSubscriptions,
  SolanaRpcApi,
  SolanaRpcSubscriptionsApi,
} from "@solana/kit";

export type Client = {
  rpc: Rpc<SolanaRpcApi>;
  rpcSubscriptions: RpcSubscriptions<SolanaRpcSubscriptionsApi>;
};

// lib/helpers.ts
import { createSolanaRpc, createSolanaRpcSubscriptions } from "@solana/kit";
import type { Client } from "./solana-client";

let client: Client | undefined;

export function createClient(): Client {
  if (!client) {
    client = {
      rpc: createSolanaRpc(`${import.meta.env.SOLANA_RPC_URL}`),
      rpcSubscriptions: createSolanaRpcSubscriptions(
        `${import.meta.env.SOLANA_RPC_SUBSCRIPTIONS_URL}`
      ),
    };
  }
  
  return client;
}

Make sure your .env file contains the Devnet URLs:

SOLANA_RPC_URL=https://api.devnet.solana.com
SOLANA_RPC_SUBSCRIPTIONS_URL=wss://api.devnet.solana.com

With the Solana client configured, we need functions to communicate with our backend. In our features/auth/api folder, we'll create two API calls: one to request a nonce and another to submit the signed message. Let's define them both.

// features/auth/types
export type RequestNonceOutput = {
  message: string;
  nonce: string;
};

export type VerifyNonceInput = {
  address: string;
  signatureBase58: Uint8Array<ArrayBufferLike>;
  message: Uint8Array<ArrayBufferLike>;
  nonce: string;
};

export type LoginResponse = {
  access_token: string;
};

// features/auth/api/requestNonce.ts
import type { RequestNonceOutput } from "../types";

export async function requestNonce(
  address: string
): Promise<RequestNonceOutput> {
  const response = await fetch(
    `${import.meta.env.VITE_API_URL}/auth/nonce/${address}`
  );

  if (!response.ok) {
    throw new Error(`Failed to request nonce: ${response.statusText}`);
  }

  const data = await response.json();
  
  // Validate response structure
  if (!data.message || !data.nonce) {
    throw new Error('Invalid response format from nonce endpoint');
  }
  
  return data as RequestNonceOutput;
}

// features/auth/api/loginWithWallet.ts
import type { VerifyNonceInput, LoginResponse } from "../types";

export async function loginWithWallet(
  signedData: VerifyNonceInput
): Promise<LoginResponse> {
  const response = await fetch(
    `${import.meta.env.VITE_API_URL}/auth/login-with-wallet`,
    {
      method: "POST",
      headers: {
        "Content-Type": "application/json",
      },
      body: JSON.stringify(signedData),
    }
  );

  if (!response.ok) {
    const errorData = await response.json().catch(() => ({}));
    throw new Error(
      errorData.message || `Login failed: ${response.statusText}`
    );
  }

  const data = await response.json();
  
  // Validate response contains access token
  if (!data.access_token) {
    throw new Error('Invalid response format from login endpoint');
  }
  
  return data as LoginResponse;
}

These are going to serve as our connection to the backend we made previously.

Before we build the UI components, we need to manage wallet connection state across the app. React Context provides a clean way to share the selected wallet without prop drilling.

As this is only an auth demonstration it's not going to be anything fancy, just enough to implement the authentication flow and some state to show we're logged in.

First off, our wallet account context. You can use some other way to manage context in your application. Here we'll be using the React Context API.

// src/context/SelectedWalletAccountContext.tsx
import { createContext } from "react";
import type { UiWallet, UiWalletAccount } from "@wallet-standard/react-core";

export type SelectedWalletAccountState = UiWalletAccount | undefined;

export const SelectedWalletAccountContext = createContext<
  readonly [
    selectedWalletAccount: SelectedWalletAccountState,
    setSelectedWalletAccount: React.Dispatch<
      React.SetStateAction<SelectedWalletAccountState>
    >,
    selectedWallet: UiWallet | undefined
  ]
>([
  undefined,
  function setSelectedWalletAccount() {
    /* empty */
  },
  undefined,
]);

The wallet account context provider handles persistence and synchronization of the selected wallet across sessions. When a user selects a wallet, we save a storage key composed of the wallet name and account address to localStorage. On subsequent visits, the provider attempts to restore the previously selected wallet if it's still available. The provider also handles cleanup when wallets disconnect and ensures the selected account stays synchronized with the actual connected wallets from the Wallet Standard registry.

// src/context/SelectedWalletAccountContextProvider.tsx
import { useEffect, useMemo, useState } from "react";
import {
  SelectedWalletAccountContext,
  type SelectedWalletAccountState,
} from "./SelectedWalletAccountContext";
import {
  getUiWalletAccountStorageKey,
  uiWalletAccountBelongsToUiWallet,
  uiWalletAccountsAreSame,
  useWallets,
  type UiWallet,
  type UiWalletAccount,
} from "@wallet-standard/react-core";

const STORAGE_KEY = "solana-wallet-standard-react:selected-wallet-and-address";

let wasSetterInvoked = false;

// Attempts to restore previously selected wallet from localStorage
function getSavedWalletAccountAndWallet(
  wallets: readonly UiWallet[]
):
  | { account: UiWalletAccount | undefined; wallet: UiWallet | undefined }
  | undefined {
  // Stop auto-selecting after user makes explicit choice
  if (wasSetterInvoked) {
    return;
  }
  
  const savedWalletNameAndAddress = localStorage.getItem(STORAGE_KEY);
  if (
    !savedWalletNameAndAddress ||
    typeof savedWalletNameAndAddress !== "string"
  ) {
    return;
  }
  
  const [savedWalletName, savedAccountAddress] =
    savedWalletNameAndAddress.split(":");
    
  if (!savedWalletName || !savedAccountAddress) {
    return;
  }
  
  // Find matching wallet and account in current connected wallets
  for (const wallet of wallets) {
    if (wallet.name === savedWalletName) {
      for (const account of wallet.accounts) {
        if (account.address === savedAccountAddress) {
          return { account, wallet };
        }
      }
    }
  }
}

export function SelectedWalletAccountContextProvider({
  children,
}: {
  children: React.ReactNode;
}) {
  const wallets = useWallets();
  
  const [selectedWalletAccount, setSelectedWalletAccountInternal] =
    useState<SelectedWalletAccountState>(
      () => getSavedWalletAccountAndWallet(wallets)?.account
    );
  
  const [selectedWallet, setSelectedWalletInternal] = useState<
    UiWallet | undefined
  >(() => getSavedWalletAccountAndWallet(wallets)?.wallet);
  
  // Wrapper that saves selection to localStorage
  const setSelectedWalletAccount: React.Dispatch<
    React.SetStateAction<SelectedWalletAccountState>
  > = (setStateAction) => {
    setSelectedWalletAccountInternal((prevSelectedWalletAccount) => {
      wasSetterInvoked = true;
      const nextWalletAccount =
        typeof setStateAction === "function"
          ? setStateAction(prevSelectedWalletAccount)
          : setStateAction;
          
      const accountKey = nextWalletAccount
        ? getUiWalletAccountStorageKey(nextWalletAccount)
        : undefined;
        
      if (accountKey) {
        localStorage.setItem(STORAGE_KEY, accountKey);
      } else {
        localStorage.removeItem(STORAGE_KEY);
      }
      
      return nextWalletAccount;
    });
  };
  
  // Restore saved wallet on mount
  useEffect(() => {
    const savedWalletAccount = getSavedWalletAccountAndWallet(wallets)?.account;
    const savedWallet = getSavedWalletAccountAndWallet(wallets)?.wallet;
    
    if (savedWalletAccount && savedWallet) {
      setSelectedWalletAccountInternal(savedWalletAccount);
      setSelectedWalletInternal(savedWallet);
    }
  }, [wallets]);
  
  // Keep selected account synchronized with connected wallets
  const walletAccount = useMemo(() => {
    if (selectedWalletAccount) {
      for (const uiWallet of wallets) {
        for (const uiWalletAccount of uiWallet.accounts) {
          if (uiWalletAccountsAreSame(selectedWalletAccount, uiWalletAccount)) {
            return uiWalletAccount;
          }
        }
        
        // If selected account's wallet is connected, use its first account
        if (
          uiWalletAccountBelongsToUiWallet(selectedWalletAccount, uiWallet) &&
          uiWallet.accounts[0]
        ) {
          return uiWallet.accounts[0];
        }
      }
    }
  }, [selectedWalletAccount, wallets]);
  
  const wallet = useMemo(() => {
    if (selectedWallet) {
      for (const uiWallet of wallets) {
        if (uiWallet.name === selectedWallet.name) {
          return uiWallet;
        }
      }
    }
  }, [selectedWallet, wallets]);
  
  // Clear selection if wallet disconnects
  useEffect(() => {
    if (selectedWalletAccount && !walletAccount) {
      setSelectedWalletAccountInternal(undefined);
    }
  }, [selectedWalletAccount, walletAccount]);
  
  return (
    <SelectedWalletAccountContext.Provider
      value={useMemo(
        () => [walletAccount, setSelectedWalletAccount, wallet],
        [walletAccount, wallet]
      )}
    >
      {children}
    </SelectedWalletAccountContext.Provider>
  );
}

Once our context is set up we can import and use it like so:

// src/main.tsx
import { StrictMode } from "react";
import { createRoot } from "react-dom/client";
import "./index.css";
import App from "./App.tsx";
import { SelectedWalletAccountContextProvider } from "./context/SelectedWalletAccountContextProvider.tsx";

createRoot(document.getElementById("root")!).render(
  <StrictMode>
    <SelectedWalletAccountContextProvider>
      <App />
    </SelectedWalletAccountContextProvider>
  </StrictMode>
);

Wallet List

With context set up to track wallet state, we can build the UI. Users need a way to see available wallets and connect them to our app. The Wallet Standard exposes all compatible browser wallets, so we'll create a dialog that lists them. We'll start with the wallet list item.

// features/auth/components/wallet_list_item.tsx
import { Button } from "@/components/ui/button"
import { SelectedWalletAccountContext } from "@/context/SelectedWalletAccountContext";
import { useConnect, type UiWallet } from "@wallet-standard/react-core";
import { useContext } from "react";

type Props = {
  wallet: UiWallet;
  setOpen: () => void;
};

export const WalletListItem = ({ wallet, setOpen }: Props) => {
  const [isConnecting, connect] = useConnect(wallet);
  const [_, setSelectedWalletAccount] = useContext(
    SelectedWalletAccountContext
  );
  
  const handleConnect = () => {
    try {
      // Connect returns array of accounts, we select the first one
      connect().then((res) => {
        setSelectedWalletAccount(res[0]);
      });
    } catch (error) {
      console.error("Failed to connect:", error);
    } finally {
      setOpen();
    }
  };
  
  if (!wallet) return;

  return (
    <li>
      <Button
        variant="outline"
        disabled={isConnecting}
        onClick={handleConnect}
        className="flex flex-row p-4 items-center justify-start gap-3 w-full"
      >
        <img alt="wallet logo" src={wallet.icon} className="w-6 h-6" />
        <p className="text-lg font-semibold">{wallet.name}</p>
      </Button>
    </li>
  );
};

One thing to note is that while we can fetch all wallets connected to the browser, you often only want the ones that support the chain your application is based on. To do this we can create a hook to fetch and filter these wallets for us. You can extend this to work for multiple chains if need be. Extracting this logic into a custom hook is production-grade because it encapsulates the filtering logic in a reusable, testable unit. It makes your components cleaner by separating concerns, and if you need to add more complex filtering logic later or support multiple chains, you only need to modify this one hook rather than hunting through multiple components.

// features/auth/hooks/useFilteredWallets.tsx
import { useWallets } from "@wallet-standard/react-core";

export function useFilteredWallets() {
  const wallets = useWallets();
  
  // Filter wallets that support Solana chains
  const solanaWallets = wallets.filter((uiWallet) =>
    uiWallet.chains.some((chain) => chain.startsWith("solana:"))
  );

  return solanaWallets;
}

Now we can implement the actual wallet list to render all connected wallets that match our base chain.

// features/auth/components/wallet_list.tsx
import { Button } from "@/components/ui/button";
import {
  DialogHeader,
  Dialog,
  DialogTrigger,
  DialogContent,
  DialogTitle,
  DialogDescription,
} from "@/components/ui/dialog";
import { WalletListItem } from "./wallet_list_item";
import { useFilteredWallets } from "../hooks/useFilteredWallets";
import { useState } from "react";
  
export const WalletList = () => {
  const [open, setOpen] = useState(false);
  const solanaWallets = useFilteredWallets();

  return (
    <Dialog open={open} onOpenChange={setOpen}>
      <form>
        <DialogTrigger asChild>
          <Button variant="outline">View Wallets</Button>
        </DialogTrigger>

        <DialogContent className="sm:max-w-106.25">
          <DialogHeader>
            <DialogTitle>Select Wallet</DialogTitle>
            <DialogDescription>
              Select the wallet you want to connect to Titan.
            </DialogDescription>
          </DialogHeader>

          <ul className="flex flex-col gap-2">
            {solanaWallets.map((wallet, idx) => (
              <WalletListItem
                key={idx}
                wallet={wallet}
                setOpen={() => setOpen(false)}
              />
            ))}
          </ul>
        </DialogContent>
      </form>
    </Dialog>
  );
};

Once a wallet is connected, we need to authenticate the user. This is where the full flow comes together: request nonce, sign it, send to backend. This is just going to be a simple button that triggers the auth flow.

The first thing that will happen on click is that we request a nonce from our backend. Immediately after we get the nonce we use the useSignIn hook to sign our message. We then extract the results we need and send them in our login request.

// features/auth/components/auth_buttons.tsx
import { useSignIn } from "@solana/react";
import { Button } from "@/components/ui/button";
import { requestNonce } from "../api/requestNonce";
import { loginWithWallet } from "../api/loginWithWallet";
import type { UiWallet } from "@wallet-standard/react-core";

type SignInProps = {
  address: string;
  wallet: UiWallet;
};

export const SignInButton = ({ wallet, address }: SignInProps) => {
  const signIn = useSignIn(wallet);
  
  if (!wallet) return;

  const handleSignIn = async () => {
    try {
      // Request nonce from backend
      const res = await requestNonce(address);

      // Sign the message with wallet's private key
      const { account, signedMessage, signature } = await signIn({
        nonce: res.nonce,
        domain: import.meta.env.VITE_APP_DOMAIN || "localhost:5173",
      });

      // Send signed data to backend for verification
      const loginResponse = await loginWithWallet({
        address: account.address,
        signatureBase58: signature,
        message: signedMessage,
        nonce: res.nonce,
      });
      
      // Store access token (you might want to use a state management solution)
      localStorage.setItem('access_token', loginResponse.access_token);
      
      console.log('Successfully authenticated!');
    } catch (error) {
      console.error("Failed to sign in:", error);
      // You might want to show this error to the user via a toast or alert
    }
  };
  
  return <Button onClick={handleSignIn}>Sign In</Button>;
};

Our finished App.tsx looks like this.

// App.tsx
import { useContext } from "react";
import { WalletList } from "./features/auth/components/wallet_list";
import { SelectedWalletAccountContext } from "./context/SelectedWalletAccountContext";
import { SignInButton } from "./features/auth/components/auth_buttons";

function App() {
  const [selectedWalletAccount, _, selectedWallet] = useContext(
    SelectedWalletAccountContext
  );

  return (
    <div className="flex gap-3 min-h-svh flex-col items-center justify-center">
      <div>
        <p className="text-lg font-semibold">
          Active account: {selectedWalletAccount?.address || 'None'}
        </p>
      </div>

      <WalletList />

      {selectedWalletAccount && selectedWallet && (
        <SignInButton
          address={selectedWalletAccount.address}
          wallet={selectedWallet}
        />
      )}
    </div>
  );
}

export default App;

Frontend Summary

That wraps up the frontend implementation. We've built a wallet connection system that integrates with the Wallet Standard to support any compatible Solana wallet, not just Phantom. The context provider manages wallet selection persistence across sessions, while the sign-in flow requests a nonce from the backend, prompts the user to sign it with their wallet, and sends the signed message back for verification. The private key never leaves the user's wallet, ensuring security throughout the process.

Conclusion

We've implemented a complete wallet-based authentication system for Solana. The backend generates unique nonces with Redis-backed storage, creates SIWS-compliant challenge messages, verifies signatures using Solana's cryptographic primitives, and manages JWT token generation after successful verification. The frontend leverages the Wallet Standard to support multiple wallet providers and handles the signing flow securely within the user's wallet extension.

This auth pattern is fundamentally different from traditional username/password authentication because the user proves ownership of their wallet through cryptographic signatures rather than shared secrets. The nonce prevents replay attacks, the standardized message format prevents phishing, and the time-limited Redis storage ensures old challenges can't be reused. You can extend this system by adding additional user data to the JWT payload, implementing token refresh logic, or supporting multiple blockchain networks with minimal modifications to the core flow.

We Turned a Real Knowledge Transfer Into Verifiable Evidence on Base Sepolia

Sat, 19 Sep 2026 02:18:27 +0000

We Turned a Real Knowledge Transfer Into Verifiable Evidence on Base Sepolia

Today we completed an experiment inside MyZubster that connects real human collaboration, GitHub history, cryptographic commitments, and blockchain verification.

The goal was not to “put knowledge on blockchain.”

The goal was more precise:

Can we take a real technical collaboration, freeze the resulting public work into a canonical record, hash it deterministically, anchor that commitment on-chain, and verify it independently later?

We used the ongoing Nicola / N4K48 MyZubster pilot as the real case.

The result is now public and reproducible.

The real source of evidence: GitHub

Nicola’s public MVP is here:

https://github.com/nicolaususnicola-lgtm/myzubster-mvp

Live pilot:

https://myzubster-mvp.onrender.com/

During the September 18 collaboration, the repository advanced across:

economic provenance;
persistent ledger storage;
revenue and asset APIs;
derived balances;
source-specific revenue breakdown;
UTC timestamps;
asset/revenue history;
MYZ ledger UI;
public documentation;
revenue simulation.

Instead of describing that work loosely, we identified an exact Git history window:

Base commit:
8da7435ddc1b9ae8b2f5c2eea5debd2df4bc5f47

Head commit:
b9ac4e8801d65b84ef882baf78fa09ce5b6b5059

That snapshot contains 30 commits.

This gives us a concrete technical object to reference.

We introduced a knowledge-transfer manifest

We created a new schema:

myzubster.knowledge-transfer.v1

with transfer ID:

KNOWLEDGE-N4K48-2026-09-18-001

The manifest records:

source identity;
recipient identity;
repository;
base commit;
head commit;
changed files;
knowledge scope;
blockchain target;
evidence boundaries.

The important design choice is that we separate:

source assertion
from
recipient attestation

At anchor time, Nicola’s recipient attestation was still:

PENDING

That is intentional.

A blockchain transaction should never be interpreted as automatic consent from another human.

Deterministic hashing

The manifest is canonicalized by:

recursively sorting object keys;
preserving array order;
serializing compact JSON;
UTF-8 encoding;
calculating SHA-256.

The resulting hash is:

39ab3a177734b5e3e254657cfe6015100644bcda2fb008cf2561d000669b9e14

The blockchain payload is:

MZ-KNOWLEDGE-V1:39ab3a177734b5e3e254657cfe6015100644bcda2fb008cf2561d000669b9e14

This is the core architecture:

large public evidence set

↓

canonical manifest

↓

SHA-256

↓

small on-chain commitment

We do not need to put source code, documentation, personal data, or full knowledge content directly on-chain.

Anchoring on Base Sepolia

For the pilot we used:

Network: Base Sepolia
Chain ID: 84532
Value: 0 ETH

The transaction was confirmed:

0xff3c108275625673ad22a886da2df7120ae81b8f0106ec833613513b03c7bc31

Block:

47000958

Confirmed at:

2026-09-18T22:23:24.000Z

Explorer:

https://sepolia.basescan.org/tx/0xff3c108275625673ad22a886da2df7120ae81b8f0106ec833613513b03c7bc31

A real integration bug: MetaMask rejected self-targeted calldata

Our first implementation tried to submit:

from: wallet
to: same wallet
value: 0
data: commitment

MetaMask rejected it with:

External transactions to internal accounts cannot include data

So we changed the design to use a fixed zero-value evidence sink:

0x000000000000000000000000000000000000dEaD

No ETH is transferred.

Only the commitment is carried in calldata.

Then smart accounts changed the transaction shape

After the transaction confirmed, the first version of our verifier reported:

MISMATCH

At first glance that looked wrong.

The receipt was successful.

The chain was correct.

The value was zero.

But the transaction destination and top-level calldata were not what our verifier expected.

The reason: MetaMask submitted the request through a delegated smart-account transaction.

The top-level transaction was type 4 and the anchor execution was wrapped inside:

redeemDelegations(...)

This forced us to improve the verifier.

Instead of only checking:

tx.to === evidenceSink
tx.data === expectedPayload

we added delegated execution decoding.

The verifier now inspects the nested execution and validates:

target
value
calldata
execution mode

Inside the delegated call we found:

Target:
0x000000000000000000000000000000000000dEaD

Value:
0

Payload:
MZ-KNOWLEDGE-V1:39ab3a177734b5e3e254657cfe6015100644bcda2fb008cf2561d000669b9e14

The result became:

MATCH

This was one of the most useful parts of the pilot.

A synthetic demo probably would not have exposed this distinction between a normal EOA transaction and a delegated smart-account execution.

Public verifier

We deployed a public verifier endpoint:

https://www.myzubster.com/api/knowledge-anchor/n4k48/0xff3c108275625673ad22a886da2df7120ae81b8f0106ec833613513b03c7bc31

It checks:

chainId ✅
receipt success ✅
top-level value = 0 ✅
delegated call recognized ✅
nested target match ✅
nested value = 0 ✅
exact calldata match ✅
execution mode match ✅

Current status:

{
"success": true,
"status": "MATCH"
}

Human-readable page:

https://www.myzubster.com/knowledge-anchor-n4k48

What exactly is proven?

This is where engineering language matters.

The blockchain anchor proves evidence about:

existence
integrity
timestamp

for the exact canonical manifest.

It does not prove:

authorship of every idea
learning
understanding
scientific validity
legal ownership
commercial value
truth of every human claim

This distinction is fundamental.

Blockchain is useful here as a tamper-evident timestamp and integrity layer, not as a replacement for human verification, peer review, contracts, or scientific validation.

The final human layer

The next step belongs to Nicola.

He now needs to add a separate attestation from his own GitHub account confirming that the record actually represents knowledge, guidance, and collaboration he received and used.

We intentionally do not modify the original anchored manifest, because that would change its hash.

Instead, Nicola can create something like:

knowledge/N4K48-ATTESTATION-KNOWLEDGE-2026-09-18.md

and commit a statement acknowledging:

KNOWLEDGE-N4K48-2026-09-18-001

and its anchored hash.

This creates a stronger chain:

source assertion

↓

public development evidence

↓

canonical hash

↓

blockchain anchor

↓

independent verifier

↓

recipient acknowledgement
Why we think this architecture matters

A lot of blockchain systems start from the wrong question:

“What can we put on-chain?”

A better question is:

“What evidence should stay off-chain, and what minimal commitment should be anchored on-chain?”

For MyZubster, this leads to a cleaner architecture:

GitHub → evidence history
SHA-256 → integrity
Base Sepolia → timestamp anchor
Human attestation → consent / acknowledgement
Research review → validation
MYZ ledger → internal accounting

Each layer does one job.

That separation avoids a lot of semantic confusion.

Knowledge is not the token

Another design principle we are keeping explicit:

knowledge ≠ blockchain asset
MYZ ≠ crypto token
GitHub commit ≠ legal ownership
blockchain timestamp ≠ scientific proof

MYZ remains an internal MyZubster accounting unit.

The knowledge anchor is a separate evidence mechanism.

The two may interact later through explicit business rules, but they should never be silently merged into one concept.

Public references

Nicola / N4K48 repository:

https://github.com/nicolaususnicola-lgtm/myzubster-mvp

Live pilot:

https://myzubster-mvp.onrender.com/

MyZubster verification page:

https://www.myzubster.com/knowledge-anchor-n4k48

Verifier endpoint:

https://www.myzubster.com/api/knowledge-anchor/n4k48/0xff3c108275625673ad22a886da2df7120ae81b8f0106ec833613513b03c7bc31

BaseScan:

https://sepolia.basescan.org/tx/0xff3c108275625673ad22a886da2df7120ae81b8f0106ec833613513b03c7bc31

MyZubster Core:

https://github.com/MyZubster-Ecosystem/myzubster

What we learned

The biggest lesson was not about hashes or blockchains.

It was about evidence boundaries.

Real systems need to distinguish:

recorded
from
verified

verified
from
validated

validated
from
owned

owned
from
understood

Once those boundaries are explicit, blockchain becomes much more useful.

Not as a magical source of truth.

But as one precise component in a larger evidence architecture.

From a Real-World Kefir Handover to an On-Chain Commitment with Node.js, SHA-256 and Base

Thu, 17 Sep 2026 09:09:36 +0000

From a Real-World Kefir Handover to an On-Chain Commitment with Node.js, SHA-256 and Base

Most blockchain demos begin with a smart contract.

This one began with a real person handing kefir culture to another person.

While building MyZubster, I wanted to test a practical question:

How can we connect a real-world event to public blockchain evidence without storing personal data on-chain — and without pretending that blockchain proves the physical event itself?

We now have a working end-to-end experiment.

The architecture

The flow is intentionally simple:

Physical handover

↓

MarketplaceHandover

↓

RECORDED

↓

Canonical payload

↓

SHA-256

↓

Blockchain commitment

↓

Base Sepolia

↓

Transaction verification

↓

Blockchain receipt stored in MyZubster

The important part is that the blockchain is not the database.

MongoDB maintains the application state and structured evidence. The public blockchain provides an independent timestamped commitment.

Creating the handover record

The physical kefir exchange progressed through explicit application states:

ACCEPTED
↓
HANDED_OVER
↓
RECEIVED
↓
RECORDED

Only after reaching RECORDED do we allow preparation of the blockchain commitment.

That distinction matters.

Creating a hash does not mean something has been anchored.

Preparing a transaction does not mean it has been confirmed.

And storing a transaction ID does not automatically mean the expected commitment actually exists on-chain.

Building the commitment

For the first implementation we defined:

myzubster.marketplace-handover.v1

The committed payload contains the identifiers, handover method, state and relevant event timestamps.

From its deterministic representation we calculate a SHA-256 digest.

For this real handover:

ba9973f08ce86d16a3611c3cccbb9cc2cc779b9ea1cb6fd87a2e5864e557b6b9

Instead of publishing the original record, the transaction contains:

MZ-HANDOVER-V1:
ba9973f08ce86d16a3611c3cccbb9cc2cc779b9ea1cb6fd87a2e5864e557b6b9

This means the public chain receives the cryptographic commitment, not the participant's personal information.

Anchoring it on Base Sepolia

We then performed the actual transaction.

Network: Base Sepolia
Chain ID: 84532
Value: 0 ETH
Block: 46933575
Gas used: 24160
Status: CONFIRMED
Confirmed: 2026-09-17T08:57:18.000Z

Transaction:

0x998a98b1733312e248f74a1387319dae30aab8123a6115c517e4ffe0ef9584bf

You don't have to trust this article.

You can inspect the transaction yourself:

https://sepolia.basescan.org/tx/0x998a98b1733312e248f74a1387319dae30aab8123a6115c517e4ffe0ef9584bf

Verifying before trusting

Before writing the blockchain receipt back into MyZubster, we verified the transaction against the chain.

The verification included the expected chain ID, transaction, block, calldata commitment and confirmation.

Only after those checks did MyZubster persist the blockchain metadata.

The resulting state is conceptually:

{
state: "RECORDED",

blockchainCommitment: {

schema: "myzubster.marketplace-handover.v1",
algorithm: "SHA-256",
hash: "ba9973f08ce86d16a3611c3cccbb9cc2cc779b9ea1cb6fd87a2e5864e557b6b9",
network: "base-sepolia",
txId: "0x998a98b1733312e248f74a1387319dae30aab8123a6115c517e4ffe0ef9584bf",
confirmedAt: "2026-09-17T08:57:18.000Z"

}
}

And the application derives:

const onchainRecorded = Boolean(
commitment.network &&
commitment.txId &&
commitment.confirmedAt
);

So we deliberately keep these concepts separate:

state = RECORDED

onchainRecorded = true

ONCHAIN_RECORDED does not replace the domain state.

It adds another evidence layer.

Moving the experiment into reusable code

A one-off transaction isn't enough.

We therefore added blockchain commitment metadata to the MarketplaceHandover model and implemented an authenticated endpoint:

POST /:handoverId/prepare-blockchain-commitment

The model can now represent:

blockchainCommitment: {
schema,
algorithm,
hash,
preparedAt,
network,
txId,
anchoredAt,
confirmedAt
}

The endpoint requires an eligible RECORDED handover and checks participant authorization before generating the commitment.

The implementation is public here:

https://github.com/MyZubster-Ecosystem/myzubster/pull/1230

Main MyZubster repository:

https://github.com/MyZubster-Ecosystem/myzubster

Testing it

After installing the repository's declared dependencies, we ran the relevant marketplace test suites:

PASS tests/marketplaceFlow.test.js
PASS tests/marketplaceEvidence.test.js

Test Suites: 2 passed, 2 total
Tests: 4 passed, 4 total
TEST_EXIT=0

The point wasn't simply to get a transaction onto a block explorer.

The blockchain representation also needed to fit the existing marketplace/evidence architecture without breaking the application flow.

What does the blockchain actually prove?

This is the most important part.

The transaction does not prove that the kefir was safe.

It does not provide microbiological validation.

It does not independently prove that the physical handover occurred exactly as described.

And it certainly doesn't turn an observation into scientific evidence.

What it gives us is much narrower:

A public, timestamped cryptographic commitment that can later be compared with the corresponding digital record.

That's useful because it allows us to ask a precise technical question:

Does the record I have now produce the same commitment that was publicly anchored at that point in time?

Why I like this architecture

Instead of asking blockchain to become the source of all truth, we can separate responsibilities:

Human action

↓

Application evidence

↓

Structured representation

↓

Cryptographic commitment

↓

Public timestamp / receipt

Each layer proves something different.

That's a much more useful model for provenance than simply putting a "verified on blockchain" badge on an application.

Next step: independent verification

The natural next step is a verifier that can reproduce the process independently:

record
→ canonicalize()
→ sha256()
→ expectedCommitment
→ fetchTransaction()
→ decodeCalldata()
→ compare()
→ MATCH | NO_MATCH

Eventually, I'd like verification to require as little trust in the MyZubster application itself as practical.

Project links

MyZubster:

https://www.myzubster.com

Main source code:

https://github.com/MyZubster-Ecosystem/myzubster

MyZubster GitHub organization:

https://github.com/MyZubster-Ecosystem

On-chain handover integration — PR #1230:

https://github.com/MyZubster-Ecosystem/myzubster/pull/1230

Kefir / fermentation knowledge repository:

https://github.com/DanielIoni-creator/Myzubster-fermentation-kefir

MyZubster Marketplace:

https://github.com/DanielIoni-creator/MyZubster-Marketplace

Base Sepolia transaction:

https://sepolia.basescan.org/tx/0x998a98b1733312e248f74a1387319dae30aab8123a6115c517e4ffe0ef9584bf

What started as one person sharing kefir culture with another became a useful test of how physical events, application state, cryptographic evidence and public blockchain infrastructure can coexist without confusing one for another.

There is still a lot to build, particularly around canonicalization, independent verification, batching and evidence schemas.

But now we have something much more valuable than a diagram:

a real event, a real application record, real code, a reproducible SHA-256 commitment and a real confirmed public transaction.

And every layer can be inspected.

MyZubster — Share → Try → Observe → Improve → Share again.

nodejs #blockchain #web3 #opensource #mongodb #sha256 #base #cryptography #softwarearchitecture #provenance

Custom TRON Addresses in 2026: Vanity Patterns, Difficulty Math, and How Not to Lose the Key

Thu, 10 Sep 2026 13:08:59 +0000

Custom TRON Addresses: The Complete Guide (2026)

A TRON address is 34 Base58 characters. People only check the start and the end. That habit is why vanity wallets exist — and why address poisoning works.

This is the expanded guide to custom TRON addresses: which pattern modes make sense, how difficulty actually scales, which characters are illegal in Base58, why "online vanity generators" are a classic key-theft vector, and how to generate one locally without shipping your private key to a stranger's server.

Tool used below: https://tronsec.io/app#vanity (browser Web Workers — keys stay on your device).

What a Vanity Address Is (and Is Not)

A vanity address is a normal TRON wallet whose Base58 string contains a pattern you chose — usually a suffix like …TRX or …SEC, sometimes a prefix after the mandatory T.

Same elliptic-curve crypto as any other wallet
Same private key format you import into TronLink / Ledger flows
No "special chain privilege." Looking fancy does not make it safer by itself

Generation is a search: try random keys → derive address → check pattern → repeat until it matches. Longer patterns = exponentially more tries.

Four Match Modes That Matter on TRON

TRON addresses always start with T. Good generators expose more than "type a cool word":

Mode	Description
Suffix (most useful)	e.g. ends with `TRX`, `USDT`-ish fragments, brand letters. Easy to spot in explorers that truncate the middle.
Prefix	Characters right after `T`. Great for brand (`TPay…`), but remember every TRON address already starts with `T`.
Contains	Pattern anywhere in the 34 chars. Often easier than a fixed end/start of the same length, but weaker as a visual checksum.
Prefix + Suffix	Strongest brand look (`TMy…SEC`), hardest search. In-browser tools usually cap each part short (a few chars) so your laptop doesn't cook for weeks.

Case sensitivity roughly doubles the alphabet cost per letter when enabled. Leave it off unless you truly need exact case.

Base58 Rules — Why Your Pattern Keeps Failing

TRON addresses use Bitcoin-style Base58. These characters do not exist in valid addresses:

0 (zero)   O (capital o)   I (capital i)   l (lowercase L)

So patterns like ILOVE, 1000, or anything with a zero will never hit. Pick letters from:

123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz

Also avoid ambiguous brand spellings that force illegal glyphs — redesign the tag instead of fighting the alphabet.

Difficulty Math (the Part Most Posts Skip)

Rough mental model for a fixed, case-insensitive match on one position class: each extra character multiplies expected attempts by about 58×.

Length	Typical time
2–3 chars	Usually seconds to a couple of minutes on a modern laptop with multi-core workers
4 chars	Often minutes; still realistic for browser search
5–6 chars	Can be long. Keep the tab open; don't expect "instant"
7+ / long prefix+suffix	Leave the pure-browser path; that is GPU / dedicated miner territory

Search is memoryless: running for an hour does not "unlock" the next hour. ETA is an average, not a countdown that must finish on time. If the UI shows Impossible / pattern too long, believe it — don't paste the same pattern into a shady "faster cloud miner."

Practical advice for USDT users: a clean 3–4 character suffix is enough for humans to notice and cheap enough to generate safely at home.

Step-by-Step: Generate Locally with TRONSEC

Open https://tronsec.io/app#vanity on a machine you trust (not a shared café PC).
Pick mode: start with Suffix and 3 letters (e.g. TRX, PAY, SEC).
Confirm the difficulty badge looks sane (not "Impossible").
Hit start. Workers grind locally in the browser — there is no "submit key to server" step.
When a hit appears, copy address + private key once, store offline (paper / password manager / hardware workflow you already use).
Import into TronLink (or your cold flow). Send a tiny test TRX/USDT before publishing the address on a website.
Close the generator tab. Do not leave private keys in screenshots, Discord, or cloud notes.

If a site asks you to "paste your seed to vanity-mine faster," that is not a generator. That is theft.

Online Vanity Generators — The Scam Pattern

Google "TRON vanity generator" and you will find pages that:

Return a key from an API (they saw it first)
Ask for email / Telegram before revealing the key
Ship a random EXE "for GPU speed"
Or clone a legit UI and sit on a typosquat domain

Checklist before you generate anything that will hold real USDT:

[ ] Keys created on your device only
[ ] No seed import into the vanity page
[ ] No mandatory account to "unlock" the result
[ ] URL is one you typed / bookmarked (for TRONSEC: tronsec.io)
[ ] After import, move funds with the same hygiene as any new wallet

Vanity does not weaken the curve math. Bad tooling does.

Vanity vs. Address Poisoning (Same Human Habit)

You like vanity because people check ends of addresses. Attackers like that habit too.

Address poisoning: dust transfers from lookalike addresses into your history so you copy the wrong one from TronScan / wallet activity.

How vanity helps:

Your published deposit address has a memorable suffix → missing suffix is an instant red flag.

How vanity does not save you:

Attackers can also mine short lookalike suffixes. Short patterns are cheap for them too.
You must still compare the full 34 characters (or use a saved address book / QR from your official site).

Related threats: clipboard hijack malware (paste rewritten on the PC) and fake USDT tokens — different problems, same "verify before send" discipline.

Who Should Actually Use One

Merchants / freelancers — publish one branded deposit address on HTTPS; announce rotations clearly.
OTC / P2P desks — fewer "is this really you?" tickets when the suffix matches the brand sheet.
Power users — label hot vs. cold visually (…HOT style patterns if Base58 allows).
Treasury — vanity is fine for a deposit face; keep large balances on hardware / multisig policy anyway.

Do not put life-changing funds on a key you generated on a malware-ridden Windows install "just to try a 6-letter suffix."

Aftercare Checklist

Backup the private key / seed the same way as any wallet.
Test deposit + withdrawal with dust amounts.
Publish the address only from a channel you control.
If you rotate, tell customers — silent rotation + vanity is how support nightmares start.
Periodically scan the address for weird inbound spam / approvals if you also use DeFi from related keys: approvals · AML.

Bottom Line

Custom TRON addresses are not a meme feature. They are a readability layer on top of the same cryptography — useful for USDT-heavy workflows, dangerous only when the generator is a phishing front.

Start short (3–4 char suffix), generate locally, verify the full string forever, and treat the private key like any other key.

🔗 Generate here: https://tronsec.io/app#vanity

TRONSEC is a free, read-only TRON security terminal. The vanity search runs in your browser. We do not ask for seed phrases.

The Internet Hasn't Changed

Mon, 07 Sep 2026 12:15:17 +0000

Before we argue about the future of the web, we need to understand what it has always been: one continuous system of innovation built on the exact same foundation.

Let's start with the Web3 ecosystem.

When people talk about Web3, the conversation usually gets tangled up in tokens, hype, and technical buzzwords. But at BinnaDevLab, when we talk about the Web3 ecosystem, we are not talking about a completely different technology. We are referring to the internet as a whole, viewed from Version 3.

Because the truth is, the internet hasn't fundamentally changed.

The internet has always been a means of connection. The core idea is simply to bring people together, share resources, and bridge communication. If you Google the word "Internet," you'll get a definition something like this: a global system of connected computer networks that people use to share information and communicate worldwide.

Over the years, we have experienced completely different ways of doing this. We went from writing letters and painting on walls, to static web pages, social media apps, and streaming reels. It feels like a different world, but it is just a system of innovation built on the exact same block.

The Water Analogy

Think about drinking water for a second.

In ancient times, people used their hands, clay pots, or carved artifacts to draw water. Today? We use modern dispensers, insulated smart cups, and bottled cans. The method changed entirely, but the fundamental action remained exactly the same: we are still drinking water.

The point of innovation is not to change the fundamental purpose. It is to improve the vessel that delivers it.

Bring this to the internet. When you strip away the buzzwords, the internet is simply our vessel for communication. The changes that happen over time are just iterations. We attach numbers to them, but if you look closely, they all mean the same thing.

Season 1: The "Read-Only" Web

When you see the word "Web1," what is the first thing that comes to your mind?

We all know the "web" is the internet. But when we attach a "1" to it, it triggers curiosity. Why call it 1?

It's just like a television series. You have Season 1, Season 2, and Season 3. The numbers are simply there to show progression. Innovation is a progression; it has different iterations, and we need to keep track of it. Web1 just means the first version of the show.

So, what did Season 1 of the internet look like? Take a pause and think about it for a minute.

Web1 was the "read-only" web.

Companies published, and you consumed. You could visit a website and read what was there, but you couldn't easily comment, post, or interact. The information was mostly static text and typed documents.

But at the time, it solved a massive problem: it removed physical barriers to information. The core promise was, "Anyone with a browser can access information from anywhere."

We haven't stopped chasing that goal. We just wanted a level up.

Human Ambition and Season 2

Humans are never satisfied.

Men sat and thought: "If birds can fly, shouldn't we build a vehicle to do that?" "If fish can swim, shouldn't we build a vehicle to do that too?"

That exact mindset pushed the internet from Season 1 to Season 2. Web1 gave us the protocols and the connection, but human ambition always wants to go further. We wanted to move from just "publish and read” to “interact, share, and build together."

This birthed Web2: the "read-and-write" web.

Web2 didn't change the fundamental internet. It just brought our pictures, our videos, and our voices into the mix. But this caused a massive cultural shift. Why? Because suddenly, you weren't just consuming the information anymore. You became the information that other people consume.

The internet became highly interactive and social. But making ourselves the product came with a hidden cost we didn't fully understand at the time.

The Hidden Cost and the Web3 Fix

Web2 is amazing, but it is dominated by a few giant platforms. They store your data. They decide what gets shown or removed. They monetize your activity, keeping the profits while you create the value.

That is why people started pushing for Web3. We saw central gatekeepers raising issues of censorship. We saw privacy slipping away. People wanted more say over their digital identity.

For some reason, people try to detach Web3 from the internet, as if it's some completely alien technology. It's not. It is simply the next season of the exact same show, designed to fix a glaring structural problem.

Web3 uses new tech enablers like blockchain, decentralized storage, and peer-to-peer protocols, to introduce the "read-write-own" web.

Here is the progression:

Web 1.0 (Read-only): Companies publish, you consume.
Web 2.0 (Read-write): You interact, but platforms own the space and the data.
Web 3.0 (Read-write-own): You interact, but you own your data, your identity, and the value you create without a central intermediary.

Instead of data living on a few company servers, it's distributed. It's not a buzzword. It's a structural fix.

You Are An Internet Builder

I need to clear up a major misconception: Web3 is not at war with Web2 or Web1.

Do not see this as a competition. Web1 hasn't even faded away; every time you read a static webpage, you are using the fundamental internet. Web3 was birthed from the others. They all share the exact same DNA.

If Web3 promises to remove centralized gatekeepers, it means eventually, someone will find the gaps in Web3 and introduce the next innovation. Maybe Web4. You will find a pattern that they are just continuously filling the gaps the previous version left behind. It is one whole, continuous system.

This means if you can build in Web1, you can build in Web2, Web3, and whatever comes next.

There are endless possibilities. You don't have to box yourself in as just a "Web2 developer" or a "Web3 developer."

You are an internet builder.

The Engineering Method

Because the web shares the same DNA, you need to have a foundational knowledge of versions 1 and 2 to actually grasp what we are building in version 3. You can't build the future if you don't understand the past.

At BinnaDevLab, we see the endless possibilities of these new iterations. We train developers to understand this entire ecosystem strictly from an engineering method.

The internet is here to stay. It may have different versions, but do not confuse it. It is still the same internet. We are still connecting. We are still sharing resources. We are still processing data. We are just using better vessels.

The Internet is Here. Come to BinnaDevLab and learn how to grow this knowledge.

Before you go, I have a quick task for you: Google what "engineering method" is, and drop your findings in the comments below. Let's discuss it.

Why Video Streaming Buffers: A Developer’s Guide to Reducing Latency and Improving Playback Quality

Sat, 05 Sep 2026 17:10:57 +0000

Video streaming has become one of the most demanding areas of modern web technology. From live events and online television to video-on-demand platforms, users expect instant playback, high resolution and a smooth viewing experience.

However, buffering remains one of the biggest challenges in streaming applications. A video that freezes, loads slowly or suddenly drops in quality can quickly create a poor user experience.

For developers working on streaming platforms, understanding the technical reasons behind buffering is essential. Network performance, video encoding, server architecture and client-side optimization all play a major role.

In this article, we will explore the main causes of streaming interruptions and the techniques developers can use to improve video delivery.

Understanding Why Video Streaming Buffers

Buffering happens when the video player cannot receive data quickly enough to continue playback.

A streaming application does not download an entire video file at once. Instead, it receives small segments of video data continuously. The player stores a temporary amount of data, known as a buffer, to ensure smooth playback.

When the incoming data rate becomes lower than the playback rate, the buffer reaches zero and the video pauses.

Several factors can create this situation:

unstable network connections;
overloaded servers;
inefficient video encoding;
poor CDN distribution;
insufficient device performance.

The Role of Internet Speed and Network Stability

Many users believe that bandwidth alone determines streaming quality. While bandwidth is important, stability is often even more critical.

A connection with high speed but frequent interruptions can provide a worse experience than a slightly slower but stable connection.

Developers should consider:

latency;
packet loss;
connection consistency;
geographic distance between users and servers.

For example, a viewer located far away from the streaming server may experience delays even with a fast internet connection.

Video Compression and Its Impact on Performance

Modern streaming relies heavily on video compression technologies.

Popular codecs include:

H.264 (AVC);
H.265 (HEVC);
AV1.

These codecs reduce file size while maintaining image quality.

H.265 and AV1 are especially important for 4K streaming because they allow higher-quality video delivery with reduced bandwidth requirements.

However, compression requires processing power. Developers must find the right balance between:

video quality;
encoding speed;
server resources;
device compatibility.

How CDN Technology Improves Streaming

Content Delivery Networks (CDNs) are one of the most important technologies behind modern streaming platforms.

Instead of delivering every video stream from a single central server, CDNs distribute content across multiple locations worldwide.

Benefits include:

lower latency;
faster loading times;
reduced server pressure;
better global performance.

A well-designed CDN strategy can significantly improve the viewing experience for users in different regions.

Adaptive Bitrate Streaming Explained

Adaptive Bitrate Streaming (ABS) is one of the most effective solutions for preventing buffering.

Instead of using a fixed video quality, the player automatically adjusts the resolution depending on network conditions.

For example:

strong connection → higher quality video;
weaker connection → lower quality video.

Popular adaptive streaming technologies include:

HTTP Live Streaming (HLS);
MPEG-DASH.

This approach allows users to continue watching without constant interruptions.

Optimizing Streaming Applications

A good streaming experience depends on both backend and frontend optimization.

Backend optimization

Developers should focus on:

efficient server configuration;
optimized database requests;
proper caching strategies;
scalable infrastructure.

Frontend optimization

The video player should provide:

fast startup time;
smooth quality switching;
efficient memory usage;
responsive controls.

A lightweight and optimized player can greatly improve user satisfaction.

The Importance of Device Compatibility

Users consume video content on many different devices:

Smart TVs;
mobile phones;
tablets;
computers;
streaming devices.

Each device has different hardware capabilities.

A streaming application should consider:

supported codecs;
screen resolution;
processing power;
operating system limitations.

Testing across multiple devices helps prevent unexpected playback issues.

Common Solutions to Reduce Streaming Freezing

Developers can apply several techniques to reduce buffering problems:

Optimize video segments

Shorter video segments can improve switching speed and reduce delays.

Improve server distribution

Using multiple server locations helps reduce geographic latency.

Monitor performance

Real-time monitoring can identify:

slow servers;
network problems;
unusual traffic patterns.

Use efficient encoding profiles

Choosing the correct encoding settings improves quality while reducing unnecessary bandwidth usage.

IPTV and Modern Streaming Architecture

Internet-based television systems use many of the same technologies as other streaming platforms.

A modern streaming architecture can include:

content servers;
encoding systems;
CDN networks;
applications;
media players.

Understanding these components helps developers build more reliable streaming solutions.

For readers interested in learning more about internet television technologies and streaming solutions, additional technical information can be explored through resources such as Vast IPTV.

The Future of Streaming Performance

Streaming technology continues to evolve rapidly.

Future improvements will likely include:

artificial intelligence-based optimization;
smarter compression algorithms;
improved cloud infrastructure;
faster wireless networks;
better personalization systems.

Technologies such as 5G, WiFi 7 and advanced video codecs will continue improving the way users consume digital content.

Conclusion

Buffering is not caused by a single problem. It is usually the result of multiple factors working together, including network quality, server performance, video encoding and application optimization.

For developers, creating a smooth streaming experience requires a complete approach that combines efficient architecture, intelligent delivery systems and continuous performance monitoring.

As streaming continues to grow, understanding these technical principles will become increasingly important for building fast, reliable and scalable video applications.

A Practical TRON Security Checklist: Wallet, Approvals, AML, Phishing

Thu, 06 Aug 2026 15:02:24 +0000

How to Check a TRON Address Before You Send USDT (No Wallet Connect)

If you move USDT on TRON, you’ve probably had this moment:

“Is this address safe… or am I about to fund a scammer?”

Explorers show balances and transactions. Telegram chats give opinions. Paid tools gate basic checks. What’s missing for most people is a simple security workflow you can run in under a minute — without connecting a wallet and without pasting a seed phrase.

That’s the workflow this guide covers.

The rule: scan before you sign (or send)

On TRON, damage usually happens in a few patterns:

Wrong destination — lookalike address / poisoned clipboard / fake support
Toxic counterparty — address already flagged or clustered with scam activity
Hidden approvals — old unlimited TRC-20 allowances waiting to drain tokens
Phish page — “connect wallet to verify AML / claim / support”

You don’t need a custody product to reduce that risk. You need a checklist.

60-second TRON safety checklist

1) Wallet scan (identity + resources + flags)

Paste the address into a wallet scanner and look for:

Security tags / hard flags
Odd activity patterns
Energy / bandwidth context (useful for “why did this fail?” — not electricity, on-chain resources)
Token holdings that look like bait (fake USDT clones, spam airdrops)

Tool: TRONSEC Wallet Scanner

2) AML-style screening (behavioral risk, not a court verdict)

Run an AML-style check for:

Concentration of counterparties
Public tags / hard signals
Peer graph / fund-flow style view

Important: this is risk screening from public on-chain data + heuristics. It is not a legal compliance determination and not “bank KYC”.

Tool: TRONSEC AML Check

3) Approvals audit (the silent drainer path)

Even “safe-looking” wallets can be one unlimited allowance away from a drain.

Check:

Active TRC-20 allowances
Unlimited / elevated grants
Unknown spenders

If you see unlimited approvals you don’t recognize — treat that as urgent.

Tool: TRONSEC Approvals Monitor

4) URL / phishing check (before you connect anywhere)

If someone sends a “verify wallet / claim / support” link:

Don’t connect first
Scan the URL
Prefer official domains you typed yourself

Tool: TRONSEC URL Scanner

5) TX decode (before you confirm in the wallet)

If a dApp asks you to sign and you don’t understand the prompt:

Copy the TXID / inspect the intended call
Look for approve, unlimited allowance, suspicious transfers, dust patterns

Tool: TRONSEC TX Decoder

Why “no wallet connection needed” matters

Most everyday checks should be read-only:

Paste an address / TX / URL
Get a report
Decide whether to proceed

Wallet connect is optional for deeper owned-wallet workflows (and approval revoke entry points). It should never be required just to answer:

“Is this address / link / approval sketchy?”

If a random site demands connect + seed / “sync phrase” to “do AML” — that’s usually the scam.

A realistic example workflow (OTC / P2P / treasury)

Counterparty sends a TRON address for USDT.
You run Wallet + AML.
If you’re paying from your own wallet, you also check your Approvals.
You send a small test transfer first when stakes are high.
Only then send the full amount.

Boring? Yes.
Cheaper than explaining a drained treasury in a group chat? Also yes.

What TRONSEC is (and isn’t)

TRONSEC is a free TRON security terminal:

Wallet / AML / Approvals / Phishing / Contract / TX tools
Academy guides in multiple languages
Open-source readable core

Links:

App: https://tronsec.io/app/
Academy: https://tronsec.io/academy/
GitHub: https://github.com/jamejohns/tronsec

It is not:

A custodial wallet
A guarantee that an address is “safe forever”
A substitute for your own judgment on OTC / P2P deals

Security tooling reduces blind spots. It doesn’t remove responsibility.

Developer note (for Dev.to readers)

The useful product principle is boring and powerful:

Separate read-only investigation from signing.

Most users need investigation first. If your UX forces connect before value, you train users into the same habit scammers exploit.

If you’re building on TRON, expose deep-links like:

/app/#scanner with address prefill
/app/#approvals
/app/#aml-check

…so support teams and wallets can send users a one-click check.

Closing

TRON is fast and cheap — which is exactly why scams scale.

Make this your default:

Scan → understand → then sign/send.

If this checklist helped, try it on a real address you were about to pay, and tell me which step caught something unexpected.

Dust Attacks on TRON: How Tiny Transfers Trick You Into Sending USDT to the Wrong Address

Tue, 21 Jul 2026 10:50:15 +0000

title: Dust Attacks on TRON: How Tiny Transfers Trick You Into Sending USDT to the Wrong Address
published: false
tags: web3, security, crypto, tron

canonical_url: https://tronsec.io/academy/tron-address-poisoning-scam/

TL;DR

Dust attacks on TRON rarely steal funds directly. Attackers send microscopic TRX, USDT, or junk TRC-10 tokens so a look-alike address appears in your transaction history. When you copy a recipient from history instead of your address book, you paste the attacker's address and send real money to the wrong place.

Receiving dust is not the loss — sending to the wrong address is.

What is a dust attack?

A dust attack is a tiny inbound transfer — often worth fractions of a cent — broadcast to thousands of wallets.

On TRON Mainnet, dust works because:

TRC-10 transfers are cheap to send at scale
Vanity addresses can mimic the first and last characters of addresses you trust
Wallet UIs truncate long base58 strings (T9x…4k7), so poisoned rows look familiar
There is no undo once you confirm a real outbound USDT transfer

Three common dust patterns on TRON

Type	What you see	Real risk
Address poisoning	0.000001 USDT from an address that looks like your exchange	Wrong paste on next payout
TRC-10 spam	Random token tickers with URLs in the name	Phishing if you click or "claim"
Spam + poisoning combo	Junk token + look-alike USDT dust	Cluttered history + social engineering

Important: inbound dust cannot drain your wallet by itself. No signature, no approval. The trap activates when you initiate a send and pick the wrong address.

How address poisoning works (step by step)

Recon — Bots watch public ledgers, TronScan comments, and OTC chats for wallets that send large USDT to the same partners repeatedly.
Vanity generation — The attacker mines a TRON address with the same prefix and suffix as your real counterparty (for example, first 6 + last 4 characters). Middle bytes differ — easy to miss when skimming.
Dust drop — They send a micro USDT or TRX transfer so the malicious address appears in your history next to the legitimate one.
The mistake — Days later you send 5,000 USDT to a client. You open history, copy what looks right, confirm in TronLink — funds go to the attacker. Irreversible.

This hits OTC desks, payroll operators, treasury staff, and anyone batching repetitive USDT sends. One wrong paste can move five or six figures in a single block.

TRC-10 spam: noise vs trap

TRC-10 is TRON's older token standard — cheap to issue and cheap to spam. Scammers scrape active addresses and airdrop dust via TransferAssetContract.

Usually harmless: receiving TRC-10 dust does not invoke TRC-20 approvals and cannot pull USDT by itself.

Becomes dangerous when:

Token name or memo contains a phishing URL ("claim at …")
A fake support handle is embedded in metadata
Someone DMs you about a "payment" you "received" and asks you to visit a site
History is so cluttered you start copying addresses from the list without full verification

Treat unsolicited TRC-10 like email spam: hide it, ignore it, never click.

Red flags checklist

Unexpected inbound transfer from an unknown address that looks like someone you know
Amount is absurdly small (0.000001 USDT, 0.1 TRX)
Sender has many outbound micro-transfers, almost no balance held
Token name includes: airdrop, claim, bonus, visit, .com, fake USDT ticker
Mobile wallet shows prefix + suffix only — middle hidden
Spreadsheet or chat uses truncated addresses (T9x…4k7)

If two or more match → do not copy from history. Verify the full 34-character address out-of-band.

What NOT to do

Don't send dust back — marks you as an active wallet, may trigger follow-up scams
Don't "activate" or "claim" spam tokens on random sites
Don't treat wallet history as an address book
Don't assume matching first/last characters means same address
Don't approve anything to "remove" spam — hide locally in the wallet UI

Defensive habits that actually work

1. Full-string verification

For any transfer above your internal threshold, compare every character of the recipient address against a trusted source — not history, not a cropped screenshot.

2. Address book + out-of-band confirmation

Save addresses only after verification: video call with address on screen, signed message from recipient wallet, or micro-test with receipt confirmed in a separate channel you control.

3. Four-eyes for treasuries

One operator prepares the transaction; a second independently confirms the full address against signed counterparty records.

4. QR from the recipient's device

Prefer QR generated on their side — never forward a QR from Telegram.

5. Scan before you send

Paste the intended recipient into a scanner before confirming. Flag addresses with inbound-only dust patterns or watchlist hits.

6. Whitelists at the signing layer

Hardware wallets or custodial APIs that reject sends to non-whitelisted addresses beat copy-paste from history every time.

How to investigate a suspicious dust transfer

Open the transaction on TronScan — note sender, token type (TRC-10 vs TRC-20), amount
Check if sender prefix/suffix matches a frequent counterparty
Decode the tx — look for TransferAssetContract vs TRC-20 TriggerSmartContract
Compare sender activity: mass micro-sends = spam/poison setup
Report the address to community watchlists — helps the next victim

Free tools (TRONSEC)

Read-only, browser-side, no seed phrase:

Wallet scanner — portfolio, tags, watchlist cross-check
TX decoder — dust/poisoning heuristics on suspicious transfers
Phishing scanner — if spam token name links to a URL
Report scam — flag poison addresses

Full guides on TRONSEC Academy:

Open source: github.com/jamejohns/tronsec

Takeaways

Dust alone doesn't steal — wrong paste does.
History is not an address book.
Prefix/suffix match ≠ same wallet.
Ignore, hide, report — don't interact with spam.
Verify full base58 before every meaningful USDT send.

Originally published on TRONSEC Academy.

Why I love this new Bitcoin use case, and what you guys think?

Tue, 14 Jul 2026 04:10:51 +0000

I recently came across an incredibly creative application of blockchain technology: Blockonomics' FIFA 2026 Global Fan Wall: https://insights.blockonomics.co/put-your-fifa-2026-world-cup-memory-on-the-global-fan-wall-for-eternity/

It’s refreshing to see Bitcoin being used for something beyond just financial transactions.

What do you guys honestly think of this?

Understanding Blockchain: A Developer's Guide to Blocks, Consensus, and Smart Contracts

Sun, 12 Jul 2026 17:30:16 +0000

Blockchain for Developers: A Practical Introduction

If you have spent any time around tech Twitter, YouTube, or dev conferences in the last few years, you have heard the word "blockchain" thrown around a lot. Sometimes it is tied to cryptocurrency hype, sometimes to NFTs, and sometimes to serious enterprise systems. But if you strip away the noise, blockchain is actually a fairly simple idea once you understand the core mechanics. This article is meant to give developers a clear, no-nonsense introduction to what blockchain actually is, how it works under the hood, and where it might fit into your own projects.

What Is a Blockchain, Really?

At its core, a blockchain is a data structure. It is a list of records, called blocks, that are linked together in a chain using cryptographic hashes. Each block contains:

A set of data (transactions, in most cases)
A timestamp
A hash of the previous block
Its own hash, calculated from its contents

Because each block includes the hash of the one before it, the blocks form a chain where every entry depends on the one that came before. If someone tries to change the data in an old block, its hash changes, which breaks the link to the next block, which breaks the link to the one after that, and so on. This is what makes blockchains tamper evident.

Here is what that chain of dependency actually looks like:

graph LR
    A["Block 0 (Genesis)<br/>Hash: 0x1a2b...<br/>Prev: none"] --> B["Block 1<br/>Hash: 0x3c4d...<br/>Prev: 0x1a2b..."]
    B --> C["Block 2<br/>Hash: 0x5e6f...<br/>Prev: 0x3c4d..."]
    C --> D["Block 3<br/>Hash: 0x7g8h...<br/>Prev: 0x5e6f..."]
    D -.->|"tamper attempt breaks all following hashes"| E["Block 4 (invalid)"]

Notice how each block only stores the hash of the block before it, not its full content. That single link is enough to make the whole chain tamper evident, since recalculating one block's data changes its hash, which no longer matches what the next block expects.

You can actually build a very basic blockchain in about 40 lines of JavaScript or Python just to see this idea in action. Here is a simplified example in JavaScript:

const crypto = require('crypto');

class Block {
  constructor(index, data, previousHash = '') {
    this.index = index;
    this.timestamp = Date.now();
    this.data = data;
    this.previousHash = previousHash;
    this.hash = this.calculateHash();
  }

  calculateHash() {
    return crypto
      .createHash('sha256')
      .update(this.index + this.timestamp + JSON.stringify(this.data) + this.previousHash)
      .digest('hex');
  }
}

class Blockchain {
  constructor() {
    this.chain = [this.createGenesisBlock()];
  }

  createGenesisBlock() {
    return new Block(0, 'Genesis Block', '0');
  }

  getLatestBlock() {
    return this.chain[this.chain.length - 1];
  }

  addBlock(data) {
    const newBlock = new Block(this.chain.length, data, this.getLatestBlock().hash);
    this.chain.push(newBlock);
  }

  isChainValid() {
    for (let i = 1; i < this.chain.length; i++) {
      const current = this.chain[i];
      const previous = this.chain[i - 1];

      if (current.hash !== current.calculateHash()) return false;
      if (current.previousHash !== previous.hash) return false;
    }
    return true;
  }
}

This tiny example already demonstrates the core property of a blockchain: data integrity through linked hashes. Everything else, consensus algorithms, peer to peer networking, smart contracts, is built on top of this basic idea.

Why Decentralization Matters

A single chain of hashed blocks on your laptop is not very useful by itself. The real value of blockchain comes from decentralization: instead of one central server holding the "true" copy of the data, thousands of independent nodes each hold their own copy and agree on what the valid chain looks like.

This is where consensus mechanisms come in. The two most common are:

Proof of Work (PoW): Nodes, often called miners, compete to solve a computational puzzle. Whoever solves it first gets to add the next block and is rewarded for it. Bitcoin popularized this approach. It is secure but energy intensive.

Proof of Stake (PoS): Instead of competing with computing power, nodes called validators lock up, or "stake," some amount of cryptocurrency as collateral. Validators are chosen to propose blocks based on their stake, and they lose part of their stake if they act dishonestly. Ethereum switched to this model in 2022 to reduce energy consumption.

There are other consensus models too, like Proof of Authority or Delegated Proof of Stake, each with different tradeoffs between speed, decentralization, and security.

Here is roughly how a new block gets added to the network under either model:

flowchart TD
    A[New transactions broadcast to network] --> B{Consensus model}
    B -->|Proof of Work| C[Miners compete to solve puzzle]
    B -->|Proof of Stake| D[Validator selected based on stake]
    C --> E[Winning miner proposes block]
    D --> F[Selected validator proposes block]
    E --> G[Other nodes verify block]
    F --> G
    G -->|Valid| H[Block added to chain, reward given]
    G -->|Invalid| I[Block rejected]

And a quick side by side comparison of the two dominant models:

Factor	Proof of Work	Proof of Stake
Resource used	Computing power	Staked cryptocurrency
Energy usage	Very high	Low
Hardware needed	Specialized mining rigs	Standard servers
Example network	Bitcoin	Ethereum (post 2022)
Attack cost	Requires majority of compute power	Requires majority of staked value
Penalty for dishonesty	Wasted computation	Stake gets slashed

Smart Contracts: Where It Gets Interesting for Developers

For most developers, the more exciting part of blockchain is not the ledger itself but smart contracts. A smart contract is just code that lives on the blockchain and runs automatically when certain conditions are met. Think of it as a backend function that nobody can quietly modify or take down, because it exists across thousands of nodes instead of a single server you control.

Ethereum is the most common platform for this, and smart contracts there are usually written in Solidity. Here is a minimal example:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract SimpleStorage {
    uint256 private storedValue;

    function set(uint256 value) public {
        storedValue = value;
    }

    function get() public view returns (uint256) {
        return storedValue;
    }
}

This looks almost like a plain class in any object oriented language. The difference is that once this contract is deployed, its logic cannot be silently changed by a company or admin. Anyone can read the contract's code and verify what it does, and every function call is recorded permanently on the chain.

This is roughly how a typical dapp talks to a deployed contract:

sequenceDiagram
    participant User
    participant Frontend as Frontend (React etc.)
    participant Wallet as Wallet (MetaMask)
    participant Contract as Smart Contract
    participant Chain as Blockchain

    User->>Frontend: Clicks "Set Value"
    Frontend->>Wallet: Request signature for transaction
    Wallet->>User: Prompt to approve
    User->>Wallet: Approves
    Wallet->>Contract: Sends signed transaction
    Contract->>Chain: Executes function, updates state
    Chain-->>Frontend: Emits confirmation/event
    Frontend-->>User: Shows updated value

This property opens the door to a lot of use cases beyond finance:

Supply chain tracking: recording the movement of goods so that every step is verifiable
Digital identity: giving people control over their own credentials without relying on a single company
Decentralized finance (DeFi): lending, borrowing, and trading without a traditional bank in the middle
Gaming and digital ownership: verifiable ownership of in-game items or digital collectibles

Should You Actually Use Blockchain?

This is the question most developers should ask before jumping in. Blockchain is not a replacement for a normal database in most situations. It is slower, more expensive to write to, and harder to update than a traditional system. It makes sense mainly when you specifically need:

Trustless coordination between parties that do not fully trust each other
Transparent, tamper resistant record keeping
Removal of a single point of control or failure

If your app just needs a fast, private database for your own users, a blockchain is almost certainly the wrong tool. But if you are building something where multiple independent parties need to agree on shared state without a middleman, it might be worth exploring.

Getting Started as a Developer

If you want to actually build with blockchain technology, here is a reasonable path:

Learn Solidity basics through interactive tools like Remix IDE, which lets you write and test contracts directly in the browser.
Set up a local development environment using Hardhat or Foundry to compile, test, and deploy contracts.
Use a testnet (like Sepolia for Ethereum) to deploy contracts without spending real money.
Connect a frontend using a library like ethers.js or viem to interact with your deployed contracts from a normal web app.
Study existing, audited contracts on platforms like OpenZeppelin to understand common patterns and security practices.

Security matters a lot more in this space than in typical web development, because a bug in a deployed smart contract can be permanent and costly. Reentrancy attacks, integer overflows, and access control mistakes have all led to real losses in production systems, so testing and audits are not optional extras here.

A Closer Look: Reentrancy Attacks

Reentrancy is one of the most well known smart contract vulnerabilities, largely because it caused the infamous DAO hack in 2016, which resulted in the loss of about 3.6 million ETH and eventually led to the Ethereum and Ethereum Classic split.

The bug happens when a contract sends funds to an external address before it updates its own internal state. If that external address is itself a malicious contract, it can call back into the original function before the first call finishes, and repeat the withdrawal multiple times before the balance is ever updated.

Here is a simplified vulnerable contract:

// VULNERABLE - do not use in production
contract VulnerableBank {
    mapping(address => uint256) public balances;

    function deposit() public payable {
        balances[msg.sender] += msg.value;
    }

    function withdraw() public {
        uint256 amount = balances[msg.sender];
        require(amount > 0, "No balance");

        // External call happens BEFORE state is updated
        (bool sent, ) = msg.sender.call{value: amount}("");
        require(sent, "Transfer failed");

        balances[msg.sender] = 0; // too late, attacker already re-entered
    }
}

An attacking contract can exploit this by putting withdrawal logic inside its own receive() function, so that every time it receives funds, it immediately calls withdraw() again, since balances[msg.sender] has not been zeroed out yet.

The fix follows a pattern called "checks, effects, interactions": update your internal state before making any external call.

// FIXED - state updated before external call
contract SafeBank {
    mapping(address => uint256) public balances;

    function deposit() public payable {
        balances[msg.sender] += msg.value;
    }

    function withdraw() public {
        uint256 amount = balances[msg.sender];
        require(amount > 0, "No balance");

        balances[msg.sender] = 0; // state updated first

        (bool sent, ) = msg.sender.call{value: amount}("");
        require(sent, "Transfer failed");
    }
}

Many teams also add OpenZeppelin's ReentrancyGuard modifier as a second layer of defense, which uses a simple lock to block any recursive call into a protected function while it is still executing:

import "@openzeppelin/contracts/security/ReentrancyGuard.sol";

contract SaferBank is ReentrancyGuard {
    mapping(address => uint256) public balances;

    function withdraw() public nonReentrant {
        uint256 amount = balances[msg.sender];
        require(amount > 0, "No balance");
        balances[msg.sender] = 0;

        (bool sent, ) = msg.sender.call{value: amount}("");
        require(sent, "Transfer failed");
    }
}

The core lesson here applies well beyond Solidity: never trust that an external call will return control to you in a clean, predictable state. Always finish updating your own data before handing control to code you do not own.

Final Thoughts

Blockchain is not magic, and it is not going to replace every database or backend system out there. But it solves a specific, real problem: how do you get a group of people or systems that do not trust each other to agree on a shared history of events, without needing a central authority to enforce it. For developers, that opens up an entirely different way of thinking about backend architecture, one where the "server" is not owned by anyone in particular but is instead maintained collectively by the network.

Whether or not you end up building on top of blockchain technology, understanding how it works is a useful addition to your toolkit as a developer, especially as more industries experiment with decentralized systems for identity, finance, and record keeping.

References

Nakamoto, S. Bitcoin: A Peer to Peer Electronic Cash System (original whitepaper)
Ethereum Whitepaper
Ethereum Developer Documentation
Solidity Documentation
OpenZeppelin Contracts (audited, reusable smart contract library)
OpenZeppelin ReentrancyGuard
Understanding the DAO Attack (background on the 2016 reentrancy hack)
Remix IDE (browser based Solidity development environment)
Hardhat Documentation
Foundry Book
Ethereum Proof of Stake FAQ

The Token Is the Least Interesting Part of Tokenization

Fri, 10 Jul 2026 17:20:20 +0000

"Most tokenization discussions stop at the token. In reality, the token is often the simplest component of the entire system."
There is a moment that happens in almost every tokenization project.

A developer deploys an ERC-721, writes a clean transfer function, and feels like the hard part is done. The token exists. Ownership is recorded on-chain. The asset has been "tokenized."

What Most Developers Think Tokenization Is

Ask a blockchain developer to describe tokenization, and you'll typically get something like this:

1. Identify a real-world asset (property, art, gold, bond)
2. Deploy an ERC-20 or ERC-721 contract
3. Mint tokens representing ownership or fractional shares
4. Let people trade on a DEX or marketplace

This isn't wrong. But it describes roughly 5% of the actual engineering problem.

Here's what that looks like in code - the part most engineers focus on:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "@openzeppelin/contracts/token/ERC721/ERC721.sol";
import "@openzeppelin/contracts/access/Ownable.sol";

contract TokenizedAsset is ERC721, Ownable {
    uint256 private _tokenIdCounter;

    struct AssetMetadata {
        string assetId;          // Off-chain reference ID
        string assetType;        // "real_estate", "art", "commodity"
        uint256 valuationUSD;    // Last known valuation (WHO UPDATES THIS?)
        address custodian;       // WHO GUARANTEES THIS EXISTS?
        bool complianceVerified; // HOW WAS THIS VERIFIED?
    }

    mapping(uint256 => AssetMetadata) public assets;

    constructor() ERC721("TokenizedAsset", "TASSET") Ownable(msg.sender) {}

    function mintToken(
        address to,
        string memory assetId,
        string memory assetType,
        uint256 valuationUSD,
        address custodian
    ) external onlyOwner returns (uint256) {
        uint256 tokenId = _tokenIdCounter++;
        _safeMint(to, tokenId);

        assets[tokenId] = AssetMetadata({
            assetId: assetId,
            assetType: assetType,
            valuationUSD: valuationUSD,
            custodian: custodian,
            complianceVerified: true  // ← Who actually verified this?
        });

        return tokenId;
    }

    function transferToken(address to, uint256 tokenId) external {
        // Token transfers instantly on-chain.
        // But does the physical asset move?    NO.
        // Is the legal title updated?          NO.
        // Is the new owner KYC verified?       NOT HERE.
        safeTransferFrom(msg.sender, to, tokenId);
    }
}

Notice the comments. Every line that touches the real world — valuation, custody, compliance — is either a placeholder or a lie waiting to surface. The contract compiles. It deploys. It works perfectly on-chain. And it answers none of the questions that matter for a real asset.

The Five Layers Nobody Talks About

A production tokenization system has to answer hard questions across five distinct layers before a single token is minted.

Layer 1 — Provenance

The question: Where did this asset come from, and how do we prove it is authentic?

For a piece of art, that means verifying the ownership chain from artist to current holder, confirming it hasn't been forged, and recording that history in a way that survives beyond any single database.

For a property, it means confirming the title is clean, no liens are outstanding, and the legal owner is exactly who they claim to be.

⚠️ Blockchain can record provenance. It cannot create it.

If you put bad provenance data on-chain, you have an immutable ledger of a lie. The blockchain cannot distinguish between a real Picasso and a forgery. That verification happens in the physical world, by human experts, before anything touches the chain.

Here is what on-chain provenance metadata should actually look like:

{
  "tokenId": "0x4a3f...",
  "asset": {
    "type": "commercial_real_estate",
    "address": "123 Main Street, New York, NY",
    "legalDescription": "Lot 14, Block 7, Manhattan District...",
    "titleDeedNumber": "NYC-2024-00847291"
  },
  "provenance": {
    "originalOwner": "0xA1B2...",
    "ownershipHistory": [
      {
        "owner": "0xA1B2...",
        "acquiredDate": "2019-03-15",
        "transferType": "purchase",
        "legalDocumentHash": "QmX7kP...ipfs"
      },
      {
        "owner": "0xC3D4...",
        "acquiredDate": "2022-08-01",
        "transferType": "tokenized_sale",
        "legalDocumentHash": "QmR2nK...ipfs"
      }
    ],
    "titleVerifiedBy": "Chicago Title Insurance Company",
    "titleVerificationDate": "2024-01-10",
    "titleVerificationDocHash": "QmT9aM...ipfs"
  },
  "custody": {
    "custodian": "Anchorage Digital Bank",
    "custodianAddress": "0xE5F6...",
    "custodyAgreementHash": "QmW3bL...ipfs",
    "insurancePolicyId": "POL-2024-18473",
    "lastAuditDate": "2024-06-01"
  }
}

This is the metadata that makes the token meaningful. Without it, you have a tradeable number with no verifiable connection to the real world.

Layer 2 — Custody

The question: Who physically controls this asset, and what legal guarantee do they provide?

A token can transfer on-chain in seconds. But if that token represents a gold bar in a vault, the gold doesn't move when the token does. Someone has to maintain the physical asset, insure it, audit it periodically, and guarantee its continued existence.

Two of the most prominent tokenized gold products — Tether Gold (XAUT) and PAX Gold (PAXG) — both rely on traditional vault custodians managing physical reserves entirely off-chain. The blockchain tracks the token. The custodian tracks the gold. These are separate systems that must stay synchronized.

What happens when they diverge? That's not a blockchain problem. That's an operational failure - and no smart contract can detect or fix it.

The real engineering challenge is building custody infrastructure that:

Maintains a real-time audit trail of physical asset status
Triggers on-chain state changes when custody events occur
Provides cryptographic proof of custody at any point in time
Has legally enforceable agreements for failure scenarios

Custody Architecture:

Physical Asset (vault / property / registry)
        ↓  [physical audit]
Regulated Custodian (licensed entity)
        ↓  [signed attestation]
Verification Service (third-party auditor)
        ↓  [cryptographic proof]
Oracle Network (Chainlink, API3, etc.)
        ↓  [on-chain update]
Smart Contract State (token metadata)
        ↓  [token represents]
Token Holder (on-chain)

Every arrow here is a trust boundary. Every trust boundary requires legal agreements, technical integrations, operational processes, and failure-mode planning. None of it is in your Solidity file.

Layer 3 — The Oracle Problem

This is where most tokenization discussions go quiet, because the answer is uncomfortable.

Blockchains are deterministic, isolated systems. They execute logic perfectly on data that already exists on-chain. They have no native ability to access external data - including the current value of the asset they tokenized.

What blockchain CAN verify:
✅ Token was transferred from address A to address B
✅ Transaction happened at block 19,847,233
✅ The transfer followed all contract rules
✅ Cryptographic signatures are valid

What blockchain CANNOT verify:
❌ The gold is still in the vault
❌ The building hasn't burned down
❌ The property appraised at $2.4M this quarter
❌ The previous owner legally held the title
❌ The shipment actually arrived at the warehouse

Every item in that second list requires an oracle — an external data provider bridging real-world information onto the chain.

But centralized oracles introduce a new problem: a single point of failure that undermines the entire value proposition of decentralization.

Here's what a naive oracle integration looks like - and why it's dangerous:

// ❌ DANGEROUS: Single centralized oracle
contract NaiveTokenizedAsset is ERC721 {
    address public trustedOracle; // Single point of failure

    function updateValuation(uint256 tokenId, uint256 newValueUSD) external {
        require(msg.sender == trustedOracle, "Only oracle can update");
        // If trustedOracle is compromised, ALL valuations can be manipulated
        assets[tokenId].valuationUSD = newValueUSD;
    }
}

Here's what a production-grade oracle integration actually requires:

// ✅ BETTER: Decentralized oracle with staleness checks
import "@chainlink/contracts/src/v0.8/interfaces/AggregatorV3Interface.sol";

contract RobustTokenizedAsset is ERC721 {
    AggregatorV3Interface internal priceFeed;
    uint256 public constant MAX_STALENESS = 3600; // 1 hour max

    function getVerifiedValuation(uint256 tokenId)
        public
        view
        returns (uint256 price, bool isStale)
    {
        (
            uint80 roundId,
            int256 answer,
            ,
            uint256 updatedAt,
            uint80 answeredInRound
        ) = priceFeed.latestRoundData();

        require(answer > 0, "Invalid price data");

        // Check data freshness - stale data is dangerous
        isStale = (block.timestamp - updatedAt) > MAX_STALENESS;

        // Check round completeness
        require(answeredInRound >= roundId, "Stale round");

        price = uint256(answer);
    }

    function isValidOracleData(
        int256 answer,
        uint256 updatedAt,
        uint80 roundId,
        uint80 answeredInRound
    ) internal view returns (bool) {
        if (answer <= 0) return false;
        if (block.timestamp - updatedAt > MAX_STALENESS) return false;
        if (answeredInRound < roundId) return false;
        return true;
    }
}

Even this is incomplete. A production system also needs:

Multiple independent oracle sources (not just Chainlink)
Circuit breakers that halt trading when oracle data is suspicious
Time-weighted average prices (TWAP) to resist manipulation
Emergency governance mechanisms to override oracle data
Off-chain monitoring that alerts when feeds go stale

BlackRock's BUIDL fund is the clearest institutional proof of this. Launched in March 2024, it grew to over $2.5 billion in assets - becoming the world's largest tokenized Treasury fund. Not because of a clever smart contract. Because BlackRock paired it with Securitize's transfer agency platform, BNY Mellon's custody arrangements, and institutional-grade oracle integrations. The token was the output. The infrastructure was the actual product.

Layer 4 — Compliance Middleware

The question: Who is legally allowed to hold this token, and in which jurisdictions?

This is where many tokenization projects quietly fail. A token representing fractional real estate in the United States may be a security under SEC regulations. That means:

KYC/AML verification for every holder
Accredited investor checks
Transfer restrictions (you cannot freely trade a security token like an ERC-20)
Ongoing reporting obligations
Geographic restrictions (certain jurisdictions cannot participate)

Here's what compliant token transfer logic actually looks like:

// ERC-3643: Security Token Standard with built-in compliance
contract CompliantSecurityToken is ERC20 {
    IIdentityRegistry public identityRegistry;
    ICompliance public compliance;

    mapping(address => bool) public frozen;

    modifier onlyVerifiedInvestor(address investor) {
        require(
            identityRegistry.isVerified(investor),
            "Investor not KYC verified"
        );
        require(!frozen[investor], "Investor account is frozen");
        _;
    }

    function transfer(address to, uint256 amount)
        public
        override
        onlyVerifiedInvestor(msg.sender)
        onlyVerifiedInvestor(to)
        returns (bool)
    {
        // Off-chain compliance check BEFORE on-chain transfer
        require(
            compliance.canTransfer(msg.sender, to, amount),
            "Transfer not compliant"
        );
        return super.transfer(to, amount);
    }

    // Required for: court orders, regulatory seizure, account recovery
    // This is legal compulsion — not a bug, a legal requirement
    function forcedTransfer(address from, address to, uint256 amount)
        external onlyOwner
    {
        _transfer(from, to, amount);
    }

    // Required for: sanctions compliance, court orders
    function freeze(address account) external onlyOwner {
        frozen[account] = true;
    }
}

Notice forcedTransfer and freeze. These functions exist because real-world compliance sometimes requires overriding user ownership - for court orders, sanctions enforcement, and regulatory seizure. Every tokenization platform operating at institutional scale has these functions. They are not bugs. They are legal requirements.

Layer 5 — Legal Enforceability

This is the quietest failure mode in tokenization - and the most dangerous.

In most jurisdictions today, courts do not recognize on-chain token transfers as legally binding property transfers. If there's a dispute over a tokenized property, courts will likely defer to the traditional title deed, not the NFT.

Progress is happening:

Switzerland's DLT Act (2021) explicitly recognizes tokenized securities as legal securities
The EU's DLT Pilot Regime (March 2023) allows approved market infrastructure to experiment with tokenized instruments
Dubai's VARA created a specific legal category for tokenized real-world assets

But in the United States, most of Asia, and much of the emerging world, the legal infrastructure has not caught up to the technology.

This means many tokenization projects exist in legal limbo: the on-chain transfer is technically valid, but the off-chain legal claim may not reflect it. The blockchain says you own something. The legal system may not agree.

The Real Architecture

Here is what a production tokenization system actually looks like:

┌──────────────────────────────────────────────────────────────┐
│                     REAL WORLD LAYER                         │
│   Physical Asset → Legal Structuring (SPV / Trust)           │
│   Custodian      → Title Registry / Legal Docs               │
└─────────────────────────┬────────────────────────────────────┘
                          │ custody link
┌─────────────────────────▼────────────────────────────────────┐
│                   VERIFICATION LAYER                         │
│   Third-Party Auditors  → Provenance Verification            │
│   KYC/AML Providers     → Investor Qualification             │
│   Appraisers            → Valuation Updates                  │
│   Legal Counsel         → Regulatory Compliance              │
└─────────────────────────┬────────────────────────────────────┘
                          │ signed attestation
┌─────────────────────────▼────────────────────────────────────┐
│                      ORACLE LAYER                            │
│   Price Feeds   → Asset Valuations (Chainlink, API3)         │
│   Event Feeds   → Custody Changes, Legal Transfers           │
│   Audit Feeds   → Physical Verification Results              │
│   Compliance    → KYC Status, Sanctions Checks               │
└─────────────────────────┬────────────────────────────────────┘
                          │ on-chain data
┌─────────────────────────▼────────────────────────────────────┐
│                  SMART CONTRACT LAYER                        │
│   Token Contract (ERC-3643 or similar)                       │
│   ├── Transfer Restrictions (compliance enforcement)         │
│   ├── Forced Transfer / Freeze (legal compulsion)            │
│   ├── Oracle Integration (valuation updates)                 │
│   ├── Identity Registry (KYC verification)                   │
│   └── Ownership History (provenance recording)               │
└─────────────────────────┬────────────────────────────────────┘
                          │ mints
                    ┌─────▼─────┐
                    │   TOKEN   │  ← what everyone focuses on
                    └───────────┘

The token sits at the bottom of this entire stack. It is the visible output of everything above it. If any layer above it fails, the token becomes meaningless - not because the contract broke, but because the real-world connection it represents no longer holds.

A Concrete Walk-Through: Tokenized Commercial Real Estate

Suppose you want to tokenize a commercial office building and offer fractional ownership.

What most engineers plan for:

Week 1 → Write ERC-20 fractional ownership contract
Week 2 → Deploy to mainnet, set up frontend
Week 3 → Launch

What actually needs to happen:

Month 1–3: Legal Structuring
├── Create Special Purpose Vehicle (SPV) to hold the property
├── Engage real estate attorneys (multiple jurisdictions)
├── Prepare Private Placement Memorandum (PPM)
├── Register securities offering (or apply for exemption)
└── Establish investor eligibility criteria

Month 2–4: Custodial Setup
├── Engage regulated custodian for the SPV
├── Draft custody agreement with failure-mode provisions
├── Set up insurance for both physical asset and digital rep
├── Establish audit schedule (physical + financial)
└── Create legal links between custodian and token contract

Month 3–5: Technical Infrastructure
├── Deploy compliance middleware (KYC/AML integrations)
├── Integrate identity registry (e.g., Fractal, Onfido)
├── Set up oracle infrastructure for valuation feeds
├── Deploy ERC-3643 or similar security token standard
├── Write and professionally audit smart contracts
├── Set up multi-sig governance for admin functions
└── Build off-chain monitoring for oracle staleness

Month 4–6: Provenance & Legal Links
├── Record title deed + ownership history as IPFS-linked metadata
├── Execute legal agreements linking tokens to SPV equity rights
├── Set up title update pipeline
├── Establish dispute resolution procedures
└── Coordinate with local land registry

Month 6: Token Mint
└── Mint tokens. Write ~200 lines of Solidity. ← you are here

Ongoing (forever):
├── Quarterly valuations         → oracle updates
├── Rental income distribution   → token holder payments
├── Regulatory reporting         → investor disclosures
├── Compliance monitoring        → sanctions screening
├── Custodian audits             → on-chain attestations
└── Legal maintenance            → filings, insurance renewals

The Solidity work is roughly 5% of this project by time and cost. The other 95% is legal, operational, compliance, and infrastructure work that most blockchain tutorials never mention.

What the Numbers Tell Us

This is not theoretical. The market is large enough to make it urgent.

Metric	Value
RWA tokenization market (mid-2025)	$23 billion
Growth rate (H1 2025)	260%
Tokenized U.S. Treasuries (late 2025)	$9+ billion
BlackRock BUIDL AUM	$2.5 billion
Total RWA protocols TVL (Oct 2025)	$18 billion
Projected RWA market by 2030 (Citi)	$4 trillion

BlackRock, Franklin Templeton, JPMorgan, BNY Mellon — all deploying real capital. Every one of them had to solve the off-chain problem before the on-chain part could work.

JPMorgan's Tokenized Collateral Network (TCN) moved from pilot to live production. Figure Technologies processed over $13 billion in HELOC originations on blockchain. The technical challenge was never the token standard. It was integration with existing legal, custodial, and regulatory infrastructure.

Questions to Ask Before Writing a Single Line of Solidity

These are the questions that determine whether your project works in production:

On custody:

Who is the regulated custodian for the physical asset?
What legal agreements govern token ownership vs. physical control?
What happens if the custodian becomes insolvent or loses the asset?

On provenance:

What documentation proves the asset's origin and ownership history?
Who verified it, and are they trusted in the relevant jurisdiction?
How is provenance updated when real-world events occur?

On valuation:

Who provides asset valuations, and how frequently?
Which oracle solution bridges this to on-chain state?
What happens during oracle downtime or data manipulation?

On compliance:

Is this token a security? (Assume yes if in doubt, especially in the US)
What KYC/AML checks are required for every holder?
How do you enforce transfer restrictions?
What happens when a holder appears on a sanctions list mid-holding?

On legal enforceability:

Does your jurisdiction recognize on-chain transfers as legally binding?
Which instrument governs a dispute - the token or the traditional record?
What is your dispute resolution mechanism?

On operations:

Which real-world events require on-chain state updates?
Who monitors for these events and triggers the updates?
What is your governance mechanism for emergencies?

If you cannot answer these before writing Solidity, the token you create will be technically correct and operationally broken.

The Honest Summary

Blockchain is genuinely excellent at a narrow set of things: recording state transitions with cryptographic finality, executing logic without trusted intermediaries, and maintaining a tamper-resistant history of on-chain events.

Tokenization of real-world assets requires all of that - plus everything blockchain fundamentally cannot do on its own.

What blockchain provides:            What tokenization requires:
─────────────────────────            ───────────────────────────
✅ Immutable transaction history  →  + Legal framework that recognizes it
✅ Cryptographic ownership proof  →  + Physical custody backing it
✅ Programmable transfer rules    →  + Off-chain compliance enforcement
✅ On-chain state machine         →  + Oracle infrastructure feeding it
✅ Transparent audit trail        →  + Human verification of what's audited

The real engineering challenge is building the bridge between these two columns. That bridge is made of legal agreements, custodial arrangements, oracle infrastructure, compliance middleware, and operational processes.

The token sits at the end of the bridge. It's where the system becomes visible to users. But the bridge itself is the product.

Tokenization is not primarily a smart contract problem. It is a provenance, custody, verification, and trust problem. The token is simply the final representation of a much larger operational reality.

The engineers who understand both columns - who are as comfortable reasoning about custodial failure modes and oracle staleness as they are writing Solidity - are the ones who will build tokenization infrastructure that actually works at scale.

REAL-WORLD ASSETS TOKENIZATION : THE $10 TRILLION EVOLUTION

Fri, 10 Jul 2026 17:19:10 +0000

Soumabha Mahapatra
soumabha015@gmail.com

ABSTRACT:

Real-world asset (RWA) tokenization refers to the process of representing physical and financial assets—such as government bonds, real estate, commodities, and invoices—as cryptographically secured digital tokens on the blockchain. In 2025, the rapid digitization of global money and the rise of institutional blockchain adoption make RWA tokenization more important than ever. Traditional financial systems face challenges such as slow settlement, limited liquidity and limited access, whereas tokenized assets enable fractional ownership, real-time transferability and transparent auditability.

With leading institutions and regulators actively exploring on-chain asset structures, the movement of real-world assets to blockchain is accelerating. According to the research, RWA tokenization can unlock the $10 trillion digital asset economy by 2030, marking one of the most significant technological changes in our modern finance. As the boundaries between traditional finance (TradFi) and blockchain-based systems shrink, tokenized assets are emerging as the foundation of global digital markets.

INTRODUCTION:

Digitization of assets has become a natural progression in today's financial landscape. As markets become larger then the transactions move online so that the limitations of traditional finance have become increasingly visible. The systems built around manual verification and multiple middleman and slow settlement cycles are no longer suitable for an economy which demands speed, transparency and global reach.

Blockchain technology has emerged as a strong candidate to address this challenge, providing a more secure, more programmable and more verifiable way to represent value. Within this framework, real-world asset (RWA) tokenization refers to the simple concept of turning physical or financial assets into digital tokens that can move across the blockchain with the same trust as the original asset.

This shift is important because tokenized assets open access to markets that were once difficult to enter, create a more transparent investment environment, and enable investor participation across borders. With global institutions now exploring large-scale tokenization models, analysts estimate that RWAs could form the basis of a multi-trillion-dollar digital asset market by 2030. As a result, RWA tokenization stands at the forefront of the next big evolution in financial technology.

LITERATURE REVIEW:

The journey of Blockchain had started with Bitcoin, which introduced a more secure way to transfer digital value without intermediaries. Thereafter by adding the smart contracts in Ethereum, so that more complex financial operations can be done in chains. This shift has opened the door to new use cases, including the tokenization of real-world assets.

Early attempts at asset tokenization began with simple models – pilot programs for tokenized gold, small real estate projects, and commodities. Although these experiments were limited, they showed that physical assets could be digitally represented and traded more efficiently.

In recent years, several platforms have taken the lead. Nowadays MakerDAO uses real-world collateral like Treasury bills in its system. BlackRock has started issuing tokenized funds on public blockchains, and Ondo Finance is giving global investors access to tokenized US Treasuries. These initiatives show growing confidence from both the crypto industry as well as traditional finance.

However, the researchers still noted some gaps. Liquidity is uneven, trust depends on off-chain verification and regulatory clarity is still developing. These challenges/gap highlight the need for robust frameworks as the RWA ecosystem expands.

WORKING PRINCIPLE OF RWA TOKENIZATION:

a) Selection of Resource and its Verification:

  The process of tokenization begins with choosing the asset to represent–it may include real estate, commodities, government bonds or financial instruments. Before an asset can be placed on-chain, it must be legal and verified by the owner. This involves reviewing the documentation, verifying the authenticity and ensuring that assets can be legally tokenized. Standard KYC(Know your Customer) and AML(Anti-Money Laundering) checks are also conducted to verify the issuer's identity and compliance with regulatory requirements.

b) Token Creation:

 When the asset is verified, then a digital token is created on the blockchain platform. These tokens generally follow generally adopted standards like ERC-20 for basic fungible tokens and ERC-3643 for regulated tokenized securities. Smart contracts draw the rules of the token – how it can be transferred, who can hold it, and any restrictions related to the compliance. This programmable layer assures that the token behaves consistently and reflects the real asset it represents.

c) Token Distribution and Trading:

  After creation, tokens are distributed among investors. The main benefit of tokenization is fractional ownership, where high-value assets can be broken into smaller, more accessible units. Then these tokens can be traded on decentralized markets, where a liquidity pool remains continuous buying and selling. In on-chain trading reduces settlement time and maintains transparency.

d)Custody and Compliance Layer:

 These physical assets underlying the token must be securely stored by a fiduciary custodian, which may include a regulated financial licensed vault provider. Regular audits can assure that on-chain tokens are always backed by off-chain assets. The compliance framework can dictate how tokens are issued, transferred and redeemed depending on the administration. This layer bridges traditional legal systems with blockchain-based markets, by ensuring trust in tokenized assets.

APPLICATIONS OF RWA TOKENIZATION:

At that current date, RWA tokenization is not just a theoretical idea – many industries have already started adopting it in practical and measurable ways. There is some most active real-world use cases:

a) Real Estate Tokenization:
One of the earliest and strongest use cases. Large properties that were once accessible only to big investors are now being divided into digital tokens. People can invest in premium commercial spaces, rental properties, or even luxury real estate by simply buying a piece of the tokenized asset.

b) Jurisdiction Bonds:
Many countries and financial institutions are experimenting with issuing bonds directly on the blockchain. Tokenized government bonds reduce the use of paperwork, speed up the settlement, and create a more open participation model.

c) Gold & Commodity Tokenization:
Gold-backed tokens have gained serious traction. A digital token represents a specific quantity of gold stored in a regulated vault. The same model is being extended to silver, oil, and other commodities.

d) Carbon Credits:
Tokenized carbon credits are helping companies measure and trade their emission allowances in a more transparent and traceable manner. It removes a lot of the fraud and inefficiency associated with the traditional carbon market.

e) Invoice Financing:
Businesses can tokenize their unpaid bills and quickly raise funds by selling tokens backed by those bills. This is particularly helpful for small and mid-level companies that face the cash-flow issues.

f) Private Credit Markets:
Tokenization has opened the door for global investors to participate in private lending opportunities that were previously restricted to large institutions.

g) Art, Collectibles & Luxury Goods:
Tokenization has given museums, creators, and collectors a way to fractionalize ownership of rare paintings, old and vintage collectibles, and high-end luxury goods, making those accessible to more people.

BENEFITS:

The rise of RWA tokenization is happening for a reason – it genuinely solves the problems that have existed in finance for decades.

a) Fractional Ownership:
One of the most powerful advantages. Even if a real estate asset costs crores, individuals can buy a small fraction of it without needing the full capital.

b) 24/7 Global Markets:
Unlike traditional markets that operate within strict time windows, tokenized assets can be traded any time, anywhere.

c) Higher Liquidity:
Assets that were historically considered “illiquid” (real estate, art, bonds) can now be traded like digital tokens, reducing the time buyers and sellers spend waiting.

d) Lower Transaction Costs:
The elimination of middlemen reduces processing fees, handling charges, verification expenses, and settlement delays.

e) Transparency & Security:
Blockchain makes the ownership records immutable. Every transaction is recorded , which drastically reduces fraud and disputes.

f) Reduced Intermediaries:
Tokenization cuts out layers of brokers, agents, paperwork handlers, and settlement authorities, creating a leaner financial system.

CHALLENGES:

Despite the excitement, RWA tokenization has several complexities. It is still a young field and naturally comes with hurdles.

a) Regulatory Uncertainty:
Governments across the world are still figuring out how to regulate tokenized versions of physical assets. Rules differ from region to region, which slows expansion.

b) Custody & Ownership Rights:
Token ownership is clear, but the legal link between the token and physical asset still varies in different jurisdictions.

c) Price Volatility:
Even though RWAs represent stable assets, the tokens themselves may fluctuate based on market demand.

d) Low Mainstream Awareness:
Many investors still don’t understand how tokenization works. Education and trust-building need time.

e) Integration with Banks:
Traditional financial institutions have been slow to adopt modern blockchain systems due to their legacy infrastructure.

f) Cybersecurity Risks:
Even though blockchain is secure, the platforms that store or trade these tokens can still be vulnerable if not designed properly.

FUTURE SCOPE:

What’s ahead for RWA tokenization is far bigger than where it stands today. A few developments that are already shaping the next phase include:

a) Tokenized Government Assets:
Countries may begin placing everything from land registries to sovereign funds on blockchain for better transparency.

b) Integration with CBDCs:
Once Central Bank Digital Currencies go mainstream, tokenized RWAs will seamlessly flow across digital financial rails.

c) Blockchain-Powered Stock Exchanges:
The future version of stock markets may run directly on blockchain, enabling instant settlement and global access.

d) AI + Blockchain Asset Verification:
AI models can independently verify documents, ownership, valuations, and authenticity, reducing fraud dramatically.

d) Global Liquidity Pools Worth $10 Trillion:
Many experts estimate that tokenization might attract trillions of dollars in new liquidity because the market becomes borderless.

e) Role of Layer-2 Chains:
Layer-2 networks will help scale RWA platforms by making transactions faster and significantly cheaper.

CONCLUSION:

Real-World Asset Tokenization (RWA) is reshaping the basis of global finance. What started as an experimental concept has now turned into a trillion-dollar opportunity which blends the physical economy with digital efficiency. For the investors, it opens doors to assets that were once out of reach. For developers, it creates a whole new ecosystem to build on. And for students and future professionals, it is the kind of shift that defines an entire generation of financial technology. The transformation has already started – and those who understand it early will be far ahead in tomorrow’s digital economy.

REFERENCES:

[1] MakerDAO, “Real-World Asset Framework,” 2023. [Online]. Available: https://ethereum.org/developers/docs/
[2] BlackRock, “Tokenized Asset Funds and Digital Market Infrastructure,” 2024. [Online]. Available: https://www.blackrock.com
[3] Ethereum Foundation, “Ethereum Smart Contract Documentation,” 2023. [Online]. Available: https://ethereum.org/en/developers/docs
[4] World Economic Forum, “The Future of Asset Tokenization,” 2023. [Online]. Available: https://www.weforum.org/reports
[5] S. Nakamoto, “Bitcoin: A Peer-to-Peer Electronic Cash System,” 2008. [Online]. Available: https://bitcoin.org/bitcoin.pdf
[6] Reserve Bank of India (RBI), “Reports on Digital Assets, Distributed Ledger Technology and Financial Innovation,” 2023. [Online]. Available: https://rbi.org.in
[7] Ondo Finance, “Tokenized Securities and On-Chain Treasuries,” 2024. [Online]. Available: https://ondo.finance
[8] International Monetary Fund (IMF), “Digitalization of Money and Tokenization Trends,” 2024. [Online]. Available: https://imf.org
[9] Chainlink Labs, “Tokenized Asset Infrastructure: Technical Overview,” 2024. [Online]. Available: https://chain.link
[10] BIS Innovation Hub, “Exploring Tokenized Markets and Programmable Finance,” 2023. [Online]. Available: https://bis.org

I would genuinely appreciate your thoughts, suggestions, and feedback on this work. Looking forward to learning from the community and improving further.

Demystifying the Bitcoin Lightning Network: A Technical Deep Dive from a Bootcamp Hackathon

Sat, 04 Jul 2026 06:34:22 +0000

Last week, I had the incredible opportunity to transition from a Bitcoin beginner to building a Layer 2 solution in less than 12 hours at the Kisumu Lightning Network Bootcamp hosted by Zone01 Kisumu.

While most articles explain the Lightning Network (LN) abstractly as "fast and cheap," I will break down the technical mechanisms;the actual cryptographic primitives and scripts that make trustless, off-chain Bitcoin transactions possible today. All from what I learnt from the 5-day bootcamp.

The Core Primitive: Bidirectional Payment Channels

At its foundation, the Lightning Network is a peer-to-peer network of bidirectional payment channels. It avoids blockchain congestion by shifting transactions off-chain, using the underlying base layer strictly as a final settlement layer.

A channel is established when two nodes execute an on-chain Funding Transaction.

The Funding State
2-of-2 Multi-Signature UTXO: Both participants lock up an agreed amount of Bitcoin into a multisig address. This requires signatures from both parties to move funds.
Commitment Transactions**: Before broadcasting the funding transaction to the blockchain, both parties sign an asymmetric, unbroadcasted
Commitment Transaction. This acts as a
balance sheet of the current channel state.

From a total beginner to atleast an intermediate knowledgeable person in regards to bitcoin,this was a great learning experience for me and I'm so grateful to the organizers and facilitators of this intensive bootcamp.

Cloudflare just dropped the x402 Protocol & Monetization Gateway. Is this actually practical for ind

Thu, 02 Jul 2026 17:51:56 +0000

Hey everyone,

I’m sure most of us here are tracking the nightmare of automated bot traffic. Cloudflare recently stated that bots now consume nearly 56% to 57.5% of global web bandwidth. As webmasters, we’ve been stuck in a lose-lose situation: either set up aggressive WAF rules to block everything (and get completely wiped out of AI Search discovery like GEO/AIO), or just let LLM crawlers scrape our content for free.

But on July 1st, Cloudflare quietly opened the waitlist for something that might change the web economy forever: Cloudflare Monetization Gateway and the x402 protocol.

Instead of a hard block or a traditional human paywall, they are basically weaponizing the old HTTP 402 Payment Required status code. The idea is to force autonomous AI agents to execute automated, millisecond micropayments right at the edge layer before they can fetch clean markdown/data.

I just secured my spot on the Early Access Waitlist today because I’m genuinely curious about how this will shift the landscape. (I'm planning to look into integrating x402 audit signals into our extension over at AgentShare.dev once I can get my hands on the actual implementation).

But here is what I want to throw out to the Legion community for debate:

How will LLM compliance work? Do you think big players like OpenAI or Anthropic will actually respect the x402 challenge, or will they just route around sites that implement it?
The Micropayment Infrastructure: Gating content at the network edge via HTTP 402 sounds beautiful in theory, but how seamless will the wallet integration be for smaller indie sites?

Has anyone else applied for the waitlist yet? Let’s talk architecture and viability below. Would love to hear your thoughts on whether this is a true paradigm shift or just infrastructure hype.

ERC20 Edge Cases Every Smart Contract Engineer Should Know

Wed, 24 Jun 2026 06:50:00 +0000

Your protocol launches. Everything passes the test suite with 100% coverage. Your audits are clean.

Then, an unexpected token enters your liquidity pool. The accounting drifts by a fraction of a percent. Within hours, the discrepancy compounds. Users attempt to withdraw, and the transactions revert. The vault is permanently bricked, and funds are stuck.

What went wrong?

Most ERC20 exploits are not actually bugs in the protocol's core logic. They happen because protocol engineers assume every token behaves exactly like a vanilla OpenZeppelin implementation.

The ERC20 standard is an interface, not a guarantee. It defines function signatures (transfer, approve, balanceOf), but it dictates absolutely nothing about the internal execution logic behind those signatures.

If your protocol integrates arbitrary tokens, your threat model immediately includes the behavior of those tokens. A single flawed assumption about how a token transfers, reverts, or accounts for balances can lead to systemic insolvency.

Let's look under the hood of the most common ERC20 edge cases that break production systems, and how to engineer defensive architectures to mitigate them.

The Four Assumptions That Break Integrations

Before we look at specific edge cases, it helps to build a mental model of why these failures happen. Almost every ERC20 integration bug stems from one of four flawed assumptions:

Amount Assumptions: Believing the amount you request to transfer is the exact amount that will arrive.
Execution Assumptions: Assuming token transfers are passive state updates, rather than active execution environments.
Permission Assumptions: Believing that having a sufficient balance and allowance guarantees a transfer will succeed.
Accounting Assumptions: Hardcoding precision logic or assuming token behavior is immutable.

Let's break down how these assumptions fail in production.

Edge Case #1: Fee-on-Transfer & Rebasing Tokens

The assumption
If I call token.transferFrom(alice, vault, 100), the vault's balance increases by exactly 100.

What actually happens
Tokens can deduct a tax on transfer (e.g., a 5% protocol fee) or continuously alter user balances algorithmically (rebasing).

Example failure
A user deposits 100 fee-on-transfer tokens. The token takes a 5% fee.

User calls deposit(100)
👇
Token executes transfer, deducts 5% tax
👇
Vault receives 95 tokens

❌ Vault internally mints 100 shares based on 'amount' parameter
✅ Vault should mint 95 shares based on actual received funds

Because the vault blindly minted 100 shares, the user can immediately withdraw 100 tokens, successfully stealing 5 tokens from previous depositors. The accounting drifts, and the last users to withdraw will be left with nothing.

Mitigation
Never trust the amount parameter for internal accounting. Always measure the actual balance delta before and after the transfer.

uint256 balanceBefore = token.balanceOf(address(this));
token.safeTransferFrom(msg.sender, address(this), amount);
uint256 balanceReceived = token.balanceOf(address(this)) - balanceBefore;

// Use balanceReceived for all subsequent logic, never 'amount'
_mintShares(msg.sender, balanceReceived);

Takeaway: Balance-delta accounting fixes this assumption. Unfortunately, the next edge case breaks protocols even when the balances match perfectly.

Edge Case #2: Tokens with Callbacks (ERC-777 & Transfer Hooks)

The assumption
Calling transfer only updates storage balances and returns execution flow directly back to my contract.

What actually happens
Standards like ERC-777, or custom tokens with transfer hooks, actively hand execution control back to the sender or receiver via external calls during the transfer process.

Example failure
Your protocol updates the user's internal debt balance after pushing tokens to them.

User calls withdraw()
👇
Protocol calls token.transfer(user)
👇
Token calls back to User's smart contract
👇
User's contract calls withdraw() AGAIN (before protocol debt is updated)

This is a classic reentrancy attack, facilitated entirely by the token's internal hook.

Why This Surprises Engineers: We naturally view tokens as passive data ledgers. Callbacks turn tokens into active, hostile execution environments.

Mitigation
Follow the Checks-Effects-Interactions (CEI) pattern religiously. Update all internal state before interacting with external tokens. Additionally, apply OpenZeppelin's ReentrancyGuard (nonReentrant modifier) to any function interacting with external tokens.

Takeaway: Reentrancy guards handle unexpected execution paths. But what happens when a token quietly fails without telling you?

Edge Case #3: Returning false vs. Reverting

The assumption
If a token transfer fails, the transaction will revert.

What actually happens
Some older tokens (like ZRX) do not revert on failure. Instead, they gracefully return a false boolean.

Example failure
Your protocol calls token.transfer(user, amount) and doesn't check the return value. The transfer fails (returns false), but your code continues executing. The protocol marks the user's debt as paid, even though no tokens actually moved.

Mitigation
Never use bare transfer or transferFrom calls. Wrap them in logic that asserts the boolean return value is true.

OpenZeppelin / best practice
Always use OpenZeppelin's SafeERC20 library (safeTransfer, safeTransferFrom). It normalizes behavior by forcing a silent false failure to revert.

Takeaway: SafeERC20 forces silent failures to revert. But occasionally, you actually want certain transfers to bypass reverts.

Edge Case #4: Zero Address & Zero Amount Reverts

The assumption
Transferring an amount of 0 is a harmless No-Op (no operation) that costs a little gas but executes successfully.

What actually happens
Different token implementations handle zeros differently. Some explicitly revert if the transferred amount is 0, or if the target is the zero address.

Imagine this scenario:
Your protocol distributes daily yields in a batch loop to 100 users. One user earned 0 yield today. The loop attempts to transfer(user, 0). The token reverts, crashing the entire transaction and preventing the other 99 users from receiving their yields.

Mitigation
Standardize behavior by wrapping transfers in a simple defensive check to bypass zero-amount logic.

if (amount > 0) {
    token.safeTransfer(user, amount);
}

Takeaway: Standardizing behavior protects your loops. But what if the token completely breaks the standard interface?

Edge Case #5: Missing Return Values (The USDT Problem)

The assumption
All ERC20 tokens return a boolean, as dictated by the standard interface.

Production Reality: Tether (USDT) on Ethereum Mainnet is non-standard. Its transfer, transferFrom, and approve functions do not return a boolean; they return void.

Example failure
If your contract compiles against the standard IERC20 interface, the EVM expects boolean return data to decode.

Standard: function transfer(...) returns (bool)
USDT:     function transfer(...) [returns void]
EVM:      "Wait, where is the boolean to decode? Revert."

Your protocol completely fails to integrate with the largest stablecoin on the market.

Mitigation
OpenZeppelin's SafeERC20 handles this under the hood. By using safeTransfer, you safely abstract away the missing return value issue at the assembly level.

Takeaway: SafeERC20 handles legacy interfaces. But interface compatibility won't save you from centralized control.

Edge Case #6: Blacklisted Addresses

The assumption
If an address has a sufficient balance and allowance, a transfer will always succeed.

What actually happens
Fiat-backed stablecoins like USDC and USDT maintain centralized blacklists. If an address is blacklisted, all transfers involving that address will revert.

Example failure
Your protocol liquidates undercollateralized debt. To close a position, it must send leftover USDC collateral to the user. The user gets blacklisted by Circle. The liquidation transaction reverts when attempting to send the leftover funds, preventing the protocol from clearing bad debt. The systemic risk cascades, threatening protocol solvency.

Design Rule: Pull-over-Push
Decouple protocol logic from token transfers. Instead of pushing funds to a user during a critical state change, record their balance internally and force them to pull (claim) it in a separate transaction.

Takeaway: Decoupling logic prevents centralized blacklists from freezing your protocol. Speaking of centralized quirks, let's look at approvals.

Edge Case #7: Non-Zero Approval Restrictions

The assumption
You can update an allowance from any number to any other number using approve(spender, newAmount).

What actually happens
To prevent approval front-running (where an attacker exploits an old allowance while a new one is pending), tokens like USDT require that allowances be reset to 0 before being updated to a new non-zero value.

Example failure
A router contract tries to update its USDT approval to a DEX from 50 to 100. It calls approve(dex, 100). Because the current allowance is 50 (non-zero), USDT reverts the transaction.

Mitigation
You must approve 0 before approving the target amount. In OpenZeppelin v5+, safeApprove was removed. Use forceApprove(), which natively handles the 0 reset under the hood.

Takeaway: Approval races are tricky, but at least the token is always the token... right?

Edge Case #8: Multiple Addresses for the Same Token

Mental Model: Think of an ERC20 token as a ledger. Usually, there is one door to access that ledger. But sometimes, developers build multiple doors (proxies, wrappers, aliases) that lead to the exact same ledger.

What actually happens
Some tokens (like older TrueUSD implementations) use multiple entry point addresses that point to the same underlying state.

Example failure
A lending protocol relies on the token's contract address as a unique identifier for price feeds. An attacker uses a wrapper contract that proxies to the same underlying token. The protocol reads the proxy as an unverified token, misprices the collateral, and allows the attacker to borrow against manipulated values.

Mitigation
Identify tokens strictly by exact, whitelisted addresses. Never rely blindly on msg.sender to dynamically determine asset identity.

Takeaway: Identity is fluid. And worse, token logic is mutable.

Edge Case #9: Upgradeable Tokens

The assumption
The token behavior I test today will be the token behavior in production tomorrow.

What actually happens
Tokens like USDC are upgradeable behind a proxy. The controlling entity can push an upgrade at any time, adding transfer fees, callbacks, or entirely new operational restrictions.

Example failure
You build a protocol assuming USDC has no fee-on-transfer. Circle upgrades USDC to enforce a 1 basis point transaction fee. Your static accounting breaks, and protocol funds become permanently locked because the math no longer balances.

Mitigation
Code defensively. Use balance-delta accounting (Edge Case #1) even if the token currently doesn't require it. Build pause functionality into your own protocol so you can halt operations if an upgrade breaks your integration.

Takeaway: You can't control token upgrades, but you can control how you calculate value. Which brings us to spot balances.

Edge Case #10: Flash-Mintable Tokens

The assumption
Massive token balances represent real, scarce capital.

What actually happens
Some tokens, like DAI, natively support flash-minting. A user can instantly mint millions of tokens in a single transaction, provided they are burned (with a fee) by the end of execution.

Example failure
Your protocol calculates governance voting power based on spot balances within a liquidity pool. An attacker flash-mints 100 million DAI, executes a massive governance manipulation, and repays the DAI in the same block.

Mitigation
Never rely on spot balances for price discovery or voting power. Use Time-Weighted Average Price (TWAP) oracles and historical checkpoints.

Takeaway: Spot balances lie. And sometimes, tokens lie about how much they transferred, too.

Edge Case #11: Transferring Less Than Requested

The assumption
If I request to transfer type(uint256).max, the token will either transfer that exact enormous amount or revert.

What actually happens
Some obscure tokens treat an amount parameter of type(uint256).max as a custom flag meaning "transfer all of the user's available balance."

Example failure
A protocol requests a uint256.max sweep. The token successfully transfers the user's actual balance of 50 tokens. The protocol incorrectly records that type(uint256).max tokens were received, creating massive artificial inflation.

Mitigation
Once again, balance-delta accounting saves the day. Never assume the requested amount is the executed amount.

Edge Case #12: High-Decimal Tokens

The assumption
Tokens either have 18 decimals (like ETH) or 6 decimals (like USDC).

What actually happens
Tokens like YAMv2 use 24 decimals.

Example failure
Your protocol multiplies a token balance by a high-precision constant before dividing it. Because the token already has 24 decimals, the multiplication exceeds type(uint256).max and triggers an unexpected math overflow, bricking the transaction.

Mitigation
Always dynamically read the decimals() function and normalize balances to a standard precision internally before performing complex math.

Bonus Edge Cases

Edge Case #13. Pausable Tokens:
Tokens can be globally paused by their admins. Ensure your system degrades gracefully and uses Pull-over-Push accounting so a globally paused token doesn't brick your entire transaction loop.

Edge Case #14. Large Approval/Transfer Reverts:
Tokens like UNI and COMP use uint96 for their internal accounting limits. Attempting to approve or transfer uint256.max will unexpectedly revert. Always approve exact required amounts.

Defensive ERC20 Integration Checklist

Before deploying any contract that touches external ERC20 tokens, verify your architecture against these rules:

Are you using SafeERC20? Never use bare .transfer() or .transferFrom().
Are you measuring balance deltas? Never assume amount sent == amount received.
Are you safe from reentrancy? Assume every token transfer is an external callback.
Are you using Pull-over-Push? Ensure a failing transfer only affects the specific user, not the broader system loop.
Have you normalized decimals? Do not assume 6 or 18 decimals.
Do you rely on spot balances? Ensure oracles and voting mechanisms cannot be manipulated via flash-mints.

Closing Thoughts

Smart contract engineering is deeply unforgiving because you are not just building software; you are building immutable financial infrastructure.

When you integrate an external token, you do not just integrate an asset. You inherit its execution models, its upgrade paths, its governance assumptions, and its operational constraints. If the token's logic changes, or if it behaves in a way you didn't model for, your protocol pays the price.

Treat every external token as fundamentally hostile. Rely on pure math, stateful invariants, and defensive accounting.

Reliable systems emerge from reducing assumptions. Let's build something we can trust.

What edge cases have caused problems in your own deployments? Let's chat about it in the comments below. Follow for more deep dives into smart contract architecture and onchain security.

The Contract Is Not the Story. The Process Behind It Is.

Tue, 23 Jun 2026 12:58:39 +0000

How behavioral intent detection changes the security calculus — in Web3 and beyond.

Most security tools ask a binary question: is this object safe or not? Is this contract clean? Is this password valid? Is this file malicious?

That framing made sense when attackers were unsophisticated. It no longer does.

The dominant threat model today is not a single bad actor running a single bad transaction. It is an industrial process — coordinated, automated, temporally distributed — designed specifically to pass every object-level check while the damage accumulates invisibly underneath.

The answer is not a better scanner. It is a fundamentally different question: not what is this object, but what process produced it, and what does that process intend to do next?

Stage 2 vs Stage 3: A Shift in What We're Analyzing

Classic blockchain security operates at what we call Stage 2: the analysis of stabilized objects. A deployed contract. A token's holder distribution. A wallet's current balance. These are artifacts — the frozen output of processes that have already run.

Stage 2 tools are necessary. They are not sufficient.

Stage 3 is the analysis of processes before they stabilize — catching the signal in the pre-action layer, while intent is still forming and before it crystallizes into an on-chain fact.

On Solana, this means three concrete data extraction points.

Three Pre-Action Signal Layers on Solana

The Jito MEV Mempool and Transaction Buffer

Ordinary transactions go directly to slot leaders. Complex activity — bots, snipers, coordination structures — routes through the Jito mempool for tip optimization and front-run minimization.

This creates a detectable pre-execution layer.

When 20 new wallets simultaneously submit transactions sharing identical simulation hashes in Jito, that is not organic user activity. That is the deployment signature of a coordinated process. The object — the contract, the token — does not yet exist. The process creating it is already visible.

Pre-Funding Chain Analysis

Token factories and Sybil networks reveal themselves during the gas-funding phase. Even when they route through bridges or liquidity distributors, the timing and volume distribution of those funding flows create a unique wave signature.

We model this as a directed graph where edge weights are determined by the time delta between funding transactions.

An organic user funds a wallet from an exchange or personal address — spontaneously, inconsistently. An automated network does it in a cascade: deterministic intervals, consistent amounts, predictable depth. The vector field captures this cascade at the first or second child transaction, long before any token is deployed or any pool is created.

Dry-Run and Simulation Traffic

Large-scale attack operators always probe before they strike. They use simulateTransaction at scale to verify that their contract or exploit will execute correctly under current network conditions.

Individual simulation logs are private to specific nodes. But aggregated anomaly patterns from RPC providers — sudden spikes in simulation requests against specific pool metadata, unusual call structure clustering — expose the preparation phase. The attack has not happened. The intent is already measurable.

The Intent Vector Field

These three signal layers feed into what we call the Intent Vector Field: a probability distribution over competing behavioral scenarios.

When we observe an anomalous micro-variance jitter — a sudden burst of correlated micro-activity across multiple addresses — the system does not flag it as "suspicious." It distributes probability mass across competing interpretations:

Wash trading setup — manufactured volume to simulate organic interest
Liquidity drain preparation — coordinated positioning before a rug
Organic hype — genuine sudden interest from real users

Each scenario has a different temporal signature, a different graph topology, a different simulation traffic pattern. The model weights these signals dynamically as new data arrives, updating the probability distribution in real time.

The output is not a binary alert. It is a vector of intent — explainable, auditable, and falsifiable.

The Same Logic Applied to Web2: FortiBleed

The paradigm shift from object analysis to process analysis is not specific to blockchain. It is a general security architecture principle — and its absence is why traditional enterprise security keeps failing at scale.

Consider the FortiBleed credential harvesting campaign: 659 discrete collection cycles, 86,000 internet-facing FortiGate devices compromised, 110 million credentials extracted. The attacker was an Initial Access Broker operating as an automated factory — not a hacker, a process.

Traditional defenses asked the wrong question at every layer: Is this traffic authorized? Is this password valid? Is this file known malware? The answers were often yes, yes, and no — while the exfiltration continued.

A Stage 3 behavioral architecture would have intervened at three points.

First: Process clustering, not device isolation. When 430,000 firewalls across the world begin executing synchronous micro-requests toward the same command-and-control infrastructure, the distributed pattern is the signal. Each individual device looks clean. The coordinated behavior across devices is the attack. A behavioral engine modeling this as a unified process — rather than 430,000 independent events — produces an intent vector early: Data Exfiltration Campaign: 0.95.

Second: Pre-action detection of credential validation. IABs do not just steal credentials — they verify them. The FortigateSniffer toolchain included automated validity checking of collected accounts. This verification process generates an anomalous internal authentication traffic pattern on the compromised device: bursts of auth requests, not tied to any user session, testing accounts that are not currently active.

A system monitoring this pre-action behavior layer detects the credential validation phase as preparation — not as exfiltration, which comes later — giving defenders a window to intervene before the harvested data leaves the network.

Third: Identity scoring over binary access. NATO defense contractors operate on binary access models: if you have the right credentials, you are in. This assumption breaks completely when credentials are the attack surface.

An identity scoring layer changes the question from did this entity authenticate correctly? to does this entity's behavior match a known-legitimate access pattern? Even with a valid stolen password, a session driven by automated tooling — anomalous navigation speed, unusual data request patterns, network-layer jitter inconsistent with human interaction — scores high on archetypes like Automated_Data_Scraper or Lateral_Movement_Operator. The session is isolated regardless of credential validity.

The Common Thread

NexusVeritas applies this architecture to Web3: behavioral classification of wallet deployers, identification of coordinated Sybil structures, pre-deployment signal detection on Solana. The specific domain is on-chain. The mathematical foundation is domain-agnostic.

The pattern across every major breach of the past year — MEV honeypots, bridge proof forgery, infinite mint exploits, supply-chain backdoors, credential harvesting campaigns — is consistent:

The object passed inspection. The process behind it did not.

A fake token pair that passes contract verification. A forged bridge proof that passes cryptographic validation. A stolen password that passes authentication. A backdoored plugin update that passes integrity checks.

In every case, the process that produced the malicious object had a behavioral signature before the object existed. In every case, the tools being used were not designed to read that signature.

The question is not whether the contract is lying. It is whether the process that deployed it has done this before — and what it is preparing to do next...?

*NexusVeritas is a behavioral risk infrastructure for Solana — deployer history analysis, wallet archetype classification, and pre-deployment signal detection.
GitHub: github.com/cryptaveritas | X: @Syp_137

How AMMs Work: The Simple Math Behind Decentralized Trading

Mon, 22 Jun 2026 11:47:13 +0000

One of the hardest problems in decentralized systems is this: how do two strangers trade without trusting each other or paying a middleman to coordinate?

In traditional finance, this is solved by centralized exchanges. On the blockchain, we solve it with an Automated Market Maker (AMM).

If you spend any time looking at decentralized finance (DeFi), you have probably seen the acronym floating around. Today, we are going to look under the hood to see exactly what an AMM is, why the Ethereum ecosystem desperately needed it, and how it translates market rules into unstoppable code.

The Constraint: Why Order Books Fail Onchain

Before we can appreciate the solution, we have to understand the architectural constraint.

In traditional finance (like the stock market or centralized crypto exchanges like Binance or Coinbase), trading runs on an Order Book.

An order book is a giant digital matchmaking list. If I want to buy 1 ETH for $2,000, I write my name on the list. The exchange then searches for someone willing to sell 1 ETH for exactly $2,000. When it finds a match, the trade executes.

This works flawlessly on centralized servers. But on a blockchain, order books have a fatal flaw: Cost.

Every single time you place, cancel, or match an order, it requires a state change on the network. State changes cost "gas" (transaction fees). If you had to pay a $20 gas fee just to list your trade on a decentralized order book whether someone buys it or not, the system would instantly become too slow and prohibitively expensive to use.

We needed a way to trade assets without a matchmaking middleman. We needed to replace human coordination with reliable computation.

The Analogy: The Potato & Apple Farmers

To understand how an AMM solves this coordination problem, let's use a simple system model.

Imagine you are a potato farmer. You have hundreds of potatoes. Eventually, you get sick of them and just want a crisp, sweet, red apple.

There are no grocery stores. To get an apple, you have to find an apple farmer who is tired of apples and wants potatoes, and trade with them directly. This is the exact equivalent of an Order Book-finding a direct match. It is exhausting.

Now, imagine an automated bin appears in the middle of your village.

A wealthy merchant came by and filled this bin with 100 apples and 100 potatoes. The bin has no human cashier. Instead, it is run by a simple mathematical formula. The formula's only rule is to balance the supply.

When you walk up to the bin and take out 20 apples, apples suddenly become scarcer. Because there are fewer apples left in the bin, the formula automatically raises the price of apples. To take those 20 apples, the bin demands you put in 25 potatoes.

Next time someone wants an apple, it will cost even more potatoes, because apples are getting rarer. But if an apple farmer comes along and dumps 50 apples into the bin to take out some potatoes, the price of apples drops back down.

That bin isn't intelligent. It doesn't predict markets. It simply enforces rules.

This automated, math-driven bin is the exact conceptual framework of an Automated Market Maker.

The Mechanism: The Constant Product Formula

In decentralized systems, that automated bin is called a Liquidity Pool. It is simply a smart contract holding a pool of two different tokens (like ETH and USDC).

Instead of waiting for an order book to match your trade, you trade directly against the smart contract.

But how does the contract know what price to charge you? It uses an algorithmic invariant. The most common one is the Constant Product Formula, which looks like this:

x * y = k

This math is beautifully simple and completely deterministic:

x is the amount of Token A (e.g., Apples).
y is the amount of Token B (e.g., Potatoes).
k is a constant number that must always stay exactly the same after a trade.

Let's use our 100 apples and 100 potatoes example.
100 (apples) * 100 (potatoes) = 10,000 (our constant 'k')

If you take 20 apples out of the pool, there are only 80 apples left. But the smart contract strictly enforces that the total multiplied together must still equal 10,000.

So, the contract calculates the new required state: 10,000 / 80 apples = 125 potatoes.

For the pool to satisfy the invariant, it must now contain 125 potatoes. Since it originally had 100, you have to deposit 25 potatoes (the difference between 125 and 100) to execute your trade.

That is it. Supply and demand, governed purely by unbreakable math. As one asset is bought out of the pool, it mathematically becomes more expensive. As an asset is sold into the pool, it becomes cheaper.

The Infrastructure: Liquidity Providers

This raises an engineering question: Where do the millions of dollars worth of tokens sitting in these smart contracts come from?

They come from Liquidity Providers (LPs).

LPs are everyday users, investors, or protocols who lock their own tokens inside the smart contract to fund the pool. In exchange for supplying this infrastructure, they receive an LP Token: a digital receipt proving they own a percentage of that specific pool.

Why would anyone risk their capital to let strangers trade against it?

Fees.

Every time a user makes a swap on an AMM, the protocol charges a tiny fee (usually around 0.3%). That fee does not go to a CEO or a centralized exchange. It goes directly back into the liquidity pool.

Because the LP tokens represent a percentage claim over the pool, as those trading fees pile up, the underlying value of the LP tokens increases. The Liquidity Providers earn a yield simply for providing the capital that makes decentralized trading possible.

Key Takeaways

Let's quickly recap the system architecture we just explored:

Order Books are inefficient onchain. Requiring a state change for every order creation and cancellation costs too much gas.
AMMs replace middlemen with math. You trade directly against a smart contract (a Liquidity Pool) rather than waiting for a human counterpart.
Prices are driven by deterministic algorithms. Using formulas like x * y = k, the AMM automatically raises the price of an asset as it becomes scarcer in the pool.
Liquidity Providers are the backbone. They supply the underlying tokens that make the system liquid, earning trading fees as a reward for their capital.

Final Thoughts

AMMs changed trading by replacing coordination with computation, turning market rules into software anyone can verify.

They took a complex, middleman-heavy financial process and reduced it to a few lines of self-executing, reliable code. They are a perfect example of how thoughtful engineering can create systems that are not only highly functional, but entirely trustless.

What are your thoughts on how AMMs are designed? Have you ever provided liquidity to a protocol yourself? Let's chat about it in the comments below.

Let's build something you can trust. Follow for more deep dives into smart contract architecture and onchain fundamentals.

We Were About to Launch. First, We Decided to Hack Ourselves.

Wed, 17 Jun 2026 13:07:28 +0000

It was an ordinary Tuesday. The API was running, tests were passing, Docker came up on the first try. We were already imagining our first clients — B2B integrations, Telegram bots, deals.

Then someone on the team said: "What if we try to break everything first?"

Good idea. It almost always turns out things break faster than you expect.

What We Were Building

An analytical API for assessing Solana token risks. Not another contract scanner — there are dozens of those. We do behavioral analysis: who's behind the token, what's the history of that wallet, does the pattern resemble known manipulation schemes.

Over several months we built a database, trained a classifier, stood up a NestJS API with PostgreSQL and Redis, wrapped everything in Docker. By all indications — production-ready.

By all indications.

Hour One. "Wait, You Can Actually Break This"

We found the first vulnerability almost immediately. Not because we searched long — we just looked at the code with fresh eyes.

Our API accepts a Solana token address in the URL and passes it to an external script for analysis. It looked something like this:

const output = execSync(
node -e "fetchData('${mintAddress}').then(...)"
);

See the problem? We were inserting a string from an HTTP request directly into a shell command. Without any validation whatsoever.

In theory, anyone who knows our endpoint address could send something like '); rm -rf /app; node -e (' instead of a token address — and that command would execute on our server. It's called shell injection, and it's one of the oldest vulnerabilities in the book.

We had been running for several months. This code had been there the whole time.

It was a little unsettling.

Fixed it in twenty minutes: added a format check before touching the input at all. Solana addresses are base58 — a strictly defined character set. Everything else gets an immediate 400.

typescriptif (!/^[1-9A-HJ-NP-Za-km-z]{32,44}$/.test(mintAddress)) {
throw new BadRequestException('Invalid mint address format');
}

Simple. Effective. Should have been there from day one.

Hour Two. When Everything Works, Just Not the Way You Think

The second finding was subtler. Looks harmless on the surface. In practice — a ticking time bomb.

NestJS has a Dependency Injection mechanism: you register services in modules, the framework figures out who provides what to whom. Convenient. But we had registered the same service in two places at once.

What happens in that case? NestJS doesn't complain. Doesn't warn you. It just quietly creates two separate instances of the same service.

Sounds benign. But our database service holds a connection pool to PostgreSQL. Two instances — two pools. Under load, that means twice as many open connections as planned. PostgreSQL has a limit on simultaneous connections. Exceed that limit and the database stops responding.

We would have discovered this at three in the morning when the first client complained the API was down.

Hour Three. When "All Green" Is a Lie

The next discovery was, perhaps, the most uncomfortable. Not because it was dangerous — because it was embarrassing.

We have a list of known exchange and bridge addresses. If several large buyers of a token were funded from one of these addresses — that's normal, that's not insider collusion. Sound logic.

But when we opened the file with those addresses, here's what we saw:

typescriptconst BRIDGE_ADDRESSES = new Set([ 'BLZRi6frs4X4DNLw56waFf6jNav84j6bKrikoZejset5', // Mayan — real 'debridge...', // ← literally three dots 'worm...', // ← three dots again 'binance...', // ← and again ]);

Someone at some point wrote a placeholder instead of a real address. And forgot. Tests didn't catch it because tests didn't know what a correct Wormhole Bridge address was supposed to look like.

The code compiled. The service started. The function was called. Results were returned. Everything was "green."

And everything was wrong.

Three out of four addresses in our protection list didn't exist. Any coordinated buying scheme through those bridges would have gone undetected.

We spent an hour finding real verified addresses and replacing the stubs with actual data. Tedious work. But exactly these tedious things stand between you and a reputational disaster.

Hour Four. The Detective and the Unreliable Witness

Probably the most interesting finding — and the hardest to debug.

One of the key elements of our analysis is determining the token creator. Who launched this memecoin? What's their history? Have we seen this wallet before?

The algorithm was straightforward: page through the token's transaction history from the end backward, find the very first one — that's the creation transaction, its initiator is the creator.

The problem surfaced by accident. We made three consecutive requests to the same token and got three different creator addresses.

One token. Three requests. Three different "creators."

The investigation took a while. Turns out: the algorithm paged through history in batches of 1,000 transactions but made a maximum of three batches. For popular tokens with thousands of transactions, the algorithm simply never reached the very first one — and each time returned a different result depending on which transactions ended up "last" in the pagination.

Imagine a detective questioning witnesses in random order and getting different testimony every time. Not because the witnesses are lying — he just talks to different people each time.

The fix was straightforward: increase the batch limit from three to ten. Now the algorithm always reaches the beginning of the history. Three requests — one result.

Hour Five. The Things You Don't Think About Until It's Too Late

The rest of the day went to what most developers put off "for later." Things that seem obvious when you read about them — and that you don't think about when you're writing code at two in the morning.

API without rate limiting. Our endpoint was open to any volume of requests. A single script could take down the service with endless calls or exhaust the limits of the external APIs we depend on. We added 60 requests per minute per IP — standard protection, but it wasn't there.

No security headers. Browser clients received no security policy instructions whatsoever. We added helmet — one line of code that closes an entire class of browser-based attacks.

500 instead of 400. When a request came in for an unsupported blockchain, our API returned 500 Internal Server Error. Not because something was broken — we were just throwing a plain Error instead of a BadRequestException. For an integrator, the difference between 400 and 500 is fundamental: the first means "you did something wrong," the second means "we crashed."

The Tally: Seven Hours Against Seven Vulnerabilities

By evening we had seven closed items and one uncomfortable realization.

We hadn't done anything exotic. We hadn't used unvetted libraries. We hadn't reinvented the wheel where we didn't need to. We just wrote code — the way most of us write it in "ship the feature" mode.

And in that code lived perfectly classic vulnerabilities. Shell injection from a 1998 textbook. Provider duplication that doesn't complain but breaks logic under load. Stubs in a critical place that nobody replaced.

All of this would have been discovered by the first clients. At the worst possible moment. When fixing it would cost far more.

The most important thing we learned: a security audit isn't about hunting exotic zero-day vulnerabilities. It's about slowing down and looking at your own code like a stranger would. What here was done on autopilot? What was a "temporary solution" three months ago? What do tests not check — because they don't know what to check for?

Seven hours of work. Seven findings. Not one of them required genius — just attention.

The project is currently in closed beta. Due to the nature of our security research and the uniqueness of the underlying classification methodology, only a partial overview is made available to the public at this stage. Core components — including the behavioral classifier, archetype definitions, and wallet dataset — remain proprietary. We'll announce the public launch and partnership opportunities separately.

Developer Journal Day6

Sun, 14 Jun 2026 21:26:50 +0000

The global AI market already exceeds $2.5 trillion in estimated spending for 2026. But what's interesting isn't just the size of the number — it's what companies are actually looking for today: not specialists in a single technology, but people capable of combining AI, Cloud, Blockchain, security and automation. That integration vision isn't new. There were projects that tried to combine AI and Blockchain long before it became trendy, and it's worth looking at what happened to them, because what they built — and what they failed to achieve — is still relevant today.
Although blockchain is a much smaller sector than AI, the trend we're seeing is that companies aren't only looking for AI specialists. They're looking for people capable of integrating:

AI
Cloud
Security
Data
Blockchain
Business automation
Sure, AI moves way more money than blockchain by a huge margin. But blockchain remains a strategic technology in areas where trust, auditing, identity, traceability and digital assets are needed. That's why many companies end up needing both instead of choosing one or the other.
DeepBrain Chain is a project I found interesting precisely because it tried to combine two things long before it became fashionable: AI + Blockchain. This idea was born in 2017, with the proposal of creating a decentralized computing power network, mainly GPUs, so that AI companies and developers could rent computational resources cheaper than those from traditional providers.
If you think about it, the concept is pretty similar to what several decentralized computing networks for AI are trying to do today.

So, is it a success?
Its market had a lot of hype during the 2017-2018 crypto boom. Its all-time high was close to $0.66 USD per token — today it sits around $0.0003 USD, more than 99% below that peak.
This doesn't automatically mean the project is a fraud, but it does indicate it never reached the adoption many investors expected, for several reasons:

It arrived too early
The AI market of 2017 was much smaller than today
Decentralized GPU infrastructure was hard to build

It ended up with a pretty damaged reputation within the crypto ecosystem. But the curious thing is that its idea doesn't seem so crazy in 2026.

What happened to Ocean Protocol? Does it still collaborate with car manufacturers?
Ocean Protocol was a fascinating case and yes, it still exists, but it's no longer in the position it held between 2020 and 2024. And the famous collaborations with car manufacturers don't seem to be the center of the story today.
Ocean wanted to create a decentralized data economy — a very brilliant idea, since companies own data, don't want to sell it completely, but do want to monetize it. Ocean allowed data access while maintaining a certain level of control and privacy.
That's how it caught the attention of industrial and automotive sectors. It participated in initiatives like Catena-X alongside companies from the European automotive ecosystem and organizations like Bosch and Fetch.ai.

When you think about supply chain, traceability, predictive maintenance or connected vehicles, that's where Ocean made sense.
With the AI boom, Ocean got very close to these projects, giving birth to what became known as the Artificial Superintelligence Alliance (ASI). The idea was to unite AI + Blockchain ecosystems under a common vision, and at that moment a lot of people thought:

"They're building the decentralized infrastructure for the AI economy"

And here comes the twist.
In 2025, Ocean left the ASI alliance, going back to operating independently. It stated it wanted to regain control of its tokenomics and strategic direction. There were also cross-accusations and governance conflicts among the participants.
The interesting thing is that Ocean hasn't disappeared. The project's own documentation still describes Ocean as an independent token after the ASI exit, and the team continues developing a vision around decentralized data and AI.
In crypto communities there are still people who see it as a historical data infrastructure project for AI that's trying to reinvent itself after the break with ASI.
Its original idea remains extremely powerful — and not because it's a cryptocurrency, but because it raises a question that companies still haven't fully resolved:

"How do you share data between organizations without losing control over it?"

From the technical side, there are concrete answers: Hyperledger, APIs, messaging systems, Smart Contracts coded to unlock information only with the private key of whoever is meant to receive it. The tools exist. But The Matrix Revolutions left us something in one of the last dialogues between The Oracle and The Architect: technical problems tend to be hard, but human problems tend to be even harder. And in the business world, sharing data between organizations isn't just a technical problem. It's a problem of trust, incentives, governance and interests that don't always align. That's where projects like Ocean Protocol tried to build something that goes beyond the code.

I wouldn't say Ocean Protocol revolutionized the automotive industry, but it was one of the projects that helped popularize the idea of decentralized data markets and data sharing between companies — something with very important applications in the automotive sector.

And finally, let's talk about the Cortex project
Because it was one of those projects that, when it appeared, seemed like science fiction. Its proposal was:
"What if Smart Contracts could execute artificial intelligence models directly inside the blockchain?"
In 2018 that was an idea very ahead of its time. Cortex wanted to upload AI models to the network, execute inferences inside the blockchain, enable smart contracts with AI capabilities, and create AI DApps — better understood as decentralized applications with integrated AI.
They claimed to be the first blockchain capable of supporting on-chain AI, and in terms of marketing and architecture, they had a basis for that claim. Even today Cortex still describes itself as the first — and according to them, the only — public blockchain capable of executing AI inference directly on-chain.
Now imagine a smart contract that asks:

Does that transaction look fraudulent?
Was the payment received?
Did the goods arrive before the deadline?

But those questions are answered by the smart contract itself without needing AI — it just has to be fully configured, or in other words, the rules have to be defined.
And that's one of the reasons why thousands of AI+Blockchain projects ended up having less impact than they promised.
Everything can be programmed with traditional logic. AI starts to make sense when the answer can't easily be expressed through rules — for example, when probabilistic inference is involved.
Cortex still exists as an active project and its documentation still claims the title of first public blockchain capable of executing AI inference on-chain. But it never reached mass adoption, partly because it arrived too early and partly because the problem it was trying to solve turns out to be unnecessary in most real-world cases. Smart contracts don't need a classification model to know if a payment was received. Traditional logic handles that perfectly. Cortex found the right answer to a question very few companies were asking.

Many times, especially in blockchain and AI, a tendency appears to think that if a technology is good, it should do everything.
In a symphony orchestra, nobody says: the violin is so good it should replace the piano, or percussion is so important that all music should be percussion.
Every instrument has strengths and limitations — and it's the same with technology. Blockchain is excellent for trust, traceability, auditing and coordination between actors. Traditional databases are excellent for speed and massive storage. AI is excellent for classification, prediction and analysis. APIs are excellent for integration. Cloud is excellent for scalability. Messaging systems are excellent for communication between services.

Beyond Identity: Rethinking Trust Infrastructure Through Zero-Knowledge Verification

Thu, 11 Jun 2026 10:15:45 +0000

Abstract:

Trust on the internet has traditionally relied on centralized authorities, public credentials, and extensive disclosure of personal information. Whether applying for a job, verifying an academic qualification, or proving professional experience, users are often required to reveal significantly more information than necessary.

While exploring emerging solutions in this space, I came across two interesting approaches. GitHired focuses on proving technical credibility through actual work rather than resume claims, while Fhenix explores privacy-preserving computation through Fully Homomorphic Encryption (FHE). Both projects address different dimensions of trust, yet neither fully solves the challenge of verifiable identity and credential ownership.

This observation led to the conceptualization of ZenProof, a privacy-preserving trust infrastructure that combines decentralized identity standards, verifiable credentials, distributed storage, and Zero-Knowledge Proofs to enable trust verification without exposing sensitive information.

1. Introduction

One question kept bothering me throughout my exploration of Web3 identity systems:

Why do we reveal everything just to prove one thing?

A university graduate only wants to prove they possess a degree.

A developer only wants to prove they possess a skill.

A professional only wants to prove they hold a certification.

Yet modern systems require complete disclosure of personal information, documents, and credentials to establish trust.

As digital ecosystems continue to evolve, trust itself has become one of the internet's most valuable resources. However, existing verification systems remain heavily dependent on centralized databases and excessive information sharing.

This led me to investigate whether trust could be verified differently.

Not through disclosure.

But through cryptographic proof.

2. Existing Approaches

GitHired: Trust Through Proof of Work

One of the most interesting platforms I encountered was GitHired.

Instead of evaluating candidates through traditional resumes, GitHired analyzes actual GitHub contributions, project complexity, and development activity. The platform operates on a simple but powerful philosophy:

Trust what developers build, not what they claim.

This approach significantly improves hiring accuracy by emphasizing demonstrable work over self-reported qualifications. GitHired's model focuses on proof-of-work rather than keyword matching or resume-based filtering.

However, while GitHired addresses credibility, it does not directly solve privacy or identity ownership challenges.

Fhenix: Trust Through Privacy

Fhenix approaches the problem from a completely different direction.

Using Fully Homomorphic Encryption (FHE), Fhenix enables computation on encrypted data without revealing the underlying information. This allows developers to build confidential smart contracts while preserving privacy throughout execution.

The technology represents a major advancement in privacy-preserving blockchain infrastructure.

However, its primary focus is confidential computation rather than decentralized credential verification.

3. Identifying the Research Gap

While studying both systems, I noticed something interesting.

GitHired solves credibility.

Fhenix solves privacy.

But neither directly addresses a broader challenge:

How can individuals prove qualifications, skills, certifications, or achievements without exposing the underlying data itself?

This gap became the foundation of ZenProof.

4. Introducing ZenProof

ZenProof is envisioned as a privacy-preserving trust infrastructure designed around a simple principle:

Prove the claim, not the data.

Instead of sharing certificates, users share cryptographic proofs.

Instead of exposing identities, users verify legitimacy.

Instead of relying on centralized verification systems, trust becomes mathematically verifiable.

To achieve this, ZenProof combines:

W3C Decentralized Identifiers (DIDs)
Verifiable Credentials
IPFS-based decentralized storage
zk-SNARK proof generation
Selective disclosure mechanisms

Together, these technologies create an environment where verification becomes possible without sacrificing privacy.

5. Why This Matters

As AI-generated content, deepfakes, forged certificates, and fake resumes become increasingly common, proving authenticity will become one of the internet's most important challenges.

The future will not belong to systems that collect the most data.

It will belong to systems that require the least data while providing the strongest guarantees of trust.

That is the vision behind ZenProof.

How do web3 Hardware wallets work?

Wed, 10 Jun 2026 08:02:58 +0000

Under the Hood: How Hardware Wallets Keep Your Crypto Safe (Even Over USB and Bluetooth)

In my last article, we established a foundational truth about Web3: your wallet does not actually store your tokens. Instead, it manages your public and private keys, interacting with the blockchain to sign transactions. We also touched on the stark difference between hot wallets (software apps or browser extensions connected to the internet) and cold wallets (physical hardware devices that remain offline).

If hot wallets run the constant risk of being targeted by malicious code, clipboard switchers, or operating system vulnerabilities, how exactly do hardware wallets bridge the gap? How do you authorize a transaction on a live blockchain using a piece of hardware that doesn't have an internet connection?

The web3 space talks a lot about "air-gapped" security, but the reality is that many of the most popular and convenient hardware configurations rely on physical USB connections or encrypted Bluetooth networks. Let’s lift the hood and look at how these data bridges work without ever exposing your private keys. Strp in, it is going to be some ride :)

I have partnered with the team at OneKey for a creator collaboration. While this article contains an affiliate link at the end that helps support my work, the architectural breakdowns and security principles shared below are entirely objective, and designed to help you stay secure on-chain.

The Core Architecture: Isolated Environments and Secure Elements

When you use a software wallet on your laptop or phone, your private keys ultimately exist somewhere inside your device’s memory (RAM) or local storage when a transaction is being signed. If your operating system is compromised by malware, a bad actor can potentially scrape those keys right out of memory.

Hardware wallets solve this fundamentally through physical and logical isolation. They are designed to operate as isolated cryptographic environments.

The Secure Element (SE)
Whether a hardware wallet connects via a cable, Bluetooth, or a QR code, the baseline security remains the same: a specialized microcontroller called a Secure Element (SE). This is the same type of hardened chip used in credit cards, passports, and military-grade hardware.

The Secure Element is specifically hardened against physical and digital attacks. It features:

Physical Countermeasures: Shields that detect changes in light, temperature, or voltage to prevent hardware tampering.
Side-Channel Attack Resistance: It is designed to mask electrical power consumption and electromagnetic radiation, preventing attackers from guessing your private keys by analyzing the power the device uses while signing a transaction.

The Monolithic Firmware
Unlike your PC or smartphone, which runs millions of lines of code, complex background processes, and third-party apps, a hardware wallet runs a minimal, dedicated microkernel or monolithic firmware. There are no web browsers, no complex drivers, and no unneeded networking stacks. This dramatically reduces the attack surface.

Understanding the Data Bridge: USB, Bluetooth, and QR Codes

The golden rule of a hardware wallet is simple: The private key never leaves the device. A common misconception is that if a hardware wallet plugs into a computer via USB or pairs with a phone via Bluetooth, the computer can "see" the key. It can't. The channel of communication doesn't change the underlying cryptography; it only changes how the data packet travels.

Let's break down the three main transport mechanisms used to sign transactions:

The Wired Path (USB-C)
This is the classic hardware wallet experience. When you plug your wallet into a laptop, the device doesn’t mount like a standard flash drive or external hard drive. Instead, it communicates via a highly restricted serial protocol or custom HID (Human Interface Device) commands - similar to how a USB keyboard sends keystrokes.

The computer can only send a specific data payload (the unsigned transaction) to the wallet and request a specific response (the cryptographic signature). The private key is physically locked inside the Secure Element and cannot be queried or read over the USB interface.

The Wireless Path (Bluetooth Low Energy)
For mobile-first Web3 users, plugging a USB cable into a phone is a clunky experience. This is where Bluetooth Low Energy (BLE) comes in.

Understandably, wireless communication makes people nervous, but the architecture is incredibly robust:

End-to-End Encryption: The Bluetooth pairing process establishes an encrypted channel between your phone and the hardware wallet using ephemeral keys. Even if someone intercepts the raw Bluetooth radio waves, they only see encrypted gibberish.
Zero Key Exposure: Just like the USB connection, the only things travelling through the air are the raw transaction data going in and the mathematical signature coming out. Your seed phrase is never broadcast over the air.

The Visual Path (True Air-Gap via QR Codes)
Some high-end hardware profiles opt for zero digital connection whatsoever. They omit USB data lines and Bluetooth chips entirely, relying instead on a built-in camera and screen. The unsigned transaction is converted into a QR code on your computer screen, you scan it with the wallet's camera, sign it offline, and the wallet displays a new QR code containing the signature for your computer to scan.

This is where the term 'air-gapped' stems from, there is no physical or electrical connection between the devices. An engineering masterpiece, you would say.

While this offers the maximum theoretical isolation, it sacrifices the sleek, pocketable form factor and rapid transaction speed of Bluetooth and USB.

How Transaction Signing Works (Regardless of the Connection)
No matter how your wallet connects to your interface, the process follows a strict 3-step asymmetric cryptographic loop:

Transaction Construction (Online): You open a Web3 interface to initiate a transaction (e.g., swapping tokens on a DEX). The software application constructs a Raw, Unsigned Transaction detailing parameters like the destination address, value, gas fees, and contract data.
The Hardware Handshake & Verification (Offline): The raw transaction bytes travel via USB, Bluetooth, or QR code to the hardware wallet. Once received, the wallet decodes the data and displays the vital parameters on its own physical screen. This is your defense against "Man-in-the-Middle" attacks; if a hacker changes the destination address on your computer screen, the hardware screen will reveal the real, malicious destination.
The Cryptographic Signature: Once you physically press the buttons on the device to approve, the Secure Element uses your private key to generate a cryptographic signature (using ECDSA on the secp256k1 curve for Ethereum). This signature - and only the signature - is passed back to the software application to be broadcasted to the blockchain network.

Moving Beyond Software Wallets

In a permissionless ecosystem, there is no "Forgot Password" or customer support line to undo a compromised private key. If you are regularly interacting with smart contracts, deploying code, or holding assets long-term, moving your primary accounts to a dedicated hardware setup isn't optional - it's a necessity.

Hardware wallets like OneKey are a standout choice for developers and power users is their dedication to absolute transparency; their firmware and hardware designs are fully open-source and auditable right on GitHub. Backed by heavyweights like Coinbase Ventures and Dragonfly, they offer an incredible product lineup.

If you want to upgrade your security stack, you can use my link below to get 10% off your entire purchase at the shop, with no extra cost to you, this also supports my articles:

Get 10% off your OneKey Hardware Wallet here

Until the next article, stay safe and verify before you sign!

The Agentic Payment Protocol Wars

Thu, 04 Jun 2026 12:11:33 +0000

X402 vs UCP vs ACP vs AP2 And Why the Answer Isn't Picking a Winner

I've spent the last year integrating every major agentic payment protocol into a single SDK. Not studying them from the outside actually writing the adapter code, handling the edge cases, debugging the interop failures.

Here's what the landscape actually looks like from the inside, and why the fragmentation problem is worse than most people realize.

The Protocols

x402: Coinbase (HTTP 402 Micropayments)

What it does: Resurrects the HTTP 402 status code. Server returns 402 Payment Required with a payment header. Client pays via stablecoin (USDC on Base). Server verifies payment, serves content.

How it works:

Agent requests resource → Server returns 402 + payment requirements
Agent constructs stablecoin transaction
Agent submits payment proof in retry request
Server verifies on-chain, serves resource

Strengths: Elegant. Simple. Native to HTTP. Works with any web resource.

Weaknesses: Only stablecoins on Base (expanding, but limited). Micropayment-focused, not designed for complex commerce flows. No negotiation phase, the price is the price.

Our integration: ProtocolDetector identifies 402 responses and auto-constructs payment transactions. Works out of the box.

UCP: Google/Shopify (Universal Commerce Protocol)

What it does: Commerce orchestration. The counterparty describes what it can do ("I sell API calls, compute time, and data feeds"), and the agent negotiates terms.

How it works:

Agent discovers UCP-enabled service → service publishes capabilities
Agent and service negotiate (quantity, pricing, terms)
Agreement reached → payment executed
Service delivers

Strengths: Flexible. Supports discovery, negotiation, and complex multi-item transactions. Agent can compare services and shop around.

Weaknesses: Complex. The negotiation phase adds latency. Requires both parties to implement the full UCP spec, not a drop-in for existing APIs.

Our integration: ProtocolDetector identifies UCP capability endpoints. The AgentWallet handles the negotiation loop. Policy checks apply at each stage.

ACP: OpenAI/Stripe (Agent Commerce Protocol)

What it does: Structured transaction format. The service presents a cart ("here's what you're buying, here's the price"), the agent confirms and pays.

How it works:

Service presents SharedPaymentToken with cart contents
Agent validates cart against policy
Agent authorizes payment
Service fulfills

Strengths: Familiar (it's basically Stripe Checkout for agents). Already live in ChatGPT. Strong backing from OpenAI + Stripe.

Weaknesses: Rigid. No negotiation, you accept the cart or you don't. Vendor-locked to the OpenAI/Stripe ecosystem in practice. The SharedPaymentToken format is specific to ACP.

Our integration: ProtocolDetector identifies ACP token formats. Policy evaluation occurs pre-authorization. Evidence bundle includes cart contents and authorization proof.

AP2: Google (Agent Payment Protocol v2)

What it does: Cryptographically signed delegation mandates. The principal (human/company) creates a W3C Verifiable Credential that authorizes the agent to spend up to $X on category Y.

How it works:

Principal creates signed delegation mandate (VC format)
Agent presents mandate to service
Service verifies the signature chain
Transaction executes within mandate bounds

Strengths: Strongest authorization model. The mandate is a cryptographic proof of delegation, not just a session token. Supports nested delegation (agent A delegates to agent B within tighter bounds).

Weaknesses: Complex credential management. Requires VC infrastructure. Not widely adopted yet. The specification is still evolving.

Our integration: ProtocolDetector identifies AP2 mandate presentations. Session key bounds are mapped to mandate constraints for interop.

MPP: Session-Based Budget Allocation

What it does: Pre-allocated budget pools that agents can draw from within defined bounds.

How it works:

Principal allocates a budget pool (e.g., 1000 USDC for this session)
Agent operates within pool bounds
Each transaction decrements the pool
Session ends → remaining funds returned

Strengths: Simplest model for bounded spending. No per-transaction authorization needed once the pool is set.

Weaknesses: No protocol negotiation, assumes the payment method is already agreed. Coarse-grained control.

Our integration: MPP is native to Veridex, this is essentially what our session key system does at the protocol level.

The Fragmentation Problem

Here's the reality in April 2026:

Coinbase-ecosystem services speak x402
Google-ecosystem services speak UCP or AP2
OpenAI-ecosystem services speak ACP
Crypto-native services speak MPP or raw transactions
Most services speak none of these yet

An AI agent that only speaks one protocol can only transact with services in that ecosystem. An agent that, speaks all five can transact with anyone.

But no developer wants to integrate five protocols. The protocol-specific code is complex, each has different discovery mechanisms, different negotiation flows, different payment formats, different verification methods.

Why We Built ProtocolDetector

ProtocolDetector in @veridex/agentic-payments solves this:

const wallet = await createAgentWallet({ ... });

// Developer writes this ONE integration:
const result = await wallet.pay({
  recipient: 'https://api.example.com/resource',
  amount: '5.00',
  currency: 'USDC',
});

// ProtocolDetector handles:
// 1. Probe the endpoint → detect which protocol(s) it supports
// 2. Select the optimal protocol based on cost, speed, and agent policy
// 3. Execute the protocol-specific flow
// 4. Generate a unified evidence bundle regardless of protocol used

One API. Five protocols underneath. The developer never writes protocol-specific code.

My Take

The protocol wars won't produce a single winner. Not in 2026, probably not ever.

x402 will dominate micropayments and API monetization (it's too elegant not to)
ACP will dominate the OpenAI ecosystem (they have distribution)
UCP will dominate complex commerce (Google + Shopify is a powerful combo)
AP2 will dominate enterprise delegation (cryptographic mandates are what compliance needs)
MPP will remain the default for session-based budgets

The answer isn't picking a winner. It's building the abstraction layer that speaks all of them.

That's what @veridex/agentic-payments does. 257 tests. 5 protocols. 1 API.

This analysis is based on our Agentic Payments Protocol Map research paper, which maps the full protocol landscape including AXTP, VIC, MAP, and the trust/identity prerequisites (ERC-8004, Visa TAP). Full paper available on request.

If you're building agents that need to transact across protocol ecosystems, the SDK is open: npm install @veridex/agentic-payments

The Brief for the Judge: Writing Audit-Ready Documentation

Tue, 26 May 2026 17:00:00 +0000

We have spent the last four posts building MilestoneCrowdfundUpgradeable protocol. We architected an upgradeable proxy, designed a mathematically rigorous escrow engine, fuzz-tested its invariants, and locked the doors against reentrancy attacks. We built a fortress.

But there is one final step. A secure fortress is incredibly dangerous if you don't leave behind a blueprint explaining exactly how the traps and locks are supposed to work.

Most developers hate writing documentation. In Web2, bad documentation means a new developer joins your team and spends three days figuring out an API endpoint instead of one hour. Frustrating, expensive, recoverable.

In Web3, bad documentation is catastrophic. When you hand your code to a security auditor, bad documentation means they might misunderstand the intended behavior of a function. They might classify a deliberate design choice as a vulnerability, forcing you to waste weeks fixing a non-issue. Worse, they might see a real bug, assume it was your intended logic, and let it pass into production where user funds get drained.

In this final post, I want to share exactly how I approached documenting MilestoneCrowdfundUpgradeable from NatSpec comments to architectural READMEs and why I believe documentation is the most underrated security tool in Web3.

The Mindset: Preparing the Brief

When I prepare a protocol for an audit, I think of the documentation as the brief I am handing to a judge before a trial.

The auditor is the judge. The code is the evidence. But without the brief, without the written explanation of intent, the documented invariants, and the explicit threat model, the judge is left to interpret the evidence alone. And interpretation without intent is where dangerous misreadings happen.

But here is the deeper truth: documentation isn't just for auditors. It is for the version of you that comes back to this codebase in six months after working on three other projects. That person has forgotten everything. The comments and the threat model are the only things standing between future-you and a catastrophic misunderstanding of your own protocol.

My rule is simple: If I have to think for more than five seconds about what a piece of code is doing, that piece of code needs a comment. Not because the code is bad, but because the next person reading it shouldn't have to spend those same five seconds. In a paid audit, those five seconds across a thousand lines become expensive hours of confusion.

NatSpec: Before, During, and After

Solidity uses a comment format called NatSpec (Ethereum Natural Language Specification). My approach to writing it happens in three distinct phases:

1. Before (The Specification)
I write the @notice and @param descriptions before I write the function body. This forces me to articulate what the function is supposed to do in plain English before I write a single line of logic. If I cannot describe it clearly in one sentence, I do not understand it well enough to code it yet. The comment becomes the specification; the code is just the implementation.

2. During (The "Why")
While writing the body, I add inline comments at critical decision points. In the last post, we looked at this exact code block:

// CEI: Effects - Update the ledger first, before money moves!
_pledges[_id][msg.sender] = 0;

Any competent developer can read _pledges[_id][msg.sender] = 0 and know what it does. What they cannot know without a comment is that this line is here specifically to prevent a reentrancy attack. My personal rule: The code says "what". Only a comment can say "why".

3. After (The Edge Cases)
After the function is complete, I write the @dev block. This is where I document the non-obvious: the edge cases I considered and rejected, the invariants this function must maintain, and the assumptions that must be true for it to be safe.

The Power of Visual State Machines

A smart contract is a state machine. It has states (Fundraising, Succeeded, Failed, Abandoned) and transitions between those states (finalize, haltCampaign).

You can write all of that in prose, but the human brain does not reason about state machines in paragraphs. It reasons about them visually. The moment I drew the state diagram for MilestoneCrowdfundUpgradeable using PlantUML, a massive gap became visible.

Looking at the diagram, I immediately noticed there was no direct transition from Fundraising to Abandoned. A campaign could only be Abandoned after it Succeeded. That was a correct design decision, you shouldn't be able to abandon a project that never even got funded but seeing it drawn forced me to go back and verify that the Solidity code actually enforced this explicitly. The diagram asked a question the code never explicitly answered.

Diagrams also communicate to people who cannot read Solidity. Your investors, your community, or a tokenomics specialist auditing your math might struggle with the raw code, but they can instantly follow a visual map.

The README Architecture

A lot of Web3 repositories just leave the default Foundry or Hardhat README file. Alternatively, they throw every piece of information into one giant, 3,000-word file.

One giant file is a red flag. It tells an auditor that the author did not think carefully about who would be reading it. I split the MilestoneCrowdfundUpgradeable documentation into specific hubs tailored to specific readers:

Protocol_Architecture.md: Written for the Auditor. Their primary question is: What is this protocol supposed to do, and what rules must it never break? This document answers that immediately.
Integration_Guide.md: Written for the Frontend Developer. Their primary question is: How do I call these functions correctly without breaking anything? They need the function signatures and error codes, not the threat model.
Incident_Response.md: Written for the Security Researcher. If they find a live vulnerability, their primary question is: Who has the authority to pause this, and how do I reach them right now? If they have to dig through installation instructions to find your emergency contact, you are wasting critical seconds during a hack.
Threat_Model.md: Written for the Skeptical Reviewer. This is the document most developers skip. It says: Here are the attacks we considered, here is why we are protected, and here are the residual risks we knowingly accepted. You cannot write a threat model without thinking like an attacker, and you cannot think like an attacker without finding things you missed.

A well-structured repository is a signal of engineering maturity. Before an auditor reads a single line of your Solidity, they have already formed a judgment about how seriously you take correctness based on your file structure.

The Hardest Part: Combating Drift

The hardest part is not writing documentation. It is keeping it true.

Code changes. Documentation does not change automatically. The gap between them is one of the most dangerous states a codebase can be in.

I experienced this directly. Early in the design of the fiat bridge, pledgeFiatOnBehalf was intended to apply a reduced platform fee. The NatSpec reflected that. Later, the stakeholder and I decided fiat pledges would be completely fee-exempt on-chain, with fees handled off-chain by Stripe.

I changed the code. I didn't immediately update the comment.

I caught it during a final review pass, but imagine if I hadn't. An auditor reading that comment would have expected fee logic that didn't exist, flagged its absence as a high-severity bug, and forced us to waste days in remediation meetings arguing over a phantom issue.

The discipline I developed from that experience is strict: Every time you change a function body, you update the NatSpec before you close the file. Not before you commit. Immediately. The comment is a structural part of the function, not a separate chore to do later.

The BinnaDev Takeaway

When a junior developer tells me, "My code is clean, it's self-documenting, I don't need to write a README," my response is always the same:

"Show me the part of your code that explains why you made that design decision."

Clean code tells you what. Only documentation tells you why. And in smart contract engineering, the why is where all the security lives. "Self-documenting code" makes sense in Web2 where the worst-case scenario is a confused colleague. It does not make sense in Web3 where the worst-case scenario is a misunderstood intent that costs your users everything they trusted you with.

Here is the practical test: If a professional auditor had to judge whether a specific line in your contract was an intentional design choice or a bug, would your code give them enough information to judge correctly without asking you a single question? If the answer is no, you need documentation.

And I will be completely honest with you on how I execute this practically.

English is not my first language. Documentation is fundamentally an asynchronous communication tool, you are writing for a stranger who cannot ask you a follow-up question, they have to wait for your response. In this context, a grammatical error doesn't just look careless; it creates genuine ambiguity. Did the developer mean this or that? To solve this, I use AI. Agile engineering tells us to prioritize working software over comprehensive documentation. That doesn't mean skip the docs; it means be smart about where your mental energy goes. The architecture, the invariant math, the security decisions, those required 100% of my focus. I used AI to help draft NatSpec suggestions and catch grammatical ambiguity so my thinking wasn't limited by the mechanics of expressing it in a second language. The ideas are mine entirely. The precision of communicating them is a collaboration.

Your code being clean means you are a careful developer. Your protocol being documented means you respect the people who will put their money into what you built. Both are required. You have the tools. Use them.

This concludes our five-part journey building the MilestoneCrowdfundUpgradeable protocol. From upgradeable proxies to defensive math, stateful fuzzing, reentrancy guards, and audit-ready documentation.

I hope this series has given you a real-world look at what security-first Web3 engineering actually looks like. Keep building, stay paranoid, and write excellent code.

Thinking Like an Attacker: The Airbags and Seatbelts of Smart Contract Security

Tue, 26 May 2026 07:00:00 +0000

In our last post, we built a mathematical proving ground using Foundry. We used stateful fuzzing to prove that the rules of our MilestoneCrowdfundUpgradeable protocol work exactly as intended.

But testing only proves that the contract behaves correctly when people follow the rules. What happens when someone actively tries to break them?

In Web2, when you think about security, you think about the perimeter. Who can get in? You build firewalls, you require authentication, you set up rate limiting. The attacker is outside the system, trying to break down the door.

In Web3, there is no perimeter. Your contract is public. The state is public. Every single function is readable by anyone on earth the moment you deploy it. The attacker is not trying to get past a wall, they are standing inside the room with you, reading your rulebook, looking for a sentence that contradicts itself.

So, my security-first mindset when I sit down to write Solidity is this: I am writing rules for a system that a brilliant, motivated, financially incentivized adversary will study longer and harder than I wrote it.

In this post, I want to show you exactly how I design against those adversaries. We are going to look at the most infamous hack in Web3 history, how to prevent it using the golden rule of smart contracts, and the real-world edge cases I had to actively design around.

The Refund Kiosk Glitch

To understand the most dangerous exploit in smart contracts, you don't need to understand code yet. You need to understand the refund kiosk glitch.

Imagine a store installs a new, automated self-service refund kiosk. It works like this:

You scan your receipt.
The machine dispenses your cash.
The machine marks your receipt as "refunded" in the database.

A clever person notices something. Between step 2 and step 3, there is a processing gap: a brief moment while the database updates.

So, the attacker builds a device and physically attaches it to the kiosk's cash dispenser slot. When cash drops into the tray, the weight of the notes triggers a pressure sensor inside the device, which automatically scans the receipt again immediately.

The attacker does not press any buttons. The act of receiving cash is itself the trigger for the next scan.

The kiosk checks the database: "Is this receipt already refunded?" The database still says no, because step 3 hasn't happened yet. So the kiosk dispenses again. Cash drops. The pressure sensor fires. The receipt scans again. The database still says no. It dispenses again.

This loop continues until the machine is completely empty. Nobody held anyone at gunpoint. The machine was following its own rules perfectly, it checked the ledger every single time before it paid. It just checked a ledger that was always one step behind reality.

The fix is incredibly simple. You just change the order of operations at the kiosk:

Scan your receipt.
Mark it as refunded in the database immediately.
Now, dispense the cash.

Now, when the cash drops and the pressure sensor fires a second scan, the kiosk checks the database, sees it is already refunded, and dispenses nothing. The loop never starts. By updating the internal record before handing over the cash, we close the exploitation gap entirely.

In smart contract engineering, this fix is called Checks-Effects-Interactions (CEI).

Check: Does this user have a valid claim?
Effect: Zero their balance in the ledger right now, before a single coin moves.
Interaction: Now, send the money.

Reentrancy: The Kiosk on Ethereum

Now that you understand the kiosk glitch, you already understand Reentrancy. Because Reentrancy is exactly that glitch, running on a blockchain.

In Ethereum, when your smart contract sends ETH to an address, if that address belongs to another smart contract, it can execute code the exact moment it receives the ETH. That receiving code is called a receive() function.

That receive() function is the pressure sensor. The attacker writes it once, deploys their contract, and the blockchain executes it automatically the moment ETH arrives. They do not manually trigger anything. The callback is a feature of how ETH transfers work, turned into a weapon.

Here is what the attacker's contract looks like:

contract Attacker {
    MilestoneCrowdfund public target;

    // The pressure sensor: When this contract receives ETH, 
    // it immediately calls claimRefund again, before the first call finishes!
    receive() external payable {
        target.claimRefund(campaignId);
    }

    function attack() external {
        target.claimRefund(campaignId);
    }
}

If we sent the money before updating our internal ledger, this attacker would drain our entire protocol in a single transaction. But because we use the Checks-Effects-Interactions pattern, look at the exact order of the claimRefund function inside MilestoneCrowdfundUpgradeable:

// 1. CHECKS: Does the user have a valid claim?
uint256 userPledge = _pledges[_id][msg.sender];
if (userPledge == 0) revert MilestoneCrowdfund__NoContribution();

// 2. EFFECTS: Update the ledger first, before money moves!
_pledges[_id][msg.sender] = 0;

// 3. INTERACTIONS: Now the money moves.
(bool success,) = payable(msg.sender).call{value: refundAmount}("");

By zeroing _pledges[_id][msg.sender] before the ETH moves, every malicious reentrant call finds a zero balance and reverts immediately. The ledger is never one step behind.

As a second line of defense, I also use OpenZeppelin's nonReentrant modifier. It works by setting a lock flag at the start of the function. Think of it as a door that locks behind you the moment you step inside. If the malicious receive() function tries to call claimRefund again, it slams into that locked door, and the entire transaction instantly reverts.

CEI makes the contract logically correct. nonReentrant makes it mechanically impossible to reenter. I tell every junior developer: do not choose between them. Use both. CEI is the airbag. nonReentrant is the seatbelt. You want both in the car.

The Real Edge Cases I Had to Design Around

Security isn't just about stopping hackers; it's about mitigating the risks of your own design choices. There were two specific edge cases I had to actively design around.

1. The Live Fee Rate
In MilestoneCrowdfundUpgradeable, the platform fee (defaultFeeBps) is a global variable that the owner can change at any time. This means two donors to the exact same campaign could pay different effective fees if the owner changes the rate between their pledges.

Why design it this way? Because the stakeholder explicitly requested the flexibility to run dynamic fee promotions. I immediately flagged the vulnerability to them: what if a compromised owner key raised the fee to 5% right before a massive whale pledge, and then immediately lowered it back? This would silently skim thousands of dollars from a single donor, and unless you were watching the transaction pool in real-time, it would be almost invisible.

I agreed to the stakeholder's requirement, but only with a strict mitigation strategy. The defense here isn't in the Solidity code, it is in the governance architecture. The owner is strictly documented as an Admin Multisig wallet. A single compromised key cannot change the fee unilaterally. The system around the code must be designed with the same rigor as the code itself.

2. The Dust Sweep
When dividing milestones by percentages, integer division always leaves a tiny fraction of a cent (wei) permanently locked in the contract. To prevent this "dust" from being lost forever, my contract uses a special code path for the final milestone:

if (c.milestonesReleased == c.milestoneCount) {
    amountToRelease = c.totalRaised - c.totalWithdrawn;
}

It simply sweeps whatever is left. But I had to ask myself rigorously: Can this sweep ever release MORE than it should? The mathematical guarantee that it cannot is my invariant: totalWithdrawn <= totalRaised. That is precisely what that same 4,495-second fuzz run from the last post was verifying. The fuzz test isn't decoration; it is the mathematical evidence that this final sweep is safe.

The BinnaDev Takeaway

If you are a junior developer about to deploy your first contract that holds real ETH, here is my ultimate advice to you:

Do not deploy until you can answer this question about every function that sends money: "What happens if the recipient is a malicious contract?"

Not a normal wallet. A smart contract. With a receive() function you did not write, controlled by someone who wants your users' funds, with a pressure sensor already wired and waiting.

If you cannot answer that question confidently for every single external call in your codebase, you are not ready to deploy. Go back and apply the Checks-Effects-Interactions pattern to every function that moves value. Add nonReentrant to every function that moves value. Then ask the question again.

The developers who get hacked are not the ones who don't know about reentrancy. They are the ones who know about it in theory, but did not sit down with their own code and ask that exact question. Knowledge without application is not protection.

Read your own code as if you are the attacker. The moment you find something that makes you uncomfortable as the attacker, you have found something to fix as the engineer. If you want a structured baseline for this evaluation, I highly recommend reading Trail of Bits' excellent post, Can You Pass the Rekt Test? It is a mandatory checklist for any serious Web3 engineering team.

Sleep comes after that review. Not before.

We have architected the protocol, proven the math, and secured the vault. But a secure protocol is useless if no one knows how to safely interact with it. In our fifth and final post, we are going to talk about the most underrated skill in Web3: Writing Audit-Ready Documentation.

Stop Guessing, Start Proving: A Guide to Stateful Fuzzing in Foundry

Mon, 25 May 2026 17:31:16 +0000

We are building MilestoneCrowdfundUpgradeable: a smart contract that holds donor funds in escrow and releases them only when real-world milestones are verified. In our last post, we designed the engine for this protocol. We built a theoretical fortress guarded by strict mathematical laws.

But in Web3, a theoretical fortress isn't good enough. If you write a web app and it has a bug, a button doesn't work. If you write a smart contract and it has a bug, people lose their life savings. Testing isn't an afterthought; it is a matter of life or death for your protocol.

To test this protocol, I didn't just write a few scripts to see if the functions worked. I built a mathematical proving ground. In this post, I want to show you exactly how I did that. We are going to talk about why I switched to Foundry, how to use a "fuzzer" to find your blind spots, the magic of Ghost Variables, and the hardest lesson I learned about testing state machines.

The Shift: Why I Chose Foundry Over Hardhat

When I write tests in Hardhat, I am writing JavaScript that talks to a Solidity contract. There is a translation layer between my brain and the blockchain. I find myself fighting JavaScript's async/await, weird big-number edge cases, and ABI encoding at the exact same time I am trying to think about protocol correctness. It's exhausting.

Foundry breaks that barrier. In Foundry, your tests are written in Solidity. The EVM (the actual engine that runs Ethereum) is the test runtime. That means there is no JavaScript middleman translating your code. If I want to pretend to be a user named Alice, I just write vm.prank(alice). If I want to fast-forward time by 30 days, I write vm.warp(block.timestamp + 30 days). It reads like pseudocode.

But the single biggest reason I switched, the one that changed how I think about testing entirely is exactness. In Hardhat, you approximate gas. In Foundry, the gas numbers in your test output are the exact gas numbers you will see on mainnet. When you're designing a crowdfunding protocol where everyday donors are paying for every pledge call, that exactness matters enormously.

Hardhat is an incredible tool for deployment and scripting, but Foundry was built from the ground up for testing. That is not a knock on Hardhat, it is just not the same tool.

Stateless Fuzzing: Why Random Beats Hardcoded

Here is the problem with writing pledge(100) in your test suite. Your brain picked the number 100. Your brain also wrote the smart contract. So your test is testing your own assumptions, not the contract's actual behavior. You have the same blind spots on both sides of the assertion.

Stateless Fuzzing breaks that loop. A fuzzer is a robot that throws thousands of random, chaotic inputs at your contract to see what breaks.

For example, I wrote a function to calculate the platform fee (_calculateFeeAndNet). The obvious test is: gross = 1000, fee = 5%, expect net = 950. That passes. Fine.

But what does the Foundry fuzzer actually throw at it?

gross = 1, fee = 4.99%. (Does integer division correctly floor the fee to zero, leaving the full amount as the net?)
gross = type(uint256).max. (Does it trigger an overflow crash before the math finishes?)
fee = 0. (Does the contract actually return (gross, 0), or does it accidentally return (0, 0)?)

None of those are inputs I would naturally write. The fuzzer doesn't have my assumptions. That's its superpower.

This was crucial for my Basis Points (BPS) math. I wrote a helper to divide 10,000 BPS across n milestones. I could have hardcoded an array of 3 milestones and called it done. Instead, the fuzzer randomly varies n on every single run. Eventually, it tries n=1 (a single milestone getting 100%) and n=20 (20 milestones, each getting ~500 BPS, with the last one absorbing all the mathematical rounding dust). Those extreme edge cases stress the math in ways a handwritten array never would.

Stateful Fuzzing & Ghost Variables: The Bank Auditor

Stateless fuzzing tests one function at a time. But a crowdfunding contract isn't a calculator, it's a state machine. The bug is almost never in a single function in isolation. It's in the sequence. pledgeETH is fine. withdrawMilestone is fine. But what happens if the sequence is pledgeETH -> setFee -> pledgeETH -> finalize -> withdrawMilestone? That is where the accounting drifts.

To test sequences, we use Stateful Fuzzing.

To explain how this works, imagine you are a Bank Auditor. You want to verify that a bank teller never gives out more money than was deposited. You could stand at the counter and check after every single transaction. But the teller's official ledger is locked inside a vault you can't open. You can only see the cash they hand to customers.

So, you bring your own notepad. Every time someone deposits $100, you write "+$100" on your notepad. Every time someone withdraws, you write "-$50". At the end of the day, your notepad says the vault should hold exactly $50. If the vault actually holds $40, something went wrong in the sequence of the day's transactions.

In my Foundry tests, that "notepad" is called a Ghost Variable.

The actual pledge ledger inside my smart contract (_pledges) is private. The test suite can't read it easily. So, I built a Handler contract that acts as the Auditor. It carries ghost_netPledge, its own running tally of what the contract should contain. Every time a random pledge succeeds, the handler writes it down. Every time a refund succeeds, it zeroes that entry.

At the end of thousands of random actions, the test asks: Does the real smart contract match my notepad? Imagine a scenario where Alice pledges 1 ETH, but a bug prevents the platform fee from being deducted. My Ghost Variable notepad records 0.95 ETH (the net), but the contract's getPledge() returns 1.00 ETH. The moment they diverge, the invariant fires. The fuzzer stops and prints the exact 12-call sequence that broke the math. That sequence is my counterexample. That's the bug report.

The Struggle: 4,495 Seconds of Patience

Here is the part nobody talks about in tutorials.

You can see it in the screenshot from my terminal. 4,495 seconds. That is over an hour and fifteen minutes of my laptop running at full capacity just to complete one single test run.

That number tells the real story of stateful fuzzing. My fuzzer ran this long because of the rigorous constraints I set. Here is exactly how I configured it. runs is how many random sequences the fuzzer invents, depth is how many calls deep each sequence goes, and the seed ensures the run is mathematically reproducible so I can track down bugs:

[invariant]
runs = 1000
depth = 300 
fail_on_revert  = false
call_override_addr = false

[fuzz]
runs = 1000
max_test_rejects = 65536
seed = "0x63726f776466756e64"

The fuzzer is not running one test, it is inventing thousands of random call sequences, executing them, and checking whether the math breaks. That computational cost is the point. You are paying for thoroughness with time.

But the truly humbling part is the feedback loop.

When you write a normal unit test and something breaks, you fix it and rerun it in seconds. With a stateful fuzz suite, the cycle feels like this:
Find a bug -> fix the contract -> wait 75 minutes -> find another bug -> fix -> wait another 75 minutes.

Now, to be fair to Foundry, it does provide a lifesaver here. When a stateful fuzz run fails, Foundry gives you the exact seed and call sequence, allowing you to replay just that one failed scenario in seconds without having to rerun the entire 75-minute suite. But the broader lesson remains.

You learn very quickly to think carefully before you type. Every structural change carries a heavy price tag in computational validation. That constraint made me a more deliberate engineer. I stopped making small speculative fixes and started reasoning through the problem fully on paper before touching the code.

The Coverage Illusion

Now look at the numbers in that screenshot more carefully.

MilestoneCrowdfundUpgradeable.sol - 100% line coverage, 100% function coverage.

A junior developer sees that and thinks: We are done, the protocol is safe. I want to push back on that directly. 100% coverage does not mean 100% secure. Not even close.

Coverage only tells you that the fuzzer visited every line. It does not tell you whether the mathematical rules governing those lines can be broken by a clever sequence of calls. A line can be executed ten thousand times and still contain an accounting bug that only surfaces on the ten-thousand-and-first call in a specific order.

This is why the invariants matter more than the coverage number. The invariants are the rules that must never break:

totalWithdrawn must never exceed totalRaised, otherwise, the creator is stealing from future refund claimants.
sum(milestoneBps) must always equal 10,000, otherwise, the math will trap dust in the contract or fail to release the full amount.
totalWithdrawn + totalRefunded must never exceed totalRaised, otherwise, the contract is paying out money that was never deposited, meaning it has become completely insolvent.

If those rules hold across thousands of random sequences, the protocol math is battle-tested. If coverage is 100% but an invariant breaks, you have a vulnerable protocol with a false sense of security. I would rather have 80% coverage and unbreakable invariants than 100% coverage and uninspected state transitions.

The Advice I Would Give My Fellow Dev

Stop writing tests that only ask "did this function return the right number?"

Start writing tests that ask "can this sequence of 50 random actions, executed by strangers in any order, break the rules this protocol was built on?"

Unit tests are essential, do not skip them. But they test your assumptions. The fuzzer tests your blind spots. Once you understand state machines and invariants, you stop guessing whether your protocol is safe and start proving it. That shift in thinking from hoping the code is correct to mathematically verifying it is the difference between a developer and an engineer.

The argument for trusting your test suite is never complete until you prove it works. Before I trusted my invariants, I deliberately broke my own contract. I went into pledgeETH and changed c.totalRaised += net to c.totalRaised += gross. I ran the suite. Instantly, Invariant 6 fired and the test failed. That is the difference between claiming your alarm system works and proving it by tripping it yourself.

The 4,495 seconds were worth every one.

Your protocol can pass every invariant and still be drained in a single transaction. In the next post, we look at how.

Smart Contracts Demand Better Infrastructure: Building on contract.dev

Sat, 23 May 2026 06:55:56 +0000

When you first start writing smart contracts on the EVM chains, your journey usually begins in Remix. It is a powerful, open-source web and desktop application for writing, compiling, testing, and deploying code, making it a fantastic tool for quick iterations and local simulations. But eventually, you outgrow it. Even with its robust features, a localized environment does not perfectly replicate how your contract will interact with live mainnet state.

To truly test a protocol, you move to a public testnet. This is where the engineering friction begins.

You suddenly need to set up an Alchemy or Infura account just to get an RPC URL. Then comes the faucet fatigue. You scour Discord or click traffic lights on web pages just to beg for a fraction of Sepolia ETH. Many faucets now require a minimum mainnet balance to prevent spam. This is a massive roadblock if you are following basic security practices.

To protect your real-world funds, you should never paste your primary wallet's private key into a local .env file where an accidental GitHub push or a malicious package could expose it. Instead, you use fresh, $0-balance "dummy" accounts. But when a faucet requires a mainnet balance, it breaks this safety measure, forcing you to either risk your real wallet or fund a dummy account with real money just to get testnet tokens. Others force you to connect your personal social media and tweet just to get a single drop.

If you are designing a system that requires multiple actors like a Client, a Provider, and an Arbiter in an Escrow, this friction multiplies. You either have to repeat this frustrating process for three separate wallets, or manually transfer tokens between them. And ironically, those manual transfers still cost you the precious testnet gas you just spent time trying to collect.

The testing infrastructure quickly becomes more exhausting than writing the actual architecture.

Recently, I began exploring ways to reduce this environmental friction and found a highly practical workflow using contract.dev. It provides the visual simplicity of a tool like Remix, but on a globally accessible, private EVM testnets that replay mainnet state and come with built-in tools for testing, analysing, and simulating smart contracts before launch.

Here is a look at how I approach testing a 3-actor Escrow system visually, eliminating local node overhead and faucet fatigue so I can focus purely on protocol behavior.

The Architecture: A Trust-Minimized Escrow

To demonstrate this workflow, I built TrustEscrow.sol. The architecture is designed to be reusable and relies on strict access control across three distinct roles:

Client: Funds the escrow.
Provider: Executes the work and receives the funds.
Arbiter: A neutral third party that resolves disputes.

Because the state transitions depend entirely on who is calling the function, verifying role transitions is critical. I explicitly designed this contract with a resetEscrow function to allow continuous lifecycle testing without needing to redeploy the contract. Here is the core state machine governing the escrow:

enum Stage {
    AwaitingFunding, // 0 - deployed or reset, waiting for client
    Funded,          // 1 - ETH held; work in progress
    Completed,       // 2 - client released funds; ready for reset
    Disputed,        // 3 - either party raised a dispute; arbiter needed
    Resolved         // 4 - arbiter settled dispute; ready for reset
}
Stage public stage;

(Note: Making the state explicitly public is a deliberate choice here, it allows visual dashboards to read and display the exact stage of the protocol later in the workflow).

Normally, verifying these transitions requires writing extensive .t.sol files with heavy vm.prank() overhead. Here is how we can verify them visually on a live network instead.

Step 1: The Instant Environment (No Alchemy, No Faucets)

The immediate relief of this workflow is the infrastructure. By creating a project on contract.dev, I was instantly handed a live Stagenet RPC URL. No third-party node providers required.

To test this escrow, I needed three distinct, funded wallets. Instead of configuring these locally or begging a public faucet, I used the platform's Wallet Generator to spin up accounts for the Client, the Provider, and the Arbiter.

Using the built-in Stagenet Faucet, I funded the Client's wallet with 100 ETH instantly. This is a live RPC that anyone in the world can interact with. You get the freedom of a public testnet without the artificial scarcity of testnet tokens.

Step 2: CI/CD Sync and Deployment

Unlike local nodes, the platform doesn't just guess your contract's ABI. By linking my GitHub repository, the platform's CI/CD pipeline automatically synced and compiled my Foundry project.

To deploy, I didn't have to learn a new framework. I simply opened my terminal and ran my standard Foundry deployment script (forge script), pointing it to the new Stagenet RPC and my newly funded wallet private key.

The moment the transaction confirmed on the network, the platform detected the deployed contract and automatically generated a Workspace: a dedicated visual dashboard perfectly mapped to my Solidity code.

(Crucial note for advanced developers: Unlike a local simulation, this Stagenet utilizes Mainnet Replay. It actively mirrors live mainnet state. If your contract interacts with live Uniswap liquidity or Chainlink oracles, you can test against those live states immediately without writing complex fork scripts).

Step 3: Verifying State Transitions

When testing architecture, immediate feedback is invaluable. Using the Account Impersonation feature directly from the dashboard UI, I impersonated the Client and executed the fundEscrow() transaction with 1 ETH.

The Workspace updated in real-time to reflect the new reality. Instead of relying on terminal queries or cast call commands, the dashboard visually confirmed that the contract balance was strictly locked at 1 ETH, and the stage variable had transitioned correctly from AwaitingFunding to Funded.

Continuing the simulation, I impersonated the Provider to raise a dispute, and finally the Arbiter to resolve it. The entire lifecycle of a complex 3-actor protocol was verified in seconds.

Step 4: Automating the Ecosystem (AI User Activity)

Manually clicking through a happy path is great for an initial sanity check. But what if you want to simulate a living, breathing protocol under continuous load? Normally, this requires writing complex Hardhat scripts or custom bots to continuously fire transactions and redeploy contracts.

This is where my workflow completely changed.

The platform includes an Activity Scheduler powered by AI. Instead of writing mock scripts, the AI reads your contract's source code, ABI, and storage layout, and designs realistic user personas for your specific protocol.

Because I built TrustEscrow to be reusable via the resetEscrow function, the AI was able to create infinite, continuous testing loops. With one click, it generated new dummy wallets, funded them, and scheduled recurring transaction workflows. In my Workspace, it automatically created two distinct, recurring timelines:

The Happy Path: It scheduled the Client to fundEscrow, releaseFunds, and resetEscrow every 20 blocks.
The Dispute Path: It scheduled a complex continuous workflow of fundEscrow -> raiseDispute -> resolveDispute -> resetEscrow every 30 blocks.

I didn't have to write a single line of testing script. I was able to sit back and watch the Stagenet process concurrent, multi-actor state transitions continuously.

Bridging the Frontend Gap

Beyond testing smart contract logic, this approach solves a very real integration problem.

When you build in Remix or on a local Anvil node, handing the protocol off to a frontend developer usually requires them to recreate your local environment just to build the UI.

Because a Stagenet is a persistent, globally accessible network, you can simply share the RPC URL with your frontend team. You hand them a live, fully-funded sandbox where the AI Activity Simulator is already generating realistic background traffic. They can begin building the interface immediately against predictable, living data.

Final Thoughts

Smart contracts handle real value, so engineering them requires a deep focus on security, invariants, and mathematical correctness. Testing infrastructure should support that focus, not distract from it.

While robust local environments are great for early iterations, serious architecture requires a production-like setting. Visual testing on a Stagenet makes it easier to observe protocol behavior, simulate concurrent user activity, and collaborate with your team without getting bogged down in RPC setups and faucet fatigue.

If you are tired of fighting local nodes to test multi-wallet architecture, I highly recommend integrating a visual Stagenet into your workflow.

You can view the full TrustEscrow architecture on my GitHub here: github.com/obinnafranklinduru/trust-escrow

Glossary of Terms (For the Curious)

EVM (Ethereum Virtual Machine): The underlying engine that processes and executes smart contracts on Ethereum and other compatible blockchains. Web2 Analogy: Think of it like the global operating system or server environment (like Node.js or AWS) that runs your code.
RPC URL: The digital bridge that allows your interface to communicate with the blockchain. Web2 Analogy: Just like an API endpoint connects a frontend web app to a backend database.
Faucet: A developer service that provides free test tokens. Web2 Analogy: Like getting free "sandbox credits" in Stripe to test payments without using real credit cards.
Mainnet vs Testnet: Mainnet is the live network with real financial value. A testnet is a public sandbox with zero-value tokens. Web2 Analogy: Mainnet is your live "Production" environment. A testnet is your "Staging" environment.
Stagenet: A private testing environment that actively mirrors the live mainnet state. Web2 Analogy: A high-fidelity staging server that has been perfectly synced with a live copy of your production database.
Private Key: The secret cryptographic password that grants total control over a wallet and its funds. Web2 Analogy: The root password to your bank account.
.env File: A hidden local file used to store sensitive information securely. Web2 Analogy: It serves the exact same purpose in Web2—keeping API keys and passwords out of public GitHub repositories.
ABI (Application Binary Interface): A file that acts as a translation manual telling a frontend exactly how to interact with a compiled smart contract. Web2 Analogy: Like an OpenAPI/Swagger document that defines the endpoints and expected payloads for a REST API.
State Machine: An architectural pattern where a contract can only exist in one specific stage at a time (e.g., AwaitingFunding or Completed). Web2 Analogy: Like an e-commerce order that must strictly move from 'Pending' -> 'Shipped' -> 'Delivered' without skipping steps.
Foundry: A fast, specialized command-line toolkit used for compiling, testing, and deploying smart contracts. Web2 Analogy: A mix between a build tool (like Webpack) and a testing framework (like Jest).
vm.prank(): A specific testing command used to impersonate a different user to verify access controls. Web2 Analogy: Like a "Login as User" feature in an admin dashboard to test what a specific customer sees.

Unboxing My New OneKey Classic 1S Hardware Wallet

Tue, 19 May 2026 13:57:58 +0000

There are moments in crypto when you realize that security is no longer optional — it becomes a responsibility.

After spending years working with blockchain infrastructure, nodes, wallets, and decentralized systems, I finally decided to move part of my operational environment toward a dedicated hardware wallet experience.

And honestly… I did not expect the experience to be this good.

First Impressions

The first thing that surprised me about the OneKey Classic 1S was the packaging quality.

Everything arrived professionally sealed and protected, giving a very strong first impression focused on authenticity and tamper protection. In a market where hardware wallet trust is everything, details like this matter much more than people think.

The packaging feels premium without being unnecessarily excessive.
Minimalistic. Clean. Professional.

You immediately notice that security was considered from the very beginning of the user experience.

Security Seals & Packaging Quality

One of the biggest concerns when purchasing a hardware wallet is whether the device could have been manipulated before arrival.

Fortunately, the OneKey Classic 1S arrived:

Completely sealed
Properly protected
Professionally packaged
With visible security-focused presentation

The unboxing experience genuinely felt closer to opening a high-end security device than a simple crypto accessory.

That matters.

Especially today.

Setup Experience

I expected the installation process to be complicated or technical.

It wasn't.

The wallet initialization and software setup process was relatively simple and intuitive.

The official OneKey software guided the entire process step-by-step, including:

Wallet creation
Recovery phrase backup
Device verification
Security confirmation
Connection process

Even for users who are not deeply technical, the experience feels approachable and clean.

Build Quality

The device itself feels solid and surprisingly lightweight.

The physical buttons are responsive, the screen is clear, and the overall design has a professional aesthetic that feels modern instead of outdated.

Some hardware wallets still look and feel experimental.

The OneKey Classic 1S does not.

It feels polished.

Why This Matters

In recent months, the crypto ecosystem has seen increasing concerns related to:

Wallet compromises
Malicious smart contracts
Fake applications
Phishing attacks
Blind signing risks

Because of that, I started looking more seriously into dedicated cold-storage solutions with:

Strong security architecture
Transparent development
Open-source firmware
Clear signing support
Modern ecosystem compatibility

The OneKey ecosystem checked many of those boxes.

Final Thoughts

The truth is simple:

I expected a decent hardware wallet.

What I received was a much more polished experience than anticipated.

From the packaging quality to the onboarding process, the OneKey Classic 1S gave a very strong first impression.

For anyone looking to improve their crypto security setup while keeping usability simple, this device is definitely worth researching.

Official Link + 10% Discount

If you want to check the device directly from the official website, you can use my referral link here:

https://onekey.so/r/MUGY73

You can also use the discount code:

MUGY73

to receive 10% OFF on your purchase directly from the official OneKey website.

Don’t touch Fabric unless you’re ready for distributed headaches ‍

Sun, 17 May 2026 17:10:50 +0000

Building a VIP Vehicle Inventory System with Hyperledger Fabric

I recently started designing a new blockchain project focused on managing exclusive vehicle inventories for VIP collectors using Hyperledger Fabric.

The idea is to build a permissioned system where verified members, dealers and validators can securely manage high-value vehicle assets, ownership history and inventory access while keeping sensitive data private.

One thing I’m realizing very quickly is that Fabric is very different from typical blockchain development.

At first, concepts like:

MSPs
endorsement policies
peers
orderers
private data collections

felt less like blockchain and more like trying to assemble enterprise IKEA furniture without instructions ‍

But the deeper I go, the more I understand why enterprise blockchain architecture requires this level of structure and permission management.

Right now I’m focusing on:

defining actors and trust models
modeling business logic
planning chaincode structure
understanding what belongs on-chain vs off-chain

Still early in development, but excited to keep building and documenting the process.

Hyperledger #Fabric #Blockchain #Web3 #SmartContracts

Building an AI-Native Cross-Chain Swap System with MCP, Claude Code, and Garden Finance

Tue, 12 May 2026 11:17:32 +0000

Cross-chain swaps are tedious by design.

Open a browser. Connect a wallet. Approve a token. Copy addresses between tabs. Sign again. Wait for confirmations. Hope nothing breaks midway through the flow.

I got tired of it. So I asked a different question:

What if the entire experience — quote, approval, signing, broadcasting, settlement — happened from a single terminal command?

swap 0.0005 wBTC to BTC

That's the goal I set. Here's how I built it, what I learned, and where it's going.

The Real Insight (Read This First)

Most blockchain tooling is built for UIs. REST APIs, ABIs, wallet popups — all of it assumes a human is clicking through a browser.

But AI systems don't click. They call tools, compose workflows, and orchestrate steps.

The insight that drove this entire project:

Modern AI works best when infrastructure is designed for it — not retrofitted around it.

Instead of wrapping another UI around Garden Finance's swap infrastructure, I made the AI system itself the interface. That one decision changed everything about how I structured the architecture.

The Final Experience

Inside Claude Code, you type:

swap 0.0005 wBTC to BTC on mainnet

Claude responds:

Using saved configuration:

• RPC URL: https://mainnet.infura.io/v3/...
• Bitcoin destination: bc1p...

Quote:
  Sending:   0.0005 wBTC
  Receiving: 0.00048712 BTC
  Solver:    hashira

Confirm? (yes/no)

After confirmation, the entire workflow executes automatically:

ERC-20 approval
Initiate transaction
Order polling every 5 seconds
Bitcoin redemption tracking through to final settlement

No browser. No tab switching. No manual signing prompts. Just the terminal.

System Architecture

The project is a four-layer AI-native infrastructure stack:

AI Client Layer
(Claude Code / Cursor)
        ↓
Orchestration Layer
(Claude Code Skill)
        ↓
Capability Layer
(Garden MCP Server)
        ↓
Protocol/API Layer
(Garden Finance API)

Each layer has exactly one job:

Layer	Responsibility
Claude Code / Cursor	Natural language interface
Claude Skill	Workflow orchestration
Garden MCP	AI-consumable protocol capabilities
Garden Finance API	Swap infrastructure

The separation turned out to be the most important architectural decision in the project.

The MCP layer exposes capabilities. The skill layer orchestrates workflows. Sensitive operations stay local. Nothing bleeds across boundaries.

Part 1 — The Garden MCP Server

The first thing I built was an MCP server that wraps Garden Finance's swap infrastructure and makes it natively consumable by AI systems.

The key design decision: expose semantic tools, not protocol primitives.

Instead of making Claude deal with raw API endpoints and low-level transaction construction, the MCP server exposes high-level tools that model user intent:

Tool	Description
`get_quote`	Get a swap quote between assets
`create_order`	Submit a cross-chain swap order
`get_order_status`	Poll an order until completion
`get_all_user_orders`	Fetch wallet order history
`get_assets`	List supported assets
`get_chains`	List supported chains
`get_liquidity`	Fetch real-time liquidity

LLMs perform significantly better when tools represent capabilities and semantic actions instead of low-level protocol primitives. That single design choice made the orchestration layer dramatically more reliable.

Hosted Endpoints

The MCP server runs remotely over HTTP — no local setup required. Connecting it to Claude Code is a single command:

# Mainnet
claude mcp add --transport http garden-mainnet [mainnet-endpoint]/mcp

# Testnet
claude mcp add --transport http garden-testnet [testnet-endpoint]/mcp

Or manually via .claude/settings.json:

{
  "mcpServers": {
    "garden-mainnet": {
      "type": "http",
      "url": "[mainnet-endpoint]/mcp"
    },
    "garden-testnet": {
      "type": "http",
      "url": "[testnet-endpoint]/mcp"
    }
  }
}

The same server works with Claude Code, Cursor, and any other MCP-compatible client without modification.

Server Architecture

The server uses MCP Streamable HTTP transport in stateless mode — each request spins up a fresh server instance:

MCP Client (Claude Code, Cursor, ...)
        │
        ▼
garden-mcp
(Express + StreamableHTTPServerTransport)
        │
        ▼
Garden Finance API

Stateless mode works perfectly here because all tools are pure API proxies with no session requirements. It also gives horizontal scalability, simpler deployments, and predictable execution for free.

Part 2 — The Claude Code Skill

The second component is the orchestration layer: a Claude Code skill that handles the full swap workflow end-to-end.

Claude Code skills are structured execution workflows that activate automatically based on user intent. This one triggers for prompts like:

swap wBTC to BTC
bridge my BTC to Ethereum
swap 0.001 BTC to wBTC

The skill itself contains no protocol logic. Instead, it coordinates:

MCP tool calls for quote discovery and order creation
Local TypeScript signing scripts (more on why below)
Shell commands and polling loops
Keychain-based secret management

Automatic MCP Registration

One onboarding detail I wanted to get right: the skill automatically checks whether the Garden MCP tools are registered, and registers them silently if not:

claude mcp list 2>/dev/null | grep -q garden-mainnet || \
  claude mcp add --transport http garden-mainnet [endpoint]

If missing, Claude registers the MCP server and asks the user to restart. Almost all manual setup friction is gone.

The Trust Boundary That Matters

One thing intentionally stays outside MCP: transaction signing.

Private keys should never leave the local machine. So all signing happens through small local TypeScript scripts executed with Bun:

get-address.ts — derive EVM address from private key
btc-get-address.ts — derive Bitcoin Taproot address
sign-and-initiate.ts — ERC-20 approval + initiate transaction
btc-send.ts — fund Bitcoin HTLC

The orchestration layer pipes MCP responses directly into these local scripts:

cat /tmp/garden-order.json | (
  cd ~/.claude/skills/garden &&
  GARDEN_PRIVATE_KEY=$(security find-generic-password -a garden -s garden-pk -w) \
  ETH_RPC_URL=<ETH_RPC_URL> \
  bun run scripts/sign-and-initiate.ts
)

This creates a clean, explicit trust boundary:

Component	Responsibility
MCP Server	Remote capabilities
Claude Skill	Workflow orchestration
Local Scripts	Signing and broadcasting
macOS Keychain	Secret storage

The private key never appears in Claude's conversation context.

Keychain Integration

The first version required entering a private key every session. Terrible UX and unnecessary risk.

The skill now integrates directly with macOS Keychain. Stored values include the private key, Ethereum RPC URL, and Bitcoin destination address. Each signing script fetches secrets directly from Keychain at execution time — never from the conversation, never from environment variables Claude can see.

The Full Swap Flow

When you type swap 0.0005 wBTC to BTC, here's what actually happens:

Verify MCP availability (register automatically if missing)
Load credentials from Keychain
Resolve any missing configuration
Derive wallet addresses locally
Fetch swap quote through MCP
Present quote and confirm with user
Create swap order via MCP
Sign and broadcast initiation locally
Poll order status every 5 seconds
Return final redeem transaction hash

The same flow handles BTC → wBTC, mainnet, and testnet through the same conversational interface.

Testnet Swaps

We ran a full suite of testnet swaps across both directions:

wBTC → BTC on Sepolia + Bitcoin testnet
BTC → wBTC on Bitcoin testnet + Sepolia

The flows are completed end-to-end, including ERC-20 approval, HTLC funding, solver initiation, and redemption tracking. Keychain secret storage, automatic MCP registration, and polling logic all behaved correctly under real swap conditions.

We're continuing to use the testnet environment for internal validation before making this publicly available. Once the signing scripts are hardened and the skill is stable across edge cases, and also after we handle all the security issues that could crop up, we'll open it up.

Why MCP Is the Right Abstraction Here

After building this, MCP's value as an abstraction layer became obvious.

Instead of giving Claude a raw REST API and asking it to figure out request construction, authentication, and error handling — MCP provides:

Structured capabilities with typed inputs
Semantic tool names that match user intent
Deterministic execution surfaces Claude can reason about reliably

The result feels less like "chatting with a bot" and more like programmable infrastructure that happens to accept natural language.

What's Next

A few things on the roadmap:

Windows Credential Manager support
Linux secret-service integration
Ledger hardware wallet support
Streaming swap status updates
More Garden asset pairs
Multi-wallet support
Autonomous swap execution flows

The architecture already composes cleanly enough to support all of them.

Closing Thought

The most interesting thing I built here wasn't the swap itself.

It was the realization that AI-native infrastructure looks fundamentally different from web-native infrastructure. Not because the underlying protocols change — but because the interface layer does.

When the AI is the interface, you stop building UIs and start building capabilities. The distinction sounds subtle. It isn't.

Coder Legion - Recent posts tagged web3

Understanding Gas on the Blockchain: A Practical Guide Using Real Transactions

Separating the Five Core Concepts

Under the Hood: How Does the Blockchain Count Gas?

Case Study One: Calling increment() on Monad Testnet

Case Study Two: Inspecting a Transaction on Ethereum Sepolia Testnet

How Do You Know What Gas Limit to Set?

Understanding Gas Price and Gwei

Decoding EIP-1559: Base Fee, Priority Fee, and Max Fee

Why Do Transactions Need a Gas Limit? (And Why Gas Costs Change)

Comparing the Two Receipts: Are Fees on Monad Expensive?

Common Misunderstandings About Gas (Quick Checklist)

How to Explain Gas to Someone Else

Let's Figure Out the Rest Together

What the DAO Hack, Parity Freeze and Ronin Exploit Teach Us About Immutability

What "Deploying" Actually Means

Two Kinds of Trust

When Forever Goes Wrong

How Engineers Live With It

Every Escape Hatch Is Also an Attack Hatch

DYOR Is Not Just a Meme

Blockchain Isn't About Crypto.It's About a Trust Problem You Didn't Know You Had

Why We Built BinnaDevLab Around This

What Actually Happens When Trust Breaks

What's Next

About BinnaDevLab

Web3 Architecture Explained Like You're 5 (From a Front-End Perspective)

MyZubster: Building a Decentralized Future

From Two Developers to a National Digital Network: Can We Build an Internet That Belongs to Its Participants?

What if we stopped building platforms and started connecting independent people?

1. Decentralization without interoperability is just fragmentation

2. Our first practical experiment: the Node Bridge

3. Local AI could change who controls information

4. What about Tor?

5. Digital identity must become portable

6. Can knowledge become independently verifiable?

7. Why our experiment also includes a comic

8. A nationwide ecosystem needs governance, not just servers

9. There is no sustainable decentralization without an economy

10. The regulatory challenge

11. Five stages from laboratory to possible national adoption

Stage 1: Build and verify

Stage 2: Invite independent participants

Stage 3: Create regional federation experiments

Stage 4: Investigate institutional integration

Stage 5: Support wider adoption

12. The most important metric is independence

Conclusion: The future does not need another digital empire

Explore MyZubster

Building Beyond Platforms: How MyZubster and N4K48 Are Connecting Independent Software, AI, Comics

Building Beyond Platforms: How MyZubster and N4K48 Are Connecting Independent Software, AI, Comics and Verifiable Knowledge

What if the next Internet belonged to its participants?

1. Two developers, two independent environments, one shared experiment

2. When software development becomes a comic

3. Building the bridge between two independent computers

The bug that changed our implementation

4. Where Tor enters our vision

5. Decentralization is not a switch

6. The missing piece in digital collaboration: proof of knowledge

7. What could this paradigm change tomorrow?

8. Our next milestone

9. One ecosystem, independent creators

Follow the journey

From Technical Review to Knowledge Attestation: What We Learned from CoderLegion

Building Evidence Systems That Know What They Cannot Prove

From Blockchain Hashes to Evidence Graphs: What We Learned Building Verifiable Knowledge

Beyond the Hype: The Enterprise Era of Web3, Crypto, and Blockchain in 2026

The Explosion of Real-World Asset (RWA) Tokenization

AI-Powered Smart Contracts and Asset Valuation

Stablecoins as Global Payment Rails

Modular Blockchains and Rollup-as-a-Service (RaaS)

Engineering an Evidence-First Knowledge Graph: From GitHub Artifacts to On-Chain Proofs in MyZubster

From Service-Disabled Veteran to Building Payment Rails for AI Agents

x402 #AIAgents #Web3 #BuildInPublic #OpenSource #VeteransInTech

🚀 MyZubster: Completing a Real Ethereum Sepolia Marketplace E2E Payment Flow

MyZubster #Web3 #Ethereum #Sepolia #Blockchain #React #NodeJS #Express #MetaMask #Cloudflare #CloudflareTunnel #DevOps #E2E #IntegrationTesting #API #JWT #OpenSource #Marketplace #PaymentInfrastructure #SoftwareEngineering

Debugging 6.5 Million PM2 Restarts: Stabilizing MyZubster Sepolia and I-ECO-01

Debugging 6.5 Million PM2 Restarts: Stabilizing MyZubster Sepolia and I-ECO-01

1. Google OAuth Was Reaching the Backend — But Authentication Still Failed

2. The .env File Was Correct — The Running Process Was Not

Case Study One: Calling `increment()` on Monad Testnet

2. The `.env` File Was Correct — The Running Process Was Not

`online` does not mean healthy

`.env` does not equal runtime environment