anson
developer · building small, sharp things for the open web.
projects
-
Lit Protocol SDK
Long-term maintainer of Lit Protocol's JavaScript SDK and network integration layer, spanning early beta networks through Datil and Naga/v8. Supported mission-critical SDK infrastructure powering 1.6M decentralized wallets and securing $400M+ in managed value across the Lit network.
Architecture: the SDK was an Nx/pnpm monorepo of published
@lit-protocol/*packages.@lit-protocol/lit-clientacted as the public facade, while@lit-protocol/networkssupplied Naga and Datil network modules, RPC and chain context, request builders, response handlers, and state managers.Network modules: each Naga environment was modeled as a swappable module export, such as
@lit-protocol/networks/naga-mainnet,naga-test,naga-dev,naga-staging, andnaga-local. The environment file owned configuration, including RPC URL, chain config, endpoints, ABI signatures, services, threshold, and attestation policy, while a sharedcreateBaseModulefactory supplied the common API, chain, state, pricing, and contract-management behavior.Local workflow: that pattern made networks plug-and-play for developers.
nagaLocalused an Anvil chain config at127.0.0.1:8545, HTTP localhost services, a dev private key, and locally generated contract signatures. ItswithLocalContexthelper could rebuild the module from a generatednetworkContext.json, so after spinning up Anvil, local contracts, and local Lit nodes, the same SDK client APIs could target the local network without changing application logic.Request flow: the client was handshake-first. It fetched fresh node connection state, live threshold, and, when required by the network module, node attestation data for release verification before trusting the node set. The selected network module then created typed requests,
dispatchRequestsfanned work across nodes and resolved once enough successful responses were collected, and the module normalized signatures, decrypted payloads, Lit Action results, PKP state, pricing, auth, and key-set context back into developer-facing APIs.Share combining: PKP signing and Lit Action execution each had their own parser before crossing into the cryptographic combiner. PKP responses filtered successful object-shaped shares, normalized
EcdsaSignedMessageShareandFrostSignedMessageShare, converted byte arrays, extractedpublicKeyandsigType, and combined only after the threshold was still satisfied. Lit Action signatures were grouped by signature name, combined per group, and could drop faulty spare shares while the remaining set stayed above threshold.Crypto boundary: final threshold math was delegated to
@lit-protocol/wasmthroughunifiedCombineAndVerify. The TypeScript layer owned quorum collection, retry behavior forNoValidShares, shape conversion, and clean return objects withsignature,verifyingKey,signedData,recoveryId,publicKey, andsigType. BLS encryption/decryption used the separateblsCombine,blsVerify, andblsDecryptpaths.Schemes: the signing enum covered ECDSA variants
EcdsaK256Sha256,EcdsaP256Sha256, andEcdsaP384Sha384, plus FROST/Schnorr variants includingSchnorrEd25519Sha512,SchnorrK256Sha256,SchnorrP256Sha256,SchnorrP384Sha384,SchnorrRistretto25519Sha512,SchnorrEd448Shake256,SchnorrRedJubjubBlake2b512,SchnorrK256Taproot,SchnorrRedDecaf377Blake2b512, andSchnorrkelSubstrate. Ethereum PKP signing defaulted toEcdsaK256Sha256; Bitcoin exposed K256 ECDSA, Schnorr, and Taproot paths.My work: my contributions lived across those layers: keeping network constants and contract exports aligned with live Datil and Naga environments, carrying API compatibility through network migrations, maintaining auth, payment, wrapped-key, and key-management integrations, and tightening e2e/artillery coverage for Naga production, test, staging, dev, and local workflows.
-
Decentralised JS Code (Lit Action) Playground
Built and maintained a scaffolding and testing tool for Lit Actions: decentralized JavaScript functions executed inside TEEs through Lit's V8/Deno runtime. Simplified the workflow for writing JavaScript action logic, packaging it correctly, and testing execution flows before deploying to the Lit network.
Architecture:
create-la-apppackaged a Lit Action project as a scaffolded developer workspace. The template separatedmy-lit-actionsource, reusablela-utils, a localmy-apprunner, generated_configcredentials, anddistoutput, with the package binary cloning the template throughnpx create-la-app@latest.Runtime bridge: Lit Actions were authored as TypeScript but had to execute as JavaScript strings inside Lit's decentralized V8/Deno action runtime. The build step bundled
my-lit-action/lit-action.tsinto an IIFE, then the postbuild step escaped template literals and re-exported it aslitActionCodeString, ready to pass directly intoLitNodeClient.executeJs.Setup flow: the CLI handled the awkward first mile: minting and funding a PKP, creating capacity delegation auth signatures, generating session signatures for
lit-litactionexecution andlit-pkpsigning, listing PKPs, and uploading the compiled action string to IPFS. That gave developers a repeatable path from empty folder to executable Lit Action.Test loop:
bun run watchrebuilt whenever action code, utilities, or the client runner changed, then executed the local app. The app loaded the compiled action string, read the PKP config, calledexecuteJswithsessionSigsandjsParams, and printed both the returned response and node logs, making a remote TEE execution model feel like a local edit-run-debug cycle.Action utilities: the included helpers encoded common Lit Action patterns: deriving the PKP Ethereum address, preparing native transfers and contract calls, signing transaction hashes through
Lit.Actions.signAndCombineEcdsa, and usingLit.Actions.runOnceso only one node broadcast the signed transaction while the decentralized action still produced a combined signature.My work: my contribution was turning an easy-to-misuse JS-string workflow into a practical developer tool: TypeScript ergonomics for the Lit Action globals, a scaffolded project layout, an auth/session/PKP setup CLI, hot reload, deployable IPFS output, and transaction examples that showed how Lit Actions could coordinate signing and execution from inside the TEE runtime.