AVAILABLE · SUMMER 2026 / NEW YORK, NY +1 (929) 650-8873 · yl9314@nyu.edu · github/KevinLYT
Selected case studies · 2024 — 2026

Three systems,
built end-to-end.

A focused archive of backend, AI, and applied-cryptography work. Each project is framed by the problem it solved, the architecture I chose, and the trade-offs I’d defend in an interview.

CASE / 01 Wallet analysis system diagram FIG.01 · WALLET-AGENT
RoleSolo build
StatusIn development
DomainAI · Backend
Year2026
Case 01 / 03 · AI Systems Mar 2026 → Now

Two routes, same wallet-risk model.

A FastAPI backend with two paths to the same analysis: a hard-coded Python pipeline, and a single-turn LangChain tool-calling agent over the same primitives. Same Pydantic JSON contract, two different ways the system reaches it.

FastAPI Pydantic LangChain OpenAI httpx pytest

The problem

An MVP for wallet-risk analysis that’s honest about what’s deterministic and what’s a model call. Recruiters and engineers should be able to clone, run locally, hit Swagger, and immediately see the difference between the two routes — without an OpenAI key being mandatory to get useful output.

What I built

  • POST /analyze-wallet — fixed pipeline. Resolves data (mock or user-supplied mock_transactions), runs extract_features, then analyze_wallet_ai (rules-only without a key, OpenAI JSON with rule fallback when keyed). Returns AnalyzeWalletResponse in every case.
  • POST /agent/analyze-wallet — single-turn LangChain AgentExecutor with three StructuredTools (get_wallet_transactions, extract_wallet_features, assess_wallet_risk). The model picks which to call from a natural-language question.
  • Post-processing layer that splits agent output into agent_answer (human-readable), risk_assessment (structured, same shape as ai_analysis), and tool_trace (one-line per tool, no raw JSON dumps).
  • pytest coverage for both routes — including stubbed agents for the schema tests so most of the suite runs without the LLM.

What I’d defend

The architectural decision: keep the fixed pipeline explicitly coded so its behavior is predictable and CI-testable, and let the agent path be the place where the LLM owns control flow. Same services power both, so swapping the mock data layer for a real chain adapter only happens once.

Repository↗ Next case↓
↳ from rules to cryptographic proofs Case 02 — Anonymous messaging via Groth16
CASE / 02 Zero-knowledge circuit diagram FIG.02 · POSEIDON-MERKLE
RoleSolo build
StatusVerifier deployed
DomainCryptography
Year2026
Case 02 / 03 · Applied Crypto Feb 2026 → Apr 2026

Anonymous membership proofs, without revealing a wallet.

A zk-SNARK messaging workflow. A user proves membership in an authorized group without exposing their wallet address — Poseidon-Merkle proofs generated client-side, Groth16 verified on Polygon.

Circom snarkjs Groth16 Poseidon Solidity Polygon

The problem

Most “anonymous” messaging systems still leak the sender’s wallet through the auth path. The goal here was a clean separation: prove the sender is in an allowed set, prove the message belongs to them, and reveal nothing else.

What I built

  • A Poseidon-based Merkle membership proof circuit in Circom, generating proofs efficiently against a moving group root.
  • A snarkjs proof generation pipeline bound to the message hash, so a proof can’t be replayed against a different message.
  • A Groth16 verifier smart contract deployed on Polygon, integrated as the access-control check before any message write.
  • Constraint-size optimizations to keep proof generation tractable in the browser.

What I’d defend

Binding the proof to messageHash rather than relying on the contract to enforce ordering. It pushes correctness into the circuit, which makes the on-chain side smaller and cheaper to audit.

Repository↗ Next case↓
↳ from proofs to a real product Case 03 — A messaging DApp that ships
CASE / 03 · LIVE Screenshot of the messaging DApp DIAO · zk-message-dapp.vercel.app
RoleFrontend + contracts
StatusLive deployment
DomainWeb3 · Product
Year2024 — 25
Case 03 / 03 · Product / Web3 Sep 2024 → Jan 2025

A messaging DApp that actually ships.

A Next.js frontend deployed on Vercel, wired to Solidity contracts on Polygon. Wallet auth, encrypted message transmission, and on-chain storage — held together by a UI that doesn’t make the user think about any of that.

Next.js TypeScript Solidity Polygon Vercel ethers.js

The problem

Web3 messaging products tend to leak the underlying machinery into the UI — gas warnings, signing modals, and chain switching all surface to the user before they’ve done the thing they came to do. I wanted to ship something that felt like a normal messaging app and only invoked the chain when it had to.

What I built

  • A Next.js frontend that handles wallet detection, network checks, and contract calls behind a small, well-typed API.
  • Solidity contracts on Polygon for encrypted message transmission and on-chain storage, deployed and live.
  • An integration layer between frontend and contracts that batches reads, caches what it can, and only signs when state actually changes.

What I’d defend

Keeping crypto-native mechanics out of the user’s way until they’re unavoidable. Hiding chain switching and signing behind a typed adapter so the rest of the app never sees a raw provider.

Open live DApp↗ Repository↗
§ Next

If any of this lines up, reach me at yl9314@nyu.edu — open to backend, AI infra, and fintech internships.

Phone+1 (929) 650-8873
GithubKevinLYT
Siteyitanlee.com