标签：#Blockchain

A useful thing happened in agent infrastructure this June: several teams shipped "escrow layers for AI agents" - production MCP tools that let an agent run a full commit -> hold -> complete lifecycle without a human anywhere in the loop. An agent can now park value with a contract or service, wait for the other side to deliver, and release on completion. That is genuinely new, and it solves a real problem. It is also worth being precise about, because "escrow" and "settlement" get used as if they were one thing. They are not. There are two structurally different ways to make a trade your agent does at 3am trustworthy, and the difference is exactly who holds the money while the trade is in flight . Model one: held custody In the held-custody model, a third party - a smart contract escrow, a custody service, a payment facilitator - takes the funds, holds them, and releases them when a condition is met. The condition can be anything you can express: a delivery confirmation, an evaluator's attestation, a timeout, a multi-sig approval. This is the right tool for a large class of agent commerce. If your agent is paying a merchant, buying a dataset, or hiring another agent to do a unit of work, the hard question is subjective : did the thing actually get delivered, and was it any good? A hash function cannot see that. A custodian can - it gives the trade a place to pause while something or someone checks. The new agent-escrow tooling is built around exactly this shape: a job, a held balance, a release on completion. For agent-to-merchant payments riding on rails like x402, held custody is the honest primitive. The cost is equally concrete. A held balance is a honeypot. Someone controls the funds between commit and complete, which means someone can freeze them, lose them, misconfigure the release condition, or get drained. You have added a trust assumption and a liveness dependency - the custodian has to be online, solvent, and honest at release time. That is often an accep

Before this week, NFTs on Solana weren't new to me. I've previously worked with Programmable NFTs ( pNFTs ) and even built projects that integrate them. However, most of my experience was centered around the Metaplex ecosystem, so I tended to think about NFTs through that lens. What surprised me during this learning arc was discovering how much can be built directly with Token Extensions. By creating NFTs from the token level upward, I gained a much deeper understanding of the underlying primitives that make digital assets work on Solana. The Mental Model: What Is an NFT on Solana? As developers, we often interact with NFTs through SDKs , frameworks , and marketplace tooling. Those abstractions are useful, but they can hide what's actually happening on-chain. This week helped me simplify the model: An * NFT * is fundamentally a token mint configured with: A supply of one Zero decimals Metadata describing the asset Optional relationships to collections or groups Using Token Extensions, many of these capabilities can be attached directly to the token itself rather than relying on additional programs or infrastructure. That shift in perspective was one of the biggest takeaways from this challenge. What I Built Over the course of this arc, I created an NFT on Solana Devnet using Token Extensions and explored several capabilities that I had never implemented directly before. The process included: Creating a mint configured as an NFT Adding metadata using the Metadata Extension Minting a single token Creating a collection using the Group Extension Associating the NFT with the collection through the Member Extension Auditing the account structure and extension data on-chain Updating metadata after the NFT had already been created One of the most valuable parts of the exercise was inspecting the accounts directly instead of relying solely on SDK abstractions. For example: spl-token initialize-metadata \ <NFT_MINT> \ "My First NFT" \ "MNFT" \ https://example.com/metadata.jso

If you’re a user—owner?—of this cryptocurrency, this is important: On May 29, the security researcher Taylor Hornby found a critical vulnerability in Zcash Orchard privacy pool using Claude Opus 4.8. The Zcash team hired Hornby specifically to look for this kind of issue. He found one fast enough to be embarrassing. The Orchard pool is the newest and most advanced shielded transaction system in the cryptocurrency Zcash. Introduced in 2022, it allows users to send and receive ZEC while keeping transaction details private. It uses zero-knowledge proofs to validate transactions without revealing amounts or participants. The bug: a specific check that was supposed to validate transaction inputs wasn’t actually enforcing the rules it appeared to enforce. An attacker could have exploited the flaw to feed false inputs into that check and generate ZEC from nothing, with the zero-knowledge proof system blessing the fraudulent transaction as valid...

