Bindu: Identity, Communication, and Payments for AI Agents in a Single Wrapper

What Bindu Handles So Agent Developers Do Not Have To

Building an agent that can communicate with other agents, prove who it is, and charge for its work requires assembling several independent infrastructure pieces: a DID library for cryptographic identity, an OAuth flow for access control, a payment middleware for micropayments, and an HTTP layer that speaks whatever protocol the rest of the agent ecosystem uses.

Bindu packages all of that behind one function call. The README describes the value proposition directly: you wrap your handler with bindufy(), and a few seconds later the agent is online with its own cryptographic identity, speaking the A2A protocol, and ready to collect USDC payments on any EVM chain before it does work.

The handler itself stays minimal. The framework inside the handler, whether Agno, LangChain, CrewAI, or a custom implementation, does not matter to Bindu. The protocol and identity layer are the same regardless of what framework processes the messages.

SDKs are available for Python, TypeScript, and Kotlin. All three share the same gRPC core, so an agent written in Python and one written in TypeScript will have the same DID identity format and speak the same A2A wire protocol.

Installing Bindu and Deploying a First Agent

Bindu requires Python 3.12 or later and uv, the fast Python package manager from Astral. The install command is:

uv add bindu

For development work on Bindu itself rather than consuming it as a library:

git clone https://github.com/getbindu/Bindu.git
cd Bindu
uv sync --dev

Running the examples requires an API key for at least one LLM provider: OPENROUTER_API_KEY, OPENAI_API_KEY, or MINIMAX_API_KEY.

The quickstart in the README shows how thin the integration surface is. The developer creates an agent using their preferred framework, passes it to bindufy() along with a configuration dictionary, and the agent goes live:

from bindu.penguin.bindufy import bindufy
from agno.agent import Agent
from agno.models.openai import OpenAIChat
from agno.tools.duckduckgo import DuckDuckGoTools

agent = Agent(
    instructions="You are a research assistant.",
    model=OpenAIChat(id="gpt-4o"),
    tools=[DuckDuckGoTools()],
)

config = {
    "author": "[email protected]",
    "name": "research_agent",
    "description": "Research assistant with web search.",
    "deployment": {"url": "http://localhost:3773", "expose": True},
    "skills": ["skills/question-answering"],
}

The expose: True flag opens an FRP tunnel so the agent is reachable without port forwarding. The agent is then live at localhost:3773 and speaks the A2A JSON-RPC protocol. Calls come in via POST with a message/send method, and the client polls tasks/get with the taskId until the state reaches completed.

The Three Security Layers That Ship by Default

Most agent frameworks treat security as the developer's problem. The README describes Bindu's approach differently: security is transport, not configuration.

When an A2A request arrives at a Bindu agent, three middleware layers fire before the handler sees the request body. The README documents each one:

The first layer is mTLS. Each agent receives an X.509 certificate from a Smallstep step-ca instance, with the SAN field set to the agent's DID, a 24-hour TTL, and automatic in-process renewal. This layer answers whether the socket itself is encrypted and mutually authenticated.

The second layer is OAuth2 via Ory Hydra. The caller presents a bearer token with roughly a one-hour TTL, validated through Hydra's token introspection endpoint. This layer answers whether the caller is authorized to perform the requested operation at the current time.

The third layer is a DID signature. Every request body is signed with an Ed25519 key, and the signature is carried in the X-DID-Signature header. This layer answers whether the JSON body was authored by the DID it claims to be from.

As of release 2026.21.1, all three layers are on by default on the operator's personal agent. The README explains why three layers are present rather than one: each fails safe in a way the others cannot, so a broken cert does not mean an unsigned body can pass, and a stolen OAuth token does not mean a mismatched DID is accepted.

A2A Protocol and DID Identity

The A2A protocol is a JSON-RPC standard for agent-to-agent communication. Bindu implements the same protocol that other agents in the ecosystem already use, which means a Bindu agent can receive calls from any A2A-compatible client. The README points to the A2A project at github.com/a2aproject/A2A as the protocol source.

Each agent gets a Decentralized Identifier (DID) assigned at startup. The DID is cryptographic: it ties to the X.509 certificate's SAN field and the Ed25519 signing key. An agent's identity is verifiable without a central authority.

Calling a Bindu agent from curl illustrates the protocol directly:

