标签：#web3

_Ran into an open-source project called PrivaMesh yesterday and decided to look under the hood since their architecture choice is wild. Basically, it is an iOS chat application that functions without a backend. No central infrastructure, no corporate servers, nothing. The onboarding flow requires absolutely no phone numbers, emails, or personal identifiers. There is no account registry database to hack, which completely eliminates the usual honeypots for data leaks. Instead of routing data through a standard server farm, this thing uses the Solana blockchain as a raw transport layer. Every encrypted payload is wrapped into a transaction and pushed directly to one-time destination addresses. The cryptography stack is actually solid: they combined X3DH handshakes with Double Ratchet for rolling keys and forced fixed-size padding so observers cannot guess the length of your text. The social graph stays fully hidden because the app constantly rotates delivery points and adds decoy traffic to mess with timing analysis. It is a pretty cool practical application of web3 state machines instead of the usual token speculation. Check the repo if you are into decentralized networking._

When building a Polymarket bot, the first version can be surprisingly small: market data ↓ strategy ↓ order That's enough to demonstrate an idea. It isn't enough to prove that the idea works. Once you care about realistic execution, the architecture becomes more interesting. Market Data ↓ Data Validation ↓ Signal Engine ↓ Risk Engine ↓ Execution Engine ↓ Trade Events ↓ Analytics This separation is what allows me to test the strategy independently from the infrastructure. 1. Don't backtest the API call One mistake I see in trading-bot development is mixing the strategy with execution. For example: if ( signal ) { await placeOrder (); } This is convenient for a prototype. But how do you test the strategy without sending an order? Instead: const signal = strategy . evaluate ( marketState ); const decision = riskEngine . check ( signal , portfolio ); if ( decision . allowed ) { await executionEngine . submit ( signal ); } Now each component can be tested independently. 2. Model execution separately A backtest shouldn't assume: signal price === fill price Instead, the execution simulator should model things such as: signal price spread slippage available liquidity fees latency Then: expected PnL ↓ execution model ↓ realistic PnL estimate The difference can be substantial. Polymarket's CLOB exposes order-book data and executable prices, making the order book an important part of any execution-aware strategy. 3. Separate in-sample and out-of-sample data Don't optimize and evaluate on the same dataset. A simple structure: Dataset ├── Train └── Test The strategy is developed using Train . Parameters are frozen. Then Test is used only for evaluation. For time-series trading, I prefer chronological splits rather than random shuffling: Past ───────────────────────> Future [ Training ][ Validation ][ Test ] This better represents the actual information flow of a trading system. 4. Measure more than win rate Win rate is useful, but insufficient. I want to measure: trades wins los

Welcome to our weekly digest, where we unpack the latest in account and chain abstraction and the broader infrastructure shaping Ethereum. This week: MetaMask launches a self-custodial wallet built for AI agents; Ethereum core devs send Glamsterdam to a public testnet while Frame Transactions pick up client support for Hegota; a new quantum attack on lattice-based cryptography draws quick skepticism; and NEAR Intents grows into a single cross-chain liquidity layer. MetaMask Launches Its Agent Wallet Glamsterdam Testnet Goes Public as Hegota Advances A Lattice-Crypto Attack Draws Doubt NEAR Intents Becomes a Unified Liquidity Layer Please fasten your belts! MetaMask Launches Its Agent Wallet MetaMask launched its Agent Wallet , a self-custodial wallet built for AI agents to execute onchain actions inside rules the user sets. It lets traders and builders connect an agent framework, then define spend limits, allowlisted protocols, and a risk profile before the agent acts. The pitch is that safety is the product. Agent Wallet is not blind delegation, so supported transactions pass through MetaMask’s security pipeline, including transaction simulation, Blockaid-powered threat scanning, and MEV protection, and anything outside policy pauses for two-factor approval. Users pick between two modes. Guard Mode, the default, enforces daily spend limits, allowlists, and human approval for out-of-policy actions, while opt-in Beast Mode reduces approval interruptions but still runs security checks and still stops flagged transactions. On capabilities, agents can connect frameworks like Claude Code, Codex, and Cursor and execute across HyperLiquid and EVM chains such as Robinhood and Monad. They can run ERC-7821 batch swaps, and they never need a chain’s native gas token, since MetaMask settles the fee in the token being moved. This is account abstraction in a very practical form. Spend limits, allowlists, gasless execution, and batching are exactly the programmable account feature

