Concepts

Endpoints

Receiving endpoints and programmable endpoints; the posture dimensions that decide what each will accept and refuse.

Money enters and rests on endpoints. A receiving endpoint is the door value arrives through; a programmable endpoint is a balance with a character — eight posture dimensions that decide, up front, what it will accept and refuse.

The eight dimensions

Every programmable endpoint publishes its full posture. The names are the wire's own:

receive    internal_only          send       disabled
lifecycle  permanent              drain      no_drain
backing    internal_ledger        purpose    customer_balance
gas        no_gas                 liquidity  no_liquidity

A customer wallet's posture — receives internally, never sends.

The two that decide most: send and receive. An endpoint whose send posture is disabled can never be a transfer source; only an outbound_enabled endpoint sends.

Five templates you can create

customer_balance_internal — a customer wallet: holds and receives internally, never sends. customer_balance_outbound_internal — an internal-ledger balance that receives internally and can initiate outbound transfers. customer_balance_collection_child — a collection child: receives externally and sends onward, the endpoint money moves from.

Two templates carry an explicit program. customer_balance_threshold_internal requires thresholdProgram to name its amount threshold and drain target. customer_balance_transient_collection_child requires transientProgram to name its expiry, parent-collection drain, and operator-review fallback. The create reference owns both complete shapes.

Why it matters

To initiate a transfer you need a source whose send posture is enabled. A plain internal wallet cannot; outbound-internal and collection-child endpoints can. Threshold and transient endpoints drain through their programs rather than acting as transfer sources. The playground's Models atlas shows each template's behavior matrix — which operations it affords, and which it refuses.