What if, all we needed to solve the cross-chain UX, was a system that lent you funds on whatever chain you are on without any delay and you could pay back later. Like a simple credit-card. We are all used to this UX in Web2. What's stopping us from building this in Web3?

Despite calling ourselves the disruptors of legacy finance tech, we sure have created many hurdles for crypto users to simply spend their money. In web2, if you have a simple credit-card, you can spend from it anywhere in the world. In contrast to this, using web3 rails today feels like crossing 7 seas and 11 rivers to simply pay for Farcaster yearly storage on Optimism. To pay $5. That's why we're,

Smoke is a credit-based approach to solve the cross-chain UX problem. The idea is simple. You get your credit-card NFT, deposit some collateral on one chain, say Base, to instantly spend from it on any chain out there. It is a novel approach to the cross-chain problem.

And it makes total sense. Borrowing on DeFi is insanely cheap.

1. Instead of paying the swap/bridge fee Metamask charges (0.85%) on their wallet, you can borrow ETH for 2 months at 5% interest. AAVE's interest is just 2% btw.

2. For the fee Rabby charges (0.25%), you can borrow for 3 weeks.

3. If you spend $50 of ETH, and you pay back after 2 days, you incur an interest of just $0.01.

So, borrowing is really cheap on-chain. And we expect Smoke to be cheaper than 5%.

Before we look into the solution further, here's a brief on the status quo and the severity of the problem for comparison. You can also jump onto the next tweet or the website @SmokeOnChain to try it out on testnet.

Stargate, Across, deBridge, Synapse, etc., all of them aggregated through Jumper & Bungee is the best bridging experience the industry has ever seen. It is much much better than how it was 3 years ago, but it can & should get better, because we have competition now, the manlet chain. Some of the above bridges are pool-based and some are intent-based, but the user experience is always this:

1. Find which chain you have funds to spend on (biggest buzzkill, imo)

2. Deposit into a bridge on that chain, aka the source chain

3. Wait for bridging to happen (pretty fast these days tbh)

4. And then spend your funds on the destination chain

This is the best case scenario. It can go wrong in several ways...

1. What if there are no routes from your source chain to your destination chain?

2. Do you have enough gas on source and destination?

3. Bridge transaction is stuck or delayed, what do?

4. You have ETH on AAVE, you would have to go withdraw it to use it.

It has been painful for all of us. Not anymore.

Smoke offers an instant and affordable way to spend your assets on any chain, while offering the upmost security, without any worries. Just like pulling money out of the smoke, just like black magic.

This UX is unheard of. It addresses most of the problems mentioned above:

1. No need to search for funds when you want to spend

2. No deposit transaction, and no waiting. It's as fast as the destination chain itself

3. No need to search for routes. Smoke either supports a chain or not. We aim to support all chains, even the manlet chain

4. Gas abstraction from day 1, no need to worry about gas, even on EOAs

5. It can be atomic as well, means, if you failed to mint an NFT, you never borrowed

6. You don't need to withdraw your ETH from AAVE to bridge. You can withdraw later to repay your CC bill

The main feature is that, when you are on a dApp, trying to spend your funds, you will have funds to spend.

• No one will come between you and that Onchain Summer hoodie you're buying on @base.

• Or that NFT you are minting on Solana.

• Or that Fantasy Top card you're apeing on @blast.

• Or depositing into @HyperliquidX through @arbitrum cuz you're down bad.

Everything will be instantaneous.

And we are not cutting corners either. It is a fully secure system.

The main unlock is the cross-chain lending protocol underneath, like ember for smoke. The protocol accepts some collateral on some of the supported chains and lends you ETH on any of the supported chains at a fixed interest rate. When you request to spend on any chain, an issuer approves your loan and you can spend it instantly.

You can pay back your bill after you use the dApp you originally intended to use. Or you can pay back end of the day, week or month. But unlike a traditional web2 credit card where you will start accruing absurd amounts of interest as penalty if you don't pay back end of the month, in this initial version of the Smoke protocol, you will be accruing a fixed interest at slightly above the market rate (a cross-chain premium) from the moment you spend. Nothing absurd.

It will be comparable to the bridge costs you are paying today, if you pay back at the end of the day/week. Minus the UX cost.

That's it. It is pretty straightforward. Why has this never been done before? Because the cross-chain lending protocols have always needed cross-chain messaging and this model doesn't.

It is not a protocol that's months away. This black magic is live for you to test out right now. Please join our Telegram/Discord or DM me to test it out. You don't need your own testnet ETH, you'll get it from us.

If you're someone who is excited about the cross-chain UX problem and want to work on this amazing protocol with me, please reach out. We will be tackling some of the most difficult problems together, learn and grow together. If you're such a person, read on below!

If you're an end user, there is nothing much apart from the nerdy stuff from here onward. Go get a testnet credit card right now! Here's a demo of what it feels like:

https://vimeo.com/

Smoke Testnet Demo

Smoke is an on-chain credit card protocol that lets you deposit funds on one chain and spend it on any chain out there, instantly.

In the last few months there has been a lot of talk about intents, solvers and chain abstraction solving the ultimate cross-chain UX problem. We are all trying to bring the Solana experience, i.e., seamless UX when interacting with any application, to the entire ecosystem of Ethereum, L2s and alt L1s, including Solana. Chain Abstraction is basically abstracting the UX problems away. Solvers are entities that abstract these problems away for you.

Note: This article does not need you to know the definition of "intents".

The goal of this post was to find people to work with (join me in this mission), get feedback from the community and to get enthusiasts to test our testnet product out. The rest of this post will achieve this by,

1. Diving into the existing solutions,

2. introducing our new approach,

3. and comparing the two head to head

Let's dive right in.

One of emergent ideas around the block in the recent past has been a concept called Time Locks or Resource Locks for finality. The idea is to time-lock user funds in a credible commitment machine, for example, a smart contract, an MPC solution or a TEE based solution, to be unlocked by the solvers under certain fill conditions when the user signs intents. A CCM is basically a credible escrow that follows certain unlock conditions.

For instance, if you want to pay for a Farcaster account on Base with your locked funds on Arbitrum, the solver fronts you the amount on Base instantly in exchange for your signature to unlock your funds on Arbitrum. But why? Because then, you wouldn't have to deposit your funds on-demand when you need funds on Base, like in the current versions of Across/deBridge. Because after depositing funds you wouldn't have to wait for finality on the source chain. Because it's annoying to find your funds on-demand!

So, instead of doing that, you would have deposited your funds into time-locks (why? We want to prevent you from withdrawing funds right away as some solvers might still have unclaimed funds) and access them instantly on the destination chains whenever you need them. There are two major solutions in this area, MagicSpend++ by Socket and OneBalance by Frontier Tech. We would like to call these solutions Current Accounts with typical Debit Cards.

From the solvers perspective, instead of waiting for a chain's finality to fill an order (like on Across/deBridge), they can instantly fill an order and then go back to claim funds. To find you the best solver, MagicSpend++ will be auctioning off your orders based on price and/or speed on Socket's MOFA system. Solvers are the middlemen between the abstraction protocol and the user who front you their capital with assurance that they'll get paid back. Solver tech is an up and coming sector in the industry. It is a validated concept (via Across/deBridge/CowSwap). But what if we didn't need them?

What if I told you, all we needed, to solve the cross-chain UX, was simple credit cards. Think about it. If we consider chains as countries, all you should need is a Mastercard/Visa credit card to spend on any chain out there. Whether you want to buy a hoodie on Base's onchain summer, or you want to mint a Retardio Cousin on Solana or you want to repay your friend on Arbitrum, all you need is someone to front you capital at an interest. And you can pay those funds back to the card issuer at the end of the day, week or month.

In the real world, you stake your social credit score as collateral in your home country and spend from your credit card all over the world. But since we haven't solved the social credit problem yet, you should be able to just deposit some collateral (maybe, yield bearing assets like wstETH, rETH or sDAI) on one chain and should be able to spend on other chains. This solution resembles traditional Credit Cards.

This new approach is very similar to MagicSpend++ or OneBalance that are being worked on by several teams right now. But instead of solvers racing to fill your orders via an auction, you would have selected a credit card issuer beforehand to borrow at a fixed interest rate. And you can pay back anytime. Since borrowing short term loans in DeFi is pretty cheap, you are essentially paying rates similar to the system with solvers and auctions.

Although there are quite a lot of similarities, there are several differences as well. These differences do impact UX and costs to some extent, better or worse. Let's look into these two main factors to differentiate between these solutions,

1. User Experience

2. Cost Efficiency

In both these systems, a user would have to deposit some funds before they can start using the system. Deposit funds to be debited (Debit Cards), deposit collateral to be able to spend (Credit Cards).

As the user spends their funds, in case of Debit Cards, they'd have to refill their chain abstracted balance periodically. But in the case of Credit Cards, they'd be aware of the accruing interest to always repay periodically.

I do not know how the Debit Cards will be structured, but I expect there to be an option to choose which funds to spend at checkout. But in case of Credit Cards, the user would simply be borrowing USDC or ETH without having to choose at all. Isn't this the reason why we all love credit cards? To spend our money without worrying whether we have funds in our bank accounts to spend?

