Skip to content
View Sanketbhandari's full-sized avatar
  • Synergetics.ai
  • Karwar, India
  • 21:44 (UTC +05:30)
  • LinkedIn in/web3sanket

Block or report Sanketbhandari

Block user

Prevent this user from interacting with your repositories and sending you notifications. Learn more about blocking users.

You must be logged in to block users.

Content in all repositories owned by your account will be closed.
Maximum 250 characters. Please don’t include any personal information such as legal names or email addresses. Markdown is supported. This note will only be visible to you.
Report abuse

Contact GitHub support about this user’s behavior. Learn more about reporting abuse.

Report abuse
Sanketbhandari/README.md

Sanket Bhandari

Software Architect at Synergetics.ai. Backend and platform work, with a specialty in custody: who is allowed to move value, and how you prove it. For a few years that meant humans holding keys. Now it means agents holding their own wallets, which is a harder version of the same problem.

Before Synergetics, wallet and key-custody engineering at NetObjex / Kresus Labs.

Selected work

Multi-tenant platform foundation — Synergetics Postgres row-level security with composite tenant foreign keys, one sanctioned bypass path rather than none, and a transactional outbox so events and state commit together. Where isolation lives is the whole decision. Put it in application code and one missed WHERE clause defeats it; put it in the database and you have to design the escape hatch on purpose.

Regulation compiled into the system, not written into a policy — Synergetics Outbound messaging that has to satisfy CAN-SPAM, CASL, GDPR, DPDP and PECR at once. Rather than a compliance document nobody reads, jurisdiction is a routing decision in code: consent model, retention, and unsubscribe handling resolve per recipient before anything sends. Legal constraints are easier to keep when the system can't violate them.

Agent systems in production — Synergetics Multi-agent workflows on Claude, MCP tool servers, and the parts that make them safe to run: retrieval that has to cite its source, a fact-guard that blocks any figure not present in the source of record, and approval gates enforced server-side rather than in the UI. Most of the design work in agent systems is deciding what the model isn't allowed to do alone.

Agent identity and wallets — Synergetics How an agent proves who it is and what it may spend: ERC-8004 registries, W3C DIDs and verifiable credentials, ERC-4337 smart accounts, ERC-6551 token-bound accounts so the identity NFT owns the wallet. A2A covers agent-to-agent task delegation and MCP covers tools; the trust layer sits under both, and that's the part nobody has settled.

Account abstraction and key custody — Kresus Labs An ERC-4337 wallet: smart accounts, account factory, and the paymaster service behind gasless and sponsored transactions. Then the threshold-signing relay for the vault, coordinating multi-party signing rounds so no single node held a whole private key. Worth being precise about what that buys you. It removes the point where a complete key exists. It does not remove custodial risk: hold t of n shares and you have custody, and the attack surface moves to whatever authorises the signing.

APIs and SDKs — Kresus Labs 20+ backend services across wallet, vault and marketplace, and three client SDKs so internal and partner teams could integrate without touching chain-level code. The SDK work taught me more about API design than the APIs did — you find out what your interface really costs when someone else has to live inside it.

What I'm working through

Things I don't have clean answers to yet:

  • An ERC-6551 token-bound account isn't an ERC-4337 account. The 6551 spec never mentions 4337. So if an agent's identity NFT owns its wallet, something still has to implement validateUserOp before a bundler will touch it, and I'm not convinced that belongs in the TBA itself.
  • Session keys are the piece agent wallets actually need: scoped, time-boxed, spend-limited authority instead of handing an agent an unbounded key. Working through ERC-7715, ERC-7710 and the 7579 module story now.
  • ERC-8004's reputation registry is the part I trust least. Anything permissionless and reputational attracts Sybils, and the early on-chain data suggests it already has.
  • EIP-7702 shifted the account-abstraction picture more than most people have absorbed. Still forming a view on where it leaves 4337 for existing EOA users.

How I work

I keep a decision log. Context, the options I had, what I picked, what it cost, and what would make me change my mind. The one for my current platform work is 128 entries. When a decision gets superseded I add a new entry pointing back rather than editing the old one, so the log stays honest about what I believed at the time.

I lean on Claude heavily for the mechanical half of the work and review everything that ships. Building agent systems for a living has mostly taught me where not to trust one.

Working with

TypeScript, Node, Fastify, Express · Postgres, row-level security, transactional outbox · Docker, GitHub Actions · Solidity, Hardhat, Slither, solhint · Ethereum, Base, Polygon PoS · Anthropic Claude API, MCP, A2A

Elsewhere

sanketbhandari22@gmail.com · linkedin.com/in/web3sanket

Pinned Loading

  1. architecture-notes architecture-notes Public

    Decision records, design notes and a running work log.

  2. agent-payments-reference agent-payments-reference Public

    An AI agent with its own identity, wallet and bounded spending authority. Composed from ERC-8004, ERC-6551, ERC-4337 and x402.

    Solidity