LI.FI Portal

<!-- Fixed left rail — composes .panel + the shared .app-rail shell -->
<aside class="panel app-rail portal-rail" data-screen="root" aria-label="Portal navigation">
  <div class="app-rail__screen is-active" data-screen-id="root">
    <header class="app-rail__head">
      <a class="brand-lockup brand-lockup--back">…</a>
      <div class="portal-rail__actions"><!-- theme · bell · .portal-rail__toggle --></div>
    </header>
    <div class="portal-rail__search"><button class="search-trigger">…</button></div>
    <div class="portal-rail__org"><div class="dropdown">…</div></div>
    <div class="app-rail__section portal-rail__nav">
      <nav class="side-nav side-nav--lg">…</nav>
    </div>
  </div>
  <footer class="app-rail__footer portal-rail__foot">…</footer>
</aside>

The root screen is the rail's only .app-rail__screen — the former appearance / theme-edit drills were retired into the Settings view's Theme panel. The head's .portal-rail__toggle (data-action="rail-toggle", wired in portal.js → initPortalRailToggle) flips body.is-rail-mini — a persistent click-toggle PUSH collapse (portal.css → "Collapsed (mini) rail"), not the hover-expand .app-rail--mini.

Unlike the playground rail, the Portal rail keeps a full --panel-radius on all four corners — it has no docked .drawer-handle to mate a squared top-right against.

