Integrating Bungee Refuel into BIM Exchange

Idea
,
1

As BIM continues expanding across ecosystems, I would like to open a discussion around a potential improvement to our bridging experience: integrating Bungee Refuel into BIM.

We are already using Bungee as our liquidity aggregator, so this would not introduce a new infrastructure layer, but rather enhance our current integration.

What is Refuel?

When users bridge assets to a new blockchain, they often arrive without the native token required to pay gas fees on the destination chain.

This creates immediate friction:

  • They cannot perform additional transactions.

  • They must separately acquire the native token.

  • Bridging small native amounts is often inefficient or impractical.

  • It adds unexpected complexity to the onboarding flow.

Refuel solves this issue by ensuring users receive a small amount of the native token on the destination chain when they bridge assets.

How It Works?

Refuel operates in two possible modes:

Manual Mode
A small amount of native token from the source chain is sent alongside the bridged asset.

Auto Mode
A small portion of the input amount is automatically allocated to provide native gas on the destination chain.

Why This Could Be Valuable for BIM

Reduced User Friction

Users bridging into the BIM ecosystem would immediately be able to:

  • Swap
  • Stake
  • Provide liquidity
  • Interact with dApps

Without facing the “no gas” problem.

Improved Onboarding

First impressions matter.
Arriving operational significantly enhances user experience.

Higher Conversion & Retention

Entry friction is one of the main causes of user drop-off in cross-chain interactions.
Refuel directly addresses this.

Strategic Alignment

Since BIM already integrates Bungee for liquidity routing, adding Refuel would be:

  • Technically coherent
  • Operationally efficient
  • UX-driven

:pushpin: Discussion Points

Would the community see value in integrating Refuel into BIM?

Should it be optional or enabled by default?

Could this improve onboarding and adoption metrics?

This is not a formal governance proposal at this stage — just an idea to gauge interest and collect feedback.

Looking forward to your thoughts.

6 Likes
2

Good idea and it would definitively help the beginner onboarding but also the experienced users when using new addresses.

For the integration, is there a way in the simulation to check whether the reception address has already been active on the specific blockchain? If yes, the option could be activated by default, otherwise it could be optional.

3 Likes
3

The “No Gas” problem is the leading cause of user drop-off. Currently, if a user bridges USDC to a new chain but has no native tokens like ETH, MATIC, or BNB to pay for the next transaction, they are stuck. They have to leave your platform, find a centralized exchange, buy gas, and send it to their wallet.

By integrating Refuel, you keep the user on your site. It turns a 4-step manual process into a single, seamless click.

And for the Implementation

1. Manual vs. Auto Mode

• Manual Mode is great for power users who know exactly how much gas they need.

• Auto Mode is the real winner for Reduced User Friction. If BIM implements this, the UI should ideally calculate a “Standard Refuel” amount e.g., enough for 5–10 swaps automatically so the user doesn’t have to think about math.

2. Strategic Alignment

The argument that BIM already uses Bungee for liquidity is the strongest point here.

• Low Tech Overhead: Since the pipeline is already there, this is an upgrade, not a rebuild.

• Competitive Edge: Many DEXs offer bridging, but fewer offer integrated gas refueling. This makes BIM a “one-stop shop.” And will attract more people.

Should it be optional or enabled by default?

I strongly recommend It should be Optional but “Smart-Toggled.”

• Why: Forcing users to buy gas they might already have could annoy them. However, BIM could implement a “Gas Check.” If the connected wallet has zero native tokens on the destination chain, the Refuel toggle should automatically switch to ON with a small helpful tooltip: “We noticed you don’t have gas on this chain; we’ve enabled Refuel to help you get started.”

• Ecosystem Growth: If users find it easier to enter the BIM ecosystem, they are more likely to stay and explore dApps, staking, and liquidity pools.

My Final Verdict

This is a high-impact, low-risk proposal. It solves a genuine technical headache with a solution that is already technically compatible with your stack.

2 Likes
4

This is a good idea.

