Atomic batch is an engine capability of every core: open and revoke multiple streams in one all-or-nothing call. On the escrow rail a batch open is ONE on-chain transaction through the sealed vault entrypoint; on control and card it is journaled with full rollback. A partial failure leaves zero orphan allowances.
The published 2.0.0 wire client does not yet expose a batch() call — the owner-api ships budgets, streams, ticks, credentials, receipts, revocation, sessions and close in owner-api/1.0.0. Batch (and subscribe) land on the wire surface in a future minor version per the versioning promise (rule 18: additive change, minor bump, CHANGELOG entry). This page documents the semantics you will get, because they are engine law today, not a proposal.
Until then: open streams sequentially and treat the budget's Σ inequality as your safety net — the engine refuses any open that would break the funded ceiling, so a partial fan-out can always be revoked cleanly.
If any stream in a batch cannot open — a cap that would break the budget's Σ inequality, an invalid service node, a backend refusal — the WHOLE batch fails and no stream exists afterwards. There is no partial success to clean up, on any rail.
Two notes carried from the engine surface:
holdbackSeconds isper-stream verified-engine material; dialed streams open individually. Passing it inside a batch fails closed rather than dropping the dial.
budget.stream(...) —caps, rates, meta.