blockace

📂 Crypto Narratives ┃ ┣ 📂 Prediction Markets ┃ ┣ 📂 Polymarket ┃ ┗ 📂 Kalshi ┃ ┣ 📂 Neobanks ┃ ┣ 📂 RedotPay ┃ ┣ 📂 KAST ┃ ┣ 📂 Telcoin ┃ ┗ 📂 DeBlock ┃ ┣ 📂 AI ┃ ┣ 📂 Bittensor (TAO) ┃ ┣ 📂 Render Network ┃ ┣ 📂 Fetch AI ┃ ┣ 📂 Internet Computer (ICP) ┃ ┣ 📂 Akash ┃ ┗ 📂 QUBIC ┃ ┣ 📂 RWAs ┃ ┣ 📂 Ondo Finance ┃ ┣ 📂 Clearpool ┃ ┣ 📂 Algorand ┃ ┣ 📂 Propbase ┃ ┣ 📂 WELF ┃ ┣ 📂 Centrifuge ┃ ┗ 📂 Maple Finance ┃ ┣ 📂 DePIN ┃ ┣ 📂 GEODNET ┃ ┣ 📂 Helium ┃ ┣ 📂 Hivemapper ┃ ┗ 📂 io net (IO) ┃ ┣ 📂 Layer 1s ┃ ┣ 📂 Ethereum ┃ ┣ 📂 Solana ┃ ┣ 📂 Sui ┃ ┗ 📂 Sei Network ┃ ┣ 📂 Privacy ┃ ┣ 📂 ZANO ┃ ┣ 📂 Monero ┃ ┣ 📂 Zcash ┃ ┣ 📂 Firo ┃ ┣ 📂 Dash ┃ ┗ 📂 PIVX ┃ ┗ 📂 DeFi ┣ 📂 Uniswap ┣ 📂 Aave ┗ 📂 Hyperliquid

Our mission at Cantina has always been to secure the frontier of finance. The frontier a few years ago was blockchains and DeFi. This is increasingly getting blurry with modern fintech and banks adapting this technology. We always had to rely on the best tools to achieve this. In the last 4 years, this meant top security researchers looking at every single line of code, reasoning through them, and making sure they were correct. People thought this was crazy, but there was no other way. None of the automated tools met the bar: ease of use and actually discovering severe findings. Many tried and failed. But we're in a unique moment in time where this is changing. The best methods are slowly transitioning from relying on eyeballs and raw brainpower of humans to autonomous security agents. This is a big claim, and people are having trouble believing in it. The best way to demonstrate this is to ask the autonomous agent to find severe bugs in codebases. We've already demonstrated this privately to many of our customers, and it'll become clear in 2026 where this is all going.

For anyone interesting in learning zk proofs, I built a web app that lets you "debug" STARKs end-to-end. You can write simple programs, generate/verify STARKs, and explore the execution traces and constraint polynomials. Link in 1st response.

The long-awaited update from the Awesome Solana Security repo. New alphas added 👇: 1⃣Article: - @__alexlazar__'s analysis of CPI vulnerabilities: newsletter.alexlazar.dev/p/external-cal… - @AlexAlekhinEth's high-level explanation of Solana network architecture: @AlexAlekhinEth/solana-how-it-works-a-technical-deep-dive-b180468abc3d" target="_blank" rel="nofollow noopener">medium.com/@AlexAlekhinEt… - @heliuslabs's complete history of Solana outages: helius.dev/blog/solana-ou… - @exo_tech_'s guide for developers on creating auditor-friendly architecture documentation: exotechnologies.xyz/p/a-developer-… 2⃣ Optional programs to study: - Solana Upgradeable BPF Loader program: github.com/solana-program… - Solana Address Lookup Table program: github.com/solana-program… 3⃣ Tool: - @AckeeBlockchain's Trident, the Fuzzing framework for Solana: ackee.xyz/trident/docs/l… - @AckeeBlockchain's Solana IDE extension, automatically detects common security issues in Solana programs and visualizes Trident fuzzing coverage: marketplace.visualstudio.com/items?itemName… 4⃣ Public contests: - Token22 Confidential Transfer contest on @code4rena (7 Low): code4rena.com/reports/2025-0… - Meteora on @code4rena (2 Medium): code4rena.com/reports/2025-0… - Solayer on @cantinaxyz (3 High and 6 Medium): cantina.xyz/code/0f543452-… - Genius on @cantinaxyz (6 High and 4 Medium (partial Solana scope)): cantina.xyz/code/12acc80c-… - @cyfrin's RustFund first flight (4 High and 3 Medium): codehawks.cyfrin.io/c/2025-03-rust… - @cyfrin's SSSwap first flight (5 High and 4 Medium): codehawks.cyfrin.io/c/2025-05-sssw…