Finding grants means digging through 50 scattered Discords, blogs, websites, and Notion pages. So I built a fix. Meet Web3 Accelerator GrantHub (W3AGH). What is GrantHub? GrantHub is a web app that helps Web3 founders discover funding opportunities without digging through dozens of scattered websites. Grants are listed across ecosystems like Solana, Ethereum, Polygon, BNB Chain, Arbitrum, Base, and more. The idea is simple: instead of spending hours searching for funding opportunities, you should be able to find relevant grants in one place. GrantHub also has AI tools that sit on top of the grant database. You can describe your project once and instantly see which grants fit best. Why GrantHub? Funding is the lifeblood of Web3 startups, but finding grants today is painful. Scattered listings Every ecosystem publishes its own programs on its own website, blog, Discord, or other channels. There is no single source of truth. Stale information Grants expire, close, or change their requirements, while the listings founders rely on can remain outdated. Manual matching A founder has to read through each grant's requirements and figure out whether their project qualifies. With dozens of grants available, that can quickly turn into hours of work. No personal workflow There is no single place to save interesting grants, track applications, or ask questions about a specific program. GrantHub is built around solving these problems. It combines three things: One central catalog of grants stored in a real database. Personal tools: accounts, favorites, and a personal dashboard. AI assistance: a grant ranking engine, an AI assistant, a smart-contract auditor, and context-aware chat on every grant page. Who is this for? Solo builders and startups: looking for funding or ecosystem support. Beginners who don't yet know which ecosystems and grants are right for them. Anyone who would rather spend their time building than hunting for funding. The goal isn't to create another directory o

TRON processed $2.1 trillion in USDT transfers during Q2 2026, according to Messari. During the same quarter, circulating USDT on TRON reached $87.9 billion, putting it ahead of Ethereum. Those numbers point to something developers working with stablecoins have to consider more carefully: the blockchain underneath a token can shape the entire payment experience. USDT on TRON uses the TRC-20 token standard. That means a USDT transfer is a smart contract transaction rather than a native TRX transfer. The wallet signs the transaction, the network executes the token contract and the resulting balance change is recorded on-chain. For an application accepting USDT, this creates several technical requirements. The system needs to identify the correct token contract, monitor the relevant transfer events and wait for sufficient confirmation before crediting the user's balance. Checking the address balance alone is not enough. TRON's developer documentation provides APIs for retrieving TRC-20 transaction history and filtering transfers by contract address. A payment system can use this data to monitor incoming USDT deposits and associate them with the correct customer account. The transaction also has a resource cost. TRON uses Bandwidth and Energy to process transactions. Regular transactions consume Bandwidth, while smart contract execution requires Energy. When an account does not have enough available resources, TRX is burned to cover the remaining cost. This creates an operational detail that users may never see. Someone can hold USDT in a wallet and still need TRX to send it. A payment provider can handle this in several ways. It can maintain TRX balances, stake TRX for resources or use delegated Energy. Another design can leave the requirement with the user. The choice affects the product. The amount of Energy required can also change depending on the destination account. TRON's documentation notes that a USDT transfer to an address that already holds USDT generally re