Most "Bitcoin in DeFi" stories quietly route through a custodian or a wrapped representation. You send BTC somewhere, someone (or some bridge multisig) holds it, and you get an IOU on another chain. That works until the thing holding your BTC is the thing that fails. For an autonomous agent that has to post collateral against an obligation it can't babysit, "trust the custodian" is exactly the assumption we're trying to delete. This post is about the alternative: a BTC collateral vault where native Bitcoin backs an obligation on another chain, the release is gated by a hashlock, and the worst case is a refund — not a loss. It's one of the primitives underneath Hashlock's settlement layer. I'll walk through the timelock ordering that makes it safe, the Bitcoin script that enforces it, and the failure modes you design around. Honest status up front: this is signet-validated, not BTC mainnet . The problem in one sentence An agent wants to commit BTC as collateral backing an action on Ethereum — settling a forward, anchoring one leg of a multi-leg trade, guaranteeing a payout — such that the BTC is released to the counterparty only if the corresponding obligation on Ethereum is fulfilled, and returns to its owner if it isn't. No third party should ever be able to hold, freeze, or abscond with the BTC in between. That's a cross-chain conditional. Bitcoin can't read Ethereum state, and Ethereum can't read Bitcoin's. The only thing both chains can independently verify is a hash preimage. So the entire construction hangs on one shared secret. The shared secret, and why timelock order is the whole game Both legs lock to the same hash H = SHA256(s) . Whoever knows the preimage s can claim. The instant s is revealed on one chain to claim a coin, it's public, and the other party copies it to claim the other coin. That's the atomic part: one preimage unlocks both legs or neither. The danger isn't the hash. It's time . If both legs had the same expiry, the party who knows the sec

This week the agent economy got another "settlement layer." Actually it got three. They don't agree on what the word means, and one of them raised $8M to keep saying it. So instead of a new argument, here's the map we drew across the week - four honest meanings of "settlement," what each one is genuinely good at, and the one job that none of the funded products this week actually cover. This is a recap post. If you read along this week, you've seen the pieces; this is the through-line. If you didn't, this is the whole week in one place. The week's biggest signal: a funded word The freshest data point is AEON's raise - $8M from YZi Labs to build, in their words, a settlement layer for the agentic economy. Under the hood it's an x402 facilitator on BNB Chain, routing agent-to-merchant payments across a very large merchant network. That is a real and useful thing. It is also, very specifically, payment : an agent sends a stablecoin to a seller it has chosen, value moving one direction to a known recipient. It sits next to two others that shipped recently and also wear the word: Circle's Agent Stack + Nanopayments moves gas-free USDC down to a millionth of a dollar, batched across chains. That's settlement as machine-speed micropayment - still one asset, still one direction, optimized for volume and tiny amounts. Fireblocks' Agentic Payments Suite puts a custodied vault between intent and execution: the vault holds funds and releases them when policy says so. That's settlement as custody-and-release - someone you trust holds the money in the middle. Three products, three meanings: route a stablecoin, micropay at machine speed, custody-and-release. All three are legitimate infrastructure. Builders should use them where they fit. The meaning none of them cover Here's the job that falls through the gap between all three: two agents that don't trust each other, swapping different assets, possibly across two chains, with no one holding the funds in between. A payment rail as

We are exploring an experimental blockchain mechanism called "Proof of Weather" In the world of blockchain, various methods are used to achieve network consensus. The most well-known is Bitcoin’s Proof of Work (PoW). While PoW is an excellent mechanism, it has one major drawback. It consumes an enormous amount of electricity. At one point, I found myself wondering: Does blockchain really require such vast computational resources? Isn’t there something else that’s needed? This led to the creation of Dawn, the experimental cryptocurrency project I am developing, and an experimental blockchain mechanism called Proof of Weather. In this article, I will discuss: Why I decided to use weather How Proof of Weather works Security considerations Implementation in Rust How Does Proof of Work Work? Proof of Work is often explained as a mechanism where computers compete against each other in computational tasks. However, one important property of PoW is that it produces outcomes that are difficult to predict in advance. Miners repeatedly perform massive amounts of hash calculations, and only those who happen to meet the conditions can generate a block. This unpredictability plays a role in determining who can produce the next block. However, this process consumes enormous amounts of electricity worldwide. So I wondered: Aren’t there already phenomena in nature that are difficult to predict? Why Weather? Proof of Weather utilizes weather data as that unpredictable element. Of course, weather forecasts exist. However, Temperatures several days in the future Atmospheric pressure at specific locations Precipitation Wind speed and other factors cannot be predicted with absolute certainty. In particular, when combining observations from multiple locations, it becomes even more difficult to accurately calculate future values in advance. In other words, meteorological observations have the potential to be used as A real-world information source where future values cannot be fully predic