New on our Frontier Red Team blog: We tested whether AIs can exploit blockchain smart contracts. In simulated testing, AI agents found $4.6M in exploits. The research (with @MATSprogram and the Anthropic Fellows program) also developed a new benchmark: red.anthropic.com/2025/smart-con…

The talented @infosec_us_team just scored a maximum bounty reward of $200,000 for their critical bug report. The protocol was ready to pay in full, but @infosec_us_team decided to donate $100,000 back to their treasury, so that the protocol can keep rewarding future whitehats. This elite security researcher team absolutely didn't have to do this. They chose to. A truly remarkable day of generosity. P.S. This bounty just earned @infosec_us_team a huge amount of Hunt Points for the IMU airdrop. P.P.S. In the future, anyone will be able to back security researchers like these and share in their IMU rewards.

🚨IT'S FINALLY OUT Mastering Ethereum 2nd Edition - The Bible of Ethereum newcomers, builders, even auditors Thank you so much @ManInBlackie, we all owe you🫡

📢 Calling all Web3 security researchers Our first audit contest will start soon⚡️ 🗓️ 17/11 → 23/11 — 18:00 CET Protocol: @Alignerz_ Type: Token launchpad Solidity (~1500 nSloc) 💰 Prize Pool: 45,000 USDT H/M: 20k • L: 3k LSG1: 6k • LSG2: 6k Winner Bonus: 7.5k • Judge: 2.5k Think you can secure the codebase? Join the contest: discord.gg/UxrgEnbY 💂🏻‍♂️ Two Senior Guards are already in place. Can you rise to challenge them?

