Joined Lit Protocol as team member #5, including the CEO and CTO, and helped build its developer platform across SDKs, authentication, applications and infrastructure.

What I changed at Lit Protocol

I worked remotely for Lit Protocol, a San Francisco startup, as Lead Software Engineer, leading the SDK team. My work connected the developer-facing SDKs and applications to the authentication, key-management and operational infrastructure underneath them.

The core repository is now private. This account draws on my retained contribution history and the public releases, pull requests and technical writing that remain available. It describes my contributions to a team effort; it does not reproduce private code.

Two terms, briefly

PKP means Programmable Key Pair: a cryptographic key managed by Lit’s distributed network. It can act as a wallet’s signing key, with permissions controlling who or what may use it.

Lit Actions are JavaScript programs run on Lit’s network. They can check conditions and request operations such as signing with a PKP. A useful mental model: the PKP is the key; an authorised Lit Action can supply rules for using it. Lit’s introduction.

From distributed infrastructure to usable APIs

Lit coordinates signing, encryption and programmable keys across a network of nodes. Developers need an API they can build an application around, even as those network interfaces change.

I helped establish the SDK's TypeScript/Nx foundations and maintained its integration layer across successive network generations. My changes added network support, session-permission tooling, wrapped-key APIs and integration tests. For example, I added Naga mainnet integration and tests, and APIs for updating wrapped keys with version information.

What changed: application developers gained access to new network and key-management capabilities through the SDK, with integration coverage to check those paths.

Lit announced SDK v2 in March 2023 and Naga mainnet with SDK v8 in January 2026. These were company releases; my work was part of the engineering behind the developer experience.

From familiar sign-in to a programmable wallet

A major part of my developer-experience work was connecting PKPs to authentication methods: existing wallets, Google and Discord sign-in, and WebAuthn/passkeys. Authentication establishes who the user is; permissions determine what that identity can do with the key. How PKP authentication works.

My changes included Google-backed PKP session signing, WebAuthn registration and minting helpers, and passing requested permission scopes through the WebAuthn flow. I also added an optional Discord sign-in callback so an application could handle the login URL instead of always being redirected immediately.

Around those flows, I worked on the PKP client, authentication helpers, session handling, examples and interactive documentation. This connected sign-in to creating or selecting a key and using it through the SDK.

What changed: developers gained reusable flows for connecting familiar sign-in methods to programmable wallets, with control over the login experience and the permissions they requested.

From manual setup to a repeatable development loop

Building a Lit Action involves more than writing JavaScript: the code needs to be packaged, configured, authenticated and executed through the network.

I built and maintained GetLit workflows for creating, building, testing, watching and deploying actions. Later scaffolding work added an executable CLI, clearer logs and response handling, and fixes for transaction setup. Contract tooling provided generated interfaces, method exports and network configuration. Runnable guides, configuration examples and interactive documentation helped developers exercise authentication, wallet and payment flows.

What changed: developers had a repeatable path from an empty project to running and debugging an action. Contract and network details were available through tooling, and examples could be run alongside the documentation.

I also wrote a guide to minting programmable keys and assigning signing permissions.

From underlying services to usable applications

I contributed to Explorer applications, network switching, statistics and contract-worker APIs. Supporting work included faucet flows, contract configuration and error reporting.

On the service side, I added WebAuthn support, PKP authentication routing, request validation and API documentation to relay tooling. My history also includes early gateway backend work and DID/JWS identity integration.

What changed: users and developers could inspect and interact with the network through applications, while authentication and relay services handled more of the steps needed to reach the underlying capabilities.

From isolated failures to operational visibility

I built monitoring components spanning a metrics SDK and service, PostgreSQL/Prisma-backed execution logs, Prometheus formatting and network-health dashboards. Dashboard changes included network-specific views, configurable time intervals and rolling success rates. Related worker changes addressed timeouts and cleanup.

What changed: teams gained a way to record executions and examine network behaviour over time, including failures and success rates.

I also worked on test infrastructure: repeatable account and configuration setup, long-running workloads, package-consumer examples, compatibility checks and load-test tooling. These provided ways to exercise changes beyond a single local example. They do not establish a measured reduction in incidents or test time.

Maintaining inherited wrapped-key infrastructure

I took over maintenance of the existing wrapped-key infrastructure after a handover from a departing engineer. The system already included API routes, Terraform configuration, IAM permissions, Lambda handlers and DynamoDB integration. I maintained that existing system; I did not design or build it from scratch.

My responsibility: ongoing maintenance of the inherited service. This was separate from my SDK work on network integrations and wrapped-key APIs.

From agent access to explicit permissions

In Vincent, I added a Viem-compatible programmable-key account integration and contributed to smart-account and permission integration for Vincent 2.0. That covered registration identifiers, agent ownership lookups and SDK permission flows.

In the scaffolding SDK, I added test-state isolation across files and networks, with configuration and application-version handling. Starter templates made that setup available to developers building tools and policies.

What changed: applications gained SDK support for identifying agents and managing their permissions. Developers could exercise different configurations with isolated, reusable test state.

Additional development work

My retained history also includes Rust client work, an iOS demonstration using Swift and Rust FFI, and a Python wrapper upgrade. I treat these as development and prototype contributions here: the available branch history does not establish that my specific changes shipped in a public release.

Verify my contributions

Lit's historical executive summary reported more than $400M in digital assets and 1.6M wallets and signers. These are company-reported network figures, not my individual performance metrics.

To ask about my core contributions at Lit Protocol, you can contact: