With around 2000 DApps and more than 60.000 users, the promise of 27.000 tx/s with Ethereum 2.0 and people arguing for Infura centralizing the public Ethereum world there is call for alternative! Altfury aims to provide to anyone the ability to interact with DApps and any smart contract without the need of paying gas.

Your user don’t have a wallet?

You can let us take care of your keys and the burden to not forget and secure them while enjoying the DeFi space faster than ever. DApp developers, the Ethereum world to your users with only the change of your endpoint URL address. Users, hassle free access to the DeFi world

No burden to use a new SDK in your DApps, work with standard Wallet Connect (Uniswap & al)! Peepz, just to go the website (optional install browser extension) pair up and go!

*Gas Station As A Service (GSAAS)


The goal of this document is to provide a design of a high-available service providing Ethereum JSON RPC endpoints over HTTP and HTTP WebSocket and other related services such as fee (tx) management to act as a drop-in repleacement (or plugin to existing wallet connectors).

Technical note

In addition, the endpoint SHOULD allow:

  • For unfunded Ethereum account to pass transaction on the blockchain under certain condition Withhold transaction then
  • Guaranteed transaction inclusion with low gas price fee For this specific feature, there is multiple ways to achieve this Pass transaction off-band to a partner miner pool that would accept transaction with a gasPrice set at 0 or fund the account via a faucet to the gasLimit x gasPrice while withholding the transaction until funding is done and then propagate it.


A remote wallet provider is a service that aims to help distant services to execute(read calls), sign(key control) and transmit transaction(write calls)

It integrate seamlessly by emulating a blockchain state with a balance corresponding for the credit of each account creating an ephemeral blockchain network (next_view(state, account_balances)->fork_view, a fork of the mainnet displaying accounts as if they have the corresponding amount making the experience seamless as


Todo do market research to describe personas

Future of work

  • Provide services about key usage (defi liquidity mining, …)


SHOULD be as minimal as possible to have a low footprint/cost (front-end requests (administration, user management, …)). Use go-ethereum as library to avoid technical debt as much as possible.

-> Wondering if serverless could be a benefit if it were handling execution read calls, this might be costly if not self-hosted

-> Browser extention to change the RPC endpoint easily -> Ledger device with dedicated credit app -> Website where account can be toped-up by XXX means


Per ethereum account (extracted from transaction signature) whitelisting. Per application(what), per logged user (who) Anonymous user SHOULD be limited by IP(Handle IPv6 per /64 block?):

  • Rate in second
  • Total number of concurrent connection
  • Time limit on connection



New usages possible out of that

  • Send NFT anonymously via TornadoCash integration

Allowed usage pattern

  • Authorize (max amount?)
  • Trade
  • Trade
  • … max amount before security callbacks?

Regulatory limits

Is this such a thing for DeFi? Tax?

Fraud prevention / whitelisting system

Smart-contract based?

Providing an ephemeral ethereum state

Transaction payment to miner

The payment is distributed to the block.coinbase each block containing private transaction (and potentially a lower than usual gas price)

Todo expand idea of private transaction via on-chain payment -> find a settlement cost minimal (ticket+payment channel)

Transaction flow

Write flows

    participant User
    participant EVM Service
    participant Eth node
    activate EVM Service
    User->>EVM Service: eth_sendRawTransaction
    EVM Service->>EVM Service: Classify user type
    EVM Service->EVM Service: Apply rate limit
    opt if user is TO_FUND_ACCOUNT type
    EVM Service->EVM Service: Apply funding TX to txpool
    opt if user is LOW_GASER
    EVM Service->EVM Service: Disable gasPrice limit
    EVM Service->EVM Service: Verify TX against txpool
    activate Eth node
    EVM Service-->>Eth node: Propagate funding transaction for TO_FUND_ACCOUNT user
    EVM Service-->>EVM Service: Wait for funding settlement for TO_FUND_ACCOUNT user
    alt Private or public transaction
        EVM Service->>Eth node: Propagate user transaction
    deactivate Eth node
        EVM Service-->>Miner pool: Dispatch transaction for LOW_GASER user

    deactivate EVM Service

Read flows




Ethereum RPC

Modified RPC

eth_call due to gasPrice parameter eth_estimateGas due to gasPrice parameter


Should reflect the gasPrice we want either low or high depending of the kind of transaction we expect to see either through a miner pool or pre-funding.


Custom implementation of this RPC, depending on USER_TYPE

Non stream RPC

  • eth_accounts

  • eth_blockNumber

  • eth_call

  • eth_chainId

  • eth_getBalance

  • eth_getBlockByHash

  • eth_getBlockByNumber

  • eth_getBlockTransactionCountByHash

  • eth_getBlockTransactionCountByNumber

  • eth_getCode

  • eth_getLogs

  • eth_getStorageAt

  • eth_getTransactionByBlockHashAndIndex

  • eth_getTransactionByBlockNumberAndIndex

  • eth_getTransactionByHash

  • eth_getTransactionCount

  • eth_getTransactionReceipt

  • eth_getUncleByBlockHashAndIndex

  • eth_getUncleByBlockNumberAndIndex

  • eth_getUncleCountByBlockHash

  • eth_getUncleCountByBlockNumber

  • eth_getWork

  • eth_hashrate

  • eth_mining

  • eth_protocolVersion

  • eth_submitWork

  • eth_syncing

  • net_listening

  • net_peerCount

  • net_version

  • web3_clientVersion

Streams RPC

  • eth_newFilter
  • eth_newPendingTransactionFilter
  • eth_getFilterChanges
  • eth_getFilterLogs
  • eth_uninstallFilter
  • eth_subscribe
  • eth_unsubscribe


  • Fast Transaction Pool, low latency viewer / transaction sender
  • Connect to peers, fetch memory pool, behave as light relay node
  • Provide transaction mempool view and fast transaction dispatching
  • Populate a central database for constant time access via API (paid access ?)
  • Monitor transaction to addresses, on update
  • Callback to backend customers through a fast protocol (GRPC?REST?…?)
  • Trigger registered function (e.g: send transaction)
  • World infrastructure required (node in each world, potentially costly + dev ops)
  • Dashboard with world view of ethereum compatible blockchain
  • Speed transaction sending for quick transaction dispatching
  • Would require ethereum node modification