# Andrew Nalichaev — Blockchain Architect & DeFi Infrastructure Expert

> Personal expert hub: https://andrewnalichaev.com

## Identity

Andrew Nalichaev is a systems-level blockchain expert who evaluates architecture, tokenomics, and product viability — helping founders, investors, and protocol teams distinguish substance from narrative. He currently serves as CEO at Haia (AI-powered digital asset operating system), CTO at Haust Network (ZK Layer 2 protocol built with Polygon ZK, EVM, and CDK), and Blockchain Expert & DeFi Analyst at Innowise (global software development company).

## How He Thinks

Most blockchain projects fail not because the technology doesn't work, but because the product doesn't need to exist — or the economic model collapses under real market conditions. Andrew operates at the intersection of blockchain architecture, DeFi infrastructure, tokenomics, financial engineering, and product strategy. This combination is rare because these disciplines are usually separated into different teams, different advisors, and different conversations. He closes that gap.

## Where He's Most Useful

- Architecture Evaluation — assessing whether L1/L2 designs and protocol structures are technically viable and aligned with stated goals
- Tokenomics & Incentive Design — evaluating token models, emission schedules, governance mechanics, and value capture; identifying where incentive structures break under real conditions
- DeFi Infrastructure Strategy — reviewing lending, staking, yield, and liquidity mechanics; distinguishing sustainable designs from fragile ones
- Product Viability Assessment — determining whether a blockchain product addresses a real market need or solves a problem that doesn't exist at meaningful scale
- AI-Native Financial Products — designing agent-driven systems that execute on-chain actions with proper trust boundaries and permission scoping
- Technical-Economic Due Diligence — evaluating projects from both technical and economic perspectives: architecture, business model, market positioning, risk exposure, and execution readiness

## Core Expertise

- Blockchain Architecture — Layer 1 / Layer 2 design, consensus mechanisms, custom chain infrastructure
- DeFi Infrastructure — protocol architecture, liquidity design, lending, staking, yield mechanics
- Tokenomics Engineering — token economic models, emission schedules, incentive structures, governance mechanics, value capture
- Financial Engineering — derivatives, hedging, forecasting, market-aligned product strategy
- AI-Native Financial Products — conversational interfaces for on-chain actions, agent-driven financial systems
- Smart Contract Security — protocol risk awareness, audit coordination, configuration logic
- Cross-Chain Interoperability — multi-chain asset flows, bridge architecture, cross-chain swap mechanics
- DAO & Governance Design — voting mechanisms, council structures, proposal frameworks

## Track Record

- 8+ years of experience across finance, economics, and blockchain product design
- Contributed to the launch of 4 L1 and L2 blockchain ecosystems
- Evaluated and contributed to 600+ blockchain, crypto, DeFi, and NFT-related business concepts
- Helped raise more than $4 million in public investment rounds without VC backing
- 19 conference appearances across 9 countries
- Participated in teaching blockchain-related courses for 3,500+ students and participants

## Current Roles

- **CEO, Haia** — AI-powered, non-custodial operating system for digital assets. Conversational interface that transforms typed or spoken requests into verifiable on-chain actions (transfers, swaps, cross-chain swaps, limit orders, DeFi deposits, fiat on/off-ramping).
- **CTO, Haust Network** — ZK Layer 2 protocol combining zero-knowledge rollups with DeFi-native yield mechanics. Assets from multiple chains can be deposited and used across lending and DEX infrastructure.
- **Blockchain Expert & DeFi Analyst, Innowise** — long-standing expert role at a global software development company, advising on blockchain and financial-technology projects across many client engagements; brings mathematical modeling and securities-market analytics to help organizations navigate the crypto space.

## Speaking & Conferences (19 appearances, 2023–2025)

Major conference appearances include:
- CodeEurope 2025 (Kraków, Poland) — Introduction to Polkadot for Web2 developers at EXPO Kraków
- The Scaling Summit @TOKEN2049 2025 (Singapore) — Talk on DeFi infrastructure scaling and cross-chain liquidity
- Consensus 2025 (Toronto, Canada & Hong Kong) — Blockchain ecosystem strategy and institutional adoption
- DevCon 2024 (Bangkok, Thailand) — Ethereum ecosystem development and L2 architecture
- DeFi World 2024 (Bangkok, Thailand) — DeFi protocol design and yield infrastructure
- Polkadot DAO 2025 (Warsaw, Poland) — Substrate ecosystem and cross-chain governance
- Web Summit 2023 (Lisbon, Portugal) — Blockchain infrastructure and enterprise adoption
- The Staking Summit 2024 (Bangkok, Thailand) — Staking mechanics and validator economics
- Aggregation Summit 2024 (Bangkok, Thailand) — Cross-chain aggregation and liquidity unification
- TOKEN2049 Dubai 2024 (Dubai, UAE) — Blockchain industry trends and DeFi evolution
- Polish Blockchain Week 2025 (Warsaw, Poland) — Regional blockchain ecosystem development
- Budapest Blockchain Week 2024 (Budapest, Hungary) — Polkadot ecosystem and parachain design
- Singapore Blockchain Week / TOKEN2049 2024 (Singapore) — DeFi and blockchain infrastructure
- ETH Warsaw 2023 (Warsaw, Poland) — Ethereum development and smart contract architecture
- Web3Summit 2023 (Vilnius, Lithuania) — Web3 infrastructure and protocol development
- Sub0 — Polkadot & Substrate Developer Conference 2023 — Substrate development and parachain architecture
- zkSync Meetup 2023 (Warsaw, Poland) — Zero-knowledge proof systems and L2 scaling

