Just about a month ago on Twitter we started talking about a new product we are calling “Fuel”. Today the project is in a stable state and we are excited to start talking about it in a more formal capacity.
Before we get lost in the details of this article, if you’d like to contact us you can do so by joining our new Fuel Telegram channel, reaching out to us on Twitter, or sending an email to firstname.lastname@example.org.
Fuel is a product developed by Greymass with the goal of being a turn key solution for application developers involved in the EOSIO ecosystem who wish to cover the resource costs (NET/CPU) of their end users.
The integration into an existing EOSIO application is simple and straight forward, so much so that we’ll list it out to start with:
greymassnoop:noopaction authorized by
That’s all that is required.
No additional server/infrastructure need to be setup by the developers to get running. Immediately they will be able to use Fuel to cover the resource cost of their users. This is due to the fact that the Greymass API infrastructure handles everything required for the entire process to take place while still supporting all normal EOSIO functions.
Beyond apps and their end users
As it turns out, Fuel is also flexible enough to handle a lot more than its original purpose, and is also capable of:
To take advantage of any of these features, Fuel must be integrated into the products and platforms you use. It is our plan to integrate these features into the products we develop, like Anchor, and we look forward to working with anyone else interested in integrating these features into their product(s).
Fuel can be used within applications today using a variety of different options:
Each of these ways to utilize our platform fits the needs of different users interacting with different products. We are happy to have a conversation to help you figure out what is best for your needs.
Fuel works currently off of a per-millisecond billing system based on the actual usage ultimately reported by the block producers. Our system follows the lifecycle of a transaction, estimating its cost before submission, recording the response during submission, and ultimately confirming the cost after the transaction becomes irreversible.
These end result of these costs can be verified on-chain by analyzing each matching transaction and the receipt of its costs. We also provide a special set of API endpoints in which you can query this data directly from our servers.
As of today, we currently are offering the following rates for EOS:
The rates above were based off a multiplier against the current REX rates with a premium added for the additional value our platform provides.
These rates are subject to change as we are still in the very early phases of developing the overall business model. We encourage feedback on this cost structure as we move forward, as this is uncharted territory and we may be the first to offer a per-millisecond billing structure to compete with REX.
For Users/Apps who want to rent infrastructure/resources:
At this early stage, most of the features within Fuel are a manual process and will require you to work with our team to get completely setup. We are developing automated systems to optimize this experience, but wanted to get the product out first for those interested in becoming early adopters.
For Token Holders who are interested in leasing resources:
If you have at minimum 100,000 EOS and are interested in leasing your resources through our platform, we are interested in discussing the options with you. Our goal is to be able to provide a competitive APR to that of REX with similar benefits.
For this initial round we are looking to create bespoke deals with large token holders, however in the long term we’d like to open this market up to anyone with a much lower minimum balance. This will come about as soon as we automate the process and it no longer requires us to manually coordinate these agreements.
We are open to expanding Fuel to other EOSIO blockchains. The EOS blockchain was just a logical first choice to begin with due to its size, our existing infrastructure, and the current resource situation on the network.
For other EOSIO-based blockchains, depending on the size of the network, we will have to expand our infrastructure in order to support its deployment. We will assess additional blockchains as they are brought to our attention and the explore whatever opportunities are opportunities available. Feel free to reach out.
To begin with we have developed a very simple economic model, which is similar to REX in many ways, yet drastically different in others. This model is subject to change as we are still exploring all the various configurations possible.
This model can best be illustrated as such:
The Fuel service acts as the hub in this model, in which:
This is very similar to the model which REX operates under, where the two parties involved are only dealing in resource usage rights. In both REX and Fuel:
There are however some distinct differences between REX and fuel, which include:
- REX requires the resources to be covered by the account performing the transaction.
- Fuel natively allows a 3rd party to cover the resources for the transaction.
- REX is a decentralized service operating on EOSIO blockchains.
- Fuel is a centralized (publicly auditable on-chain) service operated by Greymass.
- REX offers 30-day fixed terms in a “use it or lose it” situation.
- Fuel offers pay-as-you-go terms to prevent the waste of excess resources.
- REX guarantees the resources you have leased are available 24/7 for your usage.
- Fuel does not guarantee resources are available 24/7 for your usage.
- REX grants you a maximum amount of resources you can use each day.
- Fuel grants you resources which can be on-demand.
- REX has a maturation of 4-days to withdraw and a potential lock up period of up to 30-days (if the tokens in an active rental situation).
- Fuel has a maturation of 7-days to earn rewards, no maturation for withdraw, and no lock up period. Tokens can be withdrawn at any time, and only tokens that have been delegated for 7-days will be rewarded.
Each application has differing needs, and so each application will have to make a determination as to which service is best suited for their purposes.
To put this in perspective, let's create an analogy to something a bit less abstract than network resources: car rentals. Imagine a scenario where there was one car rental agency in town and these were their terms:
While these conditions are ideal for circumstances, they do not really work well for someone on a week long trip or someone who just needs the car for a day. The above terms are essentially how REX operates.
Fuel operates outside of this system and acts more like a ride sharing app, where the consumer is no longer bound to a long term lease and could instead rent a car for an afternoon or a day, only paying for what they use.
For some people, it may be more economical to rent a car for 30 days (like REX), but not every situation warrants a long rental and instead would make more sense in a short term agreement (like Fuel).
Both can coexist and play off each other quite nicely.
Fuel usage in the wild…
Fuel has a built-in free resource model which allows any account to use 5ms of CPU per day (subject to change). A handful of apps have already integrated Fuel to help cover the resource costs of their users:
We are interested in talking about Fuel, and would encourage you to join in the discussion by joining our new Fuel Telegram channel, reaching out to us on Twitter, or sending an email to email@example.com.
Thank you for your interest and we look forward to hearing from you!