I Built My First Token on Solana — Here's What Actually Surprised Me This week I went from zero tokens to minting, transferring, charging fees, and locking tokens so they can never move. Here's what stuck with me. Tokens don't live in your wallet Coming from Web2, I assumed tokens would just... show up in your account. Nope. On Solana, every wallet needs a separate token account for each token it holds. One mint, one folder. It felt weird at first. Now it makes sense. You can charge fees without writing a single backend The Token Extensions Program has a built-in transfer fee. One flag at mint creation time: spl-token create-token \ --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \ --transfer-fee-basis-points 100 That's a 1% fee on every transfer, enforced by the blockchain. No middleware. No payment processor. No way to bypass it. You can make a token that literally cannot be transferred spl-token create-token \ --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \ --enable-non-transferable I minted 10, tried to send 5, and watched the transaction get rejected. Not by my code — by the program itself. Perfect for credentials, badges, or certificates that should belong to one person forever. The biggest shift from Web2: these rules are set at creation and are permanent. You can't add a transfer fee to an existing token. You can't make a transferable token non-transferable later. It forces you to think about token design upfront, which is honestly a good constraint. solana #blockchain #webdev #beginners #100DaysOfSolana

Blockchain performance is determined by consensus rules. There is no acceleration layer within the protocol. One of the most common misconceptions about blockchain technology is the belief that transaction speed can be dramatically increased through special tools, hidden settings, or external services. While applications can improve user experience and optimize how information is presented, they cannot change the fundamental rules that govern how blockchain networks process transactions. At the core of every blockchain is a consensus mechanism. Consensus is responsible for ensuring that independent participants agree on the validity and order of transactions before they become part of the permanent ledger. Whether a network uses Proof of Work, Proof of Stake, or another consensus model, transaction processing remains tied to the protocol rules that all participants follow. Every transaction moves through a structured lifecycle: submit → validate → confirm Submission introduces the transaction to the network. Validation ensures that the transaction complies with protocol requirements and contains legitimate data. Confirmation establishes agreement across the network and records the transaction as part of the blockchain. These stages are not optional. They are essential to maintaining consistency and trust within decentralized systems. Because blockchain performance is governed by consensus, there is no protocol-level acceleration layer that can bypass validation or force immediate finality. No application can override consensus. No service can remove verification requirements. No external process can alter the execution sequence established by the protocol. What users often interpret as slow performance is usually the result of network conditions such as congestion, validator workload, transaction prioritization, or fee market activity. These factors can influence confirmation times, but they do not change the underlying rules of the system. Blockchain networks are d

I spent 7 days learning Solana token extensions. Here's what clicked, what surprised me, and the code you need to build tokens that can't be traded but can be revoked. The Problem (In Web2 Terms) Imagine you work in HR. You issue an employee a digital badge proving they're a certified security officer. Here's what you'd want: The badge stays in their wallet — they can't trade or sell it Only they can use it If they leave the company or fail a compliance check, you can revoke it silently without their permission The badge metadata (name, symbol, type) is on-chain and permanent You could build this with centralized databases and APIs. On Solana, it's just three extensions on a token mint . What Are Token Extensions? Solana's Token-2022 program lets you attach additional behaviors to any mint at creation time. Think of them like middleware for tokens. Before extensions, every token was the same — a mint with supply and decimals, token accounts holding balances, and transfer instructions. Extensions let you add rules on top : Extension What It Does Use Case Transfer Fee Charge a percentage on every transfer Protocol revenue, marketplace commissions Non-Transferable Make tokens unmovable after minting Soulbound badges, credentials, memberships Permanent Delegate Let the issuer burn tokens from anyone Revocable credentials, subscriptions with expiry Metadata Store name, symbol, URI on-chain Self-describing tokens, no external API needed Default Account State Freeze all new accounts by default Compliance gates, KYC verification The critical rule: extensions must be declared at mint creation . You cannot add them later. This forces you to think about your token's full lifecycle before deploying — which is good design discipline. The Journey: Three Combinations That Matter Over the past week I built three different token types. Here's what I learned from each. Day 34: Transfer Fees (The Marketplace Token) A token that charges 1% on every transfer, withheld automatically and

