[$250] Unable to Assign Company Cards to Admin in New Expensify (Chase and American Express Feeds). "The card is already assigned to a user in another workspace" Error message.

[m-natarajan]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number:
Reproducible in staging?: Needs Reproduction (Blocked, Unable to reproduce with other Bank company cards)
Reproducible in production?: Needs Reproduction
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @PedroEspinoza1999
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. Opened the Workspace in New Expensify.
2. Navigated to the Company Cards settings.
3. Selected the American Express feed and attempted to assign a card to the workspace admin.
4. Received the error: "Fetch API Cannot Load."
5. Repeated the same process on the Chase feed.
6. Received the same error: "Fetch API Cannot Load."
7. Logged into Expensify Classic and assigned the American Express card to the same admin successfully.

Expected Result:

The admin should be able to assign company cards to herself from both the Chase and American Express feeds in New Expensify without errors.

Actual Result:

The assignment fails in New Expensify with the error message "Fetch API Cannot Load."

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari

Screenshots/Videos

The screenshots for the issue are in Slack thread

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022060507729025505952
• Upwork Job ID: 2060507729025505952
• Last Price Increase: 2026-05-29

[MelvinBot]

Proposal

What is the root cause of that problem?

There are two distinct errors in this report and they have different root causes:

1. "The card is already assigned to a user in another workspace" — this is a client-side false positive, not a backend rejection. The string is defined at src/languages/en.ts:5482 and set in exactly one place: the pre-flight check in src/pages/workspace/companyCards/assignCard/ConfirmationStep.tsx:111-117 that runs before assignWorkspaceCompanyCard calls the backend. The AssignCard API is never sent. That matches the reporter's observation that Classic works while NewDot fails — Classic has no equivalent client-side guard.

The guard calls isCardAlreadyAssigned. For direct feeds like Chase (oauth.chase.com) and Amex Direct (oauth.americanexpressfdx.com) — see isDirectFeed — the domain filter is bypassed and the check scans every WORKSPACE_CARDS_LIST_<domain>_<feed> Onyx collection key cached on the client. Two specific things make this fragile:

• The identifier passed in is encryptedCardNumber ?? cardName (ConfirmationStep.tsx:113). When the encrypted number is missing, it falls back to the masked display name.
• isMatchingCard matches on either encryptedCardNumber or a normalized cardName. So any stale or duplicated cards_<domainID>_<feed> entry from another workspace that shares a similar masked label (e.g. CHASE INK - 1234) triggers the guard. This dovetails with [$250] Chase Direct Connection in New Expensify breaks, duplicates feeds, and fails to consistently assign cards across multiple workspaces #92092 (Chase feeds being duplicated) and [$250] Assign Card silently fails for domain-level card feeds (e.g., Chase) due to missing adminAccess Onyx key #86277 (Chase domain-level cards misbehaving).

2. "Fetch API Cannot Load" — this string does not exist anywhere in src/. It is a browser-native console message (Chrome/Safari emit it for CORS / mixed-content / blocked-origin fetch failures). The most likely emitter in this flow is getCompanyCardBankConnection, which forces the production API host for Amex (forceProductionAPI = bank === CONST.COMPANY_CARDS.BANK_CONNECTIONS.AMEX) and opens the URL via window.open. On staging/dev that produces a cross-origin popup which can hit CORS. Chase opens a third-party oauth.chase.com URL with similar potential. App catches the corresponding Failed to fetch at src/libs/Middleware/Logging.ts:110-113.

Investigation details & data flow

Trigger path for error 1:

1. Admin clicks Confirm in AssignCard flow.
2. ConfirmationStep.submit() computes cardIdentifier = encryptedCardNumber ?? cardName.
3. isCardAlreadyAssigned iterates all cached WORKSPACE_CARDS_LIST_* collection keys. For direct feeds it bypasses the feedDomainID !== domainOrWorkspaceAccountID filter.
4. isMatchingCard returns true on either an encrypted-number equality or a normalized cardName equality.
5. Match → setCardError('workspace.companyCards.cardAlreadyAssignedError') and an early return. Backend AssignCard is never called — consistent with the report.

