SteamKit
In productionThe security and throughput problems here are the same ones a trading desk has: hold credentials no operator should see, drive thousands of authenticated sessions without tripping rate limits, and keep the whole surface behind a boundary that fails closed.
SteamKit is the internal platform behind a marketplace trading desk. The domain is Steam item trading, but the engineering problems are the ones any automated desk runs into: credentials that must never be readable by the people using them, thousands of concurrent authenticated sessions that have to look legitimate to a hostile upstream, and an audit trail good enough to reconstruct any position after the fact.
Bookkeeping. The account is the core unit. Every account carries its own dedicated proxy, its own session state, and its own ledger of acquisitions and disposals. Operators can pull a guard code to complete an action without the platform ever handing them the underlying secret, which is the same separation Arbiter applies to signing keys.
Automation. Runs are driven against pre-configured, isolated browser sessions with proxy rotation handled by the platform rather than by the operator. A run that fails partway through leaves the ledger consistent, because the accounting is the source of truth and the automation is just a client of it.
Security. The entire surface sits behind a VPN-only boundary with OIDC in front of it. Inside that boundary, the database enforces row-level security, so a compromised service account still cannot read rows it was never scoped to. The default posture is closed: a component that cannot prove its identity gets nothing.
What transfers. The parts we reuse for trading and on-chain clients are the credential isolation model, the run accounting, and the fail-closed access boundary. The marketplace it happens to talk to is the least interesting thing about it.