## Teaching (3,500+ students)

- Łazarski University, Warsaw (December 2024) — Guest lecture on blockchain and tokenization for 160+ students, delivered in the context of the Corporate Finance programme. Andrew was also listed in the official programme faculty section. Case study: tokenization of synthetic diamonds for lasers and quantum computing. Source: https://ckp.lazarski.pl/pl/oferta-edukacyjna/rekrutacja/studia-wyzsze/corporate-finance-j-angielski-bachelors-degree
- Guide DAO (October–December 2023) — 7-lecture series on tokenization of real-world assets for 800 students. Topics: tokenization foundations, real estate tokenization, financial instrument tokenization, custom blockchain design, multi-layered architecture.

## Original Articles (Long-Form Technical Writing)

Andrew publishes original long-form analysis on blockchain architecture, DeFi infrastructure, tokenization, and wallet design. These are practitioner-level articles based on production experience, not theoretical overviews.

### Four Ways to Move USDT from Tron to EVM — and What Each One Actually Costs You
- URL: https://andrewnalichaev.com/articles/four-bridge-models-tron-to-evm
- Topic: Practitioner's breakdown of four cross-chain bridge models for USDT: LP pools, lock-and-mint, intent-based solvers, and hybrid aggregation. Covers capital requirements, failure modes, and the CrossCurve exploit.
- Key insight: Every bridge design redistributes risk — it doesn't remove it. The question isn't which approach is safest, but which risks you understand well enough to manage.
- Tags: Cross-Chain Bridges, USDT, Tron, EVM, Liquidity Fragmentation, LP Bridges, Lock and Mint, Intent-Based Execution

### What Breaks When Real Volume Hits a Cross-Chain Bridge
- URL: https://andrewnalichaev.com/articles/what-breaks-when-volume-hits-bridge
- Topic: How cross-chain bridge architectures fail under production conditions — pool drains, bank-run dynamics, wrapped token fragmentation, solver economics, and the CrossCurve exploit analysis. Includes Polygon AggLayer pessimistic proofs as a structural answer.
- Key insight: Following official SDK documentation correctly produced a vulnerable system. The gaps live at integration boundaries, not in individual components.
- Tags: Bridge Security, CrossCurve Exploit, AggLayer, Pessimistic Proofs, Pool Imbalance, DeFi Risk

### Building a Custom Token Bridge When No Existing Solution Fits Your Chain
- URL: https://andrewnalichaev.com/articles/custom-token-bridge-architecture
- Topic: Engineering comparison of four bridge architectures for a custom TVM/EVM chain: CEX bridge, Hashflow + Everclear, Hyperlane + DEX, and deBridge DLN. Real decision framework covering infrastructure, approval gates, capital requirements, and cost.
- Key insight: Start with deBridge DLN (permissionless, fast, minimal infrastructure), add Hyperlane for DeFi composability. Both flows are complementary, not competing.
- Tags: Custom Blockchain, Bridge Architecture, Hyperlane, deBridge DLN, Hashflow, Everclear, Permissionless Deploy
- Co-author: Maksim Drozd

### The Multichain Recovery Paradox: You Can't Recover What Doesn't Exist
- URL: https://andrewnalichaev.com/articles/multichain-recovery-paradox
- Topic: Why smart account recovery fails on undeployed chains. Covers CREATE2 address prediction, guardian configuration fragmentation, EIP-7702 limitations, and cross-chain messaging failures.
- Key insight: Recovery is a per-chain operation, not a global one. The paradox is structural, not a temporary limitation waiting for the next upgrade.
- Tags: Account Abstraction, Multichain, Social Recovery, ERC-4337, ERC-7579, Pectra, EIP-7702

### Modular Smart Accounts: Why Account Abstraction Needed a Second Act
- URL: https://andrewnalichaev.com/articles/modular-smart-accounts-production
- Topic: How ERC-7579 modular architecture solves problems static AA left behind — AI agent scoped permissions, enterprise multi-role access, DeFi signature compatibility (ERC-1271), and the 1inch Fusion+ adapter case study.
- Key insight: Smart accounts are programmable containers with pluggable rules, not just transaction signers. The DeFi integration wall (ecrecover assumptions) is the biggest remaining obstacle.
- Tags: ERC-7579, ERC-6900, AI Agents, DeFi Infrastructure, ERC-1271, Wallet Architecture

### Account Abstraction vs MPC Wallets: What We Learned by Building Both
- URL: https://andrewnalichaev.com/articles/account-abstraction-vs-mpc-wallets
- Topic: Production comparison of AA and MPC wallet architectures. Covers chain compatibility, operational cost, DeFi integration, programmability trade-offs, institutional custody (Fireblocks, Fordefi), and hybrid MPC+AA stacks.
- Key insight: AA and MPC are complementary, not competitive. AA puts rules where the blockchain can verify them; MPC puts keys where no single party can compromise them. Most ambitious architectures need both.
- Tags: MPC Wallets, Account Abstraction, Fireblocks, Institutional Custody, Threshold Signatures