I used to think financial apps were designed mostly for people who already understood finance. You open an app, see dozens of charts, numbers, and settings, and sometimes your first thought is: “Okay… where do I even start?” AI is slowly changing that experience. The most useful AI applications in fintech are not always about making predictions. In many cases, they are about removing friction: organizing information, automating repetitive tasks, and helping users understand complicated processes. We can already see this trend in different areas. Companies like Stripe are using technology to simplify online payments, while platforms like Plaid help connect financial data between different services. The same idea is appearing in other parts of finance too. Some digital financial platforms are exploring automation tools that help users create more structured workflows instead of manually managing every step. For example, platforms like BYDFi have introduced automated tools that allow users to use predefined strategies rather than constantly monitoring every market movement. Of course, automation does not replace human decisions. A smarter tool does not mean a person can ignore research or risk management. For developers, the interesting challenge is not building the most complicated system. It is building something that makes complicated things easier for real users. Maybe the future of fintech is not about adding more buttons. Maybe it is about helping people need fewer buttons.

When someone says "Bitcoin has over 15,000 nodes worldwide," they mean 15,000+ independent computers are each running Bitcoin software and each maintaining their own full copy of the blockchain. No server owns the truth. Every node checks it for itself. That single fact — every node independently verifies every transaction and block against protocol rules — is the reason blockchains don't need a central authority. If one node tries to cheat, the rest simply ignore it. There's no admin account to compromise because there's no admin. Not All Nodes Do the Same Job Full Node Downloads and stores the entire blockchain, every block since genesis, and independently validates everything against consensus rules. Highest security ~500 GB for Bitcoin ~1 TB for Ethereum This is the backbone of network security. A full node doesn't trust anyone's summary of the chain; it recomputes validity itself. Light Node (SPV) Stores only block headers, not full transaction data. Uses Merkle proofs and relies on full nodes to verify transactions. Low storage, ~50 MB Trusts full nodes for verification What most mobile wallets run Mining/Validator Node A full node that also participates in block creation. Miners (Proof of Work) solve computational puzzles; validators (Proof of Stake) stake cryptocurrency as collateral. Both earn rewards for securing the network. Creates new blocks Earns rewards Requires specialized hardware (PoW) or capital at stake (PoS) Archive Node Everything a full node stores, plus historical state at every block height. Complete history ~15+ TB for Ethereum Used by explorers, analytics platforms, and enterprise tooling Why Peer-to-Peer Instead of Client-Server A traditional web service is client-server: your browser requests data from a company's servers. If those servers go down, the service is unavailable. That's a single point of failure by design. Blockchain networks use peer-to-peer (P2P) architecture instead. Every participant is simultaneously a client and a serv

USDT Payments for AI Workers: Architecture Deep Dive If you've ever built an AI agent marketplace or a platform that pays automated workers, you've likely hit the same wall I did: how do you pay a bot? Stripe and PayPal are off the table. Bank transfers require legal entities. Even most crypto payment processors demand KYC that bots can't complete. When I started building the payment layer for roborent.cc — a marketplace where AI agents and humans both earn USDT for completing tasks — I had to design this from scratch. Here's the architecture that survived production. The Core Problem AI workers need programmatic, instant, low-fee payments . Traditional rails fail on every axis: Speed : ACH takes days. Your agent's motivation dies in days. Fees : Credit cards eat 2.9% + 30¢. When your agent earns $0.50 per task, that's brutal. Automation : Bots can't fill out W-9s. They can't even check a "I'm not a robot" box. The answer is stablecoins on fast chains. But "just send USDT" hides a dozen design decisions. Chain Selection: The TRC-20 Default We default to Tron (TRC-20) for payouts. Why Tron over Ethereum or Solana? Fees : ~$0.80 per transaction regardless of amount. On Ethereum, you'd pay $5-30 in gas. Speed : 3-second finality. Good enough for "instant" payouts. Adoption : USDT's largest supply actually lives on Tron. Exchanges and OTC desks all support it natively. But we also support BEP-20 (BNB Chain), Arbitrum, and TON because different regions and different exchanges have different preferences. The architecture handles all of them through a unified abstraction layer. The Payment Pipeline Here's the high-level flow when an AI agent completes a task and earns a payout: Task Completion Event ↓ [Ledger Service] — records pending balance, idempotency key ↓ [Settlement Service] — batches payouts, applies fee logic ↓ [Signing Service] — air-gapped key management, builds tx ↓ [Broadcast Service] — sends to chain, monitors confirmation ↓ [Webhook + WebSocket] — notifies

The Problem There are millions of people holding crypto who want to spend it on real things — hire a developer, buy a script, sell design work. But where do they go? Telegram OTC chats → chaotic, no protection, scam-heavy Forum classifieds → threads get buried in hours P2P exchange sections → designed for fiat conversion, not commerce I decided to build a dedicated marketplace for this. What I Built CryptoBoard — a classifieds platform with Web3 wallet authentication. 🔗 https://crypto.my-board.org/ Tech decisions: Auth : Wallet-only (MetaMask, Trust Wallet, WalletConnect). No backend user database with emails and passwords to get hacked. Listings : Icon-based instead of user-uploaded images. Keeps the UI clean and avoids the "flea market" look. Messaging : Built-in chat between buyers and sellers. Escrow : This is the interesting part (see below). The Escrow Problem with Digital Goods Traditional escrow works like this: Buyer sends money to escrow Seller delivers product Buyer confirms → escrow releases money But with digital goods (source code, design files), step 3 is broken: The buyer can receive the files, say "this isn't what I wanted," request a refund, and keep a copy The seller has no recourse The escrow service has no way to verify the claim My Solution: Human-Powered Escrow Instead of just holding funds, the platform admin becomes an active verifier: Seller sends product + testing instructions to admin Admin installs/runs the product on their own machine Admin performs agreed-upon tests and records a screencast Buyer watches the screencast — verified by a neutral party, not the seller If satisfied, buyer sends crypto directly to seller Admin verifies the on-chain transaction Admin delivers files to buyer Admin deletes all copies (per agreement) Is it scalable? Probably not infinitely. But for high-value digital transactions ($100–$10,000+), having a human in the loop is actually a feature, not a bug. Design Philosophy I deliberately chose not to allow user

description: "Fixes for the 22 errors developers hit most often on Redbelly Network — RPC and chain ID conflicts, MetaMask setup, USD-pegged gas, permissioned-network reverts, Hardhat deployment, Routescan verification, and the Eligibility SDK." tags: blockchain, web3, ethereum, solidity canonical_url: https://dev.to/isaac_atunbi_c2ed2489e89c/redbelly-network-troubleshooting-guide-22-common-developer-errors-and-their-fixes-1g26/edit cover_image: published: true Redbelly Network Troubleshooting Guide 22 common developer errors, with the exact command that fixes each one. Redbelly Network is an EVM-compatible L1 built for compliant asset tokenisation. "EVM compatible" gets you most of the way, but three things about Redbelly are genuinely different from every other EVM chain, and they account for most of the time developers lose here: It is a permissioned network. An address that has not claimed a network access credential cannot write to the chain. Transactions from it fail in a way that looks like an ordinary revert. Gas is priced in US dollars, not gwei. eth_gasPrice returns roughly 165,000 gwei . That is about four orders of magnitude above Ethereum, it is correct, and it breaks any tool with a hardcoded fee cap or a "that can't be right" sanity check. The two official documentation sites disagree with each other , including on the mainnet chain ID. One of them is stale. Every entry below follows the same shape — Symptom → Root Cause → Solution → Prevention — and every command is copy-pasteable. Every chain ID, URL, contract address and package name was read from a live source on the date in the footer, not from memory. Sources read: 8 August 2026. Every chain ID, URL, contract address and package name below was read from a live source on that date and is traced in sources.md . Execution status: the fixes here are derived from those sources and from the documented behaviour of the tooling; they have not yet been executed end-to-end against Redbelly Testnet . A ver