The same cross-workspace exclusion is also present in the card selection step filter, so a Chase card cached elsewhere would be hidden from the picker. The admin would only reach ConfirmationStep with a "blocked" card if they entered the flow with a prefilled cardID (e.g., from the cards table row) — useful for repro.

Alternative explanation considered: a backend rejection (no equivalent error key exists on the server side that App surfaces). Ruled out — assignWorkspaceCompanyCard failure data uses common.genericErrorMessage, not this string (CompanyCards.ts:404-478).

Related issues that corroborate (open):

• [$250] Assign Card silently fails for domain-level card feeds (e.g., Chase) due to missing adminAccess Onyx key #86277 — Chase domain-level card assignment silently fails (Domain Onyx / adminAccess path).
• [$250] Chase Direct Connection in New Expensify breaks, duplicates feeds, and fails to consistently assign cards across multiple workspaces #92092 — Chase direct-connection duplicates feeds, fails to assign consistently across workspaces. The duplicated feed Onyx entries are exactly the data shape that would trip isCardAlreadyAssigned.
• [$250] Admin is prompted with a bank credentials error when assigning an existing Capital One Direct Connection cards to a second workspace. #91199 / [$250] NewDot Capital One card assignment flow does not surface new card available to assign #91977 — Capital One (also a direct feed) assignment errors when assigning across workspaces.

What changes do you think we should make in order to solve the problem?

For error 1 (the visible blocker in NewDot): tighten isCardAlreadyAssigned so it cannot false-positive on a stale or duplicate WORKSPACE_CARDS_LIST_* entry from another workspace:

1. In ConfirmationStep.tsx:113, pass cardToAssign?.encryptedCardNumber only — drop the ?? cardName fallback for the cross-workspace guard. The masked-name fallback is the false-positive vector.
2. In isMatchingCard, when checking across workspaces (the direct-feed branch of isCardAlreadyAssigned), require an encryptedCardNumber match; only fall back to cardName matching within the same domainOrWorkspaceAccountID. Same-workspace matching should remain permissive to keep the current "don't double-assign within the same workspace" guarantee.
3. Skip cards with pendingAction === ADD from the cross-workspace scan as well (the current code skips only DELETE), to avoid optimistic Onyx entries written by an in-flight assign blocking a sibling assignment.
4. Log at the call site (Onyx state dump of the matched card key) when the guard fires, so we can confirm via VictoriaLogs whether reporters are actually hitting the cross-workspace branch.

This fix also reduces the surface for the duplicate-feed scenario in #92092 — even if Chase feeds are duplicated in Onyx, an encryptedCardNumber match is far harder to coincidentally collide than a masked name.

For error 2 ("Fetch API Cannot Load"): it is a console-level artifact of getCompanyCardBankConnection opening a cross-origin OAuth popup (production host on staging for Amex, oauth.chase.com for Chase). Whether it actually blocks the user depends on which fetch the browser is rejecting. We should ask the reporter for the full console error including the URL before changing this code path — that disambiguates whether the popup itself fails to open vs. a subresource fetch inside it. This is likely a separate fix and should not block error 1.

What alternative solutions did you explore? (Optional)

• Remove the client-side guard entirely and rely on the backend's existing assignment validation. Cleaner but loses the immediate UX feedback when a card actually is double-assigned. Not preferred.
• Clear stale WORKSPACE_CARDS_LIST_* Onyx keys when leaving a workspace. Addresses one source of bad data but doesn't fix the root cause (the guard's matching rule is too loose).
• Track this together with [$250] Chase Direct Connection in New Expensify breaks, duplicates feeds, and fails to consistently assign cards across multiple workspaces #92092 — both fixes need to land to fully resolve the Chase symptom; tightening the guard is the smaller, lower-risk change and should ship first.

Related issues