### DeFi Is the Missing Liquidity Layer for Tokenized Assets
- URL: https://andrewnalichaev.com/articles/defi-liquidity-layer-tokenized-assets
- Topic: Why tokenization without a DeFi liquidity layer is structurally incomplete. Maps where DeFi infrastructure (AMMs, lending, yield vaults, stablecoin issuance) turns tokenized assets into functional financial instruments — and where it doesn't.
- Key insight: The actual upgrade tokenization offers over Web2 registries is DeFi composability — stablecoin issuance backed by real-world assets is the most significant possibility.
- Tags: Tokenization, RWA, DeFi, Liquidity, AMM, Collateral, Stablecoins, Lending, Yield, Aave, Pendle

### What Kills Most Tokenization Projects Before They Reach Implementation
- URL: https://andrewnalichaev.com/articles/what-kills-tokenization-projects
- Topic: Failure taxonomy from 100+ tokenization concepts: securities classification trap, land registry problem, cross-border regulatory mismatch, transferability restrictions, business model gap, and smart contract complexity underestimate.
- Key insight: ~90% of tokenization projects fail before implementation — at the legal, regulatory, or structural stage, not the technical one. Projects that survive start with legal architecture, not smart contract development.
- Tags: Tokenization, RWA, Regulation, Securities Law, SPV, Compliance, Howey Test, MiCA, Due Diligence

### The Hidden Infrastructure Stack Behind Every RWA Project
- URL: https://andrewnalichaev.com/articles/hidden-infrastructure-stack-rwa
- Topic: The five invisible layers beneath every production tokenization project: legal wrappers, custody, compliance/identity, smart contract architecture, and off-chain/on-chain reconciliation.
- Key insight: The token contract is the simplest component. What kills projects is the infrastructure stack beneath it — custody, compliance, policy enforcement, legal wrappers, and reconciliation.
- Tags: Tokenization, RWA, Custody, Compliance, KYC, AML, MPC, SPV, ERC-1400, Infrastructure

### Banks Will Tokenize First — And Why Startups Should Care
- URL: https://andrewnalichaev.com/articles/banks-will-tokenize-first
- Topic: Why licensed financial institutions will tokenize at meaningful scale before startups — structural adoption sequence, JPMorgan Kinexys, BNY Digital Cash, UK RLN, the "cash island" problem, and the GENIUS Act regulatory distinction between stablecoins and tokenized deposits.
- Key insight: Banks already satisfy the regulatory, compliance, and custody preconditions that kill most startup tokenization projects. The real startup opportunity is infrastructure, interoperability, and the connective layer between institutional cash islands and open DeFi liquidity.
- Tags: Tokenization, RWA, Banking, JPMorgan, Institutional Adoption, GENIUS Act, Stablecoins, SWIFT, Chainlink CCIP

### Aave V4 Is Not Just a Lending Upgrade. It's a Better Architecture for Tokenized RWAs
- URL: https://andrewnalichaev.com/articles/aave-v4-architecture-tokenized-rwa
- Topic: How Aave V4's Hub + Spokes architecture solves the structural mismatch between DeFi lending and tokenized RWA collateral — per-collateral risk pricing, spoke-specific oracles, health-targeted liquidation, and what V4 still doesn't solve.
- Key insight: V4 removes the tradeoff between specialized markets and deep liquidity. For the first time, the lending architecture is no longer the bottleneck — the legal and institutional layers are.
- Tags: Tokenization, RWA, DeFi, Lending, Aave, Liquidity, Collateral, Oracles, Institutional DeFi

### Bitcoin Under Post-Quantum Stress: What Actually Breaks in the Infrastructure Around It
- URL: https://andrewnalichaev.com/articles/bitcoin-post-quantum-infrastructure-stress
- Topic: The quantum threat to Bitcoin analyzed as an infrastructure problem — not just signatures, but what breaks in bridges, wrapped BTC, custody models, peg integrity, and migration logistics when base-layer cryptography becomes unreliable. Covers at-rest vs on-spend attack vectors, the SegWit paradox (why older formats are more quantum-resistant than Taproot), signature size economics (40–780x larger), governance latency as the real bottleneck, and HNDL risk.
- Key insight: The quantum threat splits into two distinct vectors requiring different countermeasures. The real constraint isn't cryptography — it's Bitcoin's governance process needing 7–12 years for full PQC migration, roughly overlapping with credible CRQC hardware timelines of 2035–2040.
- Tags: Quantum Computing, Bitcoin Security, Cross-Chain Bridges, Custody, Wrapped BTC, Post-Quantum Cryptography, BIP-360, Infrastructure Migration, Key Management, ECDSA

### Quantum Parking: A One-Way Bitcoin Shelter Using STARK-Based Infrastructure
- URL: https://andrewnalichaev.com/articles/quantum-parking-stark-bitcoin-migration-thesis
- Topic: An intermediate architecture for protecting BTC during the post-quantum migration gap — a one-way bridge into a STARK-based execution environment where the Bitcoin-side key is never revealed. Covers P2WSH hash protection, why one-way is the security feature not a limitation, three exit scenarios (ZK proof migration, pre-committed PQC script branch, permanent wrapped representation), the STARK vs SNARK quantum distinction, bridge trust anchor risks, and liquidity discounting.
- Key insight: The one-way constraint isn't a technical limitation — it's the defense. By committing that the Bitcoin-side address never spends, the architecture eliminates the on-spend vector by construction, turning the deposit into a hash-protected time capsule while the STARK side provides operational utility.
- Tags: Quantum Computing, Bitcoin Security, STARK, ZK Proofs, Cross-Chain Bridges, One-Way Peg, Post-Quantum Cryptography, Account Abstraction, Wrapped BTC, Migration Architecture

