Summary
Add first-class support for custom Cashu units in Coco. Today most
flows still assume sat as the default unit, even though units
already appear in parts of the data model and persistence layer.
Goal
Coco should let callers work with non-sat units consistently across
core APIs, React hooks, and persisted wallet/operation state.
API direction
Update public amount inputs so APIs do not accept a bare numeric
amount shape like:
Instead, amount input should support:
amount: AmountLike | { amount: AmountLike; unit: string }A bare AmountLike can preserve the existing default-unit behavior,
while the object form makes the unit explicit.
Internally, Coco should generally treat amount and unit as a coupled
interface/value rather than passing amount and unit around as loosely
related fields. That should reduce confusion and prevent accidentally
mixing a value from one unit with metadata from another.
Scope
- Core: update operation APIs, services, validation, balance/selection
logic, quote handling, and history/event data so unit-aware amounts
are handled consistently.
- React: expose the same unit-aware input model through hooks and
derived balance/operation state.
- Persistence: make sure stored operations, quotes, history, proofs/
tokens, and migrations preserve unit information and remain
compatible with existing sat-based data.
Acceptance criteria
- Existing sat flows continue to work without requiring callers to
pass { unit: 'sat' } everywhere.
- Custom-unit mint/send/receive/melt flows do not silently fall back
to sats.
- Persisted data round-trips amount and unit together across supported
adapters.
- Tests cover both default sat behavior and at least one non-sat
custom unit.
Summary
Add first-class support for custom Cashu units in Coco. Today most
flows still assume
satas the default unit, even though unitsalready appear in parts of the data model and persistence layer.
Goal
Coco should let callers work with non-sat units consistently across
core APIs, React hooks, and persisted wallet/operation state.
API direction
Update public amount inputs so APIs do not accept a bare numeric
amount shape like:
amount: numberInstead, amount input should support:
A bare AmountLike can preserve the existing default-unit behavior,
while the object form makes the unit explicit.
Internally, Coco should generally treat amount and unit as a coupled
interface/value rather than passing amount and unit around as loosely
related fields. That should reduce confusion and prevent accidentally
mixing a value from one unit with metadata from another.
Scope
logic, quote handling, and history/event data so unit-aware amounts
are handled consistently.
derived balance/operation state.
tokens, and migrations preserve unit information and remain
compatible with existing sat-based data.
Acceptance criteria
pass { unit: 'sat' } everywhere.
to sats.
adapters.
custom unit.