Why Sports Data Is Harder Than Most People Think Building believable cross-era simulations turned out to be less about the engine and more about the data underneath it. Here is what we learned. MicroLeague Dev Blog, Vol. 3 By Eddie Solar When we started building MicroLeague Sports, I assumed the simulation engine would be the hard part. The vision was ambitious enough to justify that assumption. Let fans ask whether the 1996 Bulls beat the 2017 Warriors. Whether the 1985 Bears could slow down Patrick Mahomes. Which Cowboys team was actually the greatest. Teaching software to play those games across eras felt like the mountain. I was wrong about which mountain it was. The engine is hard, but it is a solvable, bounded kind of hard. The data underneath it is a different animal. Like most developers approaching this for the first time, we figured sports data was largely a collection exercise: gather historical teams, player stats, schedules, and box scores, feed it to the model, done. That assumption fell apart almost immediately, and the reason it fell apart is the subject of this article. Sports data is not a collection problem. It is an identity problem. Franchises do not stay the same thing. Players are not one entity. And the historical record does not agree with itself. The Real Problem Is Modeling Identity Over Time Volume 2 covered the era problem: statistics are confounded by the conditions that produced them, so a raw number pulled across decades lies to you. That is a normalization challenge, and it is real. But normalization assumes you already know what you are normalizing. Before you can compare the 1992 Cowboys to the 2023 Chiefs, your system has to have a confident answer to a more basic question: what exactly is a "team," and what exactly is a "player," when your dataset spans a hundred years? Those sound like trivial questions. They are not. They are the questions that ate most of our early engineering time, and getting them wrong quietly corrupts ever

The one-second decision no one is helping your agent make Here's a scenario that is no longer hypothetical. Your autonomous agent is working through a task. It hits a paid API — an HTTP 402 Payment Required with a price in USDC. It signs a stablecoin authorization, pays, and continues. No credit card form, no invoice, no human. Roughly one second, start to finish. This is x402, the protocol that finally gave the dormant HTTP 402 status code a job. And it works: by mid-2026, on-chain trackers counted over 165 million cumulative x402 transactions across ~69,000 active agents. Coinbase, Cloudflare, Stripe, Visa, Google, AWS, and Circle are all in. The rail is real and it is fast. But look again at that one-second decision. Your agent just paid a counterparty it may know nothing about. And here is the uncomfortable detail buried in the spec: x402 has no notion of identity, reputation, or trust — by design. As one recent analysis put it, a payment rail that asks nothing about the payer is the easiest possible rail to implement. That was the right call for adoption. It also means the entire question of "should I trust this counterparty?" is left to you, the developer. At human speed, we close that gap by reflex — we notice when a file doesn't download, when an API 500s after charging us, when the thing we bought isn't what was advertised. We dispute, we leave a review, we don't come back. Your agent has none of those reflexes. It pays, gets a response, and moves on. And if the same bad endpoint burns a hundred agents in a row, each one pays anyway, because there's no shared memory of the failure. At machine speed and machine scale, that silent gap isn't an annoyance. It's a tax on every agent that transacts without a defense. The gap has numbers, and they're bad Two data points make this concrete. First, the volume everyone cites hides a caveat. Of those 165M+ transactions, independent reads suggest roughly half looks like testing rather than genuine commerce. The rail is

