Coinbase has no cash-account posture check — a margin-enabled account can turn a spot SELL into a short

[eaitbrahim]

verify_cash_account() refuses a margin-postured account, fails closed on a classification it cannot read, and runs at broker build so no engine path ever sees a broker on a posture keel does not trade. It is implemented only in keel-broker-alpaca (/v2/account's multiplier must be 1) and called only on _build_broker's alpaca branch (keel/commands/_common.py:340).

Coinbase has no equivalent, and Coinbase is the venue this deployment actually trades.

The hole

keel's long-only guarantee is four layers deep — the engine hardcodes Side.BUY for entries, Setup.__post_init__ refuses a non-long setup, engine._long_shaped_ok refuses non-long geometry, and rails 18/19 refuse non-spot instrument shapes. All four are about what keel asks for. None of them is about what the venue does with the ask.

If the underlying account has margin privileges or overdraft enabled at the broker level, a SELL for slightly more than the held quantity does not fail — the venue borrows the difference and opens a short. keel's four layers are all satisfied: it asked for a spot SELL of a long position it believes it holds. The short is created by the venue, out of band, and nothing in keel would know.

This is bay' ma la yamlik (بيع ما لا يملك) reached by a route riba-based reasoning does not cover: "Do not sell what is not with you" (Sunan an-Nasa'i 4613, Abu Dawud 3503). The borrow's interest is a second violation; the sale of what is not possessed is the first and more direct one.

Why it belongs at broker build, not in a rail

_common.py:331-339 already argues this and the argument holds for Coinbase:

Refusing HERE -- rather than at order time -- is what makes it a posture and not a rail: guards are broker-less by design, and a per-order raise could fire on an exit path, where a refusal can trap a position.

A margin-enabled account is a property of the deployment, not of an order. Discovering it mid-exit would be the worst possible moment.

Scope

• verify_cash_account() on the Coinbase adapter, reading the venue's own account classification.
• Called from _build_broker's coinbase branch, same as alpaca's.
• Fail closed on an unreadable classification, matching alpaca. An account keel cannot classify is not an account keel trades.
• Conformance coverage, mirroring alpaca's.
• Establish what Coinbase Advanced Trade actually exposes first. If there is no account-classification endpoint, say so and design against what exists rather than inventing a field — the answer may be that the check has to be an operator attestation (like rail 17 and Venue visibility must be capability-based, not key-presence-based — a read-only key looks identical to a working one #233's trade scope) rather than a venue read. That is a legitimate outcome and should be recorded as one, not worked around.

Related

#372 (the alpaca posture and its reasoning), #233 (the attestation pattern if a venue read turns out impossible), and the sibling issues on SELL-side balance clamping and the orphan-bracket sweep.

[eaitbrahim]

The venue reality, established from the SDK

coinbase-advanced-py is the SDK this deployment runs. There is no spot cash-vs-margin posture field.

Account (accounts_types.py) carries uuid, name, currency, available_balance, default, active, created_at, updated_at, deleted_at, type, ready, hold, retail_portfolio_id, platform. type is the asset class of the account (crypto vs fiat), not a borrowing classification. Portfolio carries name, uuid, type — nothing else.

Every margin-adjacent field in the entire SDK lives in derivative modules:

field	module
initial_margin, available_margin, liquidation_threshold, margin_window_type, is_intraday_margin_killswitch_enabled	futures_types
borrow, loan, margin_flags, is_margin_limit_reached, liquidation_price, liquidation_status	perpetuals_types
leverage, margin_type, long_leverage, is_liquidation, current_liquidation_buffer	orders_types (derivative order fields)
margin_profile_type	rest/futures.py

That is CFM and INTX — futures and perpetuals — not spot.

Why this makes Coinbase structurally different from Alpaca

AlpacaAdapter.verify_cash_account works because Alpaca has one authoritative field: /v2/account's multiplier is the classification, so a readable answer is definitive and "unreadable" is a distinct third state worth failing closed on.

Coinbase has no such field, so "unreadable" and "readable but silent about margin" are the same state. A fail-closed check of Alpaca's shape would refuse every Coinbase deployment — it would stop live trading rather than protect it. Copying the pattern is the obvious move and the wrong one.

What is actually available

Two indirect signals, and neither is a posture answer:

1. GetTransactionSummaryResponse.margin_rate (fees_types.py). Notable because keel already fetches this response — CoinbaseAdapter.get_fee_summary calls get_transaction_summary() and reads only fee_tier and the volume fields. The margin field is already crossing the wire and being discarded.
2. get_portfolios() portfolio type, plus get_portfolio_breakdown's perp_positions / futures_positions.

Both tell you the account has derivative capability somewhere. Neither tells you whether a spot SELL on this portfolio can auto-borrow.

The design this implies

Refute-only, not verify. The adapter raises when the venue shows positive evidence of margin/derivative capability, and otherwise passes — with the passing case documented as "no contradiction found", never "cash posture proven". The residual unknown is then an operator attestation on rail 17's pattern, which is what this issue anticipated.

That splits cleanly into two shippable pieces, the same way #233 did (detect first, attest second):

• Stage 1 — CoinbaseAdapter.verify_cash_account, refute-only, wired into _build_broker beside Alpaca's.
• Stage 2 — the attestation for the residual, where the venue's own evidence can refute an attestation but never grant one.

⛔ What I cannot establish without one read

Whether margin_rate is absent, present-and-null, or present-and-populated on a spot-only retail Advanced Trade account. If it is present-and-null for everyone, treating its presence as evidence would refuse every deployment; if it is absent for everyone, the signal is useless. The SDK cannot answer this — only the account can.

One read-only call, no order, against the deployment's existing credentials:

cd ~/keel && ./.venv/bin/python -c "
from keel.commands._common import _build_broker  # or however the profile builds
" 2>/dev/null

Simpler, using the SDK directly with whatever loads the key today:

cd ~/keel && ./.venv/bin/python - <<'PY'
import json, os
from coinbase.rest import RESTClient
c = RESTClient()  # picks up COINBASE_API_KEY / COINBASE_API_SECRET from the env
s = c.get_transaction_summary()
d = s.to_dict() if hasattr(s, "to_dict") else vars(s)
print("margin_rate present:", "margin_rate" in d, "->", json.dumps(d.get("margin_rate")))
print("portfolio types:", [p.get("type") for p in c.get_portfolios().to_dict().get("portfolios", [])])
PY

Paste the two lines it prints and Stage 1 can be written against the real shape instead of a guess.