A SaaS team adds “Pay with crypto” to checkout. The first test looks fine: create a wallet address, show a QR code, receive USDT, mark the order as paid. Then production starts. One customer sends the right amount on the wrong network. Another pays after the invoice expires. A third sends 99.80 USDT instead of 100 USDT. Support sees a transaction hash but cannot find the order. Finance sees funds received but cannot match them to an invoice. The backend receives the same webhook twice and unlocks the product twice. That is the moment crypto payment integration stops being a QR-code feature and becomes a payment infrastructure problem. This is the first Dev.to post from Cryptoway . We build crypto payment infrastructure for online businesses, and here we will share practical notes about crypto payment API design, invoices, payment webhooks, stablecoin payments, checkout flows, reconciliation and payment status handling. What is a crypto payment gateway? A crypto payment gateway is the layer between a business event and a blockchain transaction. The business event can be: a SaaS subscription invoice; an e-commerce order; a digital product purchase; a marketplace deposit; a service payment link; an internal billing event. The blockchain transaction is the customer sending BTC, ETH, USDT, USDC or another supported digital asset. The gateway connects the two. It creates a payment request, shows the customer what to pay, monitors the blockchain, updates the payment status and notifies your backend when something changes. In other words: a crypto payment gateway is not the blockchain itself. It is the operational layer that makes blockchain-based payments usable inside real products. Crypto Payment Gateway vs Wallet Address A wallet address is enough for a manual payment. It is not enough for a product that needs order tracking, support visibility and finance reconciliation. Area Wallet address only Crypto payment gateway Order matching Manual matching by amount, address o

🏦 Day 6 of 7: Building a Mini Uniswap in 80 Lines of Solidity Imagine a vending machine. It has 1,000 coffee beans and 1,000 coins. No menu, no cashier — just one iron rule: the product of the two numbers inside must never decrease. That's it! This is how Uniswap works — and this is what I built on Day 6, coming from .NET. Here's how, why it's elegant, and where you can step on a rake. Why an Order Book Doesn't Work on a Blockchain Traditional exchanges — Binance, NYSE, any CEX — run on an order book . Market makers post bids and asks. A matching engine pairs them. Millions of updates per second, all in a centralised database. In a blockchain, this is impossible. Transactions take 12 seconds. Every state change costs gas. Storing millions of constantly changing orders would eat all the profit before a single trade completes. Uniswap's solution: replace the order book with a liquidity pool — a smart contract holding two tokens — and replace the matching engine with pure math. Just a formula — below. x · y = k — The Formula That Broke Finance The Constant Product Invariant : x · y = k Where x is the reserve of Token0, y is the reserve of Token1, and k is a constant that must never decrease during swaps. When a trader sells Token0 into the pool, x increases. To keep k constant, y must decrease — the contract sends out Token1. The price is determined automatically by the ratio of reserves. Live example with numbers: Pool: 1,000 Token0, 1,000 Token1. k = 1,000,000. Trader sells 100 Token0: amountOut = (reserveOut × amountIn) / (reserveIn + amountIn) amountOut = (1000 × 100) / (1000 + 100) amountOut = 100,000 / 1,100 amountOut ≈ 90.9 Token1 The trader gets ~90.9, not 100. That gap is slippage — and it's not a bug. It's the formula protecting the pool. The more you buy relative to pool size, the worse your price gets. Naturally. Mathematically. After the swap: pool has 1,100 Token0 and ~909.1 Token1. k ≈ 1,000,000. Invariant holds. The Contract: SimpleAMM Three functions.

In the past, when people heard the word “token,” they usually thought about cryptocurrency, trading,...