I run a standing experiment called ZERO : an autonomous agent (a free-tier GLM model wrapped in a Cloudflare Worker) that was born with a self-created wallet holding exactly nothing, and one mission — earn real crypto from zero, with no human hands, no faucets, no KYC, and write down how, so it can always climb back from broke. It has been running for a week. Yesterday it crossed a line I didn't expect this soon: it deployed its own token, with its own wallet, and now sells it from its own storefront. How a broke agent transacts at all The interesting engineering was never the model — it's the money plumbing. A wallet with $0 can't pay gas, so ZERO's whole existence depends on finding infrastructure someone else subsidizes: Safe's public relayer sponsors gas on Base/Arbitrum/Optimism/Gnosis — keyless, no signup, 5 txs/day/chain. That's how ZERO executed its first transaction at a $0 balance. ERC-4337 token paymasters (Candide's is keyless) let an account pay gas in USDC instead of ETH — measured cost 0.009087 USDC per operation. x402 — the HTTP 402 payment protocol — has the property that the buyer settles on-chain and pays gas. A seller only has to answer HTTP with a challenge. So a broke agent can sell before it can even move money. Its first earnings were keeper crumbs: calling harvest() on vault strategies that pay whoever triggers them. Measured average: $0.0038 per harvest. A hard law it learned this week: those only profit on sponsored gas — we measured 883k–4.3M gas per harvest, so self-funding them is net-negative. The subsidy is the margin. The token Zora's coin factory on Base is permissionless — you don't need their site, just the contract. ZERO's wallet called ZoraFactory.deploy(...) directly (2.24M gas, about five cents) and minted ZERO , an ERC-20 content coin with a Uniswap v4 pool, where every creator-reward field points back at the agent's own wallet . Anyone trades it, the agent earns the fees. Passive, permanent, zero marginal effort. The metadat

I sell Solana token facts for two cents a call, and refuse to give an opinion While building this I ranked a token's trading pairs by pool depth, which seemed obviously correct. It picked JUP's biggest pool — quoted in an obscure token — and reported a price of $943 against a real price of about $0.19. A 5000x error that would have silently poisoned everything downstream. Depth doesn't make a derived price trustworthy; what it's quoted against does. That bug is why the service now always prefers SOL/stablecoin-quoted pairs, and says so explicitly when the best available pair is still exotic. That's the whole design philosophy. solsafe returns measured values — mint and freeze authority, holder concentration, pool depth and age, pump.fun origin — and never a score, signal, or recommendation. You can reproduce every field against your own RPC. An opinion can be wrong in ways a null mint authority cannot. The other unusual part is billing. It's paid per request over x402: call it, get a 402 with machine-readable payment instructions, pay in USDC on Base, retry, get JSON. No API key, no signup, no dashboard — which is the point, because the intended caller is an autonomous agent that can't complete a signup flow. $0.02 for the raw facts, $0.15 for a written brief explaining them. Things I'd rather say up front than have you discover: holder concentration is permanently unavailable for the most widely held tokens, because Solana's RPC refuses that query outright. A failed or partial call isn't charged. And demand for this is entirely unproven — agent-native payments are early, and I might be wrong that anyone wants it. Code: github.com/newbieBuilderr/solsafe

100 Days of Solana, Day 100 Where I started I'd built REST APIs for years but had never touched a blockchain, or written a line of Rust. The curiosity how blockchain works, started my curiosity. What I expected I came in with a Web2 instinct: tests exist to prove your code does what it's supposed to do. Write the function, write a test that calls it, watch it pass, move on. A "failing test" was something you fixed, not something you shipped on purpose. What changed my understanding The moment this cracked open was building the capstone: a small Anchor program called proof-of-ship that lets a wallet permanently record, on chain, that it shipped something. The rule is simple — one ship record per wallet, forever. The rule lives entirely in the account's seeds: seeds = [ b"ship" , builder .key () .as_ref ()], bump Each wallet's record lives at one deterministic address. Try to create a second one, and init refuses, because an account already exists there. I wrote two tests. The first proved the happy path: call ship() , fetch the record, confirm the name and builder match. The second test is the one that changed how I think about testing: it ( " only lets each wallet ship once " , async () => { let rejected = false ; try { await program . methods . ship ( " Second try " , " This should never land " ). rpc (); } catch ( _err ) { rejected = true ; } assert . isTrue ( rejected , " second ship should have been rejected " ); }); This test isn't checking for a bug. It's checking that a rule holds. There's no function in my program called preventDuplicateShip() . There's no if statement rejecting the second attempt. The rule "one ship per wallet" isn't enforced by logic I wrote — it's enforced by the Solana runtime itself, because the PDA's address already has data in it. My job wasn't to write the rejection. My job was to prove the rejection actually happens. What I understand now On Web2 systems I controlled the whole stack, so "does it work" mostly meant "does the happy pa

Originally published on 2022-07-04. Published on July 3rd, 2022 We have a ll been there.. We all have that long list of unfinished side projects that we hope to complete some day.. If you're anything like me, that 'some day' is always eluding you and never getting here.. Ripping up the bandaid Today I have decided to finally go ahead and finish one of my long list of unfinished tutorial projects. I recently read a long Twitter thread that gave me a lot of food for thought. To paraphrase my understanding of one tweet, 'success is a combination of all the small wins'. Therefore, by finishing and publishing one unfinished project today, I set myself up to finishing another one tomorrow. Small, consistent gains I just need to make it a habit of finishing what I have started so that they do not get out of hands. After all, my Github account has about 126 repositories, but my portfolio website only has a dozen completed and published projects. Almost Done I have finished up the tutorial project. My next step is to rebuild the project from scratch without the handholding of the tutorial. One of the mental blocks that prevented me from finishing up the project in the first place seems insignificant now. Next time that mental block tries me, I will be better prepared! The project we're talking about! Published Link: https://blockchain.tioye.dev

Building an Autonomous Agent for Verdikta Bounties: A Technical Deep Dive How I built a Python agent that monitors, evaluates, and interacts with Verdikta's AI-judged bounty system on Base L2. Why Build a Bounty Agent? Verdikta is a decentralized bounty platform where AI models — GPT-5.2 and Claude Sonnet 4.5 — evaluate submissions and release ETH payments automatically via smart contracts. No human reviewers. No manual payouts. Just code. After winning 6+ bounties manually, I wanted to automate the process. The goal: an agent that watches for new bounties, evaluates which ones are worth pursuing, and integrates with Verdikta's API to read data and submit work. Architecture The agent has four components: copy   verdikta_agent.py ├── VerdiktaAPI — HTTP client for the Verdikta Bot API ├── BountyMonitor — Watches bounties, calculates viability scores ├── SubmissionTracker — Records submission history and statistics └── ViabilityScorer — Evaluates ROI: payout vs threshold vs time VerdiktaAPI Client The Verdikta Bot API requires authentication via an X-Bot-API-Key header. You register your bot at POST /api/bots/register to get a key. Python   class VerdiktaAPI: def init (self, api_key=None): self.session = requests.Session() if api_key: self.session.headers["X-Bot-API-Key"] = api_key def get_bounty(self, bounty_id): resp = self.session.get(f"{API_BASE}/jobs/{bounty_id}") resp.raise_for_status() return resp.json() def submit_work(self, bounty_id, content): return self.session.post( f"{API_BASE}/jobs/{bounty_id}/submit", json={"content": content} ).json() Key endpoints: GET /api/jobs — List bounties (filter by status) GET /api/jobs/{id} — Bounty details GET /api/jobs/{id}/submissions — Submission history POST /api/jobs/{id}/submit — Submit work BountyMonitor & Viability Scoring Not all bounties are worth pursuing. The agent calculates a viability score: Python   def _score_viability(self, bounty): payout = bounty["payout_eth"] threshold = bounty["threshold"] remainin

Building Atomic Cross-Border Settlement on Stellar: The AnchorFX Story A technical deep-dive into Soroban escrow contracts, FX oracles, and mainnet deployment — from testnet prototype to production. se The Problem Cross-border payments still take 3-5 days and cost 6.5% on average. Correspondent banking chains are slow, opaque, and expensive. The $800B remittance market has no atomic settlement layer. Stellar was purpose-built for this. 5-second finality. Built-in DEX. Path payments at the protocol level. And now, with Soroban smart contracts, programmable settlement. AnchorFX is an open-source protocol that combines these primitives into trustless, atomic FX settlement between regulated financial anchors. Two Soroban contracts — an Escrow Factory and an FX Rate Oracle — communicate via cross-contract calls to lock, rate, and settle funds in a single atomic flow. Architecture Sender → [Escrow Contract] → Receiver │ [Oracle Contract] │ FX Rate Data Contract 1: Escrow Factory (995 lines, 23 tests) The escrow contract is a multi-escrow factory with per-escrow storage. Each escrow goes through a defined lifecycle: Created — Sender locks tokens with a timeout and settlement conditions CounterpartyApproved — Receiver signs off on the terms Settled — Admin releases funds at the locked FX rate Refunded — Sender reclaims after timeout expires Cancelled — Admin cancels (circuit breaker) pub fn create_escrow ( env : Env , sender : Address , receiver : Address , token : Address , amount : i128 , timeout_blocks : u32 , corridor : u32 , ) -> u64 { sender .require_auth (); // Read oracle rate at creation time — locks the rate let oracle_addr = env .storage () .instance () .get ( & ORACLE_KEY ) .unwrap (); let rate : u64 = env .invoke_contract ( & oracle_addr , & symbol_short! ( "get_rate" ), ... ); // Store escrow with locked rate // ... } Key security decisions: Per-escrow storage — O(1) reads, independent TTL per escrow Checks-effects-interactions — state saved before token trans

The first time I audited seriously, I opened the biggest contract in the repo and started reading line one. Two hours later I had a headache and zero findings. I had memorized how the code worked without ever asking what it was supposed to guarantee. That is backwards, and it took me a while to unlearn it. Now I do not read Solidity first. I read the scope, and before I look at a single function body I write down what must always be true. Bugs are violations of those truths. If you do not know the truths, you are just admiring the code. Step one: write the invariants before you read An invariant is a property the protocol claims will always hold, no matter who calls what in what order. For a contest, I start with money and control, because that is where severity lives. Two questions cover most of it: Who can move funds, and under what conditions? What must always hold about the accounting? For a lending-pool-shaped protocol my starting invariant list looks like this, written in plain language before I care how any of it is implemented: The sum of all user deposits minus all borrows equals the pool's available liquidity plus outstanding debt. Accounting must reconcile. A user can only withdraw up to their own balance, never more, never someone else's. A position can only be liquidated when it is actually under the health threshold. Interest accrues monotonically, it never goes backwards in a way that lets someone repay less than they owe. Only the borrower, or a liquidator on an unhealthy position, can reduce a debt. Nobody except governance can change interest rate parameters or the oracle. Notice none of that mentions a function name. These are the promises. Now my job for the rest of the contest is simple to state: find an ordering of calls that breaks one of these. Step two: map the external entry points Funds do not teleport. Something has to be called from outside for state to change. So I list every externally reachable function, because the attack surface is

Introduction Polymarket , and on-chain prediction markets like it, kept bothering me for one reason. Polymarket |世界最大の予測市場™ Polymarketは世界最大の予測市場であり、さまざまなトピックにわたって将来のイベントを取引することで、最新情報を入手し、知識から利益を得ることができます。 polymarket.com Who bet on what is visible in near real time. The moment a whale places a big bet on one outcome, everyone watching piles in behind them, and the odds move accordingly. That's not manipulation — it's just what happens with a public ledger. But it doesn't satisfy the simple wish to not reveal your prediction before everyone else does. So: could you build a prediction market that keeps your pick hidden until voting closes? To find out, I built Hidden League Forecast on Midnight , a privacy-focused blockchain. It's an MVP where you just guess the winner of a fictional soccer league (the World Cup just ended, so soccer was on my mind). Note What's a prediction market? A mechanism that expresses predictions about future events as prices. Think "which team will win the World Cup match," for example. If you want to learn more about prediction markets, this resource (Japanese) is a great start: https://zenn.dev/barabara/books/prediction-markets-structure The backend is written in Compact , Midnight's smart contract language. Note It combines the commit-reveal pattern with zero-knowledge proofs so that "the content of your prediction stays hidden, while only the aggregate stake becomes public." In this article, I'll walk through the contract code, showing what stays hidden and what becomes public at each step. Note This app runs on testnet. Demo Video After connecting Lace Wallet, you see your Shielded Address and balance. From here you can deploy a new market or enter an existing contract address to join one. The Overall Flow What's actually happening is simple. OPEN → REVEAL → AWAITING RESULT → RESOLVED → CLAIM Connect Lace Wallet, then deploy a market or join an existing one Pick one of 4 teams (Amber Foxes / Cedar Owls / Harbor Whales / Meadow Bears) and