any.sender, transactions made simple
We are excited to release a non-custodial service for outsourcing transaction infrastructure — any.sender
tldr; Jump right in to our developer documentation and check out for yourself how easy it is to register and send up a relay transaction to the any.sender API with an on-chain enforced quality of service.
Telegram | Twitter | Docs | Website
What is transaction infrastructure?
When the number of transactions in the pending pool outstrips the capacity of new blocks, the network becomes congested. As a result, all signers need to compete in a global fee market — with transactions that pay a low fee getting lost in limbo and stuck in the pending pool.
What does this mean for new projects, wallets and users?
They need to have reliable transaction infrastructure to authorise, publish and verify that a transaction was indeed accepted into the blockchain. If the transaction gets stuck in the network’s pending pool for whatever reason, then the infrastructure should be capable of un-sticking the transaction or at the very least notifying the user of an issue.
Why is transaction infrastructure tedious to build?
Most projects and startups want to focus on building their product, not infrastructure work.
So why is it tedious? What does the developer need to consider when implementing transaction infrastructure?
- Fee-estimation. Pick a competitive fee, based on all transactions in the network’s pending pool, to make sure your transaction gets in.
- Transaction fee bumping. Unsticking a pending transaction by re-publishing it with a higher fee.
Now let’s imagine there is a list of pending transactions on the network.
- Managing transaction fees in the queue. All pending transactions from a single signing key must appear in the blockchain by order. If the first transaction has a low fee, that may prevent all other transactions getting accepted.
- Re-ordering transactions based on priority. If a new transaction arrives and it has high-priority (i.e. it should be confirmed immediately), then the signer must re-order the list of pending transactions or issue the transaction using a new signing key.
Keep in mind, while the above tasks are awkward and fiddly to implement, it is also desirable for transaction infrastructure to pay the lowest fee possible while remaining competitive in the fee market.
Any evidence that building reliable transaction infrastructure is hard?
There is plenty of empirical evidence that transaction infrastructure is a problem companies face today.
Easy solution — always overpay fees. Over the past year, the recommended fee for fast confirmations by EthGasStation is often within the 8–10 gwei range.
However, as we can see in the picture above, many transactions for popular smart contracts greatly overpaid the recommended fee. The worst offenders were WENi at 32.6 gwei (3x) and Tepleton at 24.4 gwei. Of course, we need to take into account that it is the transaction signer (and not the smart contract) picking the outrageous fee.
So another good approach to better understand if companies are overpaying fees is to randomly sample their existing transactions. If we look at exchanges, then both Huobi at 35 gwei (3x) and Binance at 40 gwei (4x) outrageously overpay their fees — likely contributing to the table above.
Bad solution — Fatal consequences. When network congestion hits, then bad transaction infrastructure simply falls over and transactions get stuck (i.e. even overpaying the fee is not always good enough).
Fixing the stuck transactions often involves manual intervention, e.g. think of the ‘bump fee’ option in meta-mask.
For many projects, the need for manual intervention only harms the user experience, but for other projects, a stuck transaction can be fatal and result in the loss of funds.
Another good example last year was DeFi Saver (shout-out to a great team btw) failed to protect two Maker DAO CDPs due to network congestion. Thankfully DeFi saver compensated the user’s losses… but… it clearly highlights that reliable transaction delivery is not a trivial problem.
How does any.sender help?
Our goal is to ensure any third party project can simply outsource their entire transaction infrastructure to any.sender in a non-custodial manner and the promised quality of service is enforced by an on-chain smart contract.
But how does that work?
Easy registration. The only thing required is an on-chain deposit of ether into the any.sender smart contract.
Sending jobs via the any.sender API. The customer can craft and sign a relay transaction with a specified deadline (e.g. accepted by block 100) via our API.
In return, the any.sender sends the customer a signed receipt to acknowledge the job was accepted and that it will be fulfilled by the desired deadline.
And that is it. The customer can simply wait and watch for the transaction to get confirmed in the blockchain.
OK. But what if the relay transaction doesn’t get in?
The any.sender quality of service is enforced by a smart contract and financial penalties can easily be imposed if we fail to adhere to our promise.
With the signed receipt, the customer can submit it as evidence to the on-chain any.sender smart contract to prove the relay transaction was not accepted into the blockchain by the promised deadline.
There are two outcomes:
- Refund (compensation). The any.sender operator must refund the customer by the pre-agreed amount ($10+) specified in the signed receipt.
- Slashed. If the customer is not refunded in a timely manner, then the any.sender operator is fined (e.g. security deposit is slashed).
Is there anything that makes any.sender special?
We have put together a summary on some of any.sender’s coolest features:
- A simple API. An on-chain deposit, plug and play service.
- Non-custodial service. We are only responsible for paying the gas fee for pre-authorised transactions.
- Lowest price first. We always broadcast the transaction at a competitive (and low) gas price and steadily bump the fee until it gets in.
- Concurrent in-flight meta-transactions. Thanks to our replay protection proposals, we are the first meta-transaction relayer to support processing transactions out of order. e.g. if an exchange wants to process 100 withdrawals, the order of each withdrawal does not matter.
- Smart contract-enforced quality of service. Customers are empowered to hold us financially accountable if we fail to deliver the promised quality of service. In a way it is one of the first real “smart contracts”.
Try out the any.sender service
To get started by:
- Going to our website
- Reading our developer documentation
- Checking out this voting example on how to use the any.sender client
- Joining the conversation in our Telegram
- Following us Twitter
We are super excited to see how well automated arbitration and smart contract accountability works in practice.
While we continue implementing features to fully achieve the service we want to deliver — it is time to let any.sender jump into the wild.
