A walkthrough of building a Web3 marketplace on Ethereum's Sepolia testnet using Solidity smart contracts, Hardhat, React/Vite, ethers.js, and MetaMask. The project implements on-chain payment splitting where 80% goes to the seller and 20% to the platform admin, all handled automatically by the smart contract without a centralized backend. Key concepts covered include MetaMask wallet authentication, gas fees, hybrid Web3 architecture (frontend stores product data, blockchain handles payments), and deploying contracts via Hardhat to Sepolia. The author also reflects on the insight that not all data belongs on-chain due to gas costs.
Nguồn: https://coinsbench.com/building-a-real-smart-contract-web3-marketplace-on-ethereum-sepolia-07b572a0f8a4. 8sync News chỉ tóm tắt và dẫn link; bản quyền nội dung thuộc tác giả và nguồn gốc.

A walkthrough of Level 3 (Truster) from Damn Vulnerable DeFi V4, a smart contract security challenge. The pool contains an arbitrary external call vulnerability in its flash loan function. By borrowing 0 ETH and passing crafted calldata that calls ERC20 approve(), an attacker can grant themselves allowance over the pool's entire token balance, then drain it via transferFrom() after the flash loan completes. Key takeaways: never allow arbitrary external calls in flash loan logic, always control who can supply calldata, and flash loans themselves are not inherently dangerous — the surrounding logic is.

A walkthrough of the Side Entrance challenge from Damn Vulnerable DeFi V4, where the goal is to drain a lending pool. The vulnerability is a business logic flaw: the flash loan contract only checks that the pool balance is restored after the loan, but doesn't verify whether funds were returned via deposit (which credits the attacker's balance) rather than a direct transfer. The exploit takes a flash loan, repays it via the deposit function to gain an internal balance, then withdraws and sends funds to a recovery address. A working Solidity proof-of-concept contract and test function are provided.
Enterprise adoption of smart contracts on public blockchains is blocked by a privacy problem: all transactions are visible by default. Zero-knowledge (ZK) cryptography solves this but requires PhD-level math expertise most engineering teams lack. EY has released the Blockchain Privacy Sandbox, a web-based tool built on its open-source Starlight ZK compiler, that lets developers take an existing Solidity contract, annotate private fields, and generate a privacy-preserving version with API endpoints in under an hour — no ZK expertise required. The sandbox is positioned as a POC validation tool, not a production environment. EY's Nightfall ZK rollup handles private token transfers on Ethereum but still has throughput limitations (6–20 minute block times). Tokenization is the most mature use case today; supply chain and financial workflows are further out. The ZK proof market is projected to grow from $1.3B in 2024 to $7.6B by 2033.
A beginner-friendly walkthrough of what happens when a smart contract function is called on the EVM. Covers how Solidity compiles to bytecode, how function selectors identify which function to execute, and why contract execution starts at the beginning of runtime bytecode rather than jumping directly to the called function. Sets up a series on EVM internals including selector collisions, delegatecall, and proxy patterns.
A bug in the Solidity compiler (versions 0.8.29–0.8.35) causes the C3-linearized list of base contracts to be permanently reversed in memory when Warning 3495 (storage layout too close to end of storage) is emitted. The root cause is use of ranges::actions::reverse instead of ranges::views::reverse from the ranges-v3 library, which mutates the underlying container in place. This reversal corrupts inheritance-dependent behavior including constructor invocation order, state-variable initialization, super and virtual function resolution, and can cause silent miscompilations or internal compiler errors. The bug only affects contracts using a custom storage layout placed within the last 2^64 slots of storage AND using inheritance. A Sourcify scan found no deployed contracts meeting these conditions. The fix is available in Solidity 0.8.36, which replaces the mutating call with a non-mutating view.
A comparison of five Ethereum payment gateways for businesses in 2026: NOWPayments, Coinbase, CoinGate, BitPay, and Coinremitter. Each is evaluated on ETH and ERC-20 stablecoin support, fee structures, settlement speed, and business-focused features like mass payouts and e-commerce integrations. NOWPayments is ranked first for high-volume merchants needing a full-stack crypto operations platform, while Coinbase suits simple non-custodial setups, CoinGate targets EU merchants needing MiCA compliance, BitPay serves enterprise fiat settlement needs, and Coinremitter appeals to small businesses seeking low fees.
When an AI agent can submit state-changing blockchain transactions without per-action human approval, the critical question shifts from capability to authority. The post argues that DAO governance provides the right framework for defining, enforcing, and revoking agent permissions when multiple parties share economic risk. It outlines a minimal authorization layer composed of four elements: explicit machine-readable permission scopes ratified by governance, hard contract-enforced limits that reject out-of-scope actions, fast-path multisig revocation bypassing governance timelocks, and a public on-chain authorization record with action logs. Real-world asset (RWA) tokenization exposes the boundary clearly — a DAO can govern on-chain exposure but cannot control off-chain issuer redemption. Existing standards (ERC-4337, EIP-7702, ERC-7579, ERC-8004) provide infrastructure pieces but no complete mandate. Major protocols like Aave, Arbitrum, and Uniswap have governance machinery that could be extended, but none currently publish a complete agent authorization process. The authorization record can prove what was permitted and logged, but cannot validate oracle integrity, custodian reserves, or legal compliance.
Smart contracts are blind — they rely entirely on external price oracles to make financial decisions. This creates a critical attack vector: oracle manipulation. By combining flash loans with spot-price oracle reads, an attacker can borrow millions, artificially inflate a token's price in an AMM pool within a single atomic transaction, drain a lending protocol's treasury using the fake price as collateral, then repay the flash loan — all without breaking any rules. The contract robs itself. TWAP oracles slow this attack but don't eliminate it on low-liquidity tokens. Real defenses require decentralized oracle networks aggregating many sources, circuit breakers that halt on abnormal price deviations, and cross-checking two independent oracles so an attacker must corrupt multiple data sources simultaneously.