Welcome back to Sherlock’s Vulnerability Spotlight, where we highlight an impactful vulnerability uncovered during a Sherlock audit. This week, we examine an ownership-ordering vulnerability found in the @BMXDeFi Deli Swap contest by @0xSimao and @blockace256. Summary of the Vulnerability: In DeliHook v4 pools, when a liquidity provider (LP) transfers their NFT position to a new owner, the protocol's auto-claim mechanism executes the reward claim in favor of the new owner instead of the previous owner. This occurs because the transferFrom function updates the NFT ownership before triggering the unsubscribe process. When the unsubscribe logic builds the context to claim rewards, it reads ownerOf(tokenId), which now returns the new owner's address. As a result, all accumulated rewards are transferred to the new owner, and the previous LP permanently loses their unclaimed rewards. Attack Steps: 1. Position Acquisition - An attacker identifies an LP with significant accumulated rewards in their NFT position - The attacker negotiates to purchase or receive the NFT position from the LP - This could be through direct purchase, OTC trading, or any legitimate transfer mechanism 2. Transfer Initiation - transferFrom function is called to transfer the NFT position - The function signature: transferFrom(address from, address to, uint256 id) - At this point, the LP believes they will receive their accumulated rewards 3. Ownership Update (Critical Step) - The super.transferFrom(from, to, id) executes first NFT ownership is immediately transferred to the new owner (attacker) - The position's accumulated rewards remain unclaimed at this point 4. Unsubscribe Context Building - The _unsubscribe(id) function is called after the ownership change - _buildContextFromToken is invoked with includeOwner = true - The function calls handler.ownerOf(tokenId) to determine the owner - Because the transfer already occurred, this returns the new owner's address (attacker) 5. Reward Theft - notifyUnsubscribeWithContext is called with the new owner's address - _claimRewards(posKey, ownerAddr) executes - All accumulated BMX reward tokens are transferred to the attacker - The previous LP receives nothing - The attacker now has both the NFT position and the previous LP's rewards The Root Cause: The vulnerability is rooted in the incorrect sequencing of operations in the transferFrom function: function transferFrom( address from, address to, uint256 id ) public virtual override onlyIfPoolManagerLocked { super.transferFrom(from, to, id); // ❌ Ownership updated FIRST if (positionInfo[id].hasSubscriber()) _unsubscribe(id); } The critical flaw is that super.transferFrom() executes before _unsubscribe(). This means when the unsubscribe process attempts to determine who should receive the rewards, it queries the current owner: function _buildContextFromToken( uint256 tokenId, bool includeOwner ) internal view returns (NotifyContext memory ctx) { IPositionHandler handler = getHandler(tokenId); ... if (includeOwner) { ctx.owner = handler.ownerOf(tokenId); // ❌ Returns NEW owner } } Since ownerOf(tokenId) now returns the new owner's address (post-transfer), the reward claim in notifyUnsubscribeWithContext sends tokens to the wrong recipient: function notifyUnsubscribeWithContext( bytes32 posKey, bytes32 poolIdRaw, int24 currentTick, address ownerAddr, // ❌ This is the NEW owner int24 tickLower, int24 tickUpper, uint128 liquidity ) external onlyPositionManagerAdapter { .... _claimRewards(posKey, ownerAddr); // Sends rewards to new owner _removePosition(pid, posKey); } The protocol lacks a mechanism to track the original position owner at the time of reward accrual, relying instead on the current NFT owner at the time of claim. What's the Impact? Direct Economic Loss: - Previous LPs permanently lose all accumulated rewards at the time of transfer - The loss is irreversible as rewards are immediately claimed and transferred - No recovery mechanism exists in the protocol Severity Classification: - High Impact : direct and irreversible economic loss for liquidity providers The Mitigation: The recommended fix is to track and use the original position owner rather than querying the current NFT owner during the unsubscribe process. Store the position owner mapping during subscription and reference it during unsubscription: // Add state variable to track original position owners mapping(bytes32 => address) public positionOwner; // Update during subscription function notifySubscribeWithContext(...) external { ... positionOwner[posKey] = ownerAddr; ... } // Fix the reward claim to use tracked owner function notifyUnsubscribeWithContext( bytes32 posKey, bytes32 poolIdRaw, int24 currentTick, address ownerAddr, int24 tickLower, int24 tickUpper, uint128 liquidity ) external onlyPositionManagerAdapter { ... // ❌ Bug - uses current NFT owner // _claimRewards(posKey, ownerAddr); // ✅ Fix - uses tracked original owner address originalOwner = positionOwner[posKey]; _claimRewards(posKey, originalOwner); // Clean up after claiming delete positionOwner[posKey]; _removePosition(pid, posKey); }

Sherlock AI reported a Critical vulnerability in the @40acresFinance protocol. The 40acres team generously allowed us to share the details publicly so others can learn from the finding. Here’s how the vulnerability worked: First, veNFTs are a special type of vote-escrowed ERC721 tokens that earn weekly rewards. 40acres gives veNFT holders instant access to loans based on their veNFT’s future revenue. Each borrower’s veNFT sits inside a personal PortfolioAccount that routes functionality through modular “facets” using the diamond proxy pattern. The exploit allows an attacker to reclaim their collateral (veNFT) from their PortfolioAccount without repaying the loan. Check out the aerodromeVote() function below. 40acres has a very cool feature that allows borrowers to vote with their veNFTs held as collateral in 40acres. The function has the following problem: The loanContract address is not validated, allowing a malicious user to specify an arbitrary contract. This contract could be approved to control the veNFT in the PortfolioAccount, enabling its transfer during the vote() call in the malicious loanContract. Attack Steps 1) Attacker deploys a malicious contract that implements ILoan.vote(uint256) to call transferFrom/safeTransferFrom to transfer the approved veNFT. 2) Attacker calls portfolioAccount.aerodromeVote(maliciousContract, tokenId). The portfolio fallback delegates to the facet, which lacks input validation and calls maliciousContract.vote(tokenId) and transfers the veNFT back to the attacker, even though the loan has not been repaid. Note: The repetition of the bug causes the lending pool to be drained - doing it once is just taking a loan & stealing your veNFT back. Impact Unbacked loans across the system. Any borrower can reclaim their own collateral mid-loan, leading to full insolvency of the lending pool. Acknowledgements Thank you to @defsec_, @vinica_boy, and @onthehunt11_ for helping with this writeup. Important to know: The 40acres team discovered the bug and applied a fix prior to launch Detected by Sherlock AI You can see the original issue as generated by Sherlock AI in the next tweet. The run took 3 hours 59 minutes from start to finish. Sherlock AI brings security to the development process, scanning commits and call paths early, surfacing high-impact flaws fast, and giving auditors clearer visibility into complex systems. In practice, that means issues like this can be caught and resolved long before audits, bounties, or deployment. Try Sherlock AI for your protocol today.

@sherlockdefi @yieldbasis @KupiaSecurity Thanks for the opportunity @yieldbasis and @sherlockdefi

🏆 @yieldbasis Audit Contest Results 🏆 Congrats to: 1. @KupiaSecurity - $49,570 🥇 2. @blockace256 - $16,453 🥈 3. montecristo - $15,871 🥉 $150,000 rewards ➡️ $16.8M+ paid out in rewards.

@ammplify_xyz competition was a difficult one, and I learnt a lot from the LSW @panprog! He actually deserved No 1 on Sherlock. Thanks @sherlockdefi for the opportunity.

