Capability matrix
What exists across the Core SDK, React SDK, and MCP; what is implemented, partial, stubbed, dev-only, or missing; and what the available proof actually establishes.
This is the honest cross-surface map of Capxul. It answers two different questions for every capability:
- Does the surface exist and work?
- How strongly has that behavior been proven?
Those questions are deliberately separate. A shipped-proven negative contract
can prove that a method always returns NOT_IMPLEMENTED; it does not make
the advertised operation available.
Checked against committed code
Last verified on 2026-08-10 against the final L1 implementation tree
a0c2c501953522ea1ce435a607c2e7b3779bf535 and the governed
docs/campaigns/architecture-arc/L1-LAYER-RECEIPT.json. The fixed public package train is
1.2.3; Capxul PR #887 is the exact published consumer. Environment-specific live claims remain
limited to the named headed, durable, PostHog, CI, and staging evidence in that receipt. A
registered MCP tool or exported React hook is not by itself proof that the underlying operation
works live.
Historical Sub-account APIs are removed
The Core and React SDKs now expose the accepted Permission model. The historical Sub-account storage, contracts, hooks, and tools no longer exist. Use Organization Permission methods and hooks for bounded authority.
How to read availability
- Implemented — a non-stub code path exists with type or hermetic behavioral proof. This does not automatically mean a production deployment or provider journey is live.
- Partial — some documented variants work and other variants reject or
return
NOT_IMPLEMENTED. - Stubbed — the public surface exists, but the operation deliberately
returns
NOT_IMPLEMENTED. - Dev-only — executable only through development signer, fixture, faucet, or hermetic mode; not an available live-mode capability.
- Missing — no equivalent public surface exists.
MCP exposes auth, Account, identity, handle, payee, Organization, relationship, destination, and test-faucet tools. It does not expose the SDK money-execution, Permission, or Organization payment methods.
Repository evidence states remain shipped-proven, shipped-unproven,
in-flight-proven, in-flight-unproven, accepted-not-implemented,
proposed, broken-or-disputed, and superseded. Each state below applies
only to the narrow boundary named in that row.
The 2026-07-18 candidate Reference receipt
proves the guarded public React journey on canonical staging: OTP, a ready
personal Account, Organization creation and Owner/Account/treasury reads, the
Base Sepolia faucet +10, txless -1/+1 allocation, and sign-out. That is
in-flight-proven integration evidence. It does not prove deployed master, a
production tier, MCP, or Capsule UI.
Product alignment contract
This table is the shared planning surface for frontend and infrastructure work. It translates the evidence-heavy reference tables below into the product action each team can take now. A frontend story should cite one of these rows; when an infrastructure boundary changes, the same pull request must update the detailed evidence row and this planning row.
- Build now — the frontend can ship the named bounded experience against an implemented Core and React SDK contract. Environment-specific live claims still require the named receipt.
- Build behind capability gate — the frontend can build loading, success, failure, and unavailable states, but must not present the end-to-end journey as available until the alignment gate closes.
- Blocked — the product promise depends on a missing or deliberately stubbed operation. Mockups and discovery can proceed; a shippable success path cannot.
| Product capability | Roadmap signal | Frontend direction | Infrastructure and backend direction | Alignment gate |
|---|---|---|---|---|
| Auth, profile, personal account | Build now | Build sign-in, profile, onboarding, account-readiness, and balance journeys. Keep environment-specific failures explicit. | Preserve the auth, identity, lifecycle, and balance contracts; close fresh named live email and account receipts per target environment. | Core and React contract tests stay green, plus a fresh live receipt for any environment advertised as live. |
| Organizations and actor-scoped work | Build now | Build Organization creation and the proven Owner, role, Account, and treasury reads; keep unproven actor-scoped families explicitly gated. | Preserve the canonical-staging Reference receipt while keeping MCP development-gated and release proof separate. | The candidate receipt closes the named React staging journey only; deployed-master and other families keep their own gates. |
| Destination metadata | Build now | Ship saved bank, mobile-money, and wallet destination management. Never label metadata storage as cash-out availability. | Maintain metadata CRUD and validation independently from settlement-provider work. | Metadata CRUD has target-environment proof; settlement remains governed by the provider cash-out row. |
| Personal payments | Build behind capability gate | Build personal pay, list, and detail around supported recipient forms; show unsupported Organization and destination variants before submission. | Close the partial Core branches deliberately and connect execution evidence without treating a pending record as settlement. | The chosen actor, recipient form, environment, and terminal outcome have an explicit receipt. |
| Provider cash-out and offramp settlement | Blocked | Do not present bank, mobile-money, or provider settlement as available. | Define and implement a provider dispatch and reconciliation contract. | A real sandbox provider call reaches a terminal state and reconciles through an authenticated webhook. |
| Organization Permissions | Build behind capability gate | Build Permission configuration and assignment against the Core and React contracts. | Keep Permission execution bound to the authenticated signer and selected Organization. | The selected environment has an activated Permission contract and live execution proof. |
| Payment documents | Build behind capability gate | Build only behind explicit capability gates or add the missing React projections first. | Add intentional React coverage and produce live evidence where required. | The required React contract exists and the selected live journey has its own receipt. |
| Unavailable product reads and actions | Blocked | Treat product payment cancellation, activity, Organization audit log, and offramp quote/status as unavailable—not empty, loading, or successful. | Replace each NOT_IMPLEMENTED negative contract with a real implementation and proof before changing the product state. | The stub is removed, behavioral proof passes, and the detailed row is upgraded from its negative contract. |
| Headless React UI | Build behind capability gate | Reuse the exported headless UI where it fits, but gate each component by the underlying capability row instead of treating the export as proof. | Keep component exports synchronized with React hooks and their Core boundaries; do not use UI existence to upgrade backend status. | Every enabled component points to an implemented underlying row and carries the same environment boundary. |
| Cards and a components package | Blocked | Discovery and design may continue, but do not plan implementation against an SDK or package that does not exist. | Land an accepted product contract, tracker, package boundary, and implementation before publishing a frontend integration commitment. | Current decision and tracker exist, the public package/API is implemented, and its proof boundary is documented. |
The signal is scoped to the capability, variant, actor, and environment named in the row. It is not a single release badge for all of Capxul. The detailed tables below remain the source of truth for exact methods, hooks, MCP registration, and evidence boundaries.
Identity and Accounts
| Capability | Core SDK | React SDK | MCP | Actual boundary |
|---|---|---|---|---|
| Email OTP, session, sign-out | Implemented: auth.canSendOtp, signIn, verifyOtp, getSession, signOut | Implemented: auth hooks | Implemented: auth.requestOtp, verifyOtp, status, signOut | shipped-proven at contract/hermetic boundaries and for the exact published 1.2.3 Capxul consumer recorded by the L1 layer receipt; other environments require their own receipt. |
| Identity, profile, current user | Implemented: identity.loadCurrent, currentUser.get, me.get, me.depositInstructions | Implemented: useCapxulProfile, useCapxulCurrentUser | Implemented: me.get, me.depositInstructions | shipped-proven mapping and hermetic behavior; no universal live-deployment claim. |
| Account lifecycle and readiness | Implemented: canonical identity actor and nested Readiness | Implemented: useCapxulIdentity, useCapxulAuth().retry | Implemented: account.status, ensureReady, deploymentStatus | shipped-proven for the L1 identity-machine/React contract and exact published Capxul J1/J2 consumer boundary; EIP-1193 deployment remains a negative scaffold. |
| Personal balance | Implemented: accounts.read | Implemented: useCapxulAccountBalance | Implemented: account.balance | shipped-proven mapping/hermetic read and in-flight-proven staged 0 -> 10 USD readback; provider/deployment state remains environment-specific. |
| Testnet faucet | Internal: _internal.accounts.fund | Dev-only: useCapxulAccountFund | Dev-only: faucet.fundTestnet | Development capability with an in-flight-proven Base Sepolia +10 transaction on canonical staging. The backend returns NOT_IMPLEMENTED when the faucet is disabled. |
| Personal onboarding | Internal composition: identity Profile write → ReadSession → EnsureAccount | Implemented: useCapxulAuth().completePersonal | Missing | shipped-proven for the renderer-neutral facade and exact published Capxul J1 persistence/relogin boundary; no separate public Core onboarding controller or MCP projection. |
| Organization onboarding | Internal composition: Profile → account claim → CreateOrganization | Implemented: CapxulOnboardingController + useCapxulAuth | Missing | shipped-proven for the renderer-neutral controller/facade and exact published Capxul J2 immutable recovery/durable Organization boundary; no MCP projection. |
See the Core authentication methods, Account methods, and React auth hooks for exact signatures.
Organizations and scoped work
| Capability | Core SDK | React SDK | MCP | Actual boundary |
|---|---|---|---|---|
| Organization create and list | Implemented: createOrg, orgs, org(id) | Implemented: useCapxulCreateOrg, useCapxulOrgs, useCapxulOrg | Dev + faucet gated: absent in live; create/list register in development | Core/React are shipped-proven hermetically and in-flight-proven for fresh exact-id create/readback on canonical staging. MCP remains development-only. |
| Organization treasury and Account | Implemented: treasury, account.get, profile.* | Implemented: treasury and Organization Account hooks | Missing | shipped-proven SDK mapping and in-flight-proven Account/treasury reads on canonical staging; MCP has no equivalent tool. |
| Members and roles | Implemented: members, roles, invite, assign/remove member, deploy roles | Implemented: member and role hooks | Dev + faucet gated: absent in live; reads/writes register in development | Founder Owner membership and Owner role/permissions are in-flight-proven on canonical staging. Other member/role writes and MCP live mode are unproven. |
| Organization audit log | Stubbed: org(id).auditLog | Stubbed: useCapxulOrganizationAuditLog | Missing | shipped-proven negative contract: every Core/React call returns NOT_IMPLEMENTED. |
| Actor address book | Implemented: personal and Organization addressBook.* | Implemented: address-book hook family | Dev + faucet gated: absent in live; personal/Organization tools register in development | shipped-proven Core/React mapping and hermetic tests; MCP is development-only. |
| Actor requests and inbox | Implemented: personal and Organization requests.* and inbox.* | Implemented: requests and inbox hooks | Dev + faucet gated: absent in live; request/inbox tools register in development | This is the actor-scoped request system, not the receivables aggregate below. |
| Organization Permissions | Implemented: permissions.create/change/assign/revoke/replace/list/get | Implemented: Permission mutation and query hooks | Missing | Core and React execute the accepted Permission contract. Environment activation and live execution require separate proof. |
| Organization payments | Implemented: payments.pay, payments.payBatch | Implemented: Organization payment mutation hooks | Missing | Core and React submit Permission-bound Organization payments. Environment activation and live value movement require separate proof. |
See the Core Organization methods and React Organization hooks.
Recipients, payments, and money movement
| Capability | Core SDK | React SDK | MCP | Actual boundary |
|---|---|---|---|---|
| Handles and saved payees | Partial: handles and payee create/get/resolve work; some target variants are stubbed | Missing dedicated hooks | Implemented: handle and payee tools | Destination and relevant capxulUserId target forms return NOT_IMPLEMENTED. |
| Destination metadata | Implemented: add/list/remove bank, mobile-money, and wallet metadata | Implemented: destination hooks | Dev + faucet gated: absent in live; destination tools register in development | shipped-proven Core/React metadata storage. Metadata is not a settlement rail. |
| Direct personal pay, list, get | Implemented: signer-backed personal payment execution and reads | Implemented: pay/list/get hooks | Missing | Core and React own the current payment execution path. Live value movement requires environment-specific proof. |
| Commitment claim, cancel, redirect | Implemented: createCommitment, claim, cancel, redirect | Implemented: Commitment mutation hooks | Missing | Core and React own the recoverable Commitment lifecycle. Live value movement requires environment-specific proof. |
| Bank or mobile-money settlement | Missing | Missing | Missing | accepted-not-implemented. Storing destination metadata does not create a cash-out rail. |
| Offramp quote and status | Stubbed: offramp.quote, offramp.status | Stubbed: offramp hooks | Missing | shipped-proven negative contracts: both calls return NOT_IMPLEMENTED. |
| Activity feed | Implemented: activity.list, activity.get, activity.annotate | Implemented: activity query and annotation hooks | Missing | Core and React read the movement-backed activity projection. |
| Payment documents | Implemented: verify and render | Missing hooks | Missing | Core/backend mappings have hermetic proof. React and MCP projections are absent. |
The instant-send guardrail
An instant, irreversible payment is permitted only to a validated recipient. An unvalidated recipient must go through a recoverable Commitment that can be cancelled or redirected. The SDK enforces this boundary; it is not a defect for an unsafe direct-send attempt to be rejected.
See the Core payment methods, React payment hooks, and payment guide for the exact contracts.
UI packages and future surfaces
| Capability | Core SDK | React SDK | MCP | Actual boundary |
|---|---|---|---|---|
| Headless React UI | Not a Core concern | Implemented: renderer-neutral authentication and onboarding controllers; legacy money slot components remain deleted | Missing | Apps own DOM, styling, forms, routes, media, provider cash-out UI, and product analytics. |
@capxul/components package | Missing | No package with this name | Missing | Do not claim this package exists. Treat it as proposed or accepted-not-implemented only with a current decision/tracker. |
| Cards | Missing | Missing | Missing | No SDK or backend surface was found. Roadmap/proposed only when backed by a current tracker. |
Provider cash-out
The current SDK has no payout or withdrawal method. Destination metadata does not create a settlement rail. Provider cash-out remains unavailable.
Known product gaps
The matrix makes these gaps explicit rather than hiding them behind a typed surface:
- multi-chain Organization treasury token balances;
- Organization payment history and export;
- personal activity aggregates;
- React projections for payees and payment documents;
- MCP coverage for Organization treasury, onboarding, audit logs, activity, Permissions, Organization payments, and live signer-backed execution;
- the receivables front door and the human-approval payment workbench, both demolished in #1144 (ADR-0018 P9 + money dispositions) and rebuilt on the requests inbox and Openfort-iframe signing;
- production bank/mobile-money settlement and a real provider cash-out rail.
Verification rule
For a capability you intend to ship:
- open the exact Core SDK method, React hook, or MCP tool family;
- distinguish Implemented, Partial, Stubbed, Dev-only, and Missing before reading its evidence state;
- require the named integration or live receipt for the environment and journey you intend to rely on;
- treat a type, generated page, registered tool, fixture, or green hermetic test as proof only at its stated boundary.