• [$250] Chase Direct Connection in New Expensify breaks, duplicates feeds, and fails to consistently assign cards across multiple workspaces #92092 — Chase Direct Connection breaks/duplicates feeds, fails to consistently assign cards across workspaces (very likely overlapping).
• [$250] Assign Card silently fails for domain-level card feeds (e.g., Chase) due to missing adminAccess Onyx key #86277 — Assign Card silently fails for domain-level Chase feeds (different mechanism, same area).
• [$250] Admin is prompted with a bank credentials error when assigning an existing Capital One Direct Connection cards to a second workspace. #91199 — Capital One Direct Connection assignment to a second workspace fails (same class of bug, direct feed).
• [$250] NewDot Capital One card assignment flow does not surface new card available to assign #91977 — Capital One assignment flow doesn't surface new card (related direct-feed flow).

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/92124#issuecomment-PLACEHOLDER) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[KJ21-ENG]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-29 23:56:47 UTC.

Proposal

What is the root cause of that problem?

The NewDot assign flow blocks the card in the client before it calls AssignCard.

When an admin presses Assign on a Company Cards row, useAssignCard stores the selected direct-feed card with the provider display label as both cardName and encryptedCardNumber. On the confirmation screen, ConfirmationStep.submit() calls isCardAlreadyAssigned() before assignWorkspaceCompanyCard().

For direct feeds such as Chase OAuth and Amex Direct, isCardAlreadyAssigned() scans every workspace card collection with the same feed name and compares only the selected card identifier. It does not consider the assignee accountID that ConfirmationStep already resolved.

That means a card already assigned to the same admin in another workspace is treated the same as a card assigned to a different user, so NewDot shows the "already assigned to a user in another workspace" error and never reaches the backend. There is also an identity boundary here: direct-feed cards often reach this flow as provider display labels, so a cross-workspace client check should not treat a masked/display label alone as a stable card identity.

What changes do you think we should make in order to solve the problem?

Make the duplicate-card validation assignee-aware and conservative for direct-feed identity.

1. Update the duplicate helper used by ConfirmationStep to accept the target assignee accountID.
2. Keep blocking a card that is already assigned in the current workspace/current feed, excluding pending-delete rows.
3. For other workspaces on direct feeds, allow the match when the existing assigned card belongs to the same accountID as the selected assignee.
4. Only block a different-account cross-workspace direct-feed match when the client has a stable card identity to compare. If the only match is the provider/masked display label, let AssignCard be the source of truth or first extend OpenPolicyCompanyCardsFeed / the assign flow to include a stable direct-card identifier.
5. Keep commercial-feed behavior domain-scoped, because those feeds have encrypted card identifiers and already avoid the cross-domain masked-name collision.
6. Apply the same rule to the card-selection list once an assignee is known, so CardSelectionStep does not hide a direct-feed card that is already assigned to the same selected member in another workspace.
7. Add focused coverage for Chase/oauth.chase.com and Amex Direct: same accountID in another workspace is allowed, different accountID with stable identity is blocked, pending-delete rows are ignored, and commercial-feed domain behavior is unchanged.

This keeps the fix scoped to Company Cards assignment and does not change feed connection, table rendering, or commercial card import behavior.

What alternative solutions did you explore? (Optional)

We could simply remove the frontend duplicate check and rely entirely on the backend. That would avoid this false block, but it would also remove useful same-workspace duplicate protection.