• Full radius on all four corners. The shared .app-rail squares its top-right so a docked .drawer-handle meets it flush (the playground's minimize notch). The Portal has no handle, so .portal-rail overrides back to --panel-radius — routed through the token so it tracks the corners composer like any .panel.
• Compose, don't re-chrome. Surface / elevation / radius / padding come from .panel + .app-rail; the Portal layer adds only the head / search / org / nav / footer arrangement. A hand-rolled background / box-shadow / border-radius on the rail is drift.
• Collapse is a persistent click-toggle PUSH, not hover-expand. The head's .portal-rail__toggle flips body.is-rail-mini, shrinking --rail-width to --rail-mini (72 px) so the rail and .app-canvas resize in lockstep; the arrow icon rotates 180° and becomes the sole head control. The shared hover-expand .app-rail--mini overlay is deliberately NOT used here — see design/components/navigation.md → App rail (Portal note).
• Nav runs flush. The rail's .panel gutter (24 px) is the only inset — .portal-rail__nav .side-nav drops its own padding so the rows align with the brand lockup and search bar above.
• Nav rows fill the width. Every .side-nav__item is full-width, so each row's hover / active fill spans the same width rather than hugging its label.

CSS: portal.css — search .portal-rail (the radius override + head/search/org/nav/footer layering) and "Collapsed (mini) rail" (the click-toggle collapse). The shared shell is styles.css — search .app-rail.
Markup: portal.html — the <aside class="panel app-rail portal-rail"> block. JS: portal.js → initPortalRailToggle (the collapse toggle).
Spec: CLAUDE.md → "LI.FI Portal — partner console" (Shell section) and "Panel primitive".

<!-- Canonical: title + sub + actions. Sub and actions are optional. -->
<div class="portal-page-head">
  <div>
    <h1 class="portal-page-head__title">Welcome back, Vilen</h1>
    <!-- optional -->
    <p class="portal-page-head__sub">Here's what's moving across your integrations.</p>
  </div>
  <!-- optional -->
  <div class="portal-page-head__actions">
    <button class="btn-secondary btn-with-icon">…</button>
    <button class="btn-primary btn-with-icon">…</button>
  </div>
</div>

• Title is the only required slot — sub and actions are optional. Pick the composition by what the page genuinely needs; don't force an empty sub-paragraph or a one-button actions row to "feel complete." A bare title is the right shape for many sub-pages.
• Pick page header vs entity header by tier, not by content shape — top-level page (Dashboard, Members, Settings, Analytics root) → .portal-page-head; secondary page drilled into from a parent (Integration detail, Analytics → Volume) → .portal-entity-head. The two render differently on purpose: the entity head leads with an avatar + status chip + integrator string because the page is about a specific entity.
• Actions are page-level — the actions slot holds CTAs that scope to the WHOLE page (New integration, Add member, Withdraw fees). Intra-section CTAs (refresh a panel, edit a row) belong in their own panel's header, not here.
• Top breathing room is canvas-level — the space above the header is --canvas-top (Portal scope: 40 px), not a header margin. Don't pad the header itself to fake top breathing; tune the canvas token.
• Bottom breathing room tracks the Spacing composer — header→content margin is calc(--grid-gap-y + --space-8), so it follows whatever vertical rhythm the active theme picked, plus one ladder step for header breathing.

CSS: portal.css — search .portal-page-head.
Tier: page-local tier-3 .portal-* — promotion candidate once a 2nd consumer appears.
Spec: CLAUDE.md → "LI.FI Portal — partner console".

<!-- Canonical: eyebrow + avatar + title + status chip + sub + actions.
     Every slot beyond avatar + title is optional. -->
<!-- optional · parent-section label (sibling) -->
<div class="portal-entity-head__eyebrow">Integrations</div>
<div class="portal-entity-head">
  <span class="avatar avatar--initial avatar--rounded portal-entity-head__avatar" data-initial="oneinteg10"></span>
  <div class="portal-entity-head__id">
    <div class="portal-entity-head__title-row">
      <h1 class="portal-entity-head__title">oneinteg10</h1>
      <!-- optional · status chip -->
      <span class="chip chip-success chip--sm">…</span>
    </div>
    <!-- optional · mono integrator-string + copy -->
    <div class="portal-entity-head__sub">…</div>
  </div>
  <!-- optional · right-aligned actions -->
  <div class="portal-entity-head__actions">…</div>
</div>

• The eyebrow marks a secondary page — Integration Detail sits under Integrations, so the header carries a parent-section eyebrow (Integrations) in the brand accent (--accent-primary). It names the parent only — the current page is the title below, so there's no repeated leaf. Top-level entity pages omit it.
• Status chip belongs on the title row — it qualifies the name (Active / Paused / Archived), so it sits inline next to the title, not in the sub-line.
• The integrator-string is copyable — pair the mono string with the copy button; it's the value engineers paste into the SDK.
• Actions are secondary — view / edit use .btn-secondary; the page's primary action (e.g., Withdraw fees) lives in the Overview metric cards on the page below, not here.
• Minimal form keeps avatar + title — the identity (avatar + name) is what makes this "entity" header rather than a page header. If you'd render only a title, reach for .portal-page-head instead.

CSS: portal.css — search .portal-entity-head.
Tier: page-local tier-3 .portal-* — promotion candidate once a 2nd consumer appears.
Spec: CLAUDE.md → "LI.FI Portal — partner console".

<div class="portal-empty__art" aria-hidden="true">
  <span class="portal-empty__card portal-empty__card--back"></span>
  <span class="portal-empty__card portal-empty__card--front">
    <span class="portal-empty__check"><svg>…</svg></span>
    <span class="portal-empty__lines"><i></i><i></i></span>
  </span>
  <span class="portal-empty__fab"><svg>…</svg></span>
</div>

• Purely decorative — mark the whole illustration aria-hidden="true"; the heading + description carry the meaning.
• Always pair it with copy + a primary CTA — the illustration sets the tone, the "New integration" button does the work.
• Don't reuse it as a generic blank slate — it's specific to the integrations empty state (cards + add affordance). Other empty states get their own art or a plain .portal-placeholder.

CSS: portal.css — search .portal-empty__art (the .portal-empty / .portal-steps block).
Tier: page-local tier-3 .portal-* — promotion candidate once a 2nd consumer appears.
Spec: CLAUDE.md → "LI.FI Portal — partner console".

<span class="portal-usage">
  <span class="portal-usage__bar">
    <span class="portal-usage__fill" style="width: 60%;"></span>
  </span>
  <span class="portal-usage__text"><strong>6</strong> / 10 integrations</span>
</span>

<!-- At capacity — add --limit (danger tone) -->
<span class="portal-usage portal-usage--limit">…</span>

The bare .portal-usage__bar is reused standalone as the onboarding progress bar — see .portal-onboard-bar.

• Mirror the fill width to the fraction — __fill width % must equal N / M, or the bar lies about usage.
• Use --limit only at capacity — it's the "you can't add more" signal, paired with a disabled "New integration" CTA and a contact-support note.
• Keep the label terse — "N / M integrations". Plan detail belongs in the sibling .portal-meta-row__note, not the pill.

CSS: portal.css — search .portal-usage.
Tier: page-local tier-3 .portal-* — promotion candidate once a 2nd consumer appears.
Spec: CLAUDE.md → "LI.FI Portal — partner console".

<div class="network-row" data-family="svm" data-state="adding">
  <div class="network-row__head">
    <img class="avatar avatar--sm avatar--rounded network-row__icon" src="avatars/chains/solana.svg" alt="">
    <div class="network-row__body">
      <div class="network-row__name">SVM <span class="chip chip-warn chip--sm">Required</span></div>
      <span class="network-row__sub">Solana · enter a Solana address</span>
    </div>
    <div class="network-row__trail"><!-- Add btn · Added chip + kebab · or "Adding" --></div>
  </div>

  <!-- grid-rows 0fr→1fr drawer; form padding lives on __form, NOT __drawer-inner -->
  <div class="reveal network-row__drawer"><div class="reveal__inner">
    <div class="network-row__form">…</div>
  </div></div>
</div>

Rendered by integration-wizard.js → networkRowHTML(); the form by walletFormHTML().

• data-state drives the three states — empty / added / adding. The accent rim + open drawer are pure CSS off [data-state="adding"]; no JS toggles a class.
• Form padding lives on .network-row__form, not __drawer-inner — the collapsing grid item must stay bare so 0fr hits true zero (CLAUDE.md → grid-rows accordion bug). The form is the padded child.
• Required vs Optional via tone chips — .chip-warn for required families (EVM, SVM), .chip-neutral for optional (Bitcoin, Sui, Tron, L2).
• Rows compose design-system primitives — .avatar, .chip, .btn-*, .input, .field-label-row, .field-valid; the Portal classes only add the row framing + drawer.
• Page-local today — one consumer (the wizard). Promote to styles.css when a second "add accounts" flow appears.

CSS: portal.css — search .network-row.
JS: integration-wizard.js → networkRowHTML() + walletFormHTML() (the Wallets step).
Tier: page-local tier-3 — promotion candidate once a 2nd consumer appears.
Spec: CLAUDE.md → "LI.FI Portal — partner console".

<span class="input-counter">
  <input class="input" type="text" maxlength="64">
  <span class="input-counter__count" aria-hidden="true">15 / 64</span>
</span>

/* at the cap: add --over to the count */
<span class="input-counter__count input-counter__count--over">64 / 64</span>

• The count is JS-bound — the consumer rewrites the text and toggles --over as the field changes. The CSS only positions + colours; the maxlength attribute does the real capping.
• aria-hidden on the count — it's a redundant visual of the maxlength constraint, so it's hidden from the accessibility tree.
• Distinct from .field-counter — that one rides the .field-label-row beside the label (a quiet caption). Reach for .input-counter when the count should overlay the field; reach for .field-counter when it should sit in the label row.
• Page-local today — renamed from .iwiz__* June 2026; single consumer (the wizard name field). Promote to styles.css when a 2nd consumer appears.

CSS: portal.css — search .input-counter.
JS: integration-wizard.js → basicsBody() (the name field).
Sibling: .field-counter (styles.css) — the label-row counter.
Tier: page-local tier-3 — promote to styles.css when a 2nd consumer appears.
Spec: CLAUDE.md → "LI.FI Portal — partner console".

<!-- portal.html — the thin shell -->
<div class="modal-overlay" id="integrationWizardModal" hidden>
  <div class="modal panel modal--lg iwiz" role="dialog" data-integration-flow></div>
</div>

// integration-wizard.js — renderStep() fills it per step:
flow.innerHTML =
    '<div class="iwiz__top">' + stepper + '</div>'          // stepper
  + '<div class="modal-body">' + head + stepBody + '</div>'   // head + body
  + '<footer class="iwiz__footer">…</footer>';                  // footer

The four steps

Footer model

Wallets also surfaces a block-reason (e.g. "SVM wallet required") left of Back until both required wallets are added. The width is .modal--lg (--w-12, 576 px).

• Composed end-to-end from design-system primitives — .steps--circles-inline, .list--cards, .option-card, .alert, .input, .network-row, .input-counter, .chip-*, .btn-*. The .iwiz__* classes are only flow-specific layout glue.
• No top-right close — Cancel (footer, bottom-left) is the dismiss affordance on every step; ESC and overlay-click also close. The stepper spans the full top edge.
• Uniform footer — Cancel left, primary right; Back stacks left of the primary on the middle steps only (not first, not the terminal API-key step).
• Back is wizard navigation — it steps to the previous step (a deliberate divergence from the modal "back returns to Main" two-tier contract; a connect-style wizard is the depth-bearing flow that carve-out allows).
• Finish emits an event — lifi:integration-created { name, string, wallets }; the host (portal.js) persists the integration and opens its Detail page.

JS: integration-wizard.js (window.LifiIntegrationWizard.initWizard); the shell is portal.html → #integrationWizardModal, opened via [data-action="open-integration-modal"].
CSS: portal.css — search .iwiz (the flow-specific layout glue).
Spec: CLAUDE.md → "LI.FI Portal — partner console".

<!-- Per-chain cell: avatar + name + native amount -->
<span class="portal-fee-chain">
  <img class="avatar avatar--circle" src="avatars/chains/optimism.svg" style="--avatar-size: var(--space-28);">
  <span>
    <span class="portal-fee-chain__name">Optimism</span>
    <span class="portal-fee-chain__amt mono">2.4081 ETH</span>
  </span>
</span>

<!-- Relative-magnitude bar in the Collectable cell -->
<span class="portal-fee-bar"><span class="portal-fee-bar__fill" style="width: 43%;"></span></span>

• Bar = relative magnitude — scale each fill to the largest chain balance, not to the grand total. It's a "which chains hold the most" scan cue.
• Native amount under the fiat — the mono __amt line shows the token amount; the fiat headline sits in the Collectable column.
• Tabular-nums on every numeric cell — fiat, native, transaction counts all align on the decimal.
• Reuse the chain avatar via .avatar — never a Portal-specific mark; the chain logos are the design-system /avatars/chains set.

CSS: portal.css — search Detail · Fees tab (the .portal-fees-* / .portal-fee-* block).
Tier: page-local tier-3 .portal-* family — promotion candidate once a 2nd consumer appears.
Spec: CLAUDE.md → "LI.FI Portal — partner console".

<div class="panel portal-panel portal-metric">
  <div class="portal-metric__head"><svg>…</svg><span>Collectable fees</span></div>
  <div class="portal-metric__value">$1,284.32</div>
  <button class="btn-primary btn-block">Withdraw fees</button>
</div>

<!-- "Good" value tone + a note instead of a button -->
<div class="portal-metric__value portal-metric__value--ok">99.98%</div>
<span class="portal-metric__note">Last 30d uptime</span>

• One action or one note per card — a .btn-block (Withdraw / Request) or a __note, never both.
• Footer pins to the bottom — margin-top:auto on .btn-block keeps a row of mixed-height cards aligned.
• Tone shifts ink, not weight — --ok only recolours the value to --success; size and weight stay constant (per the state-via-ink rule).

CSS: portal.css — search .portal-metric.
Tier: page-local tier-3 .portal-* — promotion candidate once a 2nd consumer appears.
Spec: CLAUDE.md → "LI.FI Portal — partner console".

<!-- Base row — single chain -->
<div class="portal-barlist">
  <div class="portal-barlist__row">
    <span class="portal-barlist__label"><img class="avatar avatar--circle" …>Ethereum</span>
    <span class="portal-barlist__val">$18.4M</span>
    <span class="portal-barlist__track"><span class="portal-barlist__fill" style="width: 100%;"></span></span>
  </div>
</div>

<!-- Route row — avatar-stack + chain1 + arrow ICON + chain2 -->
<div class="portal-barlist__row portal-barlist__row--route">
  <span class="portal-barlist__label">
    <span class="avatar-stack avatar-stack--xs"><img …><img …></span>
    <span class="portal-route__name">Ethereum</span>
    <svg class="portal-route__arrow-icon">…</svg>
    <span class="portal-route__name">Arbitrum</span>
  </span>
  <span class="portal-barlist__val">$6K</span>
  <span class="portal-barlist__track">…</span>
</div>

• Fill is proportional to the max — width = round(value / maxValue × 100)%, with a small floor (6–10%) so the smallest bar stays visible.
• Single chain vs route — single-chain breakdowns (volume / revenue by chain, fee types) use the base row; a from→to route uses --route (an .avatar-stack + chain1 + arrow icon + chain2 at bumped type).
• Arrow is the icon, not the glyph — route rows use the Lucide arrow-right SVG (.portal-route__arrow-icon), never a → text character.
• Rows are sorted descending — the largest value (100% fill) leads.

CSS: portal.css — search .portal-barlist (route variant: .portal-barlist__row--route).
Renderers: portal-render.js — barlistChain() (single chain) · dashboard-routes (route rows).
Tier: page-local tier-3 .portal-* — promotion candidate once a non-Portal surface needs a ranked bar breakdown.
Spec: CLAUDE.md → "LI.FI Portal — partner console".

<!-- Progress bar reuses the usage-meter track -->
<span class="portal-usage__bar portal-onboard-bar"><span class="portal-usage__fill" style="width: 60%;"></span></span>

<ul class="portal-checklist">
  <li class="is-done"><span class="portal-check"><svg>…</svg></span>Create integration</li>
  <li><span class="portal-check portal-check--todo"></span>Send a test transaction
    <a class="link-arrow" href="#">Resume →</a></li>
</ul>

• Done = filled check + line-through; todo = outlined disc, full-ink label. The shape carries state, not colour alone.
• Resume link on the next actionable step — only the first incomplete step gets the inline .link-arrow.
• Pair with the progress bar — the .portal-onboard-bar fill should equal done / total so the bar and the ticks agree.

CSS: portal.css — search .portal-checklist.
Tier: page-local tier-3 .portal-* — promotion candidate once a 2nd consumer appears.
Spec: CLAUDE.md → "LI.FI Portal — partner console".

<div class="portal-wallet-group">
  <div class="portal-wallet-group__head">
    <div>
      <div class="portal-wallet-group__title">EVM Networks <span class="chip chip-neutral chip--sm">1 default · 1 override</span></div>
      <p class="portal-wallet-group__desc">Default address …</p>
    </div>
  </div>

  <!-- Default row -->
  <ul class="list list--cards"><li class="list-item">…</li></ul>

  <!-- Per-chain overrides nest beneath a connector line -->
  <div class="portal-wallet-overrides">
    <ul class="list list--cards"><li class="list-item">…</li></ul>
  </div>
</div>

• Default first, overrides nested — the default address is a top-level .list-item; per-chain overrides indent under .portal-wallet-overrides so the precedence reads visually.
• One group per virtual machine — EVM / SVM / Bitcoin each get their own .portal-wallet-group; the count chip states "N default · M overrides".
• Empty ≠ broken — an unconfigured VM shows .portal-wallet-empty with an add CTA, not a zero-row table.
• Rows are design-system primitives — compose .list.list--cards + .list-item; the Portal classes only add the group framing.

CSS: portal.css — search .portal-wallet-group (the Detail · Wallets tab block).
Tier: page-local tier-3 .portal-* — promotion candidate once a 2nd consumer appears.
Spec: CLAUDE.md → "LI.FI Portal — partner console".

<!-- portal.html — the thin shell -->
<div class="modal-overlay" id="withdrawFeesModal" hidden>
  <div class="modal panel modal--lg wfee" role="dialog" data-withdraw-flow></div>
</div>

<!-- any trigger — chain attr optional (omitted → largest remaining balance) -->
<button class="btn-primary btn-sm" data-action="open-withdraw-modal"
        data-withdraw-slug="ledger-live-swap" data-withdraw-chain="arbitrum">Withdraw</button>

// withdraw-fees.js — renderStep() fills the shell per state:
flow.innerHTML = { select, signing, success, error }[state.step]();

The four states

Data & consequences

Width is .modal--lg (--w-12, 576 px), fixed across the flow; height tweens per state via the modal's built-in fluid resize. Gas scales with the batch: base + perToken × selected, seeded per chain. Earned figures (fees KPI, lifetime, txn counts) deliberately never shrink.

• Composed end-to-end from design-system primitives — .screen-header, .chip-avatar, .checkbox, .list--cards, .alert + .spot-icon + .spinner, .detail-list, .error-detail, .spot-icon-4xl, .btn-*. The .wfee__* classes are only flow-specific layout glue.
• Chain-scoped by design — one chain is one transaction; the header pill names it. The Fee Management trigger omits the chain attr and resolves the integration's largest remaining balance.
• Zero selection shifts ink, not weight — the hero value drops to --text-faint and the CTA disables; type structure never changes.
• Signing locks rows but keeps them legible — only the checkboxes dim (their own :disabled treatment); the selection rim and content stay at full ink.
• Success settles into the data layer — recordWithdrawal subtracts per token, every collectable surface rebinds live via 'change', drained chains disable their Withdraw action, and the audit log gains a "Just now" entry. Earned figures don't shrink.
• Cancel aborts the signature (the sim timer is cleared) and returns to select with the picks intact; Escape and overlay-click close from any state.
• The sim always succeeds — hold ⌥ on the CTA (or call LifiWithdrawFees.failNext()) to demo the error path; Try again then succeeds.

JS: withdraw-fees.js (window.LifiWithdrawFees.init); the shell is portal.html → #withdrawFeesModal, opened via [data-action="open-withdraw-modal"] (emitted by portal-render.js on the Detail Fees + Fee Management tables).
CSS: portal.css → "WITHDRAW-FEES MODAL — .wfee".
Data: partner-orgs-data.js → getWithdrawable / recordWithdrawal (the in-memory withdrawn-fee ledger).
Spec: CLAUDE.md → "LI.FI Portal — partner console".

<!-- the batch trigger — data-withdraw-all flips the shared opener to the batch;
     slug + disabled + gas line stamped per-integration by portal-render.js -->
<button class="btn-primary btn-block btn-with-icon portal-fees-withdraw"
        data-action="open-withdraw-modal" data-withdraw-all
        data-withdraw-slug="ledger-live-swap">Withdraw all fees</button>

<!-- the ORG-WIDE trigger (Fee Management) — no slug; legs span every integration -->
<button class="btn-primary btn-block btn-with-icon portal-fees-withdraw"
        data-action="open-withdraw-modal" data-withdraw-all-org>Withdraw all fees</button>

// withdraw-fees.js — the batch states share the single-flow shell:
flow.innerHTML = { bselect, brun, bsummary }[state.step]();

<!-- org scope only — a quiet integration label precedes each leg cluster -->
<div class="wfee__leg-group">
  <span class="avatar avatar--initial avatar--xs avatar--rounded">LS</span>
  <span class="wfee__leg-group-name">Ledger Live Swap</span>
</div>

<!-- one leg row (run / summary) — the checkbox slot becomes the status mark -->
<div class="list-item wfee__leg wfee__leg--done">
  <span class="list-item__lead wfee__token-lead">
    <span class="wfee__leg-mark wfee__leg-mark--done"><!-- check --></span>
    <img class="avatar avatar--circle" src="avatars/chains/ethereum.svg">
  </span>
  <span class="list-item__body">
    <span class="list-item__title">Ethereum</span>
    <span class="list-item__desc wfee__leg-status">0x4be1…9c2af</span>
  </span>
  <span class="list-item__trail wfee__leg-trail">$18,420 · explorer link</span>
</div>

The three states

Leg statuses

Data & consequences

Stop semantics: zero landed legs → back to bselect with the picks intact (nothing happened); ≥ 1 landed → bsummary with the partial receipt. Gas is per leg (base + perToken × tokens, seeded per chain); the select state totals it and the trigger's caption announces the signature count up front.

• Checklist, not stepper — .steps--circles-inline fits a fixed set of abstract stages; here the steps ARE the chains (variable count, each carrying avatar + amount + status), failure states are first-class, and the list doubles as the running receipt.
• One signature per chain — EVM has no cross-chain atomic withdraw, so the batch is N sequential transactions. The count is announced up front: the hero sub-line, the meta note, and the trigger's gas caption all carry it.
• Landed legs settle immediately — recordWithdrawal fires per leg, so the surfaces behind the overlay drain chain by chain. A later Stop never rolls an earlier leg back; you can't unsign a landed transaction.
• Failure pauses, never aborts silently — the batch holds at the failed leg with Retry / Skip chain / Stop batch. Skipped and failed balances stay collectable; re-run anytime.
• Stop is state-aware — with zero landed legs it returns to bselect with the picks intact; with ≥ 1 it exits through the partial summary so the receipt is never lost.
• Chain granularity here, token granularity there — batch rows pick whole chains; per-token selection stays in the single-chain flow (the per-chain Withdraw buttons).
• Two scopes, one engine — integration-scoped (the Detail Fees card, data-withdraw-all + slug) and org-wide (Fee Management, data-withdraw-all-org): legs are integration × chain pairs from getWithdrawableAllOrg, grouped by integration in the checklist, keyed slug|chain (a chain alone isn't unique org-wide). The chrome and copy follow the scope; the engine doesn't care.
• The summary disc grades the outcome — success / warn (partial) / danger (nothing withdrawn); Contact support appears only when a leg failed.
• Demo — hold ⌥ on the CTA to fail the second leg (the paused state then shows beside a landed one); LifiWithdrawFees.failNext() fails whichever signature resolves next.

JS: withdraw-fees.js (window.LifiWithdrawFees.openAll integration-scoped / .openAllOrg org-wide; the engine is startBatch / advanceBatch / stopBatch); the Detail trigger is stamped per-integration by portal-render.js → renderDetail, the Fee Management trigger per-org by applyFeesWithdrawAll.
CSS: portal.css → "Batch legs" + .wfee__leg-group (under the .wfee block).
Data: partner-orgs-data.js → getWithdrawableAll / getWithdrawableAllOrg / recordWithdrawal.
Spec: CLAUDE.md → "LI.FI Portal — partner console".