Smart contract development
Registry systems, token flows, marketplace mechanics, escrow, role design, upgrade assumptions, tests, release notes, and audit-scope preparation.
Focused on systems where architecture and execution both matter.
I enjoy work that has real constraints: financial-domain correctness, contract security, developer ergonomics, and enough ambiguity that the first job is to make the problem precise.
Tokenization
Applied work around bond issuance, ERC-6909-style multi-token representations, ISIN-linked lifecycle design, settlement flows, and indexer-friendly events.
Security and reviews
Threat-oriented thinking, invariant design, fuzzing, access-control reviews, audit preparation, and practical fixes that make contracts easier to reason about.
Developer tooling
CLI workflows, local development environments, generated documentation, release processes, and tools that reduce operational friction for teams.
Education
Courses, workshops, mentoring, thesis guidance, project reviews, and a student lifecycle model that turns newcomers into independent builders.
Applied cryptography
Practical interest in ZK, identity, account abstraction, privacy-preserving verification, and cryptographic systems when they support usable products.
Problem shape
What makes the work interesting.
I like projects that require a bridge between clean domain modelling and production constraints. In smart contracts this usually means separating responsibilities so that one contract does not accidentally own every rule. In education it means turning broad topics into concrete exercises and projects that students can actually finish.
The best work has a visible artifact at the end: a contract suite, a release, a demo, a course, a reviewed architecture, a useful CLI, or a student project that can keep growing after the semester ends.
Research is interesting when it improves engineering judgement or unlocks a better system. It is not the main output here; building is.