Security researchers - PREPARE🙏 New Solidity features coming, the language is getting its biggest revamp so far in its history. Many, many changes upcoming. This also means many new attack vectors. Many new things to learn and study. Adapt or die in our fast-moving tech world🫡

Black hat hackers are awful people. Imagine how far gone you have to be from basic human empathy to destroy something other people spent years building. You ruin real people’s lives. Teams that worked day and night, building something useful and honest. You don’t just steal money - you erase purpose, motivation, and trust. Then there are the users. Some of them aren’t rich. Some needed those funds to pay rent, to eat, to survive. You didn’t just drain a protocol; you kicked real people while they were already down. And for what? So you could feel clever for a moment? For the cash? When the rush fades, you’re left with the consequences: legal risks, a ruined conscience, and the knowledge that you caused real suffering for strangers. That’s not power. That’s weakness wearing a mask. Bad actors and bad energy will always exist. That will not change. What we can change is how good we get at our jobs and how hard we make it for them to wreck people’s lives.

Introducing Private Multisig -- a special multisig where no one sees who votes or how votes on proposals. The ballots are encrypted, and the whole voting process is non-interactive. Achieved via ZKP + ECC ElGamal + DKG + HE. Trustless and permissionless. No TEE needed.

Moment of truth: every finding I submitted in @code4rena contests came from a method I built using AI. Over 7 contests my method earned 🥇🥈🥈🥈🥉 with a valid/invalid ratio >1 and multiple solo ands duo High/Medium findings.

Privacy 101 Blockchains are transparent by design. Every transaction, every balance, all public. People often mistake that for anonymity, but it is really pseudonymity. Once an address is tied to you, the mask is off. So what does “privacy” actually mean in this context? It is not about invisibility, it is about unlinkability: breaking the chain between sender, receiver, and amounts. Over the years, different systems have tackled different pieces of this puzzle. The earliest attempts came in the form of mixers. Tornado on Ethereum was the most famous example. The idea was simple: throw assets into a pool and withdraw them somewhere else, breaking the direct link. But mixers were fragile. Patterns in timing or usage often gave hints away, and regulators cracked down hard. @monero approached the problem differently. It built privacy in by default using ring signatures to hide the sender in a crowd, stealth addresses to mask the receiver, and confidential transactions to hide the amounts. Strong privacy, but that same opacity made it hard to plug into the open and transparent world of DeFi. @Zcash took yet another path. With zk-SNARKs, it became possible to prove a transaction was valid without revealing details. That is very powerful cryptography, but it came with its own problems: heavy computation, complex UX, and limited adoption. Today, zk teams are trying to push privacy further into programmable smart contracts. Projects like @aztecnetwork and Namada are experimenting with private DeFi. The catch is that privacy often makes systems slower, more expensive, and less composable. DeFi thrives on transparency, so there is always friction. And even if the transaction layer is private, the leaks do not stop there. Metadata like timing, gas usage, IP addresses, and browser fingerprints can all betray you. A full privacy stack has to go beyond the ledger itself. The use cases are obvious. You do not want your salary or donations visible to the world. Traders do not want to telegraph their positions and get hunted. Governance needs secret ballots. Institutions want settlement rails that do not reveal every move. The history is short but clear. Bitcoin was never private. Monero arrived in 2014. Zcash in 2016. Tornado in 2019. The tension runs through all of this. Users want privacy. Regulators see it as a threat. The future likely looks like programmable privacy: private by default, but with selective disclosure when needed. At the core, privacy in crypto is not about hiding crime. It is about restoring a basic right: the ability to transact without being surveilled. And in that sense, we are still at the beginning.

The amount of projects fighting / trying to TGE between now and EOY is insane 1. Layer 1/2 - @monad - @megaeth - @AbstractChain - @risechain - @anoma - @FogoChain - @CantonNetwork - @irys_xyz - @katana - @AltiusLabs - @inconetwork - @fhenix - @soneium - @pharos_network 2. Wallets - @MetaMask - @Rabby_io - @rainbowdotme - @privy_io 3. AI - @SentientAGI - @saharaai - @miranetwork - @Talus_Labs - @gaib_ai - @hyperbolic_labs - @crossmint - @GoKiteAI - @Everlyn_ai - @almanak 4. Perp Dex - @Lighter_xyz - @pacifica_fi - @edgeX_exchange - @grvt_io - @OstiumLabs - @GTE_XYZ - @ranger_finance - @variational_io 5. Prediction Markets - @Polymarket - @Kalshi - @trylimitless

