Wallet & venue support
What actually works today, stated as tested. Support is claimed only where it has been exercised; everything else says so.
Venues
GENERATED from the single-source venue capability model in
@synfin/client (getVenueCapabilities), the same
treatment as wallets: Proven with a cited settled swap, or Pending. Router
policy (c), adopted 2026-07-22: every live venue is quote-compared;
EXECUTION routes only to evidence-proven venues (a plan for any other venue
is refused with venue_unavailable), and wiring a plan builder
requires the evidence row. Long-form quirks: docs/VENUE-MATRIX.md in the
repo.
| Venue | Quote | Execute | Payout delivery | Input minimum | Notes |
|---|---|---|---|---|---|
| Tradecraft | Yes | Proven 2026-07-21 | direct-preapproved-only (2026-07-22) | 6 CC (CC input side; the two 2026-07-08 rejects) | The executable venue. Mainnet settlements 2026-07-03 (7 CC), -07-11 (10 CC), -07-12 (10 CC), -07-21 (15 CC, the PUBLISHED-path citation). Payout delivery is DIRECT to preapproved receivers ONLY: the 2026-07-22 run measured NO delivery attempt toward a bare party (the deposit was accepted and the payout never came; escalation standing). A pre-swap receive-preapproval for the payout asset is a hard requirement. Accept latency band 2.15-3.6s (n=5). |
| OneSwap | Yes | Pending | direct-preapproved-only (2026-07-08) | unmeasured (flat ~8.3-9.5 CC network fee sets a practical floor) | Quote-only today; the sized second venue. Devnet mechanics + bounded-safe refund proven 2026-07-08 (deposit matched, output_failed, full 25 CC refund); no completed swap on any network. Blocked on their mainnet 502 recovery; then the decided ~3-5 day build. The proof runs USDCx to CC so our own validator preapproves the CC output side, dodging the payout-preapproval wall. |
| Cantex | Yes | Pending | unmeasured | unmeasured | Quote-only STRUCTURALLY: venue-account raw keys, no wallet-signable deposit step (assertWalletSignable excludes it). Stays quote-only until their delegation / Account admin ships; stated, not implied otherwise. Fees: 5 bps pool + flat CC network fee on top, waived at or above 500 CC. |
| Nightly (Nightly) | No | Pending | unmeasured | unmeasured | Wired quote adapter, DEGRADED since late June 2026 (provider maintenance; every recorded quote marks it unavailable). Execution undesigned. Rename to nightly queued. |
A second executable venue is roadmap, not shipped. The quote is honest
meanwhile: an unavailable venue stays listed with its
rejectionCode.
Wallets
Execution is non-custodial: you bring a WalletAdapter that acts
on the taker's own party. Support is per wallet and answer-as-tested, a wallet
is not listed as working until it has been.
| Wallet | Connect | Execute | Atomic fee | Notes |
|---|---|---|---|---|
| Loop | Yes | Yes | Not yet | Executed end to end via the PUBLISHED adapter on mainnet 2026-07-21: 15 CC -> USDCx through Tradecraft; taker-signed deposit update 12201571efea...0be5, venue accept 1220058b46a72d49fc016642717d29faaebdd911b0fe3f7571eac0ce475a7d69af34 (2.26s), payout 1.883558 USDCx received (wallet-verified, above minReceive 1.845886). Mode B managed-deposit settles as three ledger events by design with the on-ledger executeBefore as the safety. Degrades fee-less: Loop's participant does not yet carry the CIP-0112 package, so the deposit stands and no fee is collected. RUN-2 memo caveat (2026-07-22): the wire memo of the evidence run is unrecoverable (Loop-party transaction, no persisted payloads); the settlement stands as the execute proof; memo enforcement on that run is unknown (the adapter memo-drop bug was found and fixed 2026-07-22). |
| Any PartyLayer / CIP-0103 wallet | Yes | Pending (see notes) | Not yet | Supported through a WalletAdapter on the taker’s party; the reference @synfin/wallet-partylayer builds one in about five lines. Execute is answer-as-tested per wallet through the published package, not assumed from the interface; it flips to true per wallet with a cited mainnet update id. Batch capability depends on that wallet's participant carrying the CIP-0112 package. |
| Self-custodied backend (own participant) | No | Pending (see notes) | Not yet | Archetype 4 (2026-07-22): a Node backend holding its own external party's Ed25519 key on its OWN validator, signing via @synfin/wallet-partylayer/backend (interactive-submission prepare/sign/execute, single-root encoded). Self-hosted is the documented path; Synfin offers no hosted parties. Uniquely, this class controls its own participant packages: installing the CIP-0112 batching package makes it the first candidate for atomic fee collection, still evidence-gated per batchCapable. |
This table is generated from the SDK's capability model (@synfin/client's getCapabilities()): the same source an integrator queries.
A capability is marked collectable only with cited mainnet evidence (the
evidence rule); no wallet claims it today.
The atomic fee, precisely
On-ledger fee collection is flag-gated off today (FEE_COLLECTION_ENABLED is false), so this section describes what happens when it flips, not what happens now.
-
When collecting, the fee rides an atomic CIP-0112 batch
with the venue deposit: one signature, one transaction. This requires the wallet's
participant to carry
splice-util-token-standard-wallet. - If that package is absent (Loop today), the swap degrades to fee-less together, the whole fee set is dropped, never a partial charge, and the deposit still succeeds.
-
The partner path through
@synfin/client's genericWalletAdapterdoes not perform the CIP-0112 batch yet, so even under the flip the partner fee legs are planned and disclosed but not SDK-executed until that adapter gains batch capability.
The mechanics of the split and the disclosure are in How fees work.