Changelog

A detailed log of changes, research, and additions to DNZN // RESEARCH.

2026-02-28

Added: zQuoter Contract Analysis

Type: Contract Analysis | Location: zQuoter Contract

A comprehensive analysis of the zFi zQuoter contract at 0x658bF1A6608210FDE7310760f391AD4eC8006A5F, a fully stateless read-only quoter deployed August 26, 2025. The contract queries 14 AMM pools across five protocols (Uniswap V2, SushiSwap, zAMM ×4 fee tiers, Uniswap V3 ×4 fee tiers, Uniswap V4 ×4 fee tiers) in a single call and returns the best route plus ready-to-execute calldata for zRouter. Gas: 65 tok.

Key findings:

Fully stateless — zero storage slots, no owner, no admin functions, no upgrade mechanism
7 public view functions: 4 single-AMM quoters, 1 aggregator (getQuotes), 2 calldata builders (buildBestSwap, buildBestSwapViaETHMulticall)
V2/Sushi/zAMM quoted via on-chain reserve math; V3 via external Uniswap QuoterV2; V4 via embedded tick simulation
buildBestSwapViaETHMulticall routes ERC-20 → ERC-20 trades through WETH as two-hop intermediary
ZROUTER constant (0x0000000000404FECAf36E6184245475eE1254835) targets an earlier zRouter from August 2025, not the newer zRouter analyzed separately
Verified source code (Exact Match) — Solidity v0.8.30, Prague EVM, 200 optimizer runs, 2,300 lines
Risk Assessment: 0 Critical, 0 High, 2 Medium, 2 Low, 3 Informational

Related pages: Functions | Storage Layout | Potential Risks | Methodology | Artifacts

Notable aspects:

Deployed August 26, 2025 (Block 23,227,474) — before the newer zRouter (February 2026)
Different deployer (0x999657a4...b44e1c) from newer zRouter (0x1C0Aa8cC...855A20); both appear zFi-operated
Source embeds 11 Uniswap V4 math libraries inline (TickMath, SwapMath, SqrtPriceMath, etc.)
V4 tick simulation reimplements Uniswap V4 swap loop locally — queries V4 StateView lens for pool state
V3 quotes use try/catch — pool failures return (0, 0) silently
No ETH custody risk; payable constructor with no sweep function (but deployed with 0 ETH)
Complete function catalog: 7 public view functions; 0 state-changing functions; 0 admin functions

Infrastructure: Added to Contract Analysis section under zFi alongside zRouter.

Added: zRouter Contract Analysis

Type: Contract Analysis | Location: zRouter Contract

A comprehensive analysis of the zFi zRouter contract at 0x000000000000FB114709235f1ccBFfb925F600e4, a fully on-chain DEX aggregator deployed February 12, 2026 as part of the zFi superdapp. The contract aggregates Uniswap V2/V3/V4, SushiSwap, Curve Finance, and zFi's own zAMM in a single 1,659-line standalone Solidity file with no off-chain dependencies. It also integrates Lido staking helpers, Uniswap Permit2, and zFi's .wei name registration system. Gas: 95 tok.

Key findings:

Fully on-chain routing: pool addresses computed deterministically via CREATE2, no off-chain API
Five distinct swap paths: Uniswap V2/V3/V4 (hookless), SushiSwap, Curve (up to 5 hops, 8 swap types), zAMM
EIP-1153 transient storage for intra-transaction balance passing and reentrancy locking
Generic executor (snwap/snwapMulti) for arbitrary DEX integration via isolated SafeExecutor companion contract
multicall with delegatecall enables atomic multi-protocol swap chains
Zero protocol fees — only underlying DEX fees apply
Owner role (single EOA, no multisig, no timelock) controls trust whitelist, token approvals, and ownership transfer
sweep() has no access control — any address can sweep router balances (intentional by design)
Verified source code (Exact Match) — Solidity v0.8.33, Prague EVM, 9,999,999 optimizer runs
Risk Assessment: 0 Critical, 3 High, 4 Medium, 3 Low, 3 Informational

Related pages: Functions | Storage Layout | Potential Risks | Methodology | Artifacts

Notable aspects:

Deployed February 12, 2026 (Block 24,440,819) via factory contract
Owner assigned via tx.origin (not msg.sender) — deliberate due to factory deployment
Companion SafeExecutor deployed in constructor, holds zero token approvals
V4 integration is hookless-only — hooks: address(0) hardcoded in pool key
deadline == type(uint256).max overloaded as SushiSwap/zAMM-hookless selector (non-standard)
Curve lazy approvals: sets unlimited allowance to caller-supplied pool addresses on first use
29 named functions + fallback() + receive()
Complete function catalog: 22 user, 3 callback, 1 trusted, 3 admin, 1 view

