What’s new and noteworthy in Tangany WaaS 1.9

Since the initial release of our Wallet-As-A-Service API, we have implemented two of the most prominent Blockchain protocols into our solution: Ethereum (including comprehensive support for EVM-compatible networks like Polygon and BSC) and Bitcoin. With our latest release, we introduce Tezos as the newest addition to our blockchain roster featuring a market-leading range of protocol interactions provided via a developer-friendly interface.

We are also excited to announce support for EIP-1559 — an Ethereum improvement protocol that reforms the handling of transaction fees, resulting in higher reliability and lower transaction costs in the supported chains.

We are also glad to announce additional quality of life and performance upgrades to Bitcoin and many other fixes and improvements throughout the API. Furthermore, we have reworked and enhanced our public docs to include more information and examples, making it easier than ever to start developing new blockchain use cases with Tangany WaaS.

As always, find the complete changelog on our GitHub releases page

Tezos support

With Tezos, we are bringing the first proof-of-stake blockchain into our suite and offering a broad range of tools for interacting with smart contracts, batching operations, and delegating assets to bakers.

The revealing of wallets — a mandatory one-time precondition for new Tezos wallets, is handled automatically in the background as long as the walled is sufficiently funded.

In addition to the ability to read Tezos contract storage,
arbitrary smart contract methods can be also be called and executed. So far, only the native JSON data types are supported as smart contract method arguments. The mapping of complex Tezos data types like `MichaelsonMap` using standard JSON notation is expected to be rolled out in an upcoming release.

The asynchronous wallet and contract operation endpoints conveniently support the batching of multiple Tezos operations. This aspect allows, e.g., to execute different methods in a single contract transaction or even bundle several wallet transactions under a single operation hash to save fees and ensure their sequential integrity on the blockchain.

Executing multiple Tezos contract methods

For users interested in Tezos yield farming, we offer functionality to delegate wallet funds to bakers. The current delegation status can be viewed using the Tezos wallet status endpoint, also containing information about the wallet reveal status, XTZ balance, and the wallet’s Tezos address.

Check out our docs to learn more about Tezos, and stay tuned for our upcoming post when we share in-depth technical guides about Tezos smart contract interactions with WaaS.

Ethereum EIP-1559 support

Before the introduction of EIP-1559 in the London Hard Fork, Ethereum transaction fees were calculated from a product of a bid-based gas price and the consumed transaction gas. The miner always received the resulting fee, causing miners to prefer higher-priced transactions. This effect made the Ethereum gas price highly volatile, causing extreme transaction fees during peak network utilization situations.

In contrast, EIP-1559-enabled networks infer the transaction fee from the Base Fee value and the Max Priority Fee

The base fee is observable in each block and gets burned by the network during the block inclusion, and the priority fee is used to cover the miners’ operation costs. The effective fee of such “Type 2” transaction is calculated by multiplying the sum of the base- and the priority fees with the consumed amount of gas.

With each block, the base fee adjusts up to a defined threshold making it more feasible to project the maximum required fee per gas on a short-term basis. To make sure transactions are reliably included in future blocks, transaction costs are estimated using the Max Fee value, for which WaaS allocates double the base fee. This maximum fee is usually higher than the current block’s base fee and never less than the miner’s priority fee. The excess ETH yielded from the difference between the base- and the maximum fee per gas is refunded to the sending wallet, causing the effective transaction fee to fall below the initially estimated.

EIP-1559 fees calculation in WaaS

WaaS controls the priority fee via the transaction speed header based on the desired block inclusion target. The `default` header value budgets a safe Max Priority Fee for a transaction to get likely included in the next block, while the lower `slow` setting targets the next handful of blocks. The `fast` setting is designed for high network utilization scenarios and ensures the transaction is handled with a lifted priority. Using `none` causes the transaction to be dropped on most public networks and is only useful on “gas-less” private chains or for experimentation purposes on test networks.

To date, WaaS only supports EIP-1559 processing on the public Ethereum networks `mainnet` and `ropsten`. Other EVM networks will be enabled as soon as EIP-1559 is introduced to the protocols and, until then, will continue to operate via legacy “Type-1” transactions.

Bitcoin UTXO changes

Bitcoin is a UTXO-based protocol, which means that each transaction utilizes a list of Unspent TX Outputs to execute a payment. The total balance of a Bitcoin wallet is represented by the sum of all UTXO that meet the confirmations requirements setting (defaults to 1 block).

In contrast to account-based protocols like Tezos and Ethereum, the balance of a Bitcoin wallet is calculated by opposing all transaction in- and outputs made throughout the lifetime of a wallet. This is achieved by fetching the complete indexing dataset of the sending wallet — a process that could take minutes for high-traffic wallets containing long transaction histories. To combat excessive API response times and improve the accuracy of balance requests for high-traffic wallets, we introduced UTXO caching to our Bitcoin endpoints. Based on the wallet’s interactions history, this optimization can dramatically speed up responses of UTXO-critical endpoints.

Speed improvement for the send BTC transaction endpoint

Before a transaction can be passed to the network, each UTXO assigned as transaction input must be signed by the wallet — consequently, transactions using extreme UTXO amounts bear the risk of timing out the transaction processor. The number of UTXO used in a transaction also impacts a wallet’s transaction fees since each transaction input adds supplementary data to the transaction payload. Although the WaaS Bitcoin engine allocates the transaction inputs in the most efficient configuration possible, the overall potential for higher transaction fees always increases with the number of UTXO per wallet.

We decided to limit the maximum amount of processable UTXO in a single transaction to prevent these undesired effects. Bitcoin transactions may now include up to 100 UTXO per call.

Use the Bitcoin wallet status endpoint to monitor the wallet balance and the amount of available UTXO.

Use the Bitcoin wallet status endpoint to monitor the wallet balance and the amount of available UTXO.

Consider consolidating UTXO in wallets with a high amount of unspent outputs by periodically sweeping to the sending wallet itself. Each sweep transaction will consolidate up to 100 UTXO to a single output, including “dust” outputs that are otherwise avoided in regular BTC transactions. Set the new `sweep` body property to `true` in the transaction estimation endpoint to estimate fees for a sweep operation.

If a wallet exceeds the UTXO threshold, the total value of the largest applicable UTXO inputs defines the maximum transferable BTC amount per transaction. This amount can be verified using the Bitcoin estimation endpoint.

The `inputsValue` body property signifies the maximum processable amount in a single transaction