We could only allow matches with the same accountID. That handles the reported same-admin case, but if the match is based only on a direct-feed display label, it still treats a weak masked name as cross-workspace card identity. The safer fix is same-assignee aware while requiring stable identity before blocking a different-account cross-workspace match in the client.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @abdulrahuman5196 (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022060507729025505952

[trasnake87]

Proposal

Assigning a Chase or American Express direct-feed card to an admin in NewDot fails with "This card is already assigned to a user in another workspace," even though the identical assignment succeeds in Expensify Classic.

Root cause

The error never reaches the backend — it is produced entirely client-side by the pre-flight guard in ConfirmationStep.tsx, before AssignCard is sent:

// src/pages/workspace/companyCards/assignCard/ConfirmationStep.tsx:113-117
const cardIdentifier = cardToAssign?.encryptedCardNumber ?? cardToAssign?.cardName;
if (cardIdentifier && isCardAlreadyAssigned(cardIdentifier, workspaceCardFeeds, domainOrWorkspaceAccountID, bankName)) {
    setCardError(getMicroSecondOnyxErrorWithTranslationKey('workspace.companyCards.cardAlreadyAssignedError'));
    return;
}

cardIdentifier is not what its name implies for direct feeds. getFilteredCardList builds the selectable cards and, for direct feeds, sets cardID = cardName (the masked display name), whereas for commercial feeds it sets cardID = encryptedCardNumber:

// src/libs/CardUtils.ts:1017-1033
// For direct feeds (Plaid/OAuth): displayName === cardIdentifier
if (accountList) {
    return filterAmexDirectParentCard(accountList, feedName)
        .filter((cardName) => !assignedCards.has(cardName) && !allWorkspaceAssignedCards.has(cardName))
        .map((cardName) => ({cardName, cardID: cardName}));   // <-- cardID IS the masked name
}
// For commercial feeds: displayName is the key, cardIdentifier is the encrypted value
return Object.entries(customFeedCardsToAssign ?? {})
    .filter(([cardName]) => !assignedCards.has(cardName) && !allWorkspaceAssignedCards.has(cardName))
    .map(([cardName, encryptedCardNumber]) => ({cardName, cardID: encryptedCardNumber}));

CardSelectionStep then stores that cardID straight into the encryptedCardNumber field (CardSelectionStep.tsx:58 initializes cardSelected from it, CardSelectionStep.tsx:111 writes it back):

// src/pages/workspace/companyCards/assignCard/CardSelectionStep.tsx:111
setAssignCardStepAndData({cardToAssign: {encryptedCardNumber: cardSelected, cardName, customCardName}, isEditing: false});

So for Chase (oauth.chase.com) and Amex Direct (oauth.americanexpressfdx.com) — both isDirectFeed feeds per CardUtils.ts:631-637 — cardToAssign.encryptedCardNumber === cardToAssign.cardName === the masked display name, e.g. "CREDIT CARD...6607". The existing fixtures confirm this exactly: the OAuth test card stores encryptedCardNumber: 'CREDIT CARD...6607' (CardUtilsTest.ts:3926), byte-for-byte identical to its cardName.

The guard then calls isCardAlreadyAssigned, which for direct feeds bypasses the domain filter and scans every workspace in the Onyx cache sharing the feed name:

// src/libs/CardUtils.ts:1583-1597
// For direct feeds (Plaid/OAuth): check across ALL workspaces that share the same feed name,
// because the same Plaid card should not be assignable to multiple workspaces.
// For commercial feeds: restrict to the current domain only, because different domains
// can legitimately have cards with the same masked display name (e.g., "VISA - 1234").
if (isDirectFeedType) {
    if (feedName && feedBankName !== feedName) {
        return false;
    }
} else if (feedDomainID !== domainOrWorkspaceAccountID) {
    return false;
}
const {cardList, ...assignedCards} = workspaceCards;
return Object.values(assignedCards).some(
    (card) => card && card.pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE && isMatchingCard(card, cardNumberToCheck, cardNumberToCheck),
);

Two factors make this fire incorrectly:

1 - The cross-workspace scan matches on a non-unique identifier. A masked name like CREDIT CARD...6607 encodes only the bank label and last four digits. Two different physical cards — one in the admin's workspace, one in any other workspace already cached in the admin's Onyx — routinely share it. The guard reads that collision as "same card, already assigned elsewhere" and blocks, while the backend (which keys off the real OAuth/Plaid card identity) does not. That is precisely why Classic — same backend, no client guard — succeeds. The code even contradicts itself here: the comment at CardUtils.ts:1585-1586 concedes masked names collide across domains for commercial feeds, yet the direct-feed branch trusts that same masked name across workspaces.

2 - isMatchingCard normalization is looser than the filter that surfaced the card. getFilteredCardList excludes assigned names with an exact Set.has (CardUtils.ts:1020), but isMatchingCard compares via normalizeCardName, which strips ®/™/etc. (CardUtils.ts:417-432). A card can therefore pass selection (exact name unassigned everywhere) yet be blocked at confirmation (normalized name matches a different entry), e.g. American Express® - 1234 vs American Express - 1234.

Proposed fix

Scope the guard to the current workspace/domain for every feed type and let the backend stay the authority for genuine cross-account duplicates. In isCardAlreadyAssigned, delete the isDirectFeedType special-case (the const isDirectFeedType = isDirectFeed(feedName); line at CardUtils.ts:1561 and the if/else at 1583-1593) and require a domain match for all feeds:

// src/libs/CardUtils.ts — inside isCardAlreadyAssigned(), replaces lines 1583-1593
// Only flag a card already assigned within the CURRENT workspace/domain (and feed).
// Direct feeds (Plaid/OAuth) must NOT be matched across other workspaces: the only identifier
// the client has for them is the masked display name (getFilteredCardList sets cardID = cardName,
// CardUtils.ts:1023), e.g. "CREDIT CARD...6607", which is not unique across accounts.
// Genuine cross-account duplicates are rejected server-side by ASSIGN_COMPANY_CARD — the same
// path Expensify Classic uses, which is why the identical assignment succeeds there.
if (feedDomainID !== domainOrWorkspaceAccountID) {
    return false;
}
if (feedName && feedBankName !== feedName) {
    return false;
}

This keeps feedName in use (so the signature and all call sites are untouched), preserves the reliable same-workspace commercial guard (encrypted-number match), and makes the direct-feed path safe: within the current workspace the card-to-assign was already removed from the list by getFilteredCardList, so the guard correctly stops blocking and assignWorkspaceCompanyCard proceeds to API.write(WRITE_COMMANDS.ASSIGN_COMPANY_CARD) (CompanyCards.ts:478).

Exactly two *different workspace* unit tests encode the old behavior and must flip to false (every other case in the block — same-workspace, different-institution, pending-deletion, commercial same/different domain, and the no-feedName fallback — still passes unchanged):

// tests/unit/CardUtilsTest.ts:3850  — Plaid card assigned in a DIFFERENT workspace
expect(isCardAlreadyAssigned('Plaid Credit Card 3333', workspaceCardFeeds, 100, 'plaid.ins_19')).toBe(false);
// tests/unit/CardUtilsTest.ts:3933  — OAuth (Chase) card assigned in a DIFFERENT workspace
expect(isCardAlreadyAssigned('CREDIT CARD...6607', workspaceCardFeeds, 100, 'oauth.chase.com')).toBe(false);

Optionally, so genuine duplicates still surface the friendly copy — now driven by the authority rather than a client guess — map the backend rejection in assignWorkspaceCompanyCard's failureData to workspace.companyCards.cardAlreadyAssignedError instead of common.genericErrorMessage (CompanyCards.ts:464).

Why this approach

The commercial-feed branch in this very function already restricts matching to the current domain specifically because masked display names are not unique (CardUtils.ts:1585-1586); the fix simply extends that already-accepted reasoning to direct feeds, where the client has nothing but the masked name to match on. Tightening the masked-name comparison instead (factor 2) was considered and rejected — it cannot distinguish two genuinely different cards sharing a label and last four digits, so it only narrows the false-positive window rather than closing it. Deferring cross-account detection to ASSIGN_COMPANY_CARD restores exact parity with Classic, which is the behavior the reporter expects.

[wildan-m]

Proposal

Please re-state the problem that we are trying to solve in this issue.

On a commercial company-card feed (Chase, American Express), an admin cannot assign an available card to a member. The card the admin expects to assign is missing from the "Choose card" list (or the assignment is blocked), even though Expensify Classic lets the same card be assigned.

What is the root cause of that problem?

There are two code paths that decide whether a company card is "already assigned", and they disagree for commercial feeds.

isCardAlreadyAssigned (the guard that runs when you press Assign on the confirmation step) was deliberately written so that, for commercial feeds, a card is only considered already-assigned when the conflicting card lives under the same domain. The comment explains why: different domains can legitimately have cards with the same masked display name (e.g. "VISA - 1234"):

App/src/libs/CardUtils.ts

Lines 1583 to 1599 in 154718c

	// For direct feeds (Plaid/OAuth): check across ALL workspaces that share the same feed name,
	// because the same Plaid card should not be assignable to multiple workspaces.
	// For commercial feeds: restrict to the current domain only, because different domains
	// can legitimately have cards with the same masked display name (e.g., "VISA - 1234").
	if (isDirectFeedType) {
	if (feedName && feedBankName !== feedName) {
	return false;
	}
	} else if (feedDomainID !== domainOrWorkspaceAccountID) {
	return false;
	}
	const {cardList, ...assignedCards} = workspaceCards;
	return Object.values(assignedCards).some(
	(card) => card && card.pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE && isMatchingCard(card, cardNumberToCheck, cardNumberToCheck),
	);
	});

