[DBIP] Canonicalize Bridge Wallet under its operator Mt Pelerin

[naief9961-tech]

Proposal type

Modify provider identity / data normalization

Affected scope (files/folders/chains)

• references/providers/providers.csv (bridgewallet, mt-pelerin)
• references/offers/wallets.csv (bridgewallet)
• references/offers/ramps.csv (mt-pelerin)
• generated provider/offer metadata that joins offers by provider name

Motivation / problem statement

providers.csv currently models the same legal/operator identity twice: once as the product BridgeWallet and once as Mt Pelerin.

At current main (a51107a728c132f59da537f9c6342f1b840c60c6), the two provider rows share the same identifying data:

field	bridgewallet	mt-pelerin
website	https://www.mtpelerin.com/	https://www.mtpelerin.com/
docs	https://developers.mtpelerin.com/	https://developers.mtpelerin.com/
X	mtpelerin	mtpelerin
GitHub	MtPelerin	MtPelerin
LinkedIn	company/mt-pelerin	company/mt-pelerin
support email	hello@mtpelerin.com	hello@mtpelerin.com

The canonical Bridge Wallet product page is explicit about the relationship: “Bridge Wallet … is developed by Mt Pelerin Group SA.” It also describes Mt Pelerin exchange fees applying inside the wallet. Source: https://www.mtpelerin.com/bridge-wallet

This matters because Chain.Love's model is provider -> offer -> listing, and the common provider field represents the provider company/organization. Bridge Wallet is the product/offering; Mt Pelerin Group SA is the provider/operator.

The split is already visible in canonical offers:

• references/offers/wallets.csv: slug bridgewallet uses provider=BridgeWallet
• references/offers/ramps.csv: slug mt-pelerin uses provider=Mt Pelerin

A consumer grouping by provider therefore sees the wallet and ramp as unrelated companies even though the official source identifies one operator.

Detailed proposal

Use Mt Pelerin as the single canonical provider identity and keep Bridge Wallet as the wallet offer/product name.

1. Keep the mt-pelerin provider row as the surviving provider identity.
2. Change the canonical wallet offer's provider from BridgeWallet to Mt Pelerin; keep its offer slug (bridgewallet) and wallet-specific data unchanged.
3. Remove the duplicate bridgewallet provider row after merging any provider-level fields that are still useful. In particular, the duplicate row currently has a Discord value that the mt-pelerin row lacks; verify that value is still official/live before preserving it rather than copying it mechanically.
4. Do not merge the wallet offer into the ramp offer. They remain distinct products/categories under one provider.
5. Update any generated artifacts/metadata that still expose BridgeWallet as a provider identity.

Acceptance criteria

• Exactly one provider row represents Mt Pelerin Group SA.
• The Bridge Wallet offer remains present under wallets, but references the canonical Mt Pelerin provider.
• The Mt Pelerin ramp offer remains unchanged except for any generated join effects.
• No offer/listing slug is deleted or conflated across categories.
• Provider-level social/contact fields are source-verified before unioning them.
• A provider-identity scan no longer reports two rows sharing this same website/docs/GitHub/X/email identity.

Duplicate / active-work check

I searched open and closed Chain.Love issues for BridgeWallet, Mt Pelerin, and provider-duplicate wording. I found no proposal covering this pair. DBIP #3927 covers the same class of canonical-provider duplication for Flare, but not Mt Pelerin/Bridge Wallet.

I also searched pull requests for BridgeWallet + Mt Pelerin. The only matching PR found was historical PR #1323, which added official social handles to several provider rows; it does not consolidate these identities. No active implementation PR for this normalization was found before filing.

Reward eligibility

Chain.Love Discussion #41 currently advertises 10 USDC for an approved DBIP. This submission requests consideration under that program; approval and payout remain subject to maintainer review. A compatible payout address can be supplied if the proposal is approved.

Authorship / verification

Prepared with AI assistance. Repository counts/rows were mechanically checked against current main; the provider relationship was checked against Mt Pelerin's current first-party Bridge Wallet page. No claim of maintainer pre-approval is made.