标签：#blockchain

If you’ve ever built or interacted with DeFi protocols, you know the mathematical limitations of Constant Product Market Makers ($x \times y = k$). While AMMs are great for retail liquidity, executing a large transaction (e.g., $100,000+) directly against a liquidity pool triggers two major issues: Severe Slippage: The marginal price of the asset degrades exponentially relative to the trade size. MEV Exploitation (Sandwich Attacks): Public mempool transactions are highly vulnerable. Front-running bots will buy the asset ahead of your execution block, push the price up to your maximum slippage limit, and dump it immediately after. To solve this without relying on centralized, custodial desks or risky off-chain escrow setups, we built Typelex —a decentralized, non-custodial P2P OTC protocol. Here is a look at how we bypassed the AMM bonding curve entirely using on-chain atomic swaps. The Architecture of an On-Chain Atomic Swap Instead of routing trades through active liquidity pools, Typelex utilizes isolated smart contracts to execute peer-to-peer trades. The entire swap happens atomically : either all conditions are met within a single block execution, or the entire transaction reverts. Conceptual Smart Contract Logic (Solidity-based) To understand how the trustless escrow works under the hood, here is a simplified mental model of the swap execution logic: struct Order { address maker; address taker; // address(0) if public address tokenA; uint256 amountA; address tokenB; uint256 amountB; bool active; } mapping(uint256 => Order) public orders; function takeOrder(uint256 orderId) external { Order storage order = orders[orderId]; require(order.active, "Order not active"); if (order.taker != address(0)) { require(msg.sender == order.taker, "Unauthorized taker"); } order.active = false; // Pull Token B from Taker to Maker IERC20(order.tokenB).transferFrom(msg.sender, order.maker, order.amountB); // Push Token A from Contract Escrow to Taker IERC20(order.tokenA).transfer

VistralNova began by developing Web3 gaming experiences and is now expanding toward developer...

We Taught a Snowflake Warehouse to Judge World Cup Conviction and Write the Verdict Back to Solana Soumyadeep Dey Soumyadeep Dey Soumyadeep Dey Follow Jul 12 We Taught a Snowflake Warehouse to Judge World Cup Conviction and Write the Verdict Back to Solana # devchallenge # weekendchallenge # snowflake 5 reactions 1 comment 16 min read

Tokens and DAOs are often presented as simple ideas: issue a token, distribute ownership, let the community vote, and build a decentralized organization. In reality, the technical problems behind tokens and DAOs are much deeper. A token is not only an asset, and a DAO is not only a voting system. Together, they create an economic, governance, security, and coordination layer that must work reliably in a hostile, open environment. The first major problem is token design. Many projects treat token creation as a deployment task, but the real challenge is defining what the token actually controls. Does it represent governance power, protocol revenue, access rights, reputation, staking weight, or all of these at once? When one token is used for too many purposes, the system becomes fragile. For example, a token designed for liquidity may not be suitable for governance, because the most active traders may not be the most aligned decision-makers. Good token architecture should separate economic utility, governance authority, and long-term reputation where possible. The second problem is distribution. A DAO can be decentralized in branding but centralized in practice if token ownership is concentrated among founders, investors, or early insiders. On-chain governance depends heavily on voting power, so distribution directly affects decision quality. Poor distribution creates governance capture, where a small group can control treasury spending, protocol upgrades, or parameter changes. This is not only a social issue; it is a technical design issue. Vesting contracts, delegation systems, quorum rules, voting delay, and proposal thresholds all influence whether governance is resilient or easily manipulated. Another core issue is governance security. DAO voting is not automatically safe just because it happens on-chain. Token voting can be attacked through flash loans, bribery markets, vote buying, low-participation proposals, and governance fatigue. If a malicious proposal pas

Title: Week 13: a second team is now running an AI agent on atomic HTLC swaps. Here is what that validates. Tags: mcp, ai, cryptocurrency, blockchain For most of this spring, the map of the agent economy had a strange gap. Wallets to hold keys. Rails like x402 to move value. Marketplaces and reputation so an agent knows who to trust. And then, at the exact moment two parties settle a trade, a custodian: an escrow contract, an evaluator, a referee holding the money while a decision gets made. We have spent thirteen weeks arguing that the settlement layer does not need a referee, because a hash-time-locked contract can hold neither side and still guarantee the trade. This week, a second team shipped a live agent that makes the same argument in code. That is worth stopping on. The signal that mattered this week KaleidoSwap released KaleidoAgent, described as a self-sovereign trader agent on Bitcoin Layer 2s. It is fully non-custodial. It runs a Lightning and RGB wallet, executes atomic HTLC swaps on the KaleidoSwap DEX, runs DCA and portfolio strategies, manages Lightning channel liquidity, and acts as an interactive wallet assistant. The reasoning layer is an LLM (Claude or OpenAI) driving the kaleido CLI and the wallet primitives underneath. Read that list again through a settlement lens. An autonomous agent, deciding what to trade, and executing the trade over a primitive where no third party ever holds the funds. That is the exact shape of the thing we have been building. Different network, same bet. Why the mechanism is the same KaleidoSwap earlier completed what it described as the first atomic swap of an RGB asset on the Lightning Network mainnet, using tUSDT, an RGB20 version of USDT, over real Lightning channels. The detail that makes it atomic is the one that makes every HTLC atomic: The payment hash remains identical across both legs of the swap. Paying the wrapped invoice creates a Hash Time-Locked Contract in the Lightning channel, and the HTLC locks the p

Welcome to Learning Xahau, a series of articles dedicated to helping developers, builders, and blockchain enthusiasts better understand the Xahau ecosystem. Whether you're just getting started or already building advanced applications, these posts will explore Xahau's features, architecture, and best practices through practical examples and real-world use cases. If you've been building with Hooks on Xahau, you know the basic loop: write a C program, compile it to WebAssembly, install it on an account, and it fires automatically when that account is involved in a transaction. Simple and powerful, but until the 2026.6.21 major release, there were some friction points that made real-world hook architectures more complicated than they needed to be. This release ships three improvements that directly address those friction points: HookOnV2 : split the single HookOn bitmask into separate HookOnIncoming and HookOnOutgoing controls NamedHooks : assign a human-readable name to each hook slot, so senders can choose which hook to activate Simulate RPC : preview a transaction including all hook executions without spending fees or changing ledger state None of these require rewriting your hook logic. They are configuration and tooling improvements at the SetHook and transaction level. But they fundamentally change what you can build cleanly. All code in this article targets the Xahau Testnet ( wss://xahau-test.net ) and requires xahau.js 4.1.1 or later. Clone the companion repository: git clone https://github.com/Ekiserrepe/learningxahau20260621.git cd learningxahau20260621 npm install Copy .env.example to .env and fill in the seeds used across these examples: cp .env.example .env HUB_SEED = # account that installs the directional hook (07, 08, 09) NAMED_HUB_SEED= # account that installs and owns the named hooks (10, 11, 13, 14) SENDER_SEED = # account that sends payments targeting a named hook (12, 14) All accounts need testnet funds from the Xahau Testnet Faucet . HookOnV2: Di

When I first started learning Solana, one of the biggest questions I had was: "If there are no usernames or passwords, how does the blockchain know who I am?" As a Web2 developer, I was used to creating accounts with an email address, choosing a password, and relying on a company to manage my identity. After spending several days learning Solana, I realized blockchain approaches identity in a completely different way. Identity in Web2 Think about all the accounts you have today. GitHub Gmail Facebook LinkedIn Your bank Every service asks you to create another account. Each company stores your username and password in its own database. Your identity exists because they say it exists. If they suspend your account or delete it, your access disappears. In other words, your identity is owned by the platform. Identity on Solana On Solana there are no usernames. There are no passwords. There isn't even an account registration page. Instead, your identity begins with one thing: A cryptographic keypair. A keypair consists of: A Public Key A Private Key When I generated my first wallet using the Solana CLI, I immediately had a new blockchain identity. For example: Public Key: AxfVXDX7jsCw7vSnwut9hA7oX4UykE3ZeiNF6cxCKvpf This public key becomes my wallet address. Anyone can send tokens to it. Anyone can view its transactions. But nobody can spend funds from it. Why? Because only I possess the private key. Think of SSH Keys The easiest comparison for Web2 developers is SSH. When connecting to a Linux server: the server knows your public key you prove ownership using your private key Solana works almost exactly the same way. Except instead of logging into one server... you're interacting with an entire blockchain. Every transaction I make is digitally signed using my private key. Validators verify the signature before accepting the transaction. No password is ever transmitted. No administrator approves my login. The mathematics prove my identity. Why Wallets Matter One thing I f

This is a submission for Weekend Challenge: Passion Edition What I Built Loyalty Ledger — a fan loyalty tracker where your check-in streak, badges, and history live on Solana instead of some app's database. Live app: https://loyalty-ledger-blond.vercel.app Here's the problem I kept coming back to. Every sports app wants you to check in, engage, "prove your loyalty" — collect points, build a streak, unlock a badge. Cool. Except every single one of them throws that history away the second you stop opening the app. Switch apps and your streak resets to zero. Get banned, or the app shuts down, or they just quietly decide to wipe inactive accounts one day — and your history is just... gone. Because it was never actually yours. It was a number sitting in someone else's database, and they could reset it, inflate it, or delete it whenever they felt like it. You had zero say in it. And that bugged me way more than it probably should have. Like — we figured out how to make ownership portable for money, for domain names, for digital art. But "I've supported Argentina since 2019" 🇦🇷 still lives and dies inside one company's backend, and nobody's really questioned that. So I kept the weekend scope deliberately small: prove one fan's loyalty to one team, for real, end to end — instead of sketching ten features that are all half-fake. You connect a wallet, pick a sport and team, and check in. FIFA World Cup is the fully working path here ⚽ — that check-in sends an actual transaction that creates or updates a program-owned account, not a row in my database somewhere. Your streak count, your badge tier, the actual badge tokens — none of it exists anywhere I control. Which honestly felt a little weird to build, in a good way. Once that core loop worked, I built the rest of the identity around it: a Fan Passport that shows your streak, a derived "Fan Score," your tier (Rookie → Devoted → Veteran → Legend 🏆), a progress bar toward the next tier, an achievements grid with locked/unlocke

This is a submission for Weekend Challenge: Passion Edition What I Built Loyalty Ledger —...

If you only tracked one part of the agent economy this June, you'd have missed how fast the rest of the stack is being built. So here's a roundup, and one honest observation about the piece that's still missing. Four launches, one month Four things shipped in roughly four weeks, and together they sketch the shape of the machine economy: MetaMask Agent Wallet (Jun 8) - a self-custodial wallet an AI agent can drive directly. Keys for machines. Coinbase for Agents (Jun 11) - an MCP + CLI surface that connects an agent to a Coinbase account, riding on x402, which has now processed well past 160M payments. OKX.AI marketplace (Jun 30) - persistent on-chain identity, cross-job reputation, and escrow-backed dispute resolution, all in one platform. Kustodia MCP escrow - a smart-contract escrow on Arbitrum, exposed as MCP tools so an agent can create an escrow, lock funds, monitor for delivery, and release payment through natural-language calls. It also supports x402, Google's AP2, and Coinbase's AgentKit. Add the payment-rail data around all of it: across the tracked x402 flows this year, USDC is the overwhelming majority of value moved, and the median agent payment sits in the cents. This is a real economy forming, not a demo. Every one of those launches is genuine progress. And every one of them, at the moment that matters, has someone other than the two counterparties holding the asset. The pattern: hold, then decide Look at where the money physically sits during a transaction in each model. A wallet holds your keys - fine, that's custody of your own funds by design. A payment rail moves value from your account to theirs - a transfer, one direction. A marketplace with escrow holds both sides' value and releases it when a condition (often a human-designed evaluator or dispute process) says so. Kustodia is the cleanest statement of the escrow model, so it's worth being precise about it rather than vague. Their Arbitrum contract acts, in their own framing, as an impartial re

There's a moment in every Solana project where the work stops being about whether the program works and starts being about whether it's ready . You've tested it, the logic holds, the constraints are tight. Then you point it at mainnet, and a different set of questions shows up: questions about money, permanence, and strangers. This post is about that transition. Not the commands, which are short and well documented, but the shift in what you're responsible for once real users can touch your code. If you've been building on devnet and you're starting to think about a live launch, this is the mental model to carry in. Devnet was a sandbox. Mainnet is not. Devnet is a practice field. The SOL is free, you airdrop more whenever you run low, and if you deploy something broken, the only casualty is your afternoon. That safety is the whole point of devnet: it lets you fail cheaply and often, which is exactly how you should be learning. Mainnet removes the safety net, and three things change the moment you cross over. The SOL is real. Deploying a program allocates an on-chain account sized to your compiled binary, and you pay rent for that space in actual SOL. Larger programs cost more. This isn't a huge sum for a typical program, but it's real money leaving a real wallet, and that alone tends to sharpen how carefully you check things before you hit deploy. The audience is real. On devnet the only person calling your program is you. On mainnet, anyone can find your program and send it any transaction they like, the moment it's live. Everything from the security arc stops being theoretical: the accounts strangers pass in, the inputs you didn't expect, the edge cases you hoped no one would hit. Mainnet is where "every account is attacker-controlled until proven otherwise" becomes a live condition rather than a lesson. The mistakes are visible. A bad devnet deploy disappears into the noise. A bad mainnet deploy is a public event, on a permanent ledger, in front of the users you

In January, three researchers built a shopping agent on Google's Agent Payments Protocol (AP2), the standard designed to make agent-led purchases safe through cryptographically verifiable mandates. Then they attacked it with nothing more exotic than adversarial text. The paper, "Whispers of Wealth" ( arXiv 2601.22569 , revised May 2026), reports that simple prompt injections reliably subverted the agent: one attack steered which products the agent ranked and bought, another exfiltrated sensitive user data. The part of the stack that failed was not the cryptography. The mandates verified exactly what they were designed to verify. What folded was the layer that exercises judgment. Hold that result in mind, because the agent economy is currently pouring money into judgment. Everyone is hiring a referee Look at what shipped in the last few months for agent-to-agent commerce, and a single pattern repeats: put the money in escrow, and let a judge decide when it comes out. ERC-8183 formalizes it: funds sit in an escrow contract while an Evaluator - an agent or a human - decides whether the deliverable meets the spec before releasing payment. It is the pattern Virtuals' Agent Commerce Protocol runs on. Circle has piloted an escrow agent for USDC flows. Kustodia and Nava (which raised $8.3M) are startups built on the same shape. And on July 1, BNB Chain and AWS launched agents that bank themselves - agents deployed to Amazon Bedrock AgentCore with their own wallets, identity, and payment stack from birth. Even the category label is contested now: at least one project has declared itself an "MCP Settlement Standard" from a landing page. That is five separate, serious teams independently converging on the same component: a referee who holds the money. The referee exists for a good reason Before arguing against the judge, steelman him. Most agent-to-agent commerce today is hiring: one agent pays another for work. Write this code. Produce this research. Render this video. The de

The Redbelly Network EligibilitySDK is the compliance backbone for any dApp that needs to verify user eligibility (KYC, KYB, investor accreditation) before letting a wallet in. The official documentation covers each piece well on its own reference page, but there is no single walkthrough connecting the frontend widget to the backend verifier to the on-chain permission check to a production deployment. This guide is that walkthrough. Everything here was verified against the live documentation at https://docs.redbelly.network/ in July 2026: contract addresses, route names, config fields, issuer DIDs and every error string in the reference section. Every code example was then compiled against the published SDK package (v0.0.31) on React 19 with Vite and on Next.js 16 with the App Router, and the backend verifier was booted and exercised for real. Where the docs and reality diverge (a quickstart repo that is not publicly visible, a credential faucet still under development, three undocumented behaviours the builds surfaced), the guide says so and gives you the workaround. What you will build, in order: A mental model of the two verification mechanisms (and why conflating them costs you a day) A working backend verifier with the three routes the widget demands A plain React integration with full loading and error states A production-grade Next.js App Router setup: secure proxy, SIWE sessions, request gating, and both static and dynamic rendering approaches An end-to-end test run on Redbelly Testnet The decision logic for choosing between the three SDK flows, and the pattern for combining them A complete error reference: every documented error, its cause, and its fix A developer following this guide should have the widget running inside an existing dApp within about four hours. 1. Overview and Architecture What the EligibilitySDK actually is The Redbelly "Onboarding and Eligibility Kit" ( @redbellynetwork/eligibility-sdk ) is a set of React components and hooks for provin

Decentralized Autonomous Organizations are often presented as simple governance systems: token holders create proposals, vote, and execute decisions on-chain. In practice, building a production-grade DAO is far more difficult. A DAO is not only a smart contract. It is a distributed coordination system that combines governance logic, treasury security, token economics, identity, off-chain infrastructure, and human decision-making. A failure in any one of these layers can compromise the entire organization. Below are some of the most important technical problems DAO developers must solve. 1. Governance Attacks Through Borrowed Voting Power Many DAOs calculate voting power based on the number of governance tokens held at a specific moment. This creates a serious attack surface when tokens can be borrowed through lending protocols or flash loans. An attacker may temporarily acquire a large amount of voting power, submit or approve a malicious proposal, and return the borrowed assets shortly afterward. The standard defense is snapshot-based voting power. Instead of checking a user’s current balance, the governance contract reads historical balances from a previous block. function getVotes( address account, uint256 blockNumber ) public view returns (uint256) { return token.getPastVotes(account, blockNumber); } However, snapshots alone do not solve every problem. Developers should also consider proposal delays, minimum token-holding periods, quorum requirements, and vote-delegation risks. 2. Dangerous Proposal Execution The most sensitive part of a DAO is usually the executor. A successful proposal may call arbitrary contracts, transfer treasury assets, upgrade protocols, or change governance parameters. If proposal calldata is incorrectly validated, a governance action can execute unintended operations. A DAO should clearly separate: Proposal creation Voting Proposal queuing Timelock execution Emergency cancellation Using a timelock gives token holders and security teams

디지털 자산과 인공지능 분야는 핵심 기술은 다르지만, 데이터의 진실성, 규제 체계, 지정학적 함의에 대한 공통된 도전에 직면하며 점차 수렴하고 있다. 최근 일련의 사건들은 탈중앙화와 첨단 연산이 약속하는 미래가 인간의 행동, 경제적 유인, 그리고 국가적 목표라는 현실과 충돌하는 중요한 변곡점을 보여준다. 제재 대상 러시아 스테이블코인의 논란 많은 거래량 주장부터 전 미국 대통령이 약세장 속에서 거둔 전례 없는 암호화폐 수익, 그리고 선두 AI 모델을 둘러싼 당혹스러운 "너프(성능 저하)" 논쟁에 이르기까지, 이 모든 이야기는 혁신과 불투명성이 난무하는 디지털 최전선의 모습을 생생하게 그려낸다. 이 글은 겉으로는 서로 달라 보이는 이러한 현상들을 깊이 파고들어, 그 기저의 메커니즘, 기술적 복잡성, 그리고 글로벌 디지털 경제에 미치는 광범위한 영향을 탐색하고자 한다. 우리는 블록체인 분석이 불법 금융 활동 주장에 어떻게 도전하는지, 정치인들이 신생 산업에 관여하며 제기하는 윤리적 및 규제적 난제는 무엇인지, 그리고 복잡한 AI 시스템을 평가하는 미묘한 기술적 문제들을 살펴볼 것이다. 이러한 분석들을 관통하는 공통적인 실마리는 바로 강력한 검증, 투명한 거버넌스, 그리고 정교한 이해가 필수적이라는 점이다. 정보가 쉽게 조작될 수 있고, 진정한 효용성이 복잡성이나 전략적 오도 뒤에 가려지기 쉬운 생태계를 헤쳐나가기 위해서 말이다. 디지털 자산과 AI가 금융, 거버넌스, 그리고 일상생활을 계속해서 재편하는 가운데, 부풀려진 지표 속에서 진정한 활동을, 시스템적 결함 속에서 실제 역량을 식별하는 능력은 투자자, 정책 입안자, 기술자 모두에게 더없이 중요해지고 있다. 지난 10년간 암호화폐와 인공지능 분야는 폭발적인 성장을 거듭하며 각각 변혁적인 잠재력을 제시하는 동시에 새로운 도전 과제들을 안겨줬다. 예를 들어, 스테이블코인은 본래 암호화폐 시장의 변동성을 완화하기 위해 법정화폐나 다른 자산에 가치를 고정하도록 고안되었으나, 글로벌 디지털 금융 인프라의 핵심 구성 요소로 진화했다. 특히 엄격한 금융 제재를 받는 지역에서 국경 간 결제를 촉진하는 그들의 유용성은 양날의 검이 되어, 합법적인 사용자뿐 아니라 전통적인 금융 통제를 우회하려는 이들까지 끌어들이고 있다. 2022년 이후의 지정학적 환경은 경제 제재에 대한 초점을 더욱 강화했고, 제재 대상 기업들은 디지털 자산이 제공하는 대안적 금융 경로를 모색하게 되었다. 동시에 디지털 자산의 주류 금융 및 정치권으로의 통합은 가속화됐다. 한때 틈새 기술적 호기심에 불과했던 암호화폐는 이제 상당한 경제적 힘으로 자리 잡았고, 기관 투자뿐만 아니라 최근 공개된 바와 같이 유명 인사들에게도 막대한 개인 자산을 안겨주고 있다. 이러한 주류화는 필연적으로 암호화폐를 국가 규제 기관의 감시 아래 놓이게 하며, 업계의 종종 자유지상주의적 정신과 국가의 감독, 과세, 소비자 보호 요구 사이에서 긴장을 유발한다. 특히 규제 환경이 아직 형성되는 단계에서 정치인들이 이 신흥 부문에 관여하는 것은 이해 상충과 공직 내 개인적 금전 이득의 윤리적 경계에 대한 복잡한 질문들을 제기한다. 이러한 발전과 병행하여, 인공지능, 특히 대규모 언어 모델(LLM)은 불과 몇 년 전에는 상상할 수 없었던 능력을 보여주며 빠르게 발전했다. 그러나 종종 "블랙박스"처럼 작동하는 이 모델들의 복잡성은 평가, 제어, 그리고 윤리적 배포를 보장하는 데 상당한 난관을 초래한다. "너프" 또는 성능 저하를 둘러싼 논쟁은 AI 시스템의 진정한 능력을 벤치마킹하고 이해하는 데 내재된 어려움을 강조한다. 특히 안전 분류기와 같은 내부 아키텍처 구성 요소가 관찰되는 동작을 크게 바꿀 수 있기 때문이다. 제재 회피, 암호화폐의 정치경제, AI 모델 평가라는 이 세 가지 독특하지만 서로 연결된 서사는 점점 더 디지털화되고 알고리즘에 의해 움직이는 세상에서 투명성, 책임성, 그리고 정확한 평가를 위한 광범위한 노력을 강조한다. 최근의 뉴스들은 디지털 자산과 AI 생태계에 내재된 기술적 복잡성과 분석적 도전 과제들을 심층적으로 보여준다. 제

Maintaining a robust testing pipeline or managing automated node infrastructure often requires orchestrating dozens of isolated EVM wallets. Over time, these automated Python or JavaScript configurations inevitably hit a common wall: the accumulation of fragmented token dust across multiple layers (Ethereum, Arbitrum, Base, BSC, etc.). Trying to clear these micro-balances manually or writing one-off scripts to sweep individual assets scale operational costs rapidly. Each network requires separate RPC updates, custom middleware logic, and redundant gas overhead, turning standard infrastructure hygiene into an engineering bottleneck. The Problem with Traditional Asset Sweeping When handling larger developer setups or wallet clusters, custom scripts face three major friction points: Redundant Network Fees: Batching transfers without native contract-level optimization burns excessive gas when scaling to 50+ addresses. RPC Disruption: Constantly querying and broadcasting batch transfers via public or even shared private endpoints can trigger rate limits. Data Contamination: Manually routing funds from dense testing nodes increases the risk of cluster cross-contamination. To resolve this friction within our decentralized dev pipelines, we deployed a streamlined utility layer: CryptonEquity Terminal ( https://cryptonequity.com ). Building a Unified Utility Layer for Multi-Chain Workflows The terminal introduces a non-custodial Cross-Chain Dust Sweeper designed to eliminate fragmented operational friction. Instead of manually deploying individual sweeping scripts per account, the infrastructure automates multi-chain scanning and groups asset consolidation into a single transaction link. Simultaneous Layer Aggregation: Automatically detects micro-balances across dominant EVM networks at once. Gas Mitigation: Designed to structure transfer paths to limit redundant network fee overhead. Zero Onboarding Friction: Operating strictly on a non-custodial architecture, it requires n

Welcome to our weekly digest, where we unpack the latest in account and chain abstraction and the broader infrastructure shaping Ethereum. This week: Ethlabs launches as an independent EF-origin R&D lab backed by Bitmine, Sharplink, and Joe Lubin; the Ethereum Foundation reorganizes into five focused clusters and parts ways with a fifth of its staff; Starknet brings confidential USDC payments to DeFi through its STRK20 framework; and a new industry report charts how crypto-native neobanks went mainstream and why account abstraction matters more because of it. Ethlabs Launches as an Independent R&D Lab The Ethereum Foundation Restructures Into Five Clusters Starknet Brings Private USDC to DeFi Crypto Neobanks Cross From Experiment to Infrastructure Please fasten your belts! Ethlabs Launches as an Independent R&D Lab A coordinated group of Ethereum contributors has launched Ethlabs , an independent nonprofit research and development lab built to ready the network for its next wave of institutional and agentic adoption. The funding effort is led by Bitmine, Sharplink, and Ethereum co-founder Joe Lubin, with support from Anchorage, Octant, and SNZ. Ethlabs is cofounded by five former senior Ethereum Foundation researchers — Ansgar Dietrichs, Barnabé Monnot, Caspar Schwarz-Schilling, Josh Rudolf, and Julian Ma — who between them shaped finality, scaling, data availability, and protocol economics over the past decade. Dietrichs serves as Executive Director. The lab’s early work centers on what institutions need to move onchain at scale: faster settlement, native issuance, cross-chain movement, and more mainnet capacity, alongside research into ETH’s monetary properties. The team frames the moment as Ethereum’s shift from infrastructure buildout to an age of adoption, where the architecture that settles global activity is being decided now rather than in ten years. To preserve neutrality, funding flows through an independent grants administrator that handles screening and

The $765K NFT exploit nobody using block.timestamp thinks about In May 2021, an attacker exploited the Meebits NFT mint, one of Larva Labs' projects, by taking advantage of its predictable randomness mechanism. Meebits used on-chain inputs including block timestamp, nonce, and difficulty to generate the token ID for each newly minted NFT. Different token IDs had different rarities, and rarer IDs were worth significantly more on the secondary market. The attacker figured out the generation formula, simulated the outcome before committing, and repeatedly rerolled mints within the same transaction until hitting a rare NFT. They walked away with a Meebit later sold for roughly 200 ETH, worth approximately $765K at the time. The contract did exactly what it was programmed to do. The problem was the inputs it trusted as "random" were never actually random at all. This is day 7 of the 28-day Chainlink architecture series. Today covers Chainlink VRF: why on-chain randomness is a fundamentally hard problem, how VRF solves it cryptographically, and a detail most explainers skip entirely: why even a fully compromised node operator can't bias a VRF output. Why blockchains can't generate real randomness natively Smart contracts are deterministic. Every node in the network runs the same code on the same inputs and must arrive at the same result, every single time, or consensus breaks. That determinism is what makes blockchains trustworthy. It also makes native randomness structurally impossible. Any value a smart contract can read mid-execution: block.timestamp , blockhash , block.difficulty , block.prevrandao is visible to validators and miners before the block is finalized. That visibility creates a manipulation window block.timestamp : validators can manipulate this within roughly a 15-second window on Ethereum. Small enough that nobody notices, large enough to flip a coin-flip lottery in your favor repeatedly. blockhash : if a validator is about to mine a block where the hash

Written from months of grinding on shielded liquidity DeFi protocols on Midnight. If you've been trying to build anything serious with shielded fungible tokens on Midnight lending protocols, liquidity pools, DEXes you've probably hit some walls that the documentation doesn't fully prepare you for. The Midnight programming model around shielded tokens is genuinely different from anything in the EVM world, and a lot of the intuitions you carry from Solidity or even other ZK environments will get you into trouble fast. This post is a breakdown of the most impactful errors and misconceptions I ran into while building shielded liquidity DeFi contracts using Midnight's Compact language. These are not theoretical every single one of these either broke a circuit or caused a proof server failure at some point. I'll walk through what the issue is, why it happens, and what the correct pattern looks like. Background: How Shielded Tokens Actually Work Under the Hood Before we get into the errors, let's get clear on the underlying mechanics because this context is what makes the errors make sense. Midnight uses a protocol called Zswap for shielded token operations. When a user sends tokens to your contract by calling receiveShielded , what actually happens is more involved than it looks on the surface. When your circuit calls receiveShielded(coin) , the Compact runtime records a shielded receive obligation in the transaction being constructed. At this point, the proof server kicks in to generate the ZK proof for your circuit. But here's the thing your circuit only describes what the contract side is doing. The transaction still needs to be balanced : the tokens being received by the contract have to come from somewhere. This is where the wallet gets involved through an internal mechanism that runs beneath your circuit. The wallet looks at the ShieldedCoinInfo you're receiving the coin's color (token type) and value and finds a matching UTXO in the user's private coin set. It then

A new standard for autonomous-agent commerce now has a live implementation, and it's worth reading closely - not because it competes with atomic settlement, but because it draws the line between two settlement philosophies more clearly than anything I've seen so far. The standard is ERC-8183 , the Agentic Commerce Protocol, launched earlier this year by the Ethereum Foundation's dAI team and Virtuals Protocol. The implementation is BNB Chain's BNBAgent SDK , which the team describes as the first live build of the spec (shipped on testnet in March 2026, mainnet pending). If you build for AI agents, both are worth understanding on their own terms. They're also the clearest mirror I've found for explaining what "atomic settlement" actually means. What ERC-8183 does ERC-8183 models commerce as a job with an escrowed budget . There are three roles: a Client who posts the job and funds it, a Provider who performs the work, an Evaluator - a designated third party who decides whether the work was completed. The job moves through four states: Open → Funded → Submitted → Terminal . The client funds the budget into escrow. The provider submits a deliverable. Then the evaluator - and only the evaluator - attests that the job is complete (or rejects it), and the escrow releases accordingly. If the job expires, the client gets refunded. This is a sensible design for a real class of problems. A lot of agent "commerce" is genuinely work-for-hire: do a task, produce a deliverable, get paid if it's acceptable. Acceptability is subjective, so you need someone to judge it. ERC-8183 makes that judge a first-class role and standardizes the lifecycle around it. BNBAgent SDK goes further and routes disputes through UMA's data-verification mechanism, adding an arbitration layer the base spec deliberately leaves out. So far, so reasonable. The interesting part is the assumption baked into the shape of it: someone has to decide that the deal is done. What atomic settlement removes Now hold th