It would be interesting to see a fiat service for broadcasting Ethereum transactions to the network. Right now, most fiat on-ramps come in two flavours:
- A centralized exchange (like Coinbase, FTX and Binance). Poor user experience, slow, questionable regulatory frameworks, lack of transparency, often turn out to be insolvent.
- A fiat-to-token on-ramp (like Ramp.xyz and more recently Stripe). Better user experience, but limited in functionality and progammability.
I think there should be a third category: fiat-based transaction processors. Say you are an app developer and wish for your user to initiate a complex transaction flow, e.g.
call method
CrowdfundContract#deposit(), but it requires a transfer of 5 USDC to the contract to succeed
To achieve this now, the user has to purchase 5 USDC and some small amount of ETH (for gas fees) from an exchange, then withdraw these tokens to a EOA wallet address, and then finally broadcast the transaction to the network through a browser extension like Metamask or WalletConnect. This is slow, complex, error-prone, and it requires funnelling funds and private data through often questionable exchanges and various wallet/RPC providers.
But with a transaction processor, it might look differently. The app developer might embed a "Pay with Stripe" button on their website with a $5 USD price tag (in fiat), and configure the transaction details and parameters accordingly. The trusted payment processor, such as Stripe or Square, handles KYC and AML, and takes a small cut of payment for services rendered. Once payment is confirmed, the payment processor (not the app developer) broadcasts the fully-formed transaction to the Ethereum network. Within 30 seconds, the entire transaction flow would be complete.
The implications of this, aside from obvious speed and user experience:
- You can build applications where the users may not realize they are interacting with crypto and blockchain infrastructure.
- The entire flow is wrapped into a single transaction, rather than needing to juggle multiple transactions, bridges, and exchanges.
- The developer can construct complex flows, contract deployments and method calls, direct on-ramps to non-custodial wallets, and more.
Let's explore a couple of real-world scenarios where this might be useful:
With recent sanctions on zero-knowledge protocols like Tornado Cash, absolute privacy in blockchains has become severely limited. The current best option for soft privacy is to use a centralized exchange as a mixer. This is slow, costly, and requires you to trust the exchange with holding your funds and personal data.
If Stripe or Square provided transaction processing, users could interact with the blockchain explicitly or implicitly with a certain degree of soft privacy, by going directly through a transaction processor that keeps their fiat payments private. This gives users the same privacy guarantees as all of their other online spending—not as private as Tornado Cash, but good enough for the general public, and in such a way that might appease regulators and AML laws.
In practice, this type of transaction processing allows users to fund new wallets, deploy contracts, and trigger on-chain actions pseudonymously, without broadcasting their finances and identity to the entire world.
Another area this might be useful is for decentralized games, the likes of Dark Forest, OpCraft, and others. Many users playing these games might not even realize they are using a blockchain. These game servers often use rollups and side-chains for efficiency, and the default clients will rely on "burner wallets" stored locally in the browser rather than expecting the user to send every game interaction through an extension like MetaMask.
However, there is a barrier to entry in these games: how do you fund the L2/side-chain user accounts and transactions? Typically this might require the user to bridge and transfer ETH from the L1 to the L2 to initially fund their account (an account may only need a couple of dollars, as the transactions are extremely cheap on the L2). So far, most of these games tend to bear this account creation cost, but it creates a centralizing force.
With a transaction processor, the user could fund their player account with a $5 USD deposit in a single click, and then play the game without ever realizing it is using crypto and a blockchain under the hood. If at any point they wish to 'exit' the system entirely (and trustlessly), they can do so by withdrawing their deposit to a more popular non-custodial wallet like MetaMask or Rainbow. Meanwhile, crypto-savvy folk who do not wish to have their funds skimmed off the top by Stripe can just deposit ETH into their accounts by sending a regular on-chain transaction.
One more real-world example would be a crowdfund/dontaion platform built on stablecoins. This might look like Kickstarter, or Patreon, or Ko-Fi, or some combination of the three. Users would deposit value directly into creator funds, and the creators could withdraw this value trustlessly and immediately. Running on a L2 rollup, this service could be fast, with low gas fees, and entirely paid for with stablecoins (which is also the gas fee token). As the platform developer is at no point handling custody of millions of dollars of user deposits, it can be a relatively inexpensive service to run, and their platform fees could be far lower than current industry standards of 2-20%.
In this case, the transaction processor could handle deposits into the crowdfund contract, allowing a wider group of users to participate without expecting them to know anything about crypto or blockchain wallets.
There are some obvious pitfalls and challenges with the idea of a transaction processor. The first is regulatory: most major companies are forced to step extremely carefully around crypto transactions, so it's likely they will only ever send transactions within a very rigid set of constraints, and likely only give API permission to a limited set of reputable developers. The second challenge is to navigate the mechanics of traditional fiat systems: for example, a malicious user may send a credit card charge-back dispute immediately after receiving a USDC token, and the processor would have no choice but to absorb the impact. A third issue is how to deal with failed transactions—such as due to contract errors or insufficient gas. Even in these cases, the fees must still be paid by the user and processor.
There is also a more ideological rebuttal to this: it doesn't sound very decentralized! Which it isn't, but then again, no fiat on-ramp at scale will ever be decentralized.