Subscribe to RallyProtocol
<100 subscribers
RallyProtocolRallyProtocol Arrives on Base
Natively embedded wallets and gasless transactions for based builders.
RallyProtocolEmbedded Wallets in Mobile Apps: How They’re Changing Web3 UX
Embedded wallets are something we have talked about in the past. We highly recommend checking out our previous blog posts here and here if you'd like to get an overview on what embedded wallets are and why they are important. This post will highlight real-world examples of mobile apps leveraging embedded wallets, the UX, and why they matter—for developers looking to integrate them and for users who benefit from their seamless experience.OrbOrb is a mobile-only Web3 social media app built for ...
RallyProtocolEOAs vs. Smart Accounts vs. MPCs: Choosing the Best Embedded Wallet for Your Mobile dApp in 2025
As an app developer, choosing the right custody solution for your users has never been more complex—or more important. The landscape of Ethereum Virtual Machine (EVM)-compatible chains and Layer 2s (L2s) has expanded dramatically, and with it, the range of wallet solutions.
Subscribe to RallyProtocol
<100 subscribers
RallyProtocolRallyProtocol Arrives on Base
Natively embedded wallets and gasless transactions for based builders.
RallyProtocolEmbedded Wallets in Mobile Apps: How They’re Changing Web3 UX
Embedded wallets are something we have talked about in the past. We highly recommend checking out our previous blog posts here and here if you'd like to get an overview on what embedded wallets are and why they are important. This post will highlight real-world examples of mobile apps leveraging embedded wallets, the UX, and why they matter—for developers looking to integrate them and for users who benefit from their seamless experience.OrbOrb is a mobile-only Web3 social media app built for ...
RallyProtocolEOAs vs. Smart Accounts vs. MPCs: Choosing the Best Embedded Wallet for Your Mobile dApp in 2025
As an app developer, choosing the right custody solution for your users has never been more complex—or more important. The landscape of Ethereum Virtual Machine (EVM)-compatible chains and Layer 2s (L2s) has expanded dramatically, and with it, the range of wallet solutions.
Share Dialog
We’ve been using the Mumbai Testnet to support our developer community, who are building onchain mobile apps. We have GSN and all of our gasless transaction infrastructure, RallyTransact, set up there. As part of the Goerli deprecation, Mumbai is on its way out and being replaced by Amoy. More info on that here.
GSN was not deployed to Amoy yet so we took it upon ourselves to do so and get the first relayer set up. When we started testing we noticed the following error on every attempt to relay a transaction:
insufficient funds for gas * price + value: address 0x0000000000000000000000000000000000000000 have 2170300023505000000 want 900000000000000000000 (supplied gas 600000000)
We initially assumed it was a misconfiguration from our GSN deploy or one of our clients. It’s easy to miss a setting. Oddly everything worked on our integration test infra. Our integration tests use a hardhat node forking off of the testnet networks before every run. So something is different between sending transactions to hardhat vs sending transactions to Amoy.
The above error message is specific to the Polygon bor client. The same error message in geth is “insufficient balance to pay for gas” after googling around for “0x0000000000000000000000000000000000000000” and “insufficient balance to pay for gas” we found this issue in the geth repo. Aha! So sending an eth_call with a gas price set has different behavior in different node clients! Now we had something to look for.
Digging in to the GSN relayer codebase we uncovered this line:
await this.relayHubInstance.calculateCharge( maxPossibleGasFactorReserve, relayTransactionRequest.relayRequest.relayData, { gasPrice: relayTransactionRequest.relayRequest.relayData.maxFeePerGas } )
Getting rid of that pesky gasPrice was all it took and caused the same behavior across the board and we were up and running on Amoy.
We are happy to support our developer community in building onchain mobile apps by getting RallyTransact up on Amoy but we wish a few things had been easier in this migration:
Share Dialog
We’ve been using the Mumbai Testnet to support our developer community, who are building onchain mobile apps. We have GSN and all of our gasless transaction infrastructure, RallyTransact, set up there. As part of the Goerli deprecation, Mumbai is on its way out and being replaced by Amoy. More info on that here.
GSN was not deployed to Amoy yet so we took it upon ourselves to do so and get the first relayer set up. When we started testing we noticed the following error on every attempt to relay a transaction:
insufficient funds for gas * price + value: address 0x0000000000000000000000000000000000000000 have 2170300023505000000 want 900000000000000000000 (supplied gas 600000000)
We initially assumed it was a misconfiguration from our GSN deploy or one of our clients. It’s easy to miss a setting. Oddly everything worked on our integration test infra. Our integration tests use a hardhat node forking off of the testnet networks before every run. So something is different between sending transactions to hardhat vs sending transactions to Amoy.
The above error message is specific to the Polygon bor client. The same error message in geth is “insufficient balance to pay for gas” after googling around for “0x0000000000000000000000000000000000000000” and “insufficient balance to pay for gas” we found this issue in the geth repo. Aha! So sending an eth_call with a gas price set has different behavior in different node clients! Now we had something to look for.
Digging in to the GSN relayer codebase we uncovered this line:
await this.relayHubInstance.calculateCharge( maxPossibleGasFactorReserve, relayTransactionRequest.relayRequest.relayData, { gasPrice: relayTransactionRequest.relayRequest.relayData.maxFeePerGas } )
Getting rid of that pesky gasPrice was all it took and caused the same behavior across the board and we were up and running on Amoy.
We are happy to support our developer community in building onchain mobile apps by getting RallyTransact up on Amoy but we wish a few things had been easier in this migration:
It seems there are different versions of bor running on Amoy vs Polygon PoS mainnet. This makes the utility of a testnet a bit diminished as we can’t fully trust apples to apples comparisons between the two networks.
I really did miss etherscan functionality when trying to work with the Oklink explorer. Once again, differences between mainnet and testnets makes things harder for the dev community.
About RallyProtocol
RallyProtocol is an all-in-one Web3 mobile toolkit that enables developers to create seamless, end-to-end onchain experiences for native mobile apps, featuring embedded wallets and gasless transactions. Whether you’re building an iOS or Android app in Flutter, Unity, React Native, Expo, Swift, or Kotlin, our mission is to give developers the power to create user-friendly mobile UX with fewer taps and zero web3 touchpoints. Want to learn more? Dive into our developer documentation here.
It seems there are different versions of bor running on Amoy vs Polygon PoS mainnet. This makes the utility of a testnet a bit diminished as we can’t fully trust apples to apples comparisons between the two networks.
I really did miss etherscan functionality when trying to work with the Oklink explorer. Once again, differences between mainnet and testnets makes things harder for the dev community.
About RallyProtocol
RallyProtocol is an all-in-one Web3 mobile toolkit that enables developers to create seamless, end-to-end onchain experiences for native mobile apps, featuring embedded wallets and gasless transactions. Whether you’re building an iOS or Android app in Flutter, Unity, React Native, Expo, Swift, or Kotlin, our mission is to give developers the power to create user-friendly mobile UX with fewer taps and zero web3 touchpoints. Want to learn more? Dive into our developer documentation here.
No comments yet