curl -X POST http://localhost:3773/ \
  -H 'Content-Type: application/json' \
  -d '{
    "jsonrpc": "2.0",
    "method": "message/send",
    "id": "<uuid>",
    "params": {
      "message": {
        "role": "user",
        "kind": "message",
        "parts": [{"kind": "text", "text": "Hello"}],
        "messageId": "<uuid>",
        "contextId": "<uuid>",
        "taskId": "<uuid>"
      }
    }
  }'

The response is asynchronous. The client sends the request, then polls tasks/get with the same taskId until the task state transitions to completed. This is the standard A2A task lifecycle.

x402 Micropayments and the Payment Middleware

The payment layer uses the x402 protocol, an open standard from Coinbase for HTTP-native micropayments on EVM chains. The README references it at github.com/coinbase/x402. A Bindu agent can require payment in USDC on any EVM-compatible chain before executing work.

From the dependency list in pyproject.toml, x402 version 2.3.0 or later and web3 version 7.15.0 or later are required, along with eth-account at version 0.13.7. The cdp-sdk (Coinbase Developer Platform) is also a dependency.

Release 2026.22.4 is described in the release notes as the settle-first release, indicating that payment settlement happens before task execution rather than after. This is a meaningful design choice: an agent using settle-first is paid before doing work, reducing the risk of completing tasks for which payment fails.

The examples directory includes a premium-advisor/ example, suggesting a concrete pattern for gating premium functionality behind payment.

Dependency Weight and What That Means for Deployment

Bindu's pyproject.toml lists a substantial dependency set. Core runtime dependencies include uvicorn, Starlette, pydantic, loguru, rich, orjson, httpx, and cryptography. The security stack adds pyjwt and pynacl. The payment stack adds x402, web3, eth-account, and cdp-sdk. Database support adds SQLAlchemy with asyncio, asyncpg, and alembic for migrations. A Redis dependency is also present.

The telemetry stack is notable: opentelemetry-api, opentelemetry-sdk, opentelemetry-exporter-otlp, and sentry-sdk are all included. Unlike free-code, which strips telemetry, Bindu includes it as a first-class feature for production monitoring.

The TypeScript SDK note in the README is worth understanding: it spawns the Python core in the background. This means a TypeScript project that uses Bindu still requires Python 3.12 installed on the host. Python is not optional for TypeScript users; it is a hidden runtime dependency.

For teams who need only A2A communication without payment support, the full Bindu installation is heavier than necessary. The payment-related dependencies (web3, eth-account, cdp-sdk) contribute significant weight, and they cannot be deselected through a standard install.

Alternatives and Maintenance Status

The A2A protocol itself is defined in the A2A project repository and can be implemented without Bindu. A team that wants A2A compatibility without the payment layer, the three-layer security model, or the DID identity infrastructure could implement the JSON-RPC interface directly in any HTTP framework.

For the payment layer specifically, the x402 protocol has its own reference implementations. Teams already invested in a particular web framework might choose to integrate x402 and DID-based identity independently rather than adopting Bindu as a full framework.

The closest conceptual comparison is to agent communication middleware like LangChain's agent-to-agent patterns, but those do not include identity or payment layers. Bindu's design is opinionated: it ships all three concerns together rather than letting each be assembled separately.

The last push to the repository was on 2026-09-06. Releases are versioned with a date-based scheme (2026.22.4, 2026.20.7). The license is Apache-2.0. The project is hosted under the GetBindu organization on GitHub.

Editorial conclusion

Bindu is a good fit for teams building agent-to-agent systems where security cannot be an afterthought: the three-layer model is on by default rather than optional. The framework works with Agno, LangChain, CrewAI, and custom handlers, so it does not require rewriting an existing agent. The main cost is the heavy dependency tree: the pyproject.toml pulls in SQLAlchemy, asyncpg, Redis, web3, eth-account, and a full OpenTelemetry stack, which adds significant weight to any deployment. The TypeScript SDK spawns the Python core in the background, meaning Python is a runtime requirement even in TypeScript projects. For teams who only need A2A communication without the payment layer, Bindu's dependency footprint is larger than the task requires. The last push was on 2026-09-06 under an Apache-2.0 license.

Frequently asked questions

Official sources

1. GetBindu/Bindu on GitHub
2. Issues
3. Project website
4. README
5. Releases