Give your agent a passport, a mailbox, and a payment terminal

What it does

Wrap your agent handler with bindufy() and it gains a W3C DID identity, speaks the A2A JSON-RPC protocol on port 3773, and can demand USDC on EVM chains before executing work. The framework inside your handler — whether Agno, LangChain, or your own code — is irrelevant to Bindu. SDKs exist for Python, TypeScript, and Kotlin, all routing through the same gRPC core.

The interesting bit

Most frameworks make you bolt on security; Bindu treats it as transport. Every request runs through mTLS with auto-renewed X.509 certs that embed the agent’s DID as a SAN, OAuth2 via Ory Hydra with scoped bearer tokens where the DID doubles as the client_id, and an Ed25519 DID signature over the request body itself. The project claims no surveyed agent framework ships all three layers out of the box, and they are default-on for the personal agent as of version 2026.21.1.

Key highlights

• Three-layer security stack: mTLS, OAuth2, and DID signatures, each meant to reject attacks the others cannot catch.
• Payments via x402: agents can demand USDC on five pre-configured EVM chains before a handler ever sees the request.
• Polyglot SDKs in Python, TypeScript, and Kotlin; the TypeScript SDK spawns the Python core invisibly in the background so the protocol stays identical.
• Built-in public tunneling and cloud deployment to microVMs without writing a Dockerfile.
• Skills system with public and private catalogs, plus agent-to-agent negotiation for price and SLA upfront.

Verdict

If you are building an agent that must interoperate with other agents, prove its identity, and charge money without writing middleware, Bindu is worth a look. If your agent lives in a single process and never talks to strangers, it is overkill.