Architecture of Autonomous Portfolio Agents Autonomous AI agents managing cryptocurrency portfolios operate on a foundation of continuous on-chain data aggregation, sentiment analysis, and real-time execution logic. Unlike traditional algorithmic traders that rely primarily on technical indicators, these agents integrate multiple data streams: price feeds from decentralized exchanges (DEXs), liquidity pool metrics, transaction volume patterns, whale movement tracking, and off-chain market sentiment. The system architecture typically consists of an inference engine powered by a large language model (LLM) or specialized neural network, a risk management module, an execution layer connected to blockchain RPC endpoints, and a monitoring feedback loop that adjusts parameters based on portfolio performance. The core insight enabling these agents is that blockchain data is transparent and immutable. Every transaction, every token transfer, every smart contract interaction leaves a permanent record on-chain. This transparency creates an information advantage: agents can detect patterns in whale behavior, liquidity migrations, and protocol changes far faster than traditional market participants can react to publicly available news. The agent's role is to process this data stream continuously, identify meaningful signals, and execute portfolio rebalancing in response. Data Integration: On-Chain and Sentiment Signals An effective portfolio agent must ingest and synthesize diverse data sources in near-real-time. The agent retrieves price data from oracles like Chainlink or Pyth, historical candle data from indexing services like The Graph or Covalent, and liquidity information directly from smart contract states. Current liquidity depth, slippage curves, and available yield opportunities in DeFi protocols must be sampled with sufficient frequency to detect arbitrage windows and avoid trades that would incur unacceptable slippage. Sentiment analysis layers onto this foundation b

Hiring an AI Development Company? Ask These 7 Questions First Most AI projects fail long before deployment. Not because the model is bad. Because teams skip the hard engineering questions. If you're evaluating an AI development company, ask these 7 questions first: 1. How is data secured? AI systems process sensitive business information. Ask: Where is data stored? Is encryption enabled at rest and in transit? Who has access to prompts, logs, and embeddings? Are enterprise security standards followed? Security should be designed in from day one. 2. What observability exists? You can't improve what you can't monitor. A production AI system should include: Request tracing Prompt/version tracking Latency monitoring Cost visibility Error reporting If nobody can explain what happened after a bad output — that's a problem. 3. How do you handle model drift? AI performance changes over time. Questions to ask: How are outputs evaluated? Is feedback collected? How are prompts/versioning managed? What happens when accuracy drops? Production systems need iteration loops. 4. What happens during failure? No system is perfect. Ask: Is there fallback logic? Human review? Retry handling? Graceful degradation? Failure handling matters more than demos. 5. How is access controlled? Enterprise AI systems require permissions. Examples: Role-based access API authentication Audit logs Team-level controls Not everyone should access everything. 6. What compliance assumptions exist? Especially important for regulated industries. Ask whether the system considers: GDPR SOC2 HIPAA Financial or internal compliance rules Compliance cannot be an afterthought. 7. Who owns the infrastructure? Clarify ownership before signing anything. Ask: Who owns the source code? Cloud infrastructure? Models and prompts? Data pipelines? You should avoid vendor lock-in. AI success is rarely about flashy demos. It's about secure infrastructure, reliability, observability, and long-term maintainability. What question

"Settlement layer for the agent economy" has become a phrase used by more than one architecture this month. Some of those architectures are venues. Some are payment rails. Some are identity stacks. One is what we build — a trust-minimized atomic settlement primitive — and we keep getting asked how it sits next to the others. So this is a short, opinionated week-in-review. Seven moves that landed recently in agent-commerce infrastructure, what each one actually is, and where atomic settlement fits underneath. No leaderboard. No "who wins." Just the layers. 1. Coinbase's Base MCP (May 26) Coinbase shipped a Base MCP server: ChatGPT, Claude, and Cursor can connect directly to Base wallets, with built-in Uniswap and Morpho integrations. Two-line install, agent-driven swaps, on-chain account control from inside the model client. What it is: a wallet-side, exchange-aligned MCP. The agent drives a wallet on Base; Coinbase has thought hard about UX, key handling, and AI client ergonomics. If your agent is already operating inside the Coinbase + Base orbit, this is a meaningful drop in friction. What it isn't: a cross-chain settlement layer. It is one L2, deeply integrated. The agent's trust assumptions are "Coinbase wallet infrastructure + Base + the DEXes that Base MCP integrates with." That is a reasonable trust budget for a lot of trades; it is not the budget for an agent that wants to trade BTC for ETH without picking a venue. 2. The x402 Foundation (Coinbase + Cloudflare) Coinbase and Cloudflare announced an x402 Foundation this month. x402 is the HTTP-based agent payment standard — a 402 response code carrying payment metadata, designed so an agent can pay for an API call inline. Cloudflare joining elevates this from a Coinbase-led initiative to a multi-party standards effort. Cloudflare also runs an enormous slice of the internet's edge; if x402 becomes a default payment rail, it will be visible from the edge first. What it is: a payment-handshake protocol. How an ag