What is the difference between @SuccinctLabs's SP1 zkVM and the Succinct Prover Network (SPN), and when should each be used? 1. What is SP1? • SP1 zkVM stands for "Succinct Processor 1 Zero-Knowledge Virtual Machine." • Think of it as a special computer that not only runs your program but also creates mathematical proof that it ran correctly. - - - - - 2. Before SP1: • Want a ZK proof? Write complex cryptographic circuits manually (like doing calculus by hand) • Want to verify someone's computation? Re-run their entire program yourself (slow & expensive) • No trust without verification: either trust blindly or waste resources re-computing - - - - - 3. After SP1: • Just write normal code, SP1 handles the cryptography • Get mathematical proof of correctness, no need for others to re-run anything • Verify proofs in milliseconds instead of re-running hours/days of computation • Enables any developer to create real-world ZKP applications by writing code in Rust • Makes ZK accessible to regular developers, not just cryptography PhDs - - - - - 4. How SP1 Works • Write code in Rust → compiles it into RISC-V instructions • Program Table is created → a fixed recipe of all instructions • Execution Phase → CPU runs the program step by step, checking each instruction with special tables (ADD, MUL, memory, etc.) • Proof Generation → all tables are turned into math constraints to build a STARK proof that the execution was valid. • Final Compression → for long programs, proofs are combined and compressed into a tiny SNARK proof that blockchains can verify. 5. Key Innovations • Lookup-centric architecture: Tables specialize and cross-verify each other • Precompiles: 10-50x speedup for crypto operations (Ethereum blocks: 10B cycles → 200M cycles) • Efficient recursion: Combines multiple proofs into one final proof • STARK to SNARK: Compresses large proofs (STARK) into tiny ones (SNARK) Ethereum can verify - - - - - 6. Use Cases • ZK Rollups: Turn optimistic rollups into zk rollups with faster withdrawals (~1 hour vs 7 days). • ZK Light Clients: Build blockchain bridges that rely on proofs of consensus, not multisigs. • DeFi Solvency Proofs: Exchanges prove assets ≥ liabilities without revealing balances. • Identity Proofs: Prove properties like “over 18” without sharing private data. • General Compute: Off-chain tasks, machine learning inference, or data validation with zk proofs. - - - - - 7. Live Use Cases • OP Succinct, built on SP1 zkVM, cuts Optimistic Rollup finality from 7 days to ~1 hour. • @Mantle_Official is the first OP Stack L2 to launch as a ZK Validity Rollup with 1-hour finality, 12-hour withdrawals. - - - - - - - - - - Part II. Difference between SP1 and SPN. 1. What is Succinct Prover Network (SPN)? • A decentralized network that proves software using zk proofs. • Think of it as a marketplace: apps (like rollups, bridges, AI agents) need proofs — Provers (people with GPUs, data centers, or even home hardware) generate those proofs. - - - - - 2. What's the actualy difference between SP1 and SPN? • SP1 solves the software side of proving: you write normal Rust code, it compiles to RISC-V, and SP1 produces the ZK proof. • Running SP1 on your laptop would be slow and costly. • For that, there is Succinct Prover Network solves this by coordinating a global cluster of provers, datacenters, GPU farms, and even home GPUs, to deliver proofs faster and cheaper. - - - - - 3. Actors Involved • Requesters: rollups, blockchains, bridges, AI agents, games • Provers: teams with GPUs, servers, or specialized hardware to generate proofs • Delegators: Regular users who don’t run hardware but can stake their $PROVE • Auctioneer: service that coordinates requests and provers • Ethereum settlement contracts: hold all funds, check the Auctioneer’s proofs, pay out provers and delegators, and slash provers if they fail. - - - - - 4. System Workflow • A requester deposits $PROVE on Ethereum and submits a proof request. • The Auctioneer runs an auction among provers. • Provers place bids. • The winning prover runs SP1 zkVM and generates the proof. • The proof is sent to the Auctioneer, which records it in its database. • The Auctioneer proves its database state with SP1 and posts that proof to Ethereum. • Ethereum verifies the update and pays the prover (and any delegators who backed them). • Status today (Stage 2.5 testnet): reverse auction system (the lowest bid wins). - - - - - 5. What Changes at Mainnet • Real • goes live → payments, staking, and slashing have real economic weight. • Proof contests (probabilistic inclusion) → instead of one winner, several provers can submit. • Delegation opens fully → anyone can back a prover, helping them qualify for jobs and earning part of the rewards. • Bigger scale → Data centers, ASIC/FPGA teams, and proving pools of home GPUs join, making SPN the largest proving cluster in the world.