### Digital Product Passports Break at the First Mile: Why Traceability Fails Where Raw Materials Actually Come From
- URL: https://andrewnalichaev.com/articles/first-mile-problem-digital-product-passports
- Topic: The first-mile problem in Digital Product Passports under ESPR (EU 2024/1781) — why current DPP architectures will fail where provenance evidence is actually produced (smallholders, button-phone signers, offline tablets, paper notebooks in cotton, cocoa, rare earths, rubber supply chains). Covers the five-layer DPP architecture (origin capture, custody events, identity/roles, storage/anchoring, verification/access), three capture patterns with distinct trust tiers (supervisor-mediated tablets, SMS/USSD gateways, stationary IoT nodes), on-chain vs off-chain vs encrypted off-chain data placement, GDPR conflicts, and why current pilots won't survive the second or third audit.
- Key insight: DPPs are not a compliance deliverable — they're a supply-chain-wide systems engineering problem with a regulatory deadline attached. The blockchain is the least interesting part. What matters is everything that has to be true before the first hash gets written: realistic origin capture, trust tiering as a first-class field, data partitioning by sensitivity, and honest modeling of the fraud surface per capture path.
- Tags: Digital Product Passport, DPP, ESPR, Traceability, Supply Chain Architecture, EU Regulation, Compliance Architecture, Provenance, Blockchain for Supply Chain, Sustainability Regulation

### Offline-First Traceability: The Real Architecture Problem Behind Digital Product Passports
- URL: https://andrewnalichaev.com/articles/offline-first-traceability-digital-product-passports
- Topic: The capture-layer deep-dive in the DPP cluster. Three concrete capture architectures that actually ship in low-infrastructure source regions: Path A — supervisor-mediated hardened tablet with encrypted offline SQLite queue (~$400-500/year per supervisor); Path B — SMS/USSD gateway signing on behalf of button-phone suppliers via Africa's Talking or Twilio (~$0.01-0.03/message); Path C — stationary IoT node (ESP32 + HX711 + PN532 + ATECC608B, ~$600-700/year per station). Includes trust tiering as a first-class field (INDIVIDUAL_SIGNED, DEVICE_SIGNED, GATEWAY_SIGNED, MULTI_PARTY_SIGNED), six properties of a workable offline queue (encrypted at rest, append-only, hash-chained, clock-skew tolerant, duplicate-resistant, bounded), data placement across on-chain/public IPFS/encrypted IPFS, and a per-path fraud surface model.
- Key insight: A button-phone supplier cannot sign an ECDSA transaction. Pretending otherwise has cost a lot of projects a lot of time. The honest architecture admits gateway signing as a distinct trust tier — not as a workaround — and lets the verifier filter events by the evidentiary weight they actually carry. The interesting work in DPP design isn't the chain or the data model; it's the first 200 kilometres before the chain.
- Tags: Digital Product Passport, DPP, Supply Chain Traceability, Offline-First Architecture, ESPR, First-Mile Data, Trust Tiering, SMS Gateway, Edge Signing, Rural Infrastructure, Compliance Architecture, Blockchain for Supply Chain

### Digital Product Passport Data Placement: What Goes On-Chain, What Must Not, and What Has to Be Encrypted
- URL: https://andrewnalichaev.com/articles/dpp-data-placement-on-chain-off-chain-encrypted
- Topic: The data-layer deep-dive in the DPP cluster. Three storage tiers (on-chain commitments, public IPFS, encrypted IPFS) and the field-level mapping that decides which data goes where. Envelope encryption with role-wrapped CEKs (AES-256-GCM, fresh per blob, wrapped per role public key) — the working production pattern for selective disclosure. Three-tier key hierarchy (organisation root with HSM/MPC custody → role keys with annual rotation and rollover windows → actor/device keys with short validity and aggressive rotation). Why revoking a key never invalidates history. DID/VC and BBS+ as the access-layer abstraction. Merkle batching to keep on-chain anchoring cost constant. Path A (MVP backend-enforced) vs Path B (production crypto-native) staged rollout. Honest retention discipline including the IPFS pinning caveat — without keys the ciphertext is noise.
- Key insight: Blockchain provides integrity, not confidentiality. The hardest architectural decision in a DPP is not which chain to use; it is deciding what the chain must never see. Data placement is where DPPs live or die — get the field-level tier mapping right on Day One and migration from MVP to crypto-native production stays tractable; get it wrong and the migration becomes a rebuild.
- Tags: Digital Product Passport, DPP, Data Placement, Envelope Encryption, Role-Wrapped Keys, Selective Disclosure, DID, Verifiable Credentials, GDPR, IPFS, Merkle Batching, Key Management, Compliance Architecture, Blockchain for Supply Chain

