今日已更新 133 条资讯 | 累计 37382 条内容
关于我们

标签:#EU

找到 93 篇相关文章

AI 资讯

Redbelly Network Troubleshooting Guide: 22 Common Developer Errors and Their Fixes

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

2026-08-08 原文 →
AI 资讯

Why the Boring Businesses Win

I went through 1,400 Reddit complaints and 100 businesses with verified revenue. The pattern was the same every time, and it was never the exciting idea. Everyone wants to build the thing their friends would download. The app with taste. The product that sounds impressive at dinner. I used to want that too. Then I spent a year scoring Reddit complaints and cross-referencing them against 100 real businesses pulling verified revenue through Stripe. Not founder-claimed numbers. Not rounded up for a tweet. Actual payment data. The ones making real money were almost never the ones I would have picked. Here is what they looked like instead. 1. They solved one painfully specific workflow The winners were never "project management tools" or "email marketing platforms." They were a Slack bot that reminds you to follow up on unanswered threads. A browser extension that monitors price changes on niche supplier sites. A simple API that converts between file formats nobody else bothers with. The scope was almost comically narrow. And that was the point. Narrow meant the MVP shipped in 2 to 6 weeks, the pitch fit in one sentence, and one person could run the whole thing. Every time I saw a solo founder trying to build something broad, the project either stalled at 80% or launched to silence. The narrow ones launched to a small, loud group of people who were already complaining about exactly that problem. If you cannot describe what your product does in ten words, it is probably too broad. 2. They did not invent the problem. They found it. This one changed how I think about ideas entirely. In nearly every profitable business I looked at, the founder did not come up with the problem in the shower. Someone on Reddit, in a Slack group, or in an App Store review was already describing the pain in detail. The founder just showed up with the fix. Plausible Analytics came from repeated frustration with Google Analytics being bloated and privacy-hostile. Testimonial.to was built after the

2026-08-03 原文 →
AI 资讯

Your DEX tool is probably overstating Uniswap v3 TVL by 25x

I shipped a bug into a paid API and it took me a while to see it, because nothing errored. Every response was a clean HTTP 200 with a confident number in it. The number was wrong by 25x . Here is the finding, the arithmetic, and how to check your own code in about thirty seconds. The measurement Uniswap v3, WETH/USDC on Base. Left column is what my API reported as TVL. Right column is what the pool contract actually holds — a plain balanceOf on each token, at the pool address. pool reported actually held overstated uniswapV3 0.01% $2,070,000 $215,646 9.6x uniswapV3 0.05% $73,600,000 $10,069,584 7.3x uniswapV3 0.30% $2,840,000,000 $111,513,855 25.5x uniswapV3 1.00% $14,800,000 $846,661 17.4x $2.84 billion in one pool on Base. Base's entire ecosystem TVL is a few billion dollars. That is what finally made me look — not a failing test, just a number too large to be true. Why it happens A v2 pool holds two piles of tokens and the price is the ratio between them. getReserves() returns the actual piles. Easy. A v3 pool concentrates liquidity into price ranges. It does not have "reserves" in the v2 sense. What it has is a liquidity value L at the current price P , and the standard way to make v3 math reusable is to compute the virtual reserves — the amounts a v2-style pool would need to behave identically right here: x_virtual = L / √P y_virtual = L × √P These are enormously useful. Feed them into the ordinary constant-product formula and you get correct swap outputs and correct price impact, which is why essentially every v3 integration computes them. They are also not tokens anyone owns . They describe the shape of the curve at the current price, not custody. Concentration is exactly the point of v3: a position spanning a narrow band behaves like a much larger v2 pool while holding far less capital. The 25x above is that leverage, showing up as a number I then mislabelled. My code did this: tvlUsd = 2 * reserveA * priceA // fine for v2, nonsense for v3 That line is corre

2026-08-02 原文 →
AI 资讯

July closed with $55.8 billion in Physical AI funding and an industry finally stopped asking whether this works. Here's what you missed this week.

