EOSCommunity.org Forums

Fuel is now integrated directly into Anchor Link, the Anchor Wallet SDK

The combination of Anchor (both desktop and mobile), Greymass Fuel, and any external application has finally become a reality in the newest release of our wallet SDK, Anchor Link.

What this means is that any application that integrates with Anchor will be able to offer the same limited free transactions to their users that Anchor itself can, without placing any burden on the users themselves or the user experience.

Here’s a brief example showing it in action on bloks.io:

The above shows Fuel jumping into action via bloks.io for the ihasnocpunet account. The account has no EOS staked as CPU or NET while performing a small token transfer.

Any application that integrates with these new version of Anchor Link can take advantage of Fuel now!

History of Apps + Fuel + Anchor

In our original announcement post for Anchor Wallet, we stated that Anchor + Fuel would work in any authenticated app to cover transaction costs and make any transaction free:

Greymass Fuel is available directly in the wallet to provide an alternative to REX along with a minimum of 5ms free CPU per account, per day. This resources system works with all the tools in the wallet, as well as requests from any authenticated apps.

It turns out that this wasn’t always true and the way the majority of developers integrated with Anchor didn’t actually allow Fuel to work. This was an oversight on our part and we didn’t catch this until after Anchor had already launched and applications started integrating with Anchor.

Today we’re happy to announce that we have found a better way to integrate Fuel and live up to the promises we made!

Technical: How does it work?

The Anchor Link SDK now has a small pre-signature request that checks to see if the account has resources of it’s own before asking the user to sign the transaction. We plan on abstracting this approach further at some point in the future so that any resource provider similar to Fuel can tap into this process and offer alternative approaches.

What’s happening in the SDK now is as follows…

If the user has sufficient CPU on their account to perform the transaction, the transaction is forwarded to the users wallet to be signed and the transaction is processed as usual. However, if Anchor Link detects the user has little or no CPU available to perform the transaction, the SDK now shifts to an alternate mode of operations and performs the following additional steps:

  • The transaction is modified to include the Fuel action and signature requirements.
  • The transaction is forwarded to our servers to determine if Fuel is available to use with this specific user and transaction.
    • If Fuel is not available (for any reason), the transaction reverts back to the unmodified request.
      • The unmodified request is then sent to the user wallet for signature.
      • The signature is collected, and the SDK broadcasts the request to the blockchain.
    • If Fuel is available, our servers generate and return a signature authorizing the use of Fuel for this transaction.
      • The modified request is then sent to the user wallet for signature.
      • The signature is collected, and combined with the Fuel signature, and the SDK broadcasts the modified transaction along with both signatures to the blockchain.

We designed this method to always fallback to the native behavior of the blockchain. This is so that in the event that our Fuel servers are down, the specific user has exceeded their quota, or even if Fuel no longer exists - the experience will remain consistent with that of a normal transaction.

Only when the transaction will actually succeed in including Fuel will it step in and modify the transaction.

Developers: Integrating the SDK

To take advantage of Fuel, it’s resource management aspects, and offer your users the free 5ms worth of transactions per day, you’ll need an updated version of Anchor Link.

How to get the newer version of Anchor Link depends on how you’re integrating with Fuel…


If you’re directly integrating with Anchor Link, you’ll want to use the anchor-link@2.1.2 version or newer. You can update your package.json to reference this version or you can simply upgrade it through either yarn or npm.

To check what the newest version of Anchor Link is, view our releases page:


For developers using the greymass/ual-anchor plugin for the EOSIO/universal-authenticator-library from Block.one, ual-anchor@0.4.2 or greater is required. This will include the most recent version of Anchor Link and enable this new feature.

To check what the newest version of the Anchor plugin for UAL is, view our releases page:


Finally, if you are a developer using eos-transit, you will also need to upgrade to a new version to take advantage of Fuel. At the time of this writing the update is unavailable and the version number required is unknown, we are just awaiting this pull request to be merged and a new version to be tagged:

As soon as the above pull request is merged and a release is made, you’ll be able to update eos-transit to take advantage of these features!

1 Like

Hi Aaron,

Apologies if I have posted in the wrong section here!

Really enjoying Anchor Desktop, and think the new process of charging a low EOS transaction fee to hide resource management/complexity is working really well.

I have a question though, would it be possible to pre-purchase Fuel for times when FOC Fuel has been used up for the day? As a positive EOS balance is required once FOC Fuel has been spent, making transactions with a 0 EOS balance means topping up the account with EOS, which can impact the UX. With pre-purchased Fuel, the user only needs to be organised once, with Fuel set aside for just future transactions. It’s far too easy to spend 100% the EOS balance on exchanges, so remembering to set aside EOS impacts UX to some extent.

I’m sure you’ve already considered these but some additional thoughts:

  1. Allow for pre-purchased Fuel, and have users’ pre-paid Fuel balance be used first before FOC Fuel is used. This way, the system would be cheaper for you to run and provide a fairer cost model. Users can also get a warning when they have used all (or running low) of their pre-paid Fuel balance and to top up, so FOC Fuel you provide acts for a buffer here, rather than users relying on FOC Fuel balance alone.I think it would be a good end-user behavioural change and makes them less dependent on FOC Fuel as a primary way of using their wallets.

  2. Anchor Wallet could suggest an a 3 pre-purchase Fuel Options: low, medium and high, which could be the equivalent of there different types of user consumption for a month. Just an idea, but it prevents users from inputting the Fuel they would like to buy and accidentally paying huge amounts of Fuel with EOS by accident. With REX, there was no way for new users to conceptualised REX purchased with usage, so I think only offering 3 set options would be better (perhaps an advanced section could be added for advanced users fo more control).

  3. If possible, remove CPU, Network etc the user’s Fuel usage overview. Hopefully Fuel could be a currency to cover all resources with a single Fuel balance.

Again, great work on the Anchor wallets, they are brilliant .



Ah, sorry, seen there’s a similar thread:

Yep, that’s our next objective with Fuel. The order we have chosen to implement was:

  1. Free transactions based on a quota (Completed)
  2. Fee-based transactions when quota is exceeded (Completed, being rolled out now)
  3. Prepaid/Subscription based quotas for individual users and dapps (In development)

We are still working on the 3rd path, but it’s one of our higher priorities at the moment.

Exactly this :wink:

This will probably be a challenge - since determining a user’s consumption over the course of a month requires some pretty heavy computations and is based on the transaction history of the user. I don’t see this happening with the initial launch of the prepaid/subscription services, but refining into a model where we could project usage would definitely be desirable.

You’re reading our mind here! I believe the way we will represent this to the user is as “Credits”, with different operations consuming these credits to cover CPU, NET, and RAM. These credits will NOT be a token (no transfers, no refunds, etc) to avoid any legal/regulatory issues, but instead just be a unit of measure to make the user experience that much better. Think of it like purchasing “minutes” for a mobile phone bill.

With a single unit of measure like this we will be able to craft user interfaces that hopefully users will understand. They will see a number of “available” units to them and we can show a history of their usage since we keep track of it all with our internal accounting. Potentially after a few months of usage by an individual user, we could use this data to project future costs, but wouldn’t be able to do it without that prior history unless we ramped up our general history solutions.

Thanks, and thanks for engaging on this topic! We’re giving it our best and think we can help make this entire ecosystem that much more usable :+1:

1 Like