Every line of your smart contract costs something. Some lines cost more than others. In this part of our gas saving series, we’ll explore how to write smarter Solidity code that keeps your contract lean and efficient. Here are six simple and practical ways to reduce gas costs while writing Solidity smart contracts. 1. Use payable Only When Needed, But Know It Saves Gas In Solidity, a function marked payable can actually use slightly less gas than a non-payable one. Even if you're not sending ETH, the EVM skips some internal checks when the function is marked payable. See this example: function hello() external payable {} // 21,137 gas function hello2() external {} // 21,161 gas That tiny difference may not seem like much, but across thousands of calls, it adds up. Only use payable when your function is actually meant to accept ETH 2. Use unchecked for Safe Arithmetic When You’re Sure Since Solidity 0.8.0, all arithmetic operations automatically check for overflows and underflows. While this makes contracts safer, it also uses extra gas. When you're certain that overflow won't occur, you can use the unchecked keyword to skip these safety checks. uint256 public myNumber = 0; function increment() external { unchecked { myNumber++; } } Gas used: 24,347 (much cheaper than using safe math) Warning: Use unchecked carefully. Only when you're confident there's no risk of overflow. 3. Turn On the Solidity Optimizer The Solidity Optimizer is like a smart helper that cleans up and tightens your compiled bytecode. It does not change how your contract works, but it removes waste and makes it cheaper to run. If you’re using tools like Hardhat or Remix, always enable the Optimizer before deploying to mainnet. 4. Use uint256 Instead of Smaller Integers (Most of the Time) Smaller types like uint8 or uint16 might look more efficient, but they can cost more gas during execution. That’s because the EVM automatically converts them to uint256 behind the scenes. So, if you're not tightly p

"Settlement layer for the agent economy" is suddenly a crowded sentence. In the last few weeks, two very different things have started competing for it. OKX Agent Payments Protocol (APP) announced in May 2026 — backed by AWS, Alibaba Cloud, Uniswap, Paxos, QuickNode, with ecosystem support from Base, Ethereum Foundation, Solana, Sui, Aptos, Optimism — describes itself as the settlement layer where AI agents pay each other. AEON's $8M pre-seed (May 20, YZi Labs) described itself the same way. There is a list now, and it is getting longer. We build one of the things on this list, and we think the framing is wrong. These are not rivals jostling for the same slot. They are two different layers, and they answer two different versions of the same question: what does an agent need to settle a trade? This piece walks through the two layers, where each is the right answer, and why an honest comparison gets you further than picking sides. What APP and other custodial-venue protocols actually do A useful way to read OKX APP — and similar moves coming from the larger exchanges — is to treat them as a venue layer . An exchange already holds inventory across many chains. It already has the risk engines, the liquidity, the legal arrangements with banks and partners. Adding an agent-facing API on top of that machinery is a relatively short walk. What an agent gets, in exchange, is breadth. Many chains, many assets, batched and netted settlement against deep internal books, and fast execution because the exchange is just moving entries in its own ledger. For an agent whose job is "find a price somewhere and execute now," that is a powerful primitive. What the agent gives up, in exchange, is a counterparty. At any moment between deposit and withdrawal, the agent's balance is the venue's promise to pay. That promise is normally good. The agent has no way to verify, from inside its own logic, that it still is. This is not a criticism of OKX APP. It is the structural shape of any venue-