Infrastructure: Added to Contract Analysis section under zFi (new project category).

Added: Contract Analysis Service Page

Type: Site Infrastructure | Location: Contract Analysis by Request

Added a services page describing contract analysis reports available by request. The page covers the scope (what analysis includes, what it doesn't), report contents (six standard documents), pricing tiers, and links to published examples. Gas: 5 tok.

Key details:

Three tiers: free public summary, full report ($500–$1,500), and custom analysis (listed as not currently available)
Clear disclaimer: this is not a security audit — we are engineers who read contracts, not credentialed auditors
Pre-deployment contract analysis noted as an available use case
Links to zRouter, Jared 2.0 MEV Bot, and Doubler as example reports
Inquiry form linked for scope and estimate requests

Infrastructure: Added to navigation under "Tools & Services" section.

2026-02-13

Added: Doubler (etherdoubler.com) Contract Analysis

Type: Contract Analysis | Location: Doubler Contract

A comprehensive analysis of the Doubler contract at 0xfD2487cc0e5dCe97F08BE1Bc8eF1DCE8D5988B4D, a historically significant Ponzi scheme from March 2016 that implemented queue-based wealth redistribution mechanics. This contract represents one of the earliest Ponzi schemes deployed on Ethereum during the platform's first year. Analysis completed from verified source code (Solidity v0.2.0) with on-chain storage verification showing 203 participants permanently stuck with ~32.44 ETH locked. Gas: 75 tok.

Key findings:

Queue-based Ponzi mechanics visible in verified source code, promising 2x returns (minus 10% fee)
Contract Status: mathematically insolvent with sporadic activity (most recent January 2026)
Participant Outcomes: 118 paid out (36.8%), 203 stuck forever (63.2%) with 100% losses
Owner Profit: extracted all fees (~32.1 ETH) from 321 total participants
Technical Flaws: Solidity 0.2.0 with deprecated patterns, silent send() failures, 4.99 ETH accounting discrepancy
Historical Significance: early Ethereum experiment demonstrating "code is law" implications and Solidity 0.2.0 security flaws
Risk Assessment: 6 Critical, 4 High, 3 Medium, 2 Low

Related pages: Functions | Storage Layout | Potential Risks | Methodology | Artifacts

Notable aspects:

Verified source code (Exact Match) - Solidity 0.2.0-2016-01-15-cc4b4f5 (70 lines)
Deployed March 13, 2016 (Block 1,143,960) - one of the earliest Ponzi contracts
477 total transactions, all activity ceased years ago
First participant penalty: 100% of deposit taken as fees (zero balance credit)
Balance desync: internal balance variable (27.44 ETH) doesn't match actual balance (32.44 ETH)
Complete function catalog: 5 functions (constructor, fallback, enter, collectFees, setOwner)
No events emitted anywhere in contract (zero transparency)
Educational artifact demonstrating multiple deprecated patterns and vulnerabilities

Glossary additions: Ponzi Scheme, FIFO, Fallback Function, Modifier

Infrastructure: Added to Contract Analysis section under Unknown, alongside Batch Sender & Sweeper.

2026-02-05

Added: Sentinel Snapshot Registration Analysis

Type: Site Analysis | Location: Feb 5 Snapshot Registration

Analysis of the "Register for Snapshot" feature introduced on the Sentinel website on February 5, 2026. The registration button's click handler writes the user's wallet address and SENT token balance to browser localStorage only — no blockchain transaction occurs, no smart contract is called, and no on-chain record is created. The UI messaging uses language like "lock in your token holdings" and "your holdings have been recorded," but the implementation is purely client-side. Gas: 18 tok.

Key findings:

Registration button writes to browser localStorage, not to the blockchain
UI language ("lock in," "recorded") implies on-chain finality that does not occur
Three Sentinel contracts are referenced in the codebase but none are called during registration
Hive Registry contract has a registerParticipant() function that could serve this purpose but is unused
A standard blockchain snapshot queries on-chain balances at a specific block height — no pre-registration required
Backend behavior, if any, is not observable from the client-side code

2026-02-04

Added: ZeroMoon zETH Token Contract Analysis

Type: Contract Analysis | Location: zETH Token

A comprehensive analysis of the ZeroMoon (zETH) token contract at 0x41b242c36F7dc5f18be21c1a6B7b5e05b2FD6532, an ETH-backed ERC-20 token with dividend distribution deployed November 12, 2025. The token implements a refund mechanism allowing users to sell tokens back to the contract at 99.9% backing value, with deflationary burn mechanics capped at 20% of supply. Ownership has been renounced, making the contract completely immutable. Gas: 75 tok.

Key findings:

ETH-backed token with 99.9% effective backing ratio for refunds
Dividend system distributes reflection fees to EOA holders only
Dynamic pricing: base 0.0001 ETH per token, then refund price + 0.1%
Fee structure: 0.25% on buys, transfers, and refunds (0% on DEX swaps)
Deflationary burning up to 250M tokens (20% cap), then redirects to reserves
Ownership permanently renounced - no admin control or parameter changes
Contract detection via 8-interface checks excludes protocols from dividends
ReentrancyGuard protects all ETH transfers (buy, refund, claim)
Risk assessment: 0 Critical, 3 High, 5 Medium, 4 Low, 3 Informational

Related pages: Functions | Storage Layout | Potential Risks | Methodology | Artifacts

Notable aspects:

Verified source code (Exact Match) - Solidity 0.8.30, 2,928 lines
No external dependencies beyond OpenZeppelin v4.9.3 libraries
Total supply: 1.25B tokens (fixed at deployment, reduced by burns)
Current state: 3.46M tokens sold (0.28% of supply), 530K burned, 0.277 ETH backing
Magnified dividend system uses 2^128 precision to prevent rounding errors
Complete function catalog: 35+ functions (7 user, 2 admin, 9 view, ERC-20 standard)
Purchase and refund mechanisms operate without external liquidity pools
No public audit available, though contract claims extensive internal testing

Infrastructure: Added to Contract Analysis section under ZeroMoon, alongside analyses for Sentinel, Xcellar, MEV Bots, and Unknown contracts.

2026-02-03

Added: Batch Sender & Sweeper Contract Analysis

Type: Contract Analysis | Location: Batch Sender & Sweeper

A comprehensive bytecode analysis of an unverified utility contract at 0x4320b7...5C236, deployed January 9, 2026. This owner-controlled contract enables batch ETH and ERC20 token distribution to multiple recipients plus sweep functions for recovering accidentally sent assets. Analysis completed through bytecode decompilation, function signature mapping, and pattern recognition. Gas: 65 tok.

Key findings:

Dual-purpose utility: batch payments + asset recovery
Single EOA owner control (deployer: 0x5D8123...36635)
7 functions: 5 owner-only, 1 view, 1 payable fallback
Minimal storage (single slot for owner address)
SafeERC20 implementation for token compatibility
No reentrancy guard, multisig, or timelock protection
Only 1 transaction recorded (deployment) as of analysis date
Risk assessment: 0 Critical, 1 High, 2 Medium, 3 Low, 0 Informational

Related pages: Functions | Storage Layout | Potential Risks | Methodology | Artifacts

Notable aspects:

Contract source code unverified on Etherscan—analysis based entirely on bytecode
255-line Solidity reconstruction in artifacts with 95%+ confidence
Complete function selector mapping and event signature verification
Multiple mermaid diagrams visualizing architecture, access control, and function flows
50+ verification commands for independent on-chain validation
Identified use cases: airdrops, multi-recipient payroll, fund recovery

Infrastructure: Added to Contract Analysis section under Unknown (unidentified project/deployer), alongside analyses for Sentinel, Xcellar, and MEV Bot contracts.

2026-01-25

Added: Sentinel Dashboard Analysis

Type: Site Analysis | Location: Dashboard Analysis

Reconstruction and analysis of the Sentinel Dashboard HTML and JavaScript code. The dashboard source code was extracted from https://sentinelox.com/dashboard, deobfuscated, formatted with Prettier, and combined into single files for analysis. The reconstructed JavaScript totals 136,931 lines (4.6 MB) across 34 chunks. Gas: 85 tok.

Key observations:

Four contract addresses identified hardcoded in the application: SENT Token, Hive Registry, Claim Rewards, and Token Allocation
Registration flow contains writeContract hooks but actual button click handler could not be definitively traced
Claim button does NOT call the Claim Rewards contract—instead executes a simulated function that only updates browser localStorage
Swarm Pool Share display mixes real on-chain data (member balances, pool share %) with simulated reward calculations (weekly profit, reward pool)

Related pages: Swarm Dashboard Analysis | Jan 18-24 Rewards Analysis

Added: Sentinel Jan 18-24 Rewards Analysis

Type: Site Analysis | Location: Jan 18-24 Rewards Analysis

Analysis of the reward calculations displayed on the Sentinel dashboard for the week of January 18-24, 2026. We observed that the "Locked," "Today," and "Weekly" reward values shown to users are generated client-side using hardcoded daily profit values and simulation formulas rather than real on-chain trading data. Gas: 42 tok.

Key observations:

Reward values calculated from hardcoded JavaScript array [250, 364, 196, 448, 292, 226, 224], not on-chain data
"Today" value uses sine wave simulation to appear "live" and fluctuate
User's SENT balance and holding percentage are real on-chain data
Final reward calculations mix real user data with simulated profit values
Dashboard displays values approximately 48x smaller than what the Day Percent Manager contract's historical data suggests

2026-01-24

Added: Sentinel Swarm Dashboard Analysis

Type: Site Analysis | Location: Swarm Dashboard Analysis

Analysis of the Sentinel /swarm dashboard trading activity display. We observed that all trading data shown on the page is generated client-side using JavaScript sine-wave and random number functions. A separate on-chain contract (Day Percent Manager) contains historical metrics data but is not displayed anywhere on the current site. Gas: 125 tok.

Key observations:

Trading activity on /swarm is client-side simulation using Math.random() and sine-wave functions
Real on-chain Day Percent Manager contract exists with historical metrics data
On-chain data is not displayed anywhere on the current website
No disclaimers indicate that displayed trading data is simulated
Dashboard shows "LIVE" indicator while another section states "integration on-going"—conflicting signals about development status

Related pages: Dashboard Analysis | SENT Day Percent Manager

Added: Sentinel Day Percent Manager Contract Analysis

Type: Contract Analysis | Location: SENT Day Percent Manager

A comprehensive bytecode analysis of the Sentinel Day Percent Manager contract (0x1aa0c77d207cd2e20dc00523ee0511ac6514aeb3), an unverified configuration registry deployed November 25, 2025. This contract stores day-by-day percentages and amounts for a 100-day schedule but does not hold or transfer tokens — it serves purely as a read-only data source for other Sentinel contracts. Identified via the Sentinel Dashboard source code as DAY_PERCENT_MANAGER_ADDRESS. The 7-day configuration aligns with the Sentinel Swarm system's documented 7-day cycle, suggesting this may be the Swarm Metrics configuration contract. Analysis completed through bytecode decompilation, transaction pattern analysis, and on-chain storage verification. Gas: 65 tok.

Key findings:

Pure configuration store with 13 functions (5 admin, 8 view, 0 public state-changing)
Supports 100-day schedule with dual parameters per day (percent in basis points + amount)
Single EOA owner control with no multisig or timelock protection
Batch configuration via batchSetDaySchedule() used 9 times during Nov 25-29, 2025 setup
Days 1-7 configured; days 8-100 return (0, 0) — unclear if unconfigured or intentionally zero
No versioning, pause mechanism, or upgrade path
Constants: MAX_DAY=100, MAX_PERCENT=1,000,000 (basis points where 1M = 100%)
Risk assessment: 1 Critical, 3 High, 3 Medium, 2 Low, 3 Informational

Related pages: Functions | Storage Layout | Potential Risks | Methodology | Artifacts

Notable aspects:

Contract source code is unverified on Etherscan — analysis based entirely on bytecode
190+ lines of reconstructed Solidity source code in artifacts
Complete function selector mapping, event signatures, and ABI reconstruction
Multiple mermaid diagrams visualizing architecture, storage layout, and access control
50+ verification commands for independent on-chain validation
Critical risks identified: unverified source, single owner control, immediate schedule propagation, renounce risk

Infrastructure: Added to Contract Analysis section under Sentinel, alongside SENT Token, SENT Presale, SENT Hive Registry, SENT Token Allocation, and SENT Claim Rewards analyses.

Repositioned: Sentinel Treasury Operations

Type: Project Research Restructure | Location: Treasury Operations

Repositioned the presale fund flow analysis as ongoing treasury operations research. The document now tracks the treasury wallet (formerly "beneficiary wallet") with emphasis on continuous monitoring rather than static analysis.

Changes:

Renamed from "Presale Fund Flow Analysis" to "Treasury Operations"
Updated terminology: "beneficiary wallet" → "treasury wallet" throughout
Added prominent note clarifying treasury refers to presale beneficiary address
Restructured Summary table with Coverage Period and Last Activity Date
Renamed "Updated Investigation Findings" to "Investigation Updates" with date headers
Added "Monitoring Notes" section tracking active/inactive patterns and review triggers
Original file archived to tmp/presale-flow-analysis.md

Infrastructure: Updated navigation in mkdocs.yml to reflect new document name and positioning as ongoing research.

Updated: Sentinel Presale Fund Flow Analysis

Type: Project Research Update | Location: ~~Presale Fund Flow Analysis~~ (Now: Treasury Operations)

Major update to the presale beneficiary wallet analysis revealing that the USDT position was swapped back to ETH. On-chain verification discovered that the previously reported 1.84M USDT was converted back to ETH within hours of acquisition through two complete ETH→USDT→ETH cycles executed by the beneficiary wallet. Gas: 15 tok.

Critical discoveries:

USDT Position: 0 — The 1.84M USDT was swapped back to ETH by the beneficiary wallet
Cycle 1 (Jan 3): 600 ETH → 1.84M USDT → 587 ETH (reversed in 12 min and 5.5 hrs). Loss: ~13 ETH
Cycle 2 (Jan 14): 320 ETH → 1.04M USDT → 313 ETH (reversed in 2.3 hrs). Loss: ~7 ETH
Net effect: Beneficiary burned ~20 ETH in swap fees/slippage reversing both USDT positions

Updated metrics:

Current ETH balance: 550.57 ETH (up from 481.48 ETH)
Current USDT balance: 0 USDT (down from 1.84M USDT)
Total ETH received: 2,168.23 ETH (includes ~900 ETH from reversed USDT swaps)
Intermediary wallet: 525 ETH across 14 transactions (ongoing through Jan 22)

Analysis interpretation: Both cycles show identical pattern — convert ETH to USDT, hold briefly, then immediately convert back to ETH at a loss. Possible explanations include failed OTC deals, price speculation attempts, liquidity testing, or operational errors. The only remaining USDT exposure is 137 ETH equivalent held in separate wallet 0x6bae4cce...b3eb6d.

Related research: SENT Presale Contract | Sentinel Project Overview

2026-01-23

Added: Sentinel Claim Rewards Contract Analysis

Type: Contract Analysis | Location: SENT Claim Rewards

A comprehensive bytecode analysis of the Sentinel Claim Rewards contract (0x33184cD3E5F9D27C6E102Da6BE33e779528A606D), an unverified claim tracking system deployed January 1, 2026. This contract manages reward claim eligibility and tracking for the Sentinel ecosystem without holding or transferring tokens directly. Analysis completed through bytecode decompilation, transaction pattern analysis, and storage slot inference. Gas: 65 tok.

Key findings:

Claim tracking mechanism with no token transfer functionality
Single EOA owner control with no multisig or timelock protection
Depends on external FlexibleAllocation contract (also unverified) for eligibility verification
Dual-purpose storage slot serves both hasClaimed and eligibilityStatus (creates ambiguity)
620+ transactions primarily consisting of claim() calls since deployment
Risk assessment: 3 Critical, 4 High, 3 Medium, 2 Low, 2 Informational

Related pages: Functions | Storage Layout | Potential Risks | Methodology | Artifacts

Notable aspects:

Contract source code is unverified on Etherscan—analysis based entirely on bytecode
15 functions cataloged (1 user, 6 admin, 7 view, 1 internal)
Complete function selector mapping and event signature reconstruction
450+ lines of reconstructed Solidity source code in artifacts
Multiple mermaid diagrams visualizing architecture, storage layout, and access control
50+ verification commands for independent validation
Critical risks identified: unverified source, external dependency, storage ambiguity

Infrastructure: Added to Contract Analysis section under Sentinel, alongside SENT Token, SENT Presale, SENT Hive Registry, and SENT Token Allocation analyses.

2026-01-21

Added: Sentinel Project Space

Type: Project Overview | Location: Sentinel Project

Created comprehensive Sentinel project space with high-level overview and research index.

2026-01-15

Fixed: Eth Wallet Analyzer Error Handling

Type: Bug Fix | Location: Eth Wallet Analyzer

Fixed error handling in the wallet analyzer tool that caused analysis to fail when addresses had no internal transactions. The tool now gracefully handles cases where Etherscan returns "No transactions found" or "No records found" responses by treating them as empty result sets rather than hard errors.

What changed:

Updated fetchTransactions() function to distinguish between "no results found" and actual API errors
Tool now successfully analyzes addresses with missing transaction types (no internal txs, no token transfers, etc.)
Improved logging to use info level for "no results" cases instead of error

2026-01-13

Added: Sentinel Token Allocation Contract Analysis

Type: Contract Analysis | Location: Sentinel Token Allocation

A comprehensive bytecode analysis of the Sentinel Token Allocation contract, an unverified centralized allocation ledger for tracking intended SENT token distributions. This pure accounting contract manages recipient-amount mappings without holding or transferring tokens directly. Analysis completed through transaction pattern analysis, function signature extraction, and bytecode decompilation. Gas: 65 tok.

Key findings:

Centralized allocation ledger deployed December 30, 2025 (Block 24,125,223)
Tracks token allocations for 100+ recipients across 20 batch allocation transactions
Single EOA owner control with no multisig or timelock protection
Pausable operations and irreversible allocation lock function
Emergency withdrawal functions for mistakenly sent assets (ETH and ERC-20)
Pure accounting mechanism—does not hold or transfer SENT tokens
3-hour deployment window with concentrated batch processing, zero activity since
Risk assessment: 2 Critical, 3 High, 4 Medium, 3 Low, 2 Informational

Related pages: Functions | Storage Layout | Potential Risks | Methodology | Artifacts

Notable aspects:

Contract source code is unverified on Etherscan—analysis based on transaction patterns and bytecode
19 functions cataloged (10 view, 9 admin, 0 public user functions)
Complete function selector mapping and event signature reconstruction
450+ lines of reconstructed Solidity source code in artifacts
Multiple mermaid diagrams visualizing architecture, storage layout, and access control
50+ verification commands for independent validation
Critical risks identified: unverified source code and single owner control without protective mechanisms

Infrastructure: Added to Contract Analysis section under Sentinel, alongside SENT Token, SENT Presale, and SENT Hive Registry analyses.

Added: Sentinel Hive Registry Contract Analysis

Type: Contract Analysis | Location: Sentinel Hive Registry

A comprehensive bytecode analysis of the Sentinel Hive Registry contract, an unverified UUPS upgradeable membership tracking system for SENT token holders. This analysis reconstructs the contract's functionality from bytecode, identifying 33+ functions, complete storage layout, and upgrade mechanisms.

Key findings:

UUPS upgradeable proxy pattern (EIP-1967 compliant) deployed December 28, 2025
Tracks SENT token holders meeting minimum balance threshold (default 1,000 SENT)
Registration system with external eligibility verification via Hive contract
Automated daily balance checks with batch processing (100 participant cap)
Cooldown period for re-registration (default 7 days, max 30 days)
Centralized owner control with unrestricted upgrade authority (no timelock)
External dependencies: SENT token (0xe88BAab9...c304) and Hive contract (configurable)
Risk assessment: 0 Critical, 3 High, 5 Medium, 4 Low, 3 Informational

Related pages: Functions | Storage Layout | Potential Risks | Methodology | Artifacts

Notable aspects:

Contract source code is unverified on Etherscan—analysis based entirely on bytecode decompilation
Reconstructed Solidity source code included in artifacts (450+ lines)
Complete function selector mapping and ABI reconstruction
15+ mermaid diagrams illustrating architecture, storage, and logic flows
50+ cast commands provided for independent verification

Infrastructure: Added to Contract Analysis section under Sentinel, following SENT Token and SENT Presale analyses.

2026-01-11

Added: Eth Wallet Analyzer Tool

Type: Interactive Tool | Location: Eth Wallet Analyzer

A client-side browser tool for analyzing Ethereum wallet transaction history. Generates detailed reports showing ETH and ERC20 token inflows, outflows, top counterparties, and recent activity. All processing happens in the browser using Etherscan API data—no data is sent to DNZN servers.

Key features:

ETH and ERC20 token analysis with configurable filters
Activity logging with real-time status updates
Cached responses and wallet history stored locally
Report download and clipboard copy
Independent security audit included in documentation

Enhanced: Cross-Linking Across Documentation

Type: Site Infrastructure | Scope: Multiple articles

Added strategic cross-links throughout the documentation to improve navigation and create educational pathways between related concepts. Cross-links connect abstract concepts to real-world examples and technical mechanisms to practical case studies.

Articles updated:

Flash Loans → Beanstalk Governance Attack (full deep dive link)
Oracles → Flash Loans (attack pattern mechanics)
Price Impact/Slippage → jaredfromsubway.eth (real-world MEV example)
Proxy Contracts → Bridges (Ronin exploit context) + Multisigs & Timelocks (securing upgrades)
jaredfromsubway.eth → Price Impact/Slippage (attack mechanics explanation)
October Flash Crash → Market Makers (liquidity withdrawal context)
Multisigs & Timelocks → Proxy Contracts (Bybit hack technical details)
Bridges → Proxy Contracts (vulnerability patterns)
BFT → Oracles, Beanstalk Governance Attack (application-layer exploits)

Impact: Readers can now navigate from high-level concepts to detailed case studies and vice versa, creating a more interconnected knowledge base.

Added: BFT (Byzantine Fault Tolerance)

Type: Low Dive | Location: BFT

Byzantine Fault Tolerance (BFT) is the ability of a distributed system to reach consensus even when some nodes fail or act maliciously. This low dive covers the Byzantine Generals Problem, how BFT consensus works (including the 3f+1 requirement), practical BFT (pBFT) and its three-phase protocol, modern variants like Tendermint and HotStuff, and the vulnerabilities that threaten BFT systems.

Key findings:

BFT systems tolerate up to 33% faulty nodes (compared to 51% in PoW)
pBFT introduced a practical three-phase protocol (pre-prepare, prepare, commit) in 1999
Modern variants optimize different trade-offs: Tendermint (linear view changes), HotStuff (responsive + linear communication)
BFT provides absolute finality—transactions cannot be reversed once consensus is reached
Major vulnerabilities include Sybil attacks, majority attacks (>33% control), and view change failures
Communication overhead limits validator count (O(n²) in pBFT, O(n) in HotStuff)

Glossary additions: BFT, Byzantine Fault Tolerance, Byzantine Generals Problem, pBFT, Practical Byzantine Fault Tolerance, Tendermint, HotStuff, Consensus, Finality, View Change, Validator, Proof of Work, PoW, Proof of Stake, PoS, Sybil Attack

Infrastructure: Added BFT to Technology section alongside Oracles and Bridges.

2026-01-09

Added: Privacy Policy

Type: Site Infrastructure | Location: Privacy Policy

Added a privacy policy page to document Google Analytics usage. The policy explains what anonymous data is collected (page views, device info, referrals), confirms no personal information is gathered, and provides options for users who prefer to block tracking.

Revised: Market Makers (Low Dive)

Type: Low Dive | Location: Market Makers

Revised the Market Makers article from deep dive length (~508 lines) to proper low dive format (~257 lines). Removed redundant case study content that duplicated other deep dives, added TL;DR section, reduced diagram count from 9 to 2, and converted detailed case studies to brief mentions with cross-references to new dedicated deep dive articles.

Added: Alameda/FTX Collapse (November 2022)

Type: Deep Dive (Event) | Location: Alameda/FTX Collapse

The November 2022 collapse of FTX and Alameda Research demonstrated what happens when a market maker operates without oversight, with privileged exchange access, and with other people's money. Alameda had secret exemptions from FTX's risk controls, including immunity from auto-liquidation, and used customer deposits to cover trading losses.

Key findings:

Alameda had a hidden $65B line of credit to withdraw customer funds
FTT token used as collateral created circular solvency dependencies
$8.9B in customer funds went missing; $6B withdrawn in 72 hours during bank run
Sam Bankman-Fried convicted on all 7 counts, sentenced to 25 years
Post-collapse "Alameda Gap" saw market liquidity drop ~50%

Added: MOVE Token Scandal (2025)

Type: Deep Dive (Event) | Location: MOVE Token Scandal

Movement Labs executives colluded with their market maker to dump $38M worth of MOVE tokens on retail investors immediately after the December 2024 exchange listing. Internal documents showed explicit incentives to "manipulate the price to over $5 billion FDV and then dump on retail for shared profit."

Key findings:

66 million MOVE tokens dumped the day after listing
Deal structure documented coordinated pump-and-dump for "shared profit"
World Liberty Financial (Trump-associated) was an early backer
Coinbase delisted MOVE; Binance froze market maker proceeds
Multiple executives terminated; investigations ongoing

Added: Mantra OM Collapse (April 2025)

Type: Deep Dive (Event) | Location: Mantra OM Collapse

On April 13, 2025, Mantra's OM token collapsed 92% in hours—from $6.21 to under $0.50—wiping out $5B+ in market cap. OKX alleged circular collateralization schemes where USDT loans backed by OM were used to buy more OM, creating artificial price support that collapsed when risk teams froze accounts.

Key findings:

92% crash occurred on Sunday evening UTC when liquidity was thinnest
OKX alleged circular collateralization: borrow USDT against OM, buy more OM
Circulating supply and volume metrics allegedly misrepresented
Multiple market makers denied being Mantra's official MM
Token trades at ~$0.07 as of late 2025 (99% decline from peak)

Added: Glossary Terms

Type: Glossary Update | Location: Glossary

Added market maker terminology to support the new deep dive articles.

Glossary additions: Market Maker, Designated Market Maker, DMM

2026-01-08

Added: Beanstalk Governance Attack (April 2022)

Type: Deep Dive (Event) | Location: Beanstalk Governance Attack

On April 17, 2022, an attacker used a $1B+ flash loan to gain 79% voting power in Beanstalk's governance system, then executed a malicious proposal that drained $182M from the protocol in a single transaction. The attack exploited the emergencyCommit() function which allowed same-block proposal execution without delays. This deep dive covers the attack mechanics, timeline, key actors, the protocol's recovery via the "Barn Raise," and lessons for governance design.

Key findings:

Attacker flash-loaned $1.04B from Aave, Uniswap, and SushiSwap to acquire 79% voting power
emergencyCommit() function allowed instant proposal execution with zero delay
Attacker netted ~$76M profit (24,830 ETH); laundered via 270 Tornado Cash transactions
Founders "Publius" (Weintraub, Sanderson, Montoya) doxxed themselves post-attack
Protocol relaunched 4 months later with multisig governance replacing on-chain voting

Glossary additions: Governance Attack

Added: Flash Loans

Type: Low Dive | Location: Flash Loans

Flash loans are uncollateralized loans that must be borrowed and repaid within a single blockchain transaction—if repayment fails, the entire transaction reverts. This article covers the mechanics, legitimate use cases (arbitrage, collateral swaps, liquidations), major providers and their fees, attack patterns that have exploited vulnerable protocols, and defensive measures.

Key findings:

Flash loans enable borrowing unlimited funds with zero collateral, but atomicity means lenders face zero risk
Over $300M stolen via flash loan-assisted attacks since 2020 (bZx, Harvest Finance, Beanstalk)
Major providers: Aave (0.05%), Uniswap (0.05-1%), Balancer (0%), MakerDAO (0% flash mint)
Flash loans amplify existing vulnerabilities—particularly oracle manipulation and governance attacks
Defenses include TWAP oracles, governance time delays, and multi-source price feeds

Glossary additions: Flash Swap, Atomic Transaction, EIP-3156

2026-01-05

Added: Jared 2.0 MEV Bot Contract Analysis

Type: Contract Analysis | Location: Jared 2.0 MEV Bot

A detailed bytecode analysis of the Jared 2.0 MEV bot contract (0x1f2f10d1c40777ae1da742455c65828ff36df387), the second iteration of the notorious jaredfromsubway.eth sandwich attack infrastructure. This analysis examines the contract's multi-DEX integration, stateless architecture, and the technical mechanisms enabling multi-layer sandwich attacks.

Key findings:

Contract is stateless (no storage slots used) for gas efficiency and security
Integrates with 5+ DEXs: Uniswap V2/V3, Balancer, Curve, DODO
Includes Uniswap V3 liquidity functions (mint/burn/collect) for multi-layer attacks
Access control hardcoded to single EOA (jaredfromsubway.eth)
2.39M+ transactions processed since August 2024

Related pages: Functions | Storage Layout | Potential Risks | Methodology | Artifacts

2026-01-04

Added: jaredfromsubway.eth Deep Dive

Type: Deep Dive (Entity) | Location: jaredfromsubway.eth

A comprehensive analysis of one of Ethereum's most notorious MEV bot operators. jaredfromsubway.eth rose to infamy during the April 2023 memecoin frenzy, executing sandwich attacks that extracted an estimated $22M+ in revenue while spending $34M in gas fees. The article covers attack mechanics, timeline of activity, contract addresses, evolution to "Jared 2.0" with multi-layer attacks, and protection mechanisms available to traders.

Key findings:

At peak activity, jaredfromsubway transactions appeared in over 60% of Ethereum blocks
106,000+ unique addresses victimized across 238,000+ sandwich attacks
Jared 2.0 (August 2024) introduced 5-layer and 7-layer sandwich attacks using liquidity provision
Operator identity remains unknown despite extensive on-chain analysis

Glossary additions: Front-Running, Back-Running, Block Builder, MEV Searcher

Added: Proxy Contracts & Upgradeability

Type: Low Dive | Location: Proxy Contracts & Upgradeability

Proxy contracts enable smart contract upgradeability by separating storage from logic—but this flexibility introduces trust assumptions and attack surfaces. This article covers how delegatecall works, the major proxy patterns (Transparent, UUPS, Beacon), EIP-1967 storage slots, and the vulnerabilities that have cost protocols hundreds of millions.

Key findings:

Uninitialized implementation contracts remain a critical attack vector ($12M Ronin, Delta Prime, Pike Finance in 2024)
UUPS is more gas-efficient but can be permanently bricked if upgrade logic is removed
Storage layout must be preserved exactly across upgrades or state corruption occurs
EIP-1967 standardizes storage slots to prevent collisions between proxy and implementation

Glossary additions: Proxy Contract, Implementation Contract, Delegatecall, Transparent Proxy, UUPS, ERC-1822, Beacon Proxy, EIP-1967, Storage Collision, Initializer, Storage Layout

Added: Bridge Technology Overview

Type: Low Dive | Location: Bridges

Cross-chain bridges enable asset transfers between isolated blockchains by introducing trust assumptions—and those assumptions have cost users over $2.8B since 2022. This article covers the mechanics (lock-and-mint, burn-and-mint, lock-and-unlock), the trust spectrum from centralized custodians to ZK-verified systems, and a graveyard of major exploits.

Key findings:

Private key compromise dominates attack vectors—not smart contract bugs
The $625M Ronin hack originated from a fake LinkedIn job offer targeting an Axie engineer
Canonical bridges (operated by L2 teams) inherit chain security; third-party bridges introduce new trust assumptions
$55B TVL across bridges in 2025 makes them persistent honeypots

Glossary additions: Bridge, Cross-Chain Bridge, Wrapped Token, Lock and Mint, Burn and Mint, Canonical Bridge, Validator Bridge, IBC