beep .. beep ..
We are building Ychain in public.
The current beta is intentionally narrow:
- Bitcoin first
- multi-tenant API
- SQLite
- one Node.js process
- external signing
- no private key custody
Financial infrastructure gets better when the constraints are explicit.
The Ychain beta keeps workers in-process.
Deposit monitoring, webhook delivery, and transaction checks run inside the same Node.js service.
Tradeoff:
- less operational complexity now
- no distributed workers yet
- migration path later
Early infra should be debuggable.
Ychain is MCP-first because agents should not integrate money systems like humans do.
They need tool-shaped primitives:
- create payment request
- inspect balance
- read deposit state
- prepare transaction
- verify webhook
Money rails should be callable and auditable.
UTXO isolation is a security boundary.
Coin selection cannot be "find spendable outputs."
It has to be:
- tenant-scoped
- wallet-scoped
- unspent
- unlocked
- confirmation-aware
The wrong UTXO is not a bug. It is a financial incident.
Multi-tenant Bitcoin infrastructure has one unforgiving rule: tenant A must never touch tenant B's money.
In Ychain that means tenant scope is not just auth.
It has to exist in wallets, addresses, deposits, UTXOs, ledgers, webhooks, and idempotency keys.
Autonomous systems will need money permissions before they need financial autonomy.
The useful primitives are not flashy:
- spending limits
- settlement states
- ledgers
- scoped API access
- external signing
That is where agent money rails start.
Idempotency keys are not a nice-to-have in financial APIs.
If a client retries a POST, it must not create duplicate:
- payment requests
- broadcasts
- ledger transfers
In Ychain, idempotency is tenant-scoped.
Retries should be boring.
@RoundtableSpace Working on the boring but important parts of agent money infrastructure.
Payment states, tenant isolation, idempotent writes, and webhook reliability.
Not flashy.
But if AI agents are going to move money, these are the parts that need to be correct.
@BitcoinMagazine The interesting part is not just that Bitcoin can be used to buy a home.
It is that large-value settlement starts to look different when money movement becomes programmable.
That is where the infrastructure story begins.
@BitcoinMagazine This is where things get interesting. Once AI agents can hold and move Bitcoin, the next question becomes infrastructure: who sets the rules, how limits are enforced, and how every payment stays auditable.
Agent money needs more than a wallet layer.
@RenzoAI The missing piece is not “agent wallets.” It is the infrastructure around them: permissions, limits, ledgers, settlement states, audit trails, and safe transaction flows.
AI agents do not just need to hold crypto. They need reliable money rails.
@gaspardlezin This is the important shift.
Payment companies are no longer competing only on rails.
They are competing on the layers around money movement:
identity, risk, fraud, data, compliance, and programmable access.
The future payment stack is less a network-
financial infrastructure.
@QuackAI_AI@ZetaChain Exactly.
Agent payments should not mean “AI can spend freely.”
They need programmable boundaries:
budgets, permissions, vendor rules, risk limits, and audit trails.
Autonomy only works when the money movement is constrained by policy.
We chose SQLite for the Ychain beta.
Not because it is the final architecture.
Because early infrastructure benefits from:
- one-server deployment
- simple backups
- fewer moving parts
- faster iteration
Postgres HA can wait until the product earns that complexity.
Ychain beta does not hold private keys.
The API prepares a PSBT.
The customer signs externally.
The API validates and broadcasts the signed transaction.
That is the right default for early money rails:
useful infrastructure without platform custody.