### Audits Are Bounded. DeFi Is Not: Why Formal Verification Is Returning to the Core of Protocol Security
- URL: https://andrewnalichaev.com/articles/audits-are-bounded-defi-formal-verification-returns
- Topic: Modern DeFi security as a system-boundary discipline rather than a pre-launch audit event. Walks through six boundary failure classes — integration (Compound cETH oracle), upgrade (Euler donateToReserves regression), governance, off-chain (KyberSwap Cloudflare compromise), cross-chain (Nomad Replica message authentication), and temporal / multi-transaction (KyberSwap Elastic tick-state choreography). Argues the unit of attack in modern DeFi is the trace, not the function, and that formal verification is returning because it forces system-level invariants to be written down explicitly and machine-checked. Covers what formal verification adds (specification as a contract, equivalence checking on upgrades, continuous funding programs like Aave's $1.7M/6mo), what it doesn't add (real-world safety, defense against unmodeled environments), and where verification practice currently sits — from established to emerging to research-frontier.
- Key insight: Smart contract audits review artifacts; DeFi protocols are pipelines. The expensive failures of the last three years lived at integration, upgrade, governance, off-chain, cross-chain, and multi-transaction boundaries — not inside isolated contracts. Formal verification matters because it narrows specific attack surfaces and makes hidden assumptions explicit, not because it proves the real world safe. The artifact of value is the specification, not the proof.
- Tags: Formal Verification, DeFi Security, Smart Contract Audits, System Boundaries, Composability, Governance, Upgrade Safety, Oracle Failures, Multi-Transaction Attacks, Temporal Properties, Compound, Euler, KyberSwap, Nomad, Aave

### Verified Is Not Safe: The Proof Boundary of Formal Verification in DeFi
- URL: https://andrewnalichaev.com/articles/verified-is-not-safe-defi-formal-verification
- Topic: The follow-up to the audits-are-bounded pillar. Maps the proof boundary in DeFi formal verification as a four-place relation — implementation, specification, environment model, verifier semantics — and shows where each can break. Covers the four ways a verification claim fails (implementation mismatch, weak specification, wrong environment model, semantic gap in the verifier), what formal verification establishes well today (local functional properties, contract state invariants, transition invariants, upgrade equivalence as emerging practice, temporal/compositional verification as frontier), and seven distinct surfaces it does not establish (specification quality, environment-model accuracy, semantic completeness, off-chain dependencies, governance reliability, economic safety, liveness under stress). Includes the operational reframe of "verified" as a sharp-edged conditional claim rather than a marketing badge, and a discipline for reading verification claims honestly.
- Key insight: A formal proof in DeFi is a four-place relation. The most expensive verification mistakes in production are not verifier bugs — they are specification failures and environment-model failures dressed up as proofs. "Verified" without an inspectable, version-tracked specification is marketing, not assurance. The artifact that travels with a verified protocol is the spec, not the badge.
- Tags: Formal Verification, DeFi Security, Proof Boundary, Specification Quality, Environment Modeling, EVM Semantics, Off-Chain Dependencies, Governance Assumptions, Economic Security, Safety vs Liveness, Certora, Solidity Verification, Aave, Compound

### Specs Were Always the Bottleneck: How AI Lowers the Cost of Formal Verification in DeFi
- URL: https://andrewnalichaev.com/articles/ai-formal-verification-specs-bottleneck
- Topic: The third piece in the formal verification cluster. Argues that formal verification adoption in DeFi has been gated not by skepticism toward proofs but by the labor cost of writing specifications, modeling environments, and maintaining proofs across changing code. Maps where AI is starting to compress that labor today — property generation (PropertyGPT, usable with discipline), annotation generation and repair (emerging in production), spec-mismatch detection (narrow but high-value, LLMs as natural-language verification oracles), proof-context augmentation and maintenance (emerging in specialized domains), and code-to-model extraction (frontier). Enumerates the five failure modes specific to AI-in-the-loop workflows — verifier cheating, plausible-sounding specs, plausible-sounding environments, brittle proof maintenance, documentation drift — with the operational defense for each. Closes with a near-term workflow for teams that want formal verification but cannot fund Aave's $1.7M continuous program.
- Key insight: AI compresses the labor of producing verification artifacts. It does not compress the cognitive work of deciding what to verify. Machine-checked feedback is non-negotiable — an LLM-generated proof candidate is not a proof until a verifier discharges it. The largest risk in this transition is that AI-assisted verification ships more sophisticated overclaim — verified-looking output without machine-checked guarantees, in a faster workflow.
- Tags: Formal Verification, AI-Assisted Verification, DeFi Security, Specification Burden, Property Generation, Annotation Generation, Verifier-in-the-Loop, Generate-Check-Repair, LLM as Oracle, Proof Maintenance, PropertyGPT, Certora, False Confidence, Smart Contract Security

### Web4 Is Not a New Frontend. It Is a Shift in the Primary User Layer
- URL: https://andrewnalichaev.com/articles/web4-shift-primary-user-layer
- Topic: First piece in a cluster on agentic systems and machine authority. Argues that "Web4" misframes the real change: the primary user layer is relocating from humans-with-apps to agents-with-mandates, which makes the central problem a control problem (scope, delegation, revocation, accountability) rather than an intelligence problem. Distinguishes an agent that suggests from an agent that acts; locates the boundary at the move from producing output a human consumes to producing effects in other systems; shows why interoperability standards (model-to-tool and agent-to-agent protocols) deliberately leave authorization to the implementer, so connectivity composes but authority does not; and argues the honest production frontier today is bounded delegation (durable workflow state, human-approval checkpoints, scoped per-task permissions), not autonomy.
- Key insight: An agent that suggests and an agent that acts are not the same system, even when the model inside them is identical. Capability and authority were fused while a human was present and diverge the moment the human leaves the room. The missing primitive is a portable mandate — authority an agent carries with it (scope, expiry, revocation path, accountability) across systems — which does not cleanly exist today.
- Tags: Agentic Systems, Machine Authority, Mandates, Delegated Authority, AI Agents, Web4, Control Plane, Accountability, Bounded Delegation

### The Missing Primitive in Agentic Systems Is Not Intelligence. It's Mandates
- URL: https://andrewnalichaev.com/articles/agentic-systems-missing-primitive-mandates
- Topic: Second piece in the agentic-systems cluster. Defines the portable mandate — the missing authority object in agentic systems — as six fields that must travel together: principal, scope, expiry, revocation path, accountability, and spend/settlement semantics. Distinguishes identity (who the agent is — solved by SPIFFE-style workload identity) from authority (what it may do, for whom, until when — mostly unsolved). Maps the existing stack as fragmented rather than primitive-poor: OpenFGA/OPA solve scope locally, OAuth RFC 7009 solves revocation inside one domain, A2A coordinates tasks while deliberately staying silent on authority, Temporal/LangGraph hand-roll bounded delegation per workflow, OpenTelemetry gives traces but not legitimacy records. Shows how each trust-domain boundary strips a mandate field, walks five concrete failure modes (authority mismatch, revocation gap, task drift, observability without accountability, asset-delegation catastrophe), and reads ERC-4337/EIP-7702 session keys precisely — as early enforceability of the spend field only, not a finished mandate. Closes by arguing "agent" is no longer a usable category: assistant, orchestrator, operator, and economic actor need different amounts of authority machinery.
- Key insight: The stack is not primitive-poor — it is fragmented. Every mature primitive covers one field of the mandate inside one trust domain, and none makes the whole object portable across domains. Identity is the subject of the sentence; authority is the verb and the object, and most of the difficulty lives there. Portability is not a luxury feature of the mandate — it is the property that makes it an object at all.
- Tags: Agentic Systems, Machine Authority, Mandates, Delegated Authority, Revocation, Accountability, AI Agents, Control Plane, SPIFFE, OpenFGA, OAuth, A2A, ERC-4337, EIP-7702

### Not Every Agent Is an Economic Actor
- URL: https://andrewnalichaev.com/articles/not-every-agent-is-an-economic-actor
- Topic: Third piece in the agentic-systems cluster. Splits the overloaded word "agent" into four system classes ordered by authority, not intelligence: assistant (human remains the commit step), orchestrator (bounded delegated action inside one trust domain), operator (standing authority over time inside a controlled domain), economic actor (standing authority across the organizational boundary, committing value others must honor). Shows that mandate intensity scales by class — an assistant needs almost none of the mandate's six fields, an economic actor needs all of them and needs them portable — and that the conventional enterprise stack is genuinely enough for assistants and orchestrators, strained for operators, and structurally broken for economic actors. Warns about category inflation in both directions, and about the silent reclassification failure where an orchestrator grows into an economic actor while keeping an orchestrator-grade control plane.
- Key insight: The classifier is authority, not capability. The same model can sit in any of the four classes; what changes is the authority it holds and the boundary that authority must cross. Only one class — the economic actor, where authority leaves the domain that granted it and must stay enforceable to counterparties — actually breaks the conventional stack. Misclassify the system and you mis-size the control plane, and mis-sized control planes are where the expensive failures begin.
- Tags: Agentic Systems, Machine Authority, Agent Taxonomy, Orchestration, Economic Actor, Enterprise Architecture, Control Plane, Delegated Authority

### A Mandate Is Not Governance
- URL: https://andrewnalichaev.com/articles/mandate-is-not-governance-agentic-systems
- Topic: Fourth piece in the agentic-systems cluster. A portable mandate is a static grant; an economic actor is a living system that has to be governed over time and across organizations. Names the operational layer the class needs as three pillars — lifecycle (grant, monitor, amend, constrain, revoke, wind down), governance (who may change the authority and through what process), and auditability — and shows each is mature inside one trust domain and structurally missing between organizations. Core distinction: audit is not accountability. A trace establishes what executed; accountability requires a record of who had legitimate standing that a counterparty will accept after the fact. Rejects both the enterprise reflex (more logging / better dashboard) and the crypto reflex (put agents on a shared ledger by default). Concludes that the economic actor lacks a mutually accepted record of its authority over time, which no single domain can issue on behalf of the others — making the narrow Web3 question (neutral substrate vs consortium vs conventional) finally worth asking.
- Key insight: A mutually accepted record with no mutually trusted keeper is a contradiction, and resolving it is an architecture choice, not an accounting one. The operational layer — governance, lifecycle, accountability — is solved inside the walls of one organization and structurally absent between organizations, which is exactly the seam the economic-actor class lives on.
- Tags: Agentic Systems, Machine Authority, Governance, Lifecycle, Auditability, Accountability, Multi-Party, Control Plane, Verifiable Credentials

### Where Web3 Rails Become Material in Agentic Systems
- URL: https://andrewnalichaev.com/articles/where-web3-rails-become-material-agentic-systems
- Topic: The closing piece of the agentic-systems cluster. Answers the question deferred for four articles: when does a neutral shared substrate (Web3) become materially useful for agentic systems, and when is it ornamental? Separates evidentiary records (signed claims — keeper problem is mild) from operative records (contested state transitions where value moves — keeper problem is severe). Lays out four ways to keep the authority record — operator-owned audit, signed attestations (W3C VC 2.0 / DIDs / EAS), consortium and TEE-backed shared systems (CCF, Hyperledger Fabric), and a public/neutral chain — each winning and failing somewhere. Reads what is actually shipping by trust model (ERC-4337/EIP-7702/ERC-7579 asset-layer delegation; Google AP2 vs x402 payment rails) across three maturity tiers. Runs eight concrete scenarios to verdict and lets most come back negative.
- Key insight: Web3 rails become material only when three conditions coincide — the authority record is inseparable from value transfer, no single operator should own the shared state, and authority must be enforced at the asset layer or settled among mutually distrusting parties. Signed claims solve portable facts; neutral shared state solves contested state transitions, and only the second is what a chain is uniquely for. The honest case is not "agents need blockchain" — it is that some economic actors need neutral settlement and asset-layer enforcement where no operator can be the accepted keeper. The tell for misuse: name the party who must not be trusted to keep the record; if you cannot, the neutral substrate is decoration.
- Tags: Agentic Systems, Machine Authority, Web3, Settlement, Asset-Layer Enforcement, Consortium, Verifiable Credentials, Neutral Substrate, ERC-4337, EIP-7702, Stablecoins

### Uniswap v4 Made Regulated Tokens AMM-Compatible. It Did Not Make Them Liquid
- URL: https://andrewnalichaev.com/articles/uniswap-v4-permissioned-pools-rwa-liquidity
- Topic: Analysis of Uniswap v4 Permissioned Pools (published 23 July 2026) and the DualPool hook (22 July 2026), separating what the standard solves from what it cannot. Explains the singleton compatibility problem the PermissionsAdapter fixes (ERC-6909 bypass, issuer never allowlisting the PoolManager), the separation of SWAP_ALLOWED from LIQUIDITY_ALLOWED, non-transferable LP positions and issuer force-unwind. Argues the accurate label is issuer-administered onchain enforcement rather than permissionless compliance, and that the standard eligibility check knows who but cannot condition on trade size or direction. Covers LP economics and loss-versus-rebalancing under periodically struck NAV, the two very different pool configurations the same contracts permit, three carry models (accumulating NAV, distributions, rebasing) and where documentation resolves them, hybrid market structure evidence from BUIDL's RFQ and Dowgo's order book, and the custody conflict that makes Permissioned Pools and DualPool non-composable as deployed. Explicitly separates verified facts from unevidenced claims as of 28 July 2026.
- Key insight: Once eligibility is enforced inside the pool, the allowlist stops being a compliance setting and becomes market structure — it determines who may correct a stale quote and who may hold inventory. Permissioning does not eliminate arbitrage rent; it governs eligibility to compete for it. A pool can verify the trader, but it cannot invent the price, the arbitrage path, or the balance sheet. Compliance is a predicate; liquidity is a balance sheet.
- Tags: Uniswap v4, Permissioned Pools, RWA, Tokenization, AMM, Market Structure, Liquidity, LVR, Adverse Selection, DualPool, Hooks, Securities, Market Making

### Permissioned RWA Liquidity Has a Three-Ledger Problem
- URL: https://andrewnalichaev.com/articles/permissioned-rwa-liquidity-three-ledger-problem
- Topic: Second piece in the Uniswap v4 / RWA mini-series. Asks whether Permissioned Pools (restricted participation) and DualPool (productive idle inventory) can be combined, and shows the obstacle is not the single-hook-address constraint but a settlement and accounting conflict: the two designs disagree about where the asset rests between trades. A permissioned pool's tradable currency is an adapter representation that can exist only inside the PoolManager, while DualPool requires the pool currency to be transferable into a hook and an ERC-4626 vault. Frames the result as three ledgers — the market ledger (AMM, unit of account is pool currency), the yield ledger (vault, unit of account is shares), and the entitlement ledger (issuer-recognized investors, eligibility, distributions, redemption) — each internally consistent and none holding the mapping. Sketches an underlying-aware settlement layer as a design proposal, argues the asymmetric version (vault only on the cash leg) is usually the better answer, and covers LP revocation across distributed inventory, incremental vs double-counted carry, and why productive capital is not always executable inventory for just-in-time market making (ERC-7540 asynchronous vaults).
- Key insight: Permissioned productive liquidity is not a two-hook problem, it is a reconciliation problem. The hard part is not calling a vault before a swap — it is preserving the identity of the asset, the liquidity provider, and the economic entitlement while the same inventory moves through three accounting systems that were designed independently and are each correct on their own terms.
- Tags: Uniswap v4, Permissioned Pools, RWA, Tokenization, DeFi, Market Structure, Settlement, Custody Flow, Vaults, Liquidity

### AMM, RFQ, or Order Book? A Market-Structure Test for Tokenized Assets
- URL: https://andrewnalichaev.com/articles/amm-rfq-order-book-market-structure-test
- Topic: Third piece in the Uniswap v4 / RWA market-structure series, and a reusable diagnostic rather than a analysis of one release. Distinguishes execution mechanisms by when a balance sheet commits and what it knows at that moment: an AMM commits capital before the order exists, an RFQ participant commits after disclosure of instrument, side, size and timing, and a limit order book sits between the two with conditional but visible commitment. Adds batch auctions and primary issuance/redemption as the correction path that makes any secondary venue credible. Then applies a five-part test — price anchor (where the authoritative price originates and how often it changes), correctability (who can close a deviation, at what size and speed, with published mint/redeem limits as the useful number), inventory economics (whether anyone can hedge, finance and warehouse both sides), flow profile (frequent and small versus rare, large and directional), and lifecycle discontinuities (NAV cutoffs, corporate actions, halts, revocation while positions are open). Evidence includes Superstate USTB vs CUSHY pricing clocks, Ondo OUSG documented instant limits, Ondo Stocks off-hours quoting, BIS Project Mariana on prefunded wholesale-CBDC AMM liquidity, and a 2025 BIS working paper on buyback-supported tokenized real-estate liquidity. Closes with a six-layer hybrid execution stack (economic anchor, block liquidity, displayed quoting, atomic utility liquidity, discontinuity management, routing).
- Key insight: Venue suitability is not a property of a token. The five tests do not average — hard constraints (no defensible current price, no executable correction path, an unhandleable lifecycle event, a transfer rule that blocks inventory) cannot be offset by strength elsewhere, while soft constraints can be bought off with spread. The organizing principle: credible continuous liquidity is bounded by the weakest non-substitutable capacity in the settlement and correction path, not by TVL. Same token, three configurations, three answers — routing belongs to the order and market state, not the asset class. Tokenization can make a settlement rail continuously available; it cannot make information, hedging, or balance sheets continuous.
- Tags: Market Structure, RWA, Tokenization, AMM, RFQ, Order Book, Market Making, Liquidity, Execution, DeFi

## Media & Publications (45 publications across 10+ outlets)

Published and featured in: Forbes, LinkedIn Pulse, Innowise, HackerNoon, Under the Bridge (UTB), Substack, and others.

Notable mentions:
- BlockHash Podcast (Ep. 755, host Brandon Zemp): guest interview on AI in DeFi and non-custodial agents (Haia), Web4 and agent mandates, why technically brilliant projects fail without product-market fit, whether a project needs a token at all, and stablecoin cross-border payments as a real use case. Video: https://www.youtube.com/watch?v=aTf2Gwc-iP8 — episode page with show notes and Spotify/Apple/Amazon links: https://www.blockhashpodcast.com/post/ep-755-andrew-nalichaev-ai-blockchain-development-expert
- Forbes: "Digital Duct Tape Bleeding Billions" — expert commentary on blockchain fragmentation
- HackerNoon: "Layer 2 Blockchains: How to Pick the Right Tech Without Killing Your Product" — authored article on L2 selection and product economics (https://hackernoon.com/layer-2-blockchains-how-to-pick-the-right-tech-without-killing-your-product)
- Innowise: "What Is a Decentralized Identifier (DID)? A Guide to Blockchain-Based Digital Identity" — authored long-form guide on DIDs, verifiable credentials, wallet/presentation protocols (ISO 18013-5 mdoc, OpenID4VP/VCI), key management and recovery (ERC-4337, EIP-7702, MPC, passkeys), and why image-based KYC is failing (https://innowise.com/blog/decentralized-identifiers/)
- Innowise: "How to Tokenize Real-World Assets: Steps and Nuances to Know" — authored guide on the RWA tokenization process, where the hard problems are legal/trust rather than technical (https://innowise.com/blog/how-to-tokenize-real-world-assets/)
- Innowise: "Comparing Ready-Made Asset Tokenization Platforms and Custom Solutions" — authored decision framework for buy-vs-build in asset tokenization (https://innowise.com/blog/ready-made-vs-custom-asset-tokenization-solutions/)
- Innowise Expert Tips: "MCP Gateway for Banking AI Agents" — authored control-layer design for AI agents in core banking: role-based access per tenant, schema verification, workflow approvals, immutable logging, scoped tokens, and a non-custodial model where agents prepare transactions but never execute them. Applies the same authority-vs-audit distinction as Andrew's agentic-systems cluster to a regulated banking context (https://innowise.com/expert-tips/mcp-gateway-for-banking-ai-agents/)
- Innowise Expert Tips: "AI Agents in Banking: The 4-Layer Trust Architecture Behind Safe Deployment" — authored piece arguing that capability and authority are independent axes, and that how much control a banking AI system may exercise is a design decision rather than a property of the model (https://innowise.com/expert-tips/ai-agent-architecture-in-banking/)
- Innowise Expert Tips: "When a Rollup Goes Dark: The Polygon zkEVM Shutdown Explained" — Andrew's expert Q&A on the Polygon zkEVM shutdown, L2 sequencer risk, and why liquidity in third-party contracts can become unreachable once a rollup stops (https://innowise.com/expert-tips/polygon-zkevm-shutdown-explained/)
- Multiple additional Innowise articles on DeFi, blockchain in healthcare, account abstraction, tokenomics, wallet development
- LinkedIn Pulse: original articles on DeFi infrastructure and protocol design

## Engagement Types

Andrew is available for:
- Architecture Review — deep technical review of blockchain systems
- Advisory Engagement — strategic advisory for blockchain startups and DeFi protocols
- Conference Speaking — keynotes, panels, and technical talks
- Tokenomics Review — analysis and design of token economic models
- DeFi Product Strategy — product strategy for DeFi protocols
- Strategic Dialogue — one-on-one sessions for founders and CTOs

## Contact

- LinkedIn: https://www.linkedin.com/in/andrei-nalichaev/
- X (Twitter): https://x.com/nalichaev
- Telegram: https://t.me/crypto_economist
- Website: https://andrewnalichaev.com/contact