anson — developer building for the open web

shimex tooling

Local OpenAI-compatible provider gateway for Codex Desktop. Routes Anthropic, DeepSeek, Ollama, LM Studio, Cloudflare Workers AI, ClinePass, and other providers through a managed Shimex.app while leaving the original Codex install untouched.

site github

Lit Protocol SDK web3 infra

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-client acted as the public facade, while @lit-protocol/networks supplied 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, and naga-local. The environment file owned configuration, including RPC URL, chain config, endpoints, ABI signatures, services, threshold, and attestation policy, while a shared createBaseModule factory supplied the common API, chain, state, pricing, and contract-management behavior.

Local workflow: that pattern made networks plug-and-play for developers. nagaLocal used an Anvil chain config at 127.0.0.1:8545, HTTP localhost services, a dev private key, and locally generated contract signatures. Its withLocalContext helper could rebuild the module from a generated networkContext.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, dispatchRequests fanned 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 EcdsaSignedMessageShare and FrostSignedMessageShare, converted byte arrays, extracted publicKey and sigType, 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/wasm through unifiedCombineAndVerify. The TypeScript layer owned quorum collection, retry behavior for NoValidShares, shape conversion, and clean return objects with signature, verifyingKey, signedData, recoveryId, publicKey, and sigType. BLS encryption/decryption used the separate blsCombine, blsVerify, and blsDecrypt paths.

Schemes: the signing enum covered ECDSA variants EcdsaK256Sha256, EcdsaP256Sha256, and EcdsaP384Sha384, plus FROST/Schnorr variants including SchnorrEd25519Sha512, SchnorrK256Sha256, SchnorrP256Sha256, SchnorrP384Sha384, SchnorrRistretto25519Sha512, SchnorrEd448Shake256, SchnorrRedJubjubBlake2b512, SchnorrK256Taproot, SchnorrRedDecaf377Blake2b512, and SchnorrkelSubstrate. Ethereum PKP signing defaulted to EcdsaK256Sha256; 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 developer tooling

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-app packaged a Lit Action project as a scaffolded developer workspace. The template separated my-lit-action source, reusable la-utils, a local my-app runner, generated _config credentials, and dist output, with the package binary cloning the template through npx 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.ts into an IIFE, then the postbuild step escaped template literals and re-exported it as litActionCodeString, ready to pass directly into LitNodeClient.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-litaction execution and lit-pkp signing, 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 watch rebuilt 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, called executeJs with sessionSigs and jsParams, 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 using Lit.Actions.runOnce so 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.