But getFilteredCardList, which builds the list of selectable (unassigned) cards, does not apply that same domain restriction. It collects allWorkspaceAssignedCards from every workspace feed across all domains, keyed only by masked cardName, and then removes any commercial-feed card whose masked name appears in that global set:

App/src/libs/CardUtils.ts

Lines 1002 to 1015 in 154718c

	// Get cards assigned across all workspaces
	const allWorkspaceAssignedCards = new Set<string>();
	for (const workspaceCards of Object.values(workspaceCardFeeds ?? {})) {
	if (!workspaceCards) {
	continue;
	}
	const {cardList, ...workspaceCardItems} = workspaceCards;
	for (const card of Object.values(workspaceCardItems)) {
	if (!card?.cardName) {
	continue;
	}
	allWorkspaceAssignedCards.add(card.cardName);
	}
	}

App/src/libs/CardUtils.ts

Lines 1027 to 1033 in 154718c

	// For commercial feeds: displayName is the key, cardIdentifier is the encrypted value
	return Object.entries(customFeedCardsToAssign ?? {})
	.filter(([cardName]) => !assignedCards.has(cardName) && !allWorkspaceAssignedCards.has(cardName))
	.map(([cardName, encryptedCardNumber]) => ({
	cardName,
	cardID: encryptedCardNumber,
	}));