Integrating Refuel into BIM will directly reduce cross-chain friction and improve user experience during bridging.

The “no gas” problem is a real issue and often causes user drop-off. Adding Refuel can make bridging smoother and improve the first-time experience. Since BIM already uses Bungee for liquidity routing, this feels aligned and easy to implement.

My suggestion is to have it enabled by default with an option to disable, so new users benefit while advanced users retain control.

I believe this could positively impact onboarding and adoption metrics.

I have one question:

What would the cost structure of Refuel be, and who would ultimately absorb the gas subsidy, the user or the protocol?

1 Like
5

This is a very good suggestion, LP17. The lack of gas (native tokens) after bridging is a big challenge for new entrants. I think it would be better if it was made and 'Optiona’This is a very good suggestion,

1 Like
6

"so that users can choose whether they want to refuel or not. This will greatly improve our UX without forcing anyone.”

1 Like
7

That’s a very relevant point — especially regarding activation logic.

In theory, it should be possible to check whether a receiving address has already interacted with the destination chain by verifying on-chain activity (e.g., nonce > 0, prior transactions, or balance history).

A practical design could be:

  • If the address has never been active on the destination chain → Refuel enabled by default.

  • If the address has activity but native balance < estimated gas threshold → Suggest enabling Refuel.

  • Otherwise → Keep it optional.

This would combine:

  • Smart defaults

  • Non-intrusive UX

  • Respect for user control

From a product perspective, this could significantly improve onboarding while remaining flexible for advanced users.

1 Like
8

Thank you for the support and for raising a very important question regarding the cost structure.

Regarding Refuel, the mechanism is designed so that there is no protocol-level subsidy by default.

Cost Structure

Refuel does not introduce an additional protocol fee.
The only cost involved is:

  • The native gas required on the destination chain

  • This amount is deducted from the bridged amount

In other words:

  • The user ultimately pays the gas cost

  • The protocol does not subsidize transactions

  • There is no hidden fee — only the real execution cost

The system simply allocates a small portion of the transferred value to ensure the user receives native gas on arrival.

1 Like
9

The “No Gas” problem is the leading cause of user drop-off. Currently, if a user bridges USDC to a new chain but has no native tokens like ETH, MATIC, or BNB to pay for the next transaction, they are stuck. They have to leave your platform, find a centralized exchange, buy gas, and send it to their wallet.

By integrating Refuel, you keep the user on your site. It turns a 4-step manual process into a single, seamless click.

And for the Implementation

Manual vs. Auto Mode

• Manual Mode is great for power users who know exactly how much gas they need.

• Auto Mode is the real winner for Reduced User Friction. If BIM implements this, the UI should ideally calculate a “Standard Refuel” amount e.g., enough for 5–10 swaps automatically so the user doesn’t have to think about math.

Strategic Alignment

The argument that BIM already uses Bungee for liquidity is the strongest point here.

• Low Tech Overhead: Since the pipeline is already there, this is an upgrade, not a rebuild.

• Competitive Edge: Many DEXs offer bridging, but fewer offer integrated gas refueling. This makes BIM a “one-stop shop.” And will attract more people.

Should it be optional or enabled by default?

I strongly recommend It should be Optional but “Smart-Toggled.”

• Why: Forcing users to buy gas they might already have could annoy them. However, BIM could implement a “Gas Check.” If the connected wallet has zero native tokens on the destination chain, the Refuel toggle should automatically switch to ON with a small helpful tooltip: “We noticed you don’t have gas on this chain; we’ve enabled Refuel to help you get started.”

• Ecosystem Growth: If users find it easier to enter the BIM ecosystem, they are more likely to stay and explore dApps, staking, and liquidity pools.

My Final Verdict

This is a high-impact, low-risk proposal. It solves a genuine technical headache with a solution that is already technically compatible with your stack.

1 Like
10

I agree with this split :ok_hand:t3:

1 Like
11

I concur. Especially if enabled by default, this could meaningfully reduce friction for new users.

1 Like