When the users spend money from their [Chain Abstracted Balance](https://ethresear.ch/t/magicspend-spend-now-debit-later/19678#magicspend-2), their order will be auctioned off via solutions like Socket's MOFA. So there is some auctioneer's cost involved here. The winning solvers receive approvals from the users to claim funds from the CAB on other chains.

Borrow costs before claim: Now, it depends how long the user funds are locked for, if it is something like 20 mins, then the protocol can batch claims to reduce cross-chain messaging costs for that time. If it is an optimistic system like on Across, the solvers can claim after 2-4 hours. So the funds would be locked for that period of time. Remember, solvers are essentially calculating these opportunity costs. So I estimate this waiting period costs to be equivalent to the typical lending market costs.

Cross-chain proof costs: To reclaim user funds, the solvers have to submit a cross-chain proof on the source chain proving that they filled an order. I expect this cost to be minimal as it could be either optimistic or batched messaging. But it is still a cost to consider.

Rebalacing costs: Finally, the solver will have to rebalance their funds back to the origin chain. They can use Socket's MOFA in Slow Mode again, or use EverClear to rebalance. There is costs involved here as well, especially if they are bearing opportunity costs during the period of batched settlement on Socket's MOFA or EverClear. This cost includes another auction's costs.

Finally, for doing all of this, solvers will be taking a cut for sure.

Sum of all costs = Borrow costs before claim + cross-chain proof costs + rebalacing costs + auctioneer's cut x 2 + solver's cut

When users spend using their credit cards, they start accruing interest on their loans. They can then repay anytime but their leisure to repay anytime cannot be considered into this cost comparison. Let's say they are a frugal L2 user, so they repay after 10 mins.

Borrow costs until repayment: This cost is the interest the users pay from the moment they spent their credit till they pay back, which can vary widely as they can pay back anytime.

Rebalancing costs: If the user has to bridge to a different chain to pay back, there will be some rebalancing costs borne by the user. Rebalancing can happen via Socket's MOFA Slow Mode, Stargate Train or EverClear. This rebalancing cost includes the interest accrued during the wait to maximally batch orders. Then again, this will be double the interest as they would be losing the opportunity of earning yield on this asset plus the negative interest on the credit card protocol.

Sum of all costs = Borrow costs until repayment + rebalancing costs + auctioneer's cut (MOFA)

We believe that we are saving some costs by not having on-demand auctions or solvers in the system. But maybe we are paying the costs in the form of UX since this requires having to repay end of the day/week/month. Well, you're refilling on the other system. We also believe that repayments can be automated as they are all a specific on-chain action.

One of the major challenges in this approach is that it requires individual lenders. The way we have set it up requires lenders to be the sole approvers for a particular user and their collateral. For instance, if you choose the credit card issuer "Towlie", only Towlie is allowed to approve your spend requests. You are stuck with Towlie until you repay all your loans and withdraw your collateral. So it is a centralization factor and you, as a user, could be grieved by the issuer refusing to lend you money at a particular moment. Good thing is, you can rage quit the system anytime. Plus, we will make switching credit cards super easy, unlike the traditional web2 cards.

Another challenge is finding sophisticated lenders as they would also have to run off-chain nodes to receive and approve requests on demand. Plus, lending will be long term here and the lender will get a bad rep for forcing repayments if they wish to exit the system.

Despite a few challenges, we feel more confident than ever before that this is a commendable approach to solving the cross-chain UX problem. With this solution, any dApp can easily pull balances from user's credit card with a simple approval from the user instead of having to lose a potential customer to the annoyance of bridging we have today.

If you are working on a similar product, we welcome you to collaborate with us. One of the main goals of this post is to find co-workers and collaborators. Please reach out.

The on-chain credit cards will surpass the convenience provided by the web2 credit cards. Don't take my word for it. Here's a video that displays the ease of spending money on-chain.

Join our Discord or Telegram to be the first ever testnet credit card holders. (PS: They're NFTs)

PS: Here is how these solutions compare to normal bridging. Kudos to Vaibhav for the original comparison.

CAKE (Chain Abstraction Key Elements) is an open framework where each CAF (Chain Abstraction Framework) team is free to choose their own model to solve the same problem. It essentially means choosing a different set of Key Elements. We chose to go with the credit based system with lenders as opposed to the solver based system. We just replaced solvers with lenders here with some trade-offs.

We will make spending great again. Imagine the cross-chain UX in your wildest dreams. We will surpass that.