So a Chase/Amex card whose masked display name (typically the last four digits) coincides with a card already assigned in a different domain/workspace is silently dropped from the selectable list. The admin then has no way to assign it in New Expensify, while Classic — which does not run this cross-domain masked-name filter — still allows it. This matches the reported symptom of being unable to assign a card to the admin specifically on the Chase and American Express (commercial) feeds.

What changes do you think we should make in order to solve the problem?

Make getFilteredCardList use the same domain-scoping rule that isCardAlreadyAssigned already uses, so the two paths agree.

Concretely, when building allWorkspaceAssignedCards, parse each WORKSPACE_CARDS_LIST collection key into its domainID and feed-name parts (the same parsing isCardAlreadyAssigned does: strip the collection prefix, split on the first underscore). For commercial feeds, only add a card's masked cardName to the set when that entry's domainID equals the current feed's domainOrWorkspaceAccountID — i.e. restrict the cross-workspace dedup to the current domain. For direct (Plaid/OAuth) feeds, keep the existing global behavior, because the same Plaid card must not be assignable to multiple workspaces regardless of domain (this mirrors the isDirectFeedType branch in isCardAlreadyAssigned).

This keeps the genuine "one card, one assignment within a domain" protection intact while no longer hiding a legitimately-assignable commercial-feed card just because an unrelated card in another domain happens to share the same masked last-four display.

What alternative solutions did you explore? (Optional)

Extract the key-parsing and domain-scoping logic shared by isCardAlreadyAssigned and getFilteredCardList into a single helper so the "is this card assigned in the relevant scope?" decision lives in one place and the two paths can never drift apart again.

[KJ21-ENG]

Updated my proposal to keep the same client-side duplicate-guard root cause, while clarifying the same-assignee rule and the direct-feed identity boundary for Chase/Amex cards.

[ReaperOAK]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.