Release Notes 1.6

With this new release, we are expanding WaaS’s capabilities to interact with Ethereum smart contracts and also introduce several quality-of-life upgrades for our supported Blockchains. For this new feature set, we have put a focus on streamlining the WaaS developing experience as well as improving the overall accessibility to our expanding Tangany ecosystem.

Check everything the new and updated below and let us always know on what features we should work next.

Sweep Bitcoin wallets

The Bitcoin sweeping endpoint available via POST /btc/wallet/:wallet/sweep-async can be used to transfer all confirmed coins from a wallet to an arbitrary Bitcoin address. This endpoint also takes into account any fees that occur during the transaction and handles edge cases with unconfirmed UTXOs.

Unconfirmed coins from e.g. pending transactions are normally not swept due to their only recent inclusion to the blockchain. To enforce sweeping unconfirmed coins as well, the request configuration header tangany-bitcoin-tx-confirmations needs to be set to none.

Call Ethereum Smart Contract methods

In a past release we have introduced the universal Ethereum smart contract endpointPOST eth/contract/:contract/:wallet/send-async that supports executing blockchain state altering contract methods (“write” access).

Suitably in addition we are introducing multiple endpoints to call “read-only” smart contract methods. The general contract call endpoint POST /eth/contract/:contract/call features an ABI-like configuration in the request body that makes it very easy to interact with a smart contract.

Verifying the approved allowance via ABI call on our ERC20 test token

The wallet-based contract call endpoint POST /eth/contract/:contract/:wallet/call works similarly but sets the msg.sender variable of the underlying ABI call to the route’s :wallet address. Contract functions that rely on msg.sender benefit greatly from this call type.

At last GET /eth/contract/:contract/call/:method and GET /eth/contract/:contract/:wallet/call/:method are convenience endpoints designed to quickly access basic smart contract data. Both routes call the smart contract :method in a predefined fashion. While the first route does not pass any arguments to the method call, its wallet-based variant does set msg.sender to the route’s :wallet address and automatically resolves the wallet address as the method’s first address type argument. Use this route to e.g. quickly get ERC20 balances for WaaS wallets:

The default response type for both convenience routes is `uint256`

The response type can be adjusted via the optional ?typequery parameter with a valid solidity data type. The response type defaults to uint256.

Accessing string type data call. With the default type the value would be “32”

Execute payable Smart Contract methods

To execute payable functions in a smart contract, the transaction is required to be accommodated by some Ether funding the method call. This is now supported in the POST /eth/contract/:contract/:wallet/send-async endpoint utilizing the optional amount body parameter.

Use wallet names in request body

In addition to the established WaaS workflow for sending funds to Blockchain addresses, it is now possible to directly send transactions to known Tangany wallets of the current tangany-vault-url Key Vault using the body argument wallet.

In the past, when trying to send Ether to an arbitrary recipient wallet my-wallet it was required to resolve the Ethereum address of my-wallet in a separate call

.. and then copy the address to the transaction route:

Using the new wallet body argument it is now possible to complete the same transaction in a single API call:

The “my-wallet” blockchain address of the current Key Vault is automatically resolved based on a current Key Vault

The simultaneous usage of the wallet and to parameters are supported for verification purposes. If a mismatch between both recipient types is encountered the request is rejected with matching error:

The “to” address must match the resolved address for the “wallet” argument

The wallet JSON body parameter is supported extensively throughout the API:

  • POST eth/wallet/:wallet/send
  • POST eth/wallet/:wallet/send-async
  • POST eth/wallet/:wallet/sign
  • POST eth/wallet/:wallet/estimate-fee
  • POST /eth/contract/:contract/call
  • POST /eth/contract/:contract/:wallet/call
  • POST eth/contract/:contract/:wallet/send-async
  • POST /eth/erc20/:token/:wallet/send
  • POST /eth/erc20/:token/:wallet/transfer-from
  • POST /eth/erc20/:token/:wallet/approve
  • POST /eth/erc20/:token/:wallet/mint
  • POST btc/wallet/:wallet/send
  • POST btc/wallet/:wallet/sign
  • POST btc/wallet/:wallet/estimate-fee

In our upcoming post, we will explore possibilities utilizing the wallet parameter as a custom Solidity type using our universal smart contract endpoint POST eth/contract/:contract/:wallet/send-async

Other notable changes

All notable changes are also curated in our public changelog and can be referenced in our public API documentation. Get started using WaaS 1.6 in minutes with our handy Postman collection

We plan to update our official SDKs to support WaaS 1.6 mid-august as our JavaScript SDK recently went out of beta state with the introduction of WaaS 1.5 support last week.

Keep your eyes peeled on our social activity to stay informed about all-things Tangany and always stay safe through these troubled times!

Alexey Utin
Alexey Utin
Alexey is one of the Co-founders of Tangany and our Tech Lead.
Share on email
Email
Share on twitter
Twitter
Share on linkedin
LinkedIn
Share on xing
XING
Share on facebook
Facebook

What you may also like

Release Notes 1.6

With this new release, we are expanding WaaS’s capabilities to interact with Ethereum smart contracts and also introduce several quality-of-life

Read More »
Receive the latest news

Tangany Newsletter