Skip to content
eosjs demos using the greymassfuel account and ONLY_BILL_FIRST_AUTHORIZER
JavaScript HTML TypeScript
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Type Name Latest commit message Commit time
Failed to load latest commit information.


These demos use eosjs and the greymassfuel account to cosign transactions using the ONLY_BILL_FIRST_AUTHORIZER feature of EOSIO. If you're interested in a similar demo using Scatter/Transit, please visit greymass/greymassfuel-transit-demo.


This feature of EOSIO allows an 3rd party account to cover the network resource costs (CPU/NET) for a transaction created by any user.

Note to app/dapp developers:

If you are interested in working with Greymass to bring this feature to your users, feel free to reach out to us either via email ( or join our telegram channel. We are in the very early stages of this project and eventually plan to offer it as a paid turn-key solution. This will help to offset the costs of our current and future API infrastructure.

Example Repository Structure

The repository shows examples for the primary of versions eosjs in use within the EOSIO ecosystem.

  • v20.0.0 - fully functional
  • v16.0.9 - does NOT work for all accounts (see eosjs@pull/604)

Each version specific folder contains two files:

  • browser-example.html: creates a cosignable transaction within an HTML page that can run in a browser
  • browser-example.js: creates a cosignable transaction in within a javascript file that can be included in a build process that supports imports
  • server-example.js: creates a cosignable transaction using a server side script

Running Examples

All examples are set to use the Jungle testnet, via our APIs, and have a private key embedded in them for the greymasstest account for the voting permission. This permission can only call the voteproducer action for the purposes of the demo.


Open the browser-example.html file in your browser and click the button.


Install the appropriate packages via yarn/npm and run the script.

As a note - switching between the two examples requires switching versions of eosjs. The commands below (yarn add ...) should accomplish this for you.

Running the v20.0.0 Example:

cd greymassfuel-eosjs-demos
yarn add eosjs node-fetch
node v20.0.0/server-example.js

Running the v16.0.9 Example:

cd greymassfuel-eosjs-demos
yarn add eosjs@16.0.9 node-fetch
node v16.0.9/server-example.js

Integration into Greymass API Infrastructure

Greymass has deployed a modified version of our cosigner-prototype to our public APIs infrastructure, available for the following chains:

This invisible service layer is set to intercept native /v1/chain/push_transaction API calls and determine if the data submitted is valid and capable of being cosigned for. Any request that fails this validation is forwarded directly to the normal transaction APIs and unaffected.

For both current networks this is deployed on, the greymassfuel account and the cosign permission are used. These permissions and allowed contract/actions can be viewed on using the following links:

The greymassfuel account on the Jungle testnet has ample CPU/NET resources and you are free to test against using these examples. The greymassfuel account on the EOS network on the other hand doesn't have many resources (at the time of this writing), so it will likely be less usable for demo purposes.

A quota has also been established on the EOS API infrastructure, only allowing a specific number of transactions per account. The Jungle API does not have this restriction.

Have spare resources on EOS? Delegate/Donate

The greymassfuel account on the EOS network is being configured to allow a certain amount of transactions per day, per account, on a first-come first-serve basis. This is currently live through the public API endpoint.

This configuration allows users (with a compatible wallet) who are unable to perform transactions (due to their own resources being low) to perform select actions they otherwise wouldn't be able to. The greymassfuel account covers the resource costs for these actions. The list of actions currently available for cosigning can be seen on the greymassfuel under the cosign permission.

If you have extra network resources on EOS, you can contribute to this pool by delegating tokens (as CPU) to greymassfuel. Do NOT use the transfer flag while delegating. By delegating tokens, you will retain full ownership of your tokens, full voting rights, and will only be conveying the rights to use those tokens as resources.

If you'd like to make an actual donation to this effort, you are free to transfer tokens to the greymassfund account. Any tokens sent to the greymassfund directly will be considered donations and not refunded.

Important notes to those developing custom solutions

Using a server side cosigner like this presents a number of risks to the account which is cosigning, and for that reason the follow best practices are recommended:

  • Use a specific cosigning account + permission with explicitly defined actions.
  • Do NOT stake tokens directly to the cosigning account, or give the account control of anything that has value. Delegate resources to it from a secured account, or rent resources for it via REX.
  • Do NOT use the active or owner key for cosigning, as potential attackers could then use those keys to sign malicious transactions on behalf of the cosigner.
  • Do NOT grant blanket permissions (eosio:: or eosio.token::) to the cosigning permission in a way which allows actions that could alter the account.
You can’t perform that action at this time.