July 2026 is over. The month that opened with AUTONOMOUS 2026 and WAIC 2026 running simultaneously on opposite sides of the Pacific closed with the sector tallying what it built. The number that defines the period is $55.8 billion in robotics funding across H1 - nearly double the prior full-year record. But the more durable signal from this week is operational rather than financial: Neura Robotics has a confirmed deployment date at a Schaeffler facility in December, NVIDIA's simulation-to-real pipeline is now functional at production scale, and five simultaneous shifts are reshaping factory floors right now, not in 2027. The questions that drove the first half of 2026 - does Physical AI work, is the funding real, will the robots actually arrive - are no longer interesting. H2 starts with harder ones. Stats: Value Description $55.8B Robotics funding raised in H1 2026, nearly double the prior annual record $8.6B Humanoid startup funding in H1 2026 alone, 1.8x all of 2025 December 2026 Confirmed first deployment of Neura Robotics humanoids at Schaeffler's German facilities 5 Simultaneous operational shifts reshaping factory floors identified in the mid-2026 analysis Neura Robotics Has a Deployment Date: December 2026 in a Schaeffler Factory Most Physical AI deployment announcements are directional. "We are partnering with X to explore robotics in our facilities" is a press release. A confirmed month and a specific facility is a contract. Neura Robotics confirmed that Schaeffler - one of the key investors in its $1.4 billion Series C alongside Amazon, Nvidia, Qualcomm, and the European Investment Bank - plans to deploy Neura's humanoids in its German facilities in December 2026 . Schaeffler manufactures precision bearings and components for electric vehicles, operating in environments where dimensional tolerances are measured in micrometers. Deploying a humanoid robot in that context is a fundamentally different challenge than warehouse pick-and-place or automotive sequ

2026-07-31 原文 →
AI 资讯

Running Shape Up in Jira or Linear quietly turns it back into Scrum

Process mismatch In tools built for Scrum, a task is an input: something you file, size, and work on. In Shape Up, a task is an output — something discovered while building work that was already shaped and bet on. That's the core mismatch, and it plays out differently depending on the tool. Jira Jira does exactly what it was built to do. Its shape is Scrum's shape: a backlog, estimates, sprints. Teams bring Shape Up in anyway and try to make it fit the tool's shape. A scope becomes an epic. A task becomes a ticket. The pitch — Shape Up's document for a problem, its appetite, and a proposed solution — has no equivalent object in Jira, so it ends up living in a Confluence doc, disconnected from the work it's supposed to govern. The substitutions are each small and reasonable on their own: An estimate field is there, so it gets filled in — and the velocity report looks broken without it. Losing bets need somewhere to go, so they land in the backlog. They aren't dead, they're waiting — and now someone has to groom them. Appetite ("how much is this worth") quietly reverts to estimate ("how long will this take"). Before long, the team is running Scrum, with a backlog-refinement meeting back on the calendar. The tool's requirements pull the ceremonies back in. Linear Linear is fast and well made. It even has cycles. The mismatch here isn't a quality problem — it's an inheritance problem. Linear carries the same assumptions as Scrum, just executed better. When a cycle ends with work unfinished, Linear rolls it forward automatically into the next one. It's meant as a convenience feature. It's also the inverse of Shape Up's circuit breaker. Shape Up's bet is that the deadline is real. The whole mechanism depends on a hard stop forcing a decision — cut the scope and ship what's done, while there's still time to make that call. A tool that quietly carries unfinished work forward removes the one moment the method needs. Every six weeks, it says: the deadline was just a suggestio

2026-07-29 原文 →
AI 资讯

Shipping a Solidity contract to mainnet? Do this 20-minute self-check first

You built something. Tests pass. You're days from mainnet. Before you either skip security entirely (please don't) or spend weeks lining up a full audit, here's a self-check you can run in 20 minutes that catches the mistakes I see most often in first-time deployments. I run security reviews for small and new protocols, and the same handful of issues come up again and again. None of these need a tool — just your eyes and this list. 1. Who can call what? Open every external / public function that moves funds, mints, pauses, or upgrades. For each, ask: should a random address be able to call this? If not — is there an onlyOwner / onlyRole / require(msg.sender == ...) guarding it, in the function itself or in every internal function it calls? The classic bug isn't a missing modifier. It's a function that looks unguarded but delegates to a guarded internal one (fine), or one that looks guarded but the guard is in a branch a caller can skip (not fine). Trace the call, don't trust the signature. 2. The first-depositor trap (if you have a vault) If you mint shares from deposits (ERC-4626 or anything share-based), the first depositor can sometimes donate assets directly to the contract to inflate the share price, so the second depositor rounds down to zero shares and loses funds. Fix: virtual shares, a dead-shares mint at deploy, or a minimum-liquidity lock. OpenZeppelin's ERC-4626 handles this out of the box — a hand-rolled vault usually doesn't. 3. Reentrancy — but only the real kind Not every external call is reentrancy. It's a bug when an attacker-controlled call can re-enter and corrupt shared storage before you've updated it. Quick checks: Do you update state before the external transfer (checks-effects-interactions)? Is there a nonReentrant on functions that move value? Is the call target a trusted, immutable contract, or an arbitrary address the attacker supplies? A call to a protocol-owned contract, or a memory /local variable written after the call, is usually not

2026-07-24 原文 →