We are happy to announce our latest version of the Tangany Suite. With 1.8 we are bringing new, exciting features, introducing further usability enhancements, and double down on improving the overall performance and reliability. Take a look at some of the highlights below and do not forget to check out our full changelog for a complete picture

Transaction Monitoring

Get automatically notified about balance changes and always stay informed about relevant transactions via webhook-based transaction monitors. Instead of polling transaction statuses manually it is now possible to receive automatic notifications whenever incoming and outgoing transactions interact with one of your monitored wallets.

Tailor the monitoring experience to your needs by making use of a wide array of available monitoring configuration options. For example, you can get only notified about incoming transactions that spent above certain threshold gas and after the block 12244000.

Received monitoring webhook as seen on webhook.site

Take a deep dive into our Transaction Monitoring feature with our newest tutorial https://medium.com/tangany/how-to-monitor-ethereum-transactions-26a081168322 and learn how it can benefit your specific scenario.

We release Transaction Monitoring as a limited beta (opt-in) and will continue improving it based on usage data and customer feedback. Connect with our customer support to apply for beta-access for your subscription

Wallet tagging

Add user-defined data as key-value pairs to new and existing wallets. Up to 10 tags are supported per wallet.

Find wallets tagged with certain keys using the ?tag query parameter in the new GET /wallets endpoint. Exclude certain tags from the search using the ?xtag query

Pass multiple queries to further confine the search results: ?tag=some-tag&tag=and-this-tag&xtag=not-this-tag

Use the new PATCH /wallet/:wallet endpoint to assign tags to existing wallets. Optionally pass the application/json-patch+json header and a RFC JSON Patch body to add, remove or modify certain wallet tags atomically.

Pass the Etag header value returned in the wallet resource via the If-Match header to prevent from updating outdated resources. If the underlying wallet resource has been modified from the expected model state, the call will be rejected with 412 Precondition Failed

Convert universal smart contract calls to data

Convert Ethereum smart contract call to hexadecimal data via the smart contract estimation endpoint POST /eth/contract/:contract/:wallet/estimate-fee 

The result data can be used for verification purposes. Another possible use case is to employ it for smart contract interactions via the data interface:

Using the converted hex data in data transaction
Completed data transaction as seen on Etherscan

Ethereum custom networks whitelisting

Custom Ethereum network URLs provided via the tangany-ethereum-network are now explicitly required to be whitelisted via customer support ticket to be used for RPC access in API calls. Invocation attempts for non-whitelisted custom networks are now declined with a 400 error response

This is a mandatory security enhancement that minimizes the risks of unauthorized access to customer’s private networks. For existing customers, an automatic zero-downtime migration was performed before the release making sure no further action is required to continue accessing legacy custom networks

Ethereum transaction performance

We fine-tuned our async Eth transaction engine and greatly enhanced the transaction per wallet ratio by utilizing smart nonce caching. Async Ethereum endpoints now send faster and more reliably enabling wallets to process batches of simultaneous transactions to empower high-volume traffic applications on public and private networks. 

At the same time, the common Ethereum idiosyncrasy of overlapping transaction nonces in such rapid-sending scenarios which often causes lost, canceled, or unknown transactions is now dramatically reduced. In fact, it is now possible to simultaneously send dozens of asynchronous Ethereum transactions (e.g via POST /eth/contract/:contract/:wallet/send-async) from a single wallet without bothering about losing even a single one due to a non-unique nonce assignment

Simultaneously sending 25 Ethereum Tx from a single wallet and awaiting confirmation

As always, check out the complete changelog at https://raw.githubusercontent.com/Tangany/Wallet-as-a-Service/master/CHANGELOG.md and follow us on social media to stay up-to-date with our newest developments

Content

— Introduction

— Transaction Monitors explained

— Benefits of monitoring transactions

— Configurations

— Notifications

— Maintenance

— Requirements

Introduction

This blog post aims to give you a brief introduction to a new beta feature called Transaction Monitors in Tangany’s Wallet as a Service API. I am going to explain how Tangany’s Transaction Monitors work and how you could configure them to suit your use cases.

There will be some configuration examples, but I’ll walk you through them step by step. If you want to start monitoring your own transactions, check out the requirements at the very bottom of this post.

Transaction Monitors explained

Upon creation, Tangany’s Transaction Monitors watch every Ethereum transaction and will notify you accordingly. This includes blocks on Mainnet and Ropsten. The monitor will search through all the new transactions and tries to find a match to the search criteria you provided on creation. When a monitor finds a match it will notify you about the matched transaction via webhooks.

Deposit Notifications and Deposit Monitoring

Get alerts whenever deposits or withdrawals are made. Monitor activities on wallets and smart contract addresses by getting automatically notified.

Benefits of monitoring transactions

Using Tangany’s monitoring infrastructure can provide numerous advantages depending on your use case. Some obvious benefits are:

Reduce operation costs

Since monitors notify you about transactions on-chain, polling transaction status becomes superfluous. Retrieving a transaction status over and over again to verify its inclusion into a block or its confirmations is consuming resources. Regardless of which hard- or software your infrastructure is built on, at some point, you will save e.g. bandwidth, processes, database operations, power, and so on.

Better safe than sorry

Supervise transactions regarding Anti Money Laundering, Anti Terrorism, or any other regulations. Tracking involved parties and receiving information about malicious transactions is an essential step towards staying compliant.

Know what’s up

Monitoring its infrastructure is crucial for every IT project. Knowing which transactions use too much gas, are more likely to fail or which wallets register a huge amount of transactions is valuable when using such insights to make improvements.

Configurations

Now we’re getting a bit more techie. Feel free to check out the requirements and information at the very bottom of this post to jump right into the action with me or review our docs about monitoring. Let’s start with probably the most basic example:

{
"target": "transaction",
"description": "In- and outgoing wallet txs",
"configuration": {},
"webhook": {
"url": "https://your-service.tld",
}
}

target: the target a monitor is operating on. For now, only transaction is supported
description:a maybe human-readable description of your choice
configuration: the heart of every monitor — its configuration. A Transaction Monitor will be configured to match all in- and outgoing transactions by default. We will discuss more advanced configurations later on.
webhook: a publicly available URL or IP you want your notifications to be sent to. A monitor will send a HTTP request to this endpoint which contains information about the matched transaction.

The configuration parameter has a wide range of possible filters to narrow down matched transactions. Here is a list of supported filters:

{[…]
"configuration": {
"direction": "in" or "out"
"wallet": "wallet-name" or ["name0", "name1", ...]
"from": "0x123Abc" or ["0x123Abc", ...]
"to": "0x123Abc" or ["0x123Abc", ...]

"blockNr": 0,
"gas": 0,
"gasPrice": "0",
"gasUsed": 0,
"isError": true or false,
"nonce": 0,
"timestamp": 1505597189,
"value": "0.1"
}
[…]}

Party filters like fromto and wallet can hold arrays and are evaluated using the logical operator Equals or Equals one of.
direction and isError evaluate using Equals as well.
All other configuration parameters evaluate using the logical operator Greater or Equals.

Be aware that multiple filters are combined using a logical AND. Therefore, all conditions must be met for the monitor to eventually send a notification.

Monitor parties

Transaction Monitors can be configured to notify about transactions between parties. fromto and wallet narrow down matched transactions to specified Tangany wallet names or Ethereum addresses and can even be more specific by utilizing the direction parameter. Examples:

{[…]
"configuration": { "from": "0x123Abc" }
[…]}
{[…]
"configuration": {
"wallet": ["wallet-name0", "wallet-name1"]
"direction": "out"
}
[…]}

Monitor transaction properties

Monitoring transaction properties adapt to your use case and can be utilized in lots of different ways and combinations. Tell us about your intentions and feature requests in our 1-minute survey. Here are some examples:

{[…]
"configuration": { "value": "0.5" }
[…]}
{[…]
"configuration": { "isError": true }
[…]}
{[…]
"configuration": {
"direction": "out",
"timestamp": 1615456830
}
[…]}

Notifications

Transaction Monitors send notifications to an endpoint of your choice containing information about the matched transaction. This webhook can be an endpoint to your service backend, a Slack channel, or any other publicly accessible URL or IP address.

A monitor will send its notifications out once the provided transaction confirmation number is reached. Transaction confirmations indicate the number of blocks that are added to the chain subsequently. So you are in control of getting “live” notifications (confirmations: 0) or more trustworthy notifications based on higher confirmation numbers.

Following an example for a basic notification configuration:

{[…]
"webhook": {
"url": "https://your-service.tld",
"method": "post"
}
[…]}

url: the URL or IP address the monitor will send its notifications to
method: the HTTP method the monitor will utilize. post is default and can be omitted

POST webhooks

When a Transaction Monitor is configured to send notifications utilizing the HTTP method post, the incoming request from Tangany could be similar to this example:

POST https://your-service.tld HTTP/1.1
tangany-monitor: fcf66d8e-xxxx-4c5b-xxxx-5655dcfa6c69{
"monitor": "fcf66d8e-xxxx-4c5b-xxxx-5655dcfa6c69",
"target": "transaction",
"description": "my monitor",
"wallet": "my-wallet",
"blockchain": "ethereum",
"network": "ropsten",
"confirmations": 6
"configuration": {
[…] // entire configuration object
},
"hash": "0x69afc6e9ffa5c0ecd26451ba67081845[…]",
"transaction": {
[…] // transaction status information
}

}

Besides important information about the responsible monitor, the requests include data about the matched transaction. The transaction object provides all information one could get by calling Tangany’s transaction status endpoint: https://api.tangany.com/v1/eth/transaction/:hash

GET webhook

When the monitors’ webhook is configured to utilize the HTTP GET method, a shortened data collection is sent by appending URL Query Parameters to the provided webhook url.

{[…]
"webhook": {
"url": "https://your-service.tld/some-path?key=value",
"method": "get"
}
[…]}

The above webhook configuration would result in monitor notification similar to the following requests:

GET https://your-service.tld/some-path?key=value
&monitor=fcf66d8e-xxxx-4c5b-xxxx-5655dcfa6c69
&target=transaction
&description=my%20monitor
&wallet=my-wallet
&blockchain=ethereum
&network=ropsten
&confirmations=6
&hash=0x69afc6e9ffa5c0ecd26451ba67081845[…] HTTP/1.1

The matched transaction, responsible for the monitor to send the notification, can be found in the hash URL Query Parameter identifiable by its transaction hash. Your predefined Query Parameters (key=value) remain untouched and will be sent along with.

Maintenance

Tangany WaaS provides the necessary functionality to keep your Transaction Monitors in a healthy state. Monitors can be retrieved in paginated lists or individually by their identifier.

Status

When retrieving an existing monitor a status will be returned that indicates its current operational state.

{[…]
"target": "transaction",
"description": "my-monitor",
"configuration": {[…]},
"webhook": {[…]},
"status": "active",
"invocations": {
"failed": 3,
"transmitted": 42
},
[…]}

A monitors’ status can be activepausedhalted and deleted, whereas deleted is only returned once — on deletion.
halted indicates an unhealthy state, likely due to infrastructural failures.
active and paused can be controlled on creating and updating requests. paused monitors will stop looking for matches and will therefore not send any notifications.

A monitors’ status request also reveals some insight about its invocations— the number of successful and failed attempts to send notifications.

Updating a monitor

A monitor can be replaced (PUT) by providing an entire valid monitor configuration. Although, the monitors id and invocation data will be preserved.

A monitor can be updated without providing an entire monitor configuration as well. If you want to stop all your monitors from sending notifications your PATCH request body should look like the following. All other properties remain untouched, only the status is altered.

{
"status": "paused"
}

Imagine the ETH fiat value is increasing and your AML monitors are triggering too late. The value filter of some monitor configuration objects is too high. Follow the RFC JSON Patch notation to update nested properties. You could update affected monitor configurations with the following PATCH request body and no other properties will be altered.

[{ "op":"replace", "path":"/configuration/value", "value":"0.1" }]

Requirements

This feature is a limited beta release and may not function as promoted. Please use with caution! We recommend testing the new Transaction Monitor feature with our ready-to-use Postman Collection. Check out our last tutorial to get a quick introduction to Tangany’s Wallet as a Service API.

Constraints

Known issues

Don’t forget to tell us what you think about Transaction Monitors in our 1-minute survey. We would love to hear about your use case and your feature requests!

For more information visit us at https://tangany.com. We’re open to any kind of feedback, so please let us know.

Take care,
Dan 🦄

Tangany is a regulated white-label custodian for digital assets and amongst other protocols highly focussed on the smart-contract blockchain Ethereum. For this ecosystem, we offer a custody service, a node infrastructure, and a lot of exciting features, like the Ethereum Gas Tank. Ethereum offers an enlarged scope of different customized smart contracts and Tangany supports all of them via our universal smart contract API — developed in-house in Germany. That means the Tangany custody solution is able to communicate with every smart contract deployed on the Ethereum network.

Next to the most common standard ERC-20 which is mostly used for fungible Utility Tokens (e.g. Initial Coin Offerings / ICOs/STO/Security Tokens), it supports moreover every possible business case like

In this article, we want to highlight three novel use cases next to the ERC-20 standard, all based on Ethereum. Moreover, we share also valuable insights about the token standard of Tokeny, which is called T-REX.

ERC-20 — the most famous ERC standard

Since 2015 the ERC-20 standard was known as the most significant on Ethereum. ERC-20 has emerged as the technical standard and it is used for all smart contracts on the Ethereum blockchain for token implementation. It provides a list of rules that all Ethereum-based tokens must follow. ERC-20 tokens are blockchain-based assets that have value and can be sent and received. The primary difference is that instead of running on their own blockchain, ERC-20 tokens are issued on the Ethereum network. The Blockchain hype during the year 2017 and 2018 was driven mostly through the issuance of a lot of different ERC-20 tokens to raise funds for new Blockchain projects. But this standard is still used in 2020 and an important instrument for the Blockchain and Ethereum ecosystem. It is also widely supported by crypto exchanges and other service providers.

Non-fungible Token (NFT) standards ERC-721 and ERC-1155

Non-fungible Tokens (NFTs) are famously gaining popularity in the collectable and gaming ecosystem, and it is one of the hyped sectors in the blockchain and crypto industry. The use cases for NFTs stretch far beyond gaming and collectables. Developers all over the globe are creating entire virtual worlds by using the ERC-721 and ERC-1155 smart contracts and we still are at the early when it comes to the mass adoption. Moreover, NFTs can be used in a wide range of different sectors, such as art, music, fashion, IoT and a lot more.

The ERC-721 standard is currently most used for any kind of collectables and crypto games to tokenize unique individual items and assets. It provides basic functionality to transfer and track the ownership of NFTs.

The ERC1155 multi-token standard allows managing fungible, semi-fungible and non-fungible tokens, often used in the gaming sector. There it has great application since such games have fungible elements (like life/energy), but also non-fungible elements like weapons and other collectables that all differ from one another.

Security Tokens standards ERC-1400 and ERC-1404

The ERC-1400 standard is specifically designed for Security Tokens, these tokens are real securities and represent any kind of real-world asset on the blockchain. The standard allows, for instance, restricted transfers, the adding of transfer information, document library management, and forced transfers. This can be achieved by combining various ERC standards, which each fulfills another aspect of the needed Security Token functionality. Therefore it has a broad range of functionalities that enable a legally confirm deployment of Security Token.

The ERC-1404 is an extension of ERC-20 standard and it allows the issuance of Security Tokens with transfer restrictions to fulfil compliance requirements. For example, it allows the implementation of a whitelist. So the issuer can selectively control who is able to buy and own the token. All token holders (investors) need to run an onboarding process with a KYC and AML check. Furthermore, it allows for human-readable messages to be implemented in case of a token transfer being reverted.

Security Tokens standard T-REX

Interms of functionality, the T-REX (from Tokeny) ranks as the most advanced standard to tokenize assets on the Ethereum public blockchain. Based on the ERC-20 standard, it supplements it with more than 100 functions to enforce compliance and manage control for the issuer, agents and investors.

The T-REX standard allows securities issuers and their agents benefit from a high level of control over digital securities. At any time, issuers and authorized agents can perform management operations such as creating or destroying securities, making transfers, blocking positions, pausing transfer activity, authorizing or revoking Investors, etc. These operations can be performed one-by-one or by batch to allow for the reduction of gas fees.

Digital Identity standard ERC-725

The ERC-725 standard is proposed for Blockchain-based identity developed by Fabian Vogelsteller, the creator of the famous ERC-20 standard. ERC-725 describes proxy smart contracts and multiple keys and different smart contracts can be controlled with it. Identity smart contracts can describe machines, objects, groups and individuals.

Why is self-sovereign identity so important? Users should be able to own and manage their digital identity instead of ceding ownership of identity to centralized organizations. In the last years, we have seen the risks and negative effects of having a centralized identity with damaging leaks and forbidden selling of user data. A portable, open standard for identities will enable decentralized governance and reputation. Every individual should be able to take and use their identity across different apps and platforms.

You want to find out more about the different Ethereum token standards, please check out the following websites:

Conclusion:

The Ethereum ecosystem and the different smart contract standards are evolving on a constant basis and a lot of new business cases arise. In this article three different use cases — Non-fungible Tokens, Security Tokens and Digital Identity — were highlighted and evaluated more in detail. All of these use cases could have a big potential when it comes to Blockchain mass adoption in the coming years.

With its regulated and highly secure custody service, Tangany supports all of the novel use cases based on Ethereum (also the T-REX standard) and provides an extensive wallet infrastructure which can be easily implemented into the client’s infrastructure via our smart API.

If you want to learn more about it, please reach out to Tangany via the websiteLinkedIn, or e-mail (julian.richter@tangany.com).

We are thrilled to announce our recent software update 1.7! In this release, we introduce exciting productivity features, usability improvements and efficiency optimizations. Let’s have a closer look at what 1.7 brings.

Total wallet count

Use GET /wallet to query the total wallet count in the current vault

Wallet public keys

Using the GET /wallet/:wallet endpoint it is now possible to retrieve the cryptographic public key of a wallet. Use the public key to e.g. verify a wallet-signed string.

Custom Bitcoin confirmations 

The configuration header tangany-bitcoin-tx-confirmations does now accept positive integer numbers to specify a custom amount of block confirmations. This influences the UTXO selection in wallet transactions & balance queries as well as the confirmation status of a sent transaction

Optional Ethereum contract body parameters

We have further streamlined our Ethereum universal smart contract endpoints by making the inputs body parameter optional. This especially benefits smart contract method calls where no input arguments are required

Asynchronous Bitcoin transactions

Similar to our Ethereum endpoints, Bitcoin transaction can now also be sent asynchronously using the new POST /btc/wallet/:wallet/send-async endpoint.  This is also very useful for tracking the status of a BTC transaction

Search smart contract events

In 1.5 we have added the ability to explore Ethereum smart contract events and query individual events via the GET /eth/contract/:contract/events and GET /eth/transaction/:hash/event/:index routes. Today we are introducing a new query parameter which allows to find individual Ethereum transactions based on the arguments of the invoked smart contract method. As an example, this simple configuration retrieves all token transactions with a particular wallet as the recipient:

Check out our documentation examples to build complex search queries using this powerful tool.

Sign and verify payloads

Each managed wallet can now be used to cryptographically sign arbitrary strings using the new POST /wallet/:wallet/sign endpoint

Any resulting signature can be either be verified against the POST /wallet/:wallet/verify endpoint using the signature’s source wallet.

Signatures that were generated the default signing algorithm DER can also be verified using  OpenSSL:

To accomplish this the verifying party requires the knowledge of the signing wallet’s public key. The hexadecimal public key from GET /wallet/:wallet needs to be converted to PEM format and saved to a file (“key.pub”). We have provided an example script to showcase how to accomplish this conversion.  Also the resulting hexadecimal signature needs to be saved to file in binary form (“signature.bin”). At last the to-be verified payload text has also to be saved to a file in order to be verified via OpenSSL (“payload.txt”).

Execute the following command to verify a payload against the signature in OpenSSL:

openssl dgst -sha256 -verify key.pub -signature signature.bin payload.txt

Array type arguments in Ethereum contract calls

Our Ethereum smart contract call endpoints have become even more flexible and do now support array type input arguments

Make sure to check out our complete change log here and subscribe to our newsletter to stay up to date with our newest developments

Ethereum is the major blockchain when it comes to tokens, tokenization, and also DeFi projects. However, the increase in popularity comes with its costs. The more users and projects are relying on Ethereum, the scarcer the resources. Ethereum is still very limited to transactions per second. No more than about 12 transactions per second. These 12 transactions are distributed between all entities globally.

To visual that, let’s take a view of the average fee per transaction over the last five years:

source: https://blockchair.com/ethereum/charts/average-transaction-fee-usd

You can clearly see the three spikes. The first one occurred in late 2017 with the success of ICO. Initial Coin Offerings was (and still is) the activity to issue newly created tokens on Ethereum and to sell them to the community. Ideally, this sparks the project behind the tokens to be successful. Hundreds of ICO were done in summer 2017 – per week.

The second spike was shortly after in summer 2018 with the launch of Cryptokitties. The card game was revolutionary. It allows players to create, trade, and collect cards with different kitties and every one with its own design and attributes. Every trade was reflected in Ethereum. Well, it’s kind of obvious that if several thousand players try to trade cards on an infrastructure that it is only able to manage about 12 transactions per second – globally. As the hype around Cryptokitties declined, the fees decreased as well.

The third, and current spike in late 2020, is rooted in the rise of DeFi. Decentralized Finance promises to enable people to take their finance into their hands without any middleman. Staking and lending are some of the buzzwords.

As long as Ethereum has such limitations, spikes like the past three will occur again. This might change with the upgrade to Ethereum 2.0 which aims to manage several thousand transactions per second.

However, it’s fully unclear when this upgrade will be released. We at Tangany don’t expect to see full 2.0 before 2023. This is why we, together with our partners, have identified alternatives to reduce network fees.

Omnibus Wallet Architecture

It’s common best practice to use one wallet per user. For one, this reflects the original idea of blockchain the best and secondly, there are (nearly) unlimited numbers of wallets available.

This is also the approach we and our partners see with most. Exceptions are exchanges (for the same reasons) that are using the omnibus wallet since the beginning.

An omnibus wallet architecture means that instead of using one wallet per user, to switch to a centralized form. Only one or a couple of wallets are being used for all users. With that, transactions are no longer done on-chain but off-chain. If an asset is to be allocated to another user, this record will not be on the blockchain. Therefore, zero transaction fees.

The tricky part is to have a powerful off-chain ledger in place. And with that, we don’t mean a .csv file. This ledger could be something like a private blockchain (we generally recommend Quorum for that purpose). On this private blockchain, every user will have it’s own wallet again. These wallets will mirror all the assets. It’s some kind of customized second-layer solution for Ethereum.

So, if a user wants to know his balance in the omnibus wallet, we only have to take a look at his non-disclosed private blockchain wallet. So if a transaction should be done it will only be executed on the private blockchain.

As the private blockchain comes with zero transaction fees and higher scalability, there are no restrictions. It is even possible to implement an explorer for transparency reasons if required.

That leads to reduced transaction fees of 100%. Such an architecture can also be used for other blockchains like Bitcoin, Tezos, or EOS.

From a legal point of view, this is doable within the European Union as it was validated by Tangany. This includes cryptocurrencies, stable coins, and security tokens.

Ethereum Second-Layer Solutions

In the past few months, a few second-layer solutions have emerged. Those solutions are way more matured now compared to a couple of years before. Namely Polygon (formerly known as Matic) is a highly demanded solution to overcome the limitation of Ethereum. Polygon is 100% compatible with Ethereum and enables to send assets back and forth between those two blockchains.

Polygon can also be used via the Tangany API and enables the functionality to migrate back to Ethereum once the scaling issues are settled which should be the case with the Ethereum 2.0 phase 1 upgrade.

In our view at Tangany, this seems to be a quite simple but efficient method to save on the network fees. If you would like to learn more visit https://tangany.com.

Migration to another blockchain

Depending on the business case, migration to another blockchain could be reasonable. If the project hasn’t officially started yet even better.

No matter if migrated or directly started on another blockchain, leaving Ethereum comes with its pros and cons. The pros are often higher scalability and with that way lower transaction fees. We are speaking here up to 99% lower.

However, we have to consider also the cons. The most important one is for sure that Ethereum is some kind of market leader for tokens. Leaving the platform might make it harder to get the token supported on 3rd party services like exchanges. Additionally, Ethereum is quite well-known, tested and validated for 5 years.

Similar alternatives to Ethereum are EOS, Binance Smart Chain and Tezos. Those three blockchains support smart contracts, have often a similar technical architecture and are also considered to be reliable. At Binance and Tezos it’s even possible to re-use the same wallets as on Ethereum.

The migration can be done quite easily. All tokens need to be redeployed on the new blockchain. If the same wallet can be used, the tokens will be distributed automatically. If a new wallet is required (because the blockchain uses another cryptography), those are generated first before the tokens are distributed accordingly.

Efficient Smart Contracts

Another, less radical approach compared to the ones before, is to optimize the smart contract. The higher the complexity of the smart contract, the higher the fees. That is why a smart contract should be as simple and small as possible. Remove all unneeded functions and check if the code can be simplified. Maybe even validate whether some functions could be done outside of the smart contract such as the management of a whitelist.

With that we have seen decreased network fees by 33%.

Optimized Gas Estimation

For every transaction, there is the possibility to set the amount of fee. Depending on the urgency of the transaction, the included fee can be reduced. The less fee is included, the longer it takes until the transaction is executed.

As the fee level is very volatile it is recommended to recheck the current market price for transactions. By not using outdated market prices it is possible to save about 25% of the fees per transaction.

Another benefit by using the latest market price is that transactions can be timed. This means, the approximately time until the transaction is executed can be estimated. By using a Gas fee which is 25% below the market price, it will take slightly longer. By 25% above it will be faster.

That optimization can easily be done with Tangany Custody Suite and our powerful API which comes with an in-built solution for that.

Conclusion

No matter what activities are done on Ethereum, the limitation of scalability will still be part of that for quite some years. Avoiding high Ethereum transaction fees is always a good project to tackle.

Tangany has accumulated a lot of experience with that in the past years and our API is able to provide out-of-the-box solutions in most cases.

Feel free to reach out at info@tangany.com or visit us at https://tangany.com.

The release of Tangany Custody Suite 1.5 included a powerful engine to read historical information of wallets and smart contracts on Ethereum. This article will take a deep-dive to explore the capability of that feature from a technical perspective.

Our Read API provides four new API endpoints. The endpoints enable user-friendly browsing and reading of all transactions and events on the Ethereum blockchain.

1. Transactions

Using the route GET /eth/transactions, every transaction on the Ethereum blockchain can be searched. Different search parameters and sorting options can be provided via the URL. The result includes the number of hits found, a list of transaction hashes found, and pagination links to get further results of the same search.

Search Parameters

Individual parameters are combined and sorted in a similar way to an AND operator. A transaction search can be defined using the following parameters:

Sorting Options

Search results can be sorted based on transaction properties. A selection of sorting options is available for this:

Search Results

A search result always contains three values: number of hits, list of hits and pagination links. The return of a transaction search that finds no hits looks like this:

{
  hits: { total: 0 },
  list: [ ],
  links: {
   next:null,
   previous: null
 }
}

The number of search results is conveyed via the hits.total value. This can be between 0 and a maximum of 10,000.

The list value contains an array of search results. A search result is formed based on the hash of the found transaction and at least one possible link for retrieving the resource.

{
 hash: "0x1d143d9696851b5ced...",
 links: [ {
  href: "/eth/transaction/0x1d143d9696851b5ced...",
  type: "GET",
  rel: "transaction"
 }]
}

In case there is a pagination, the results include two links for the next page and the previous one.

Example

/eth/transactions?to=0xda[shortened]ec7&iserror=true&sort=valuedesc&index=100&limit=50

Here, all faulty transactions are searched for in which the transferred address is entered as the recipient. The return contains a maximum of 50 transactions, with the first 100 search results being skipped. Furthermore, the search results are sorted in descending order according to their transmitted value in ether.

2. Wallet Transactions

Using the route GET /eth/wallet/:wallet/transactions, all transactions of a wallet can be searched. This route forms a shortcut to the transaction search as all search parameters and sorting options can be used.

Without specifying parameters, the search returns the transaction history of the wallet, i.e. all incoming and outgoing transactions.

Search Parameter Direction

In addition to the transaction search, the wallet-based search offers another search parameter: direction 'in' | 'out'.

This parameter enables the filtering of search results according to incoming or outgoing transactions of the wallet without specifying specific addresses. The direction parameter cannot be used with from or to search parameters at the same time.

/eth/wallet/:wallet/transactions?direction=in, for example, returns all transactions on the wallet starting with the latest.

3. Contract Events Search

With the API endpoint GET /eth/contract/:contract/events, events of a smart contract can be searched. As with the transaction search, search parameters and sorting options can be passed to define the search.

Search Parameters

Sorting options

Search Results

The search results contain the number of hits and pagination links found, if available. The result list is structured similarly to the transaction search. It contains an array of hits, each containing the name of the event and at least one possible link to get the resource. This URL has the respective transaction hash and log index. Since several events can be assigned to a single transaction, the log index of an event is used for unambiguous identification.

{
 "hits": {…},
 "list": [{
   "event": "transfer",
   "links": [ {
     "href": "/eth/transaction/0x2882c9[shortened]f7b852332/event/69",
     "type": "GET",
     "rel": "event"
 }]
 }],
 "links": { … }
}

4. Contract Event

If a search was carried out for smart contract events, URLs for the respective hits can be found in the search results in the following format: GET /eth/transaction/:hash/event/:index.

Individual events and their properties can be called up via this API endpoint. :index is the LogIndex of an event that is required for unambiguous identification. The return for the following request /eth/transaction/0x2925c9[shortened]b877052332/event/69 looks like this:

{
 "event": "transfer",
 "contract": "0xdAC17F958D2ee523a2206206994597C13D831ec7",
 "timestamp": 1594033889,
 "transactionIndex": 80,
 "logIndex": 69,
 "blockNr": 10405547,
 "inputs": [{
    "value": "0xB364B4db2e46474B86F411E272e64B59c488e1Cc",
    "name": "from",
    "type": "address"
   }, {
    "value": "0x45E0b446f02F29B33e2E7532D84b0F99c66c6BD4",
    "name": "to",
    "type": "address"
   }, {
    "value": "400000000",
    "name": "value",
    "type": "uint256"
   }]
}

Conclusion

Reading the information on transactions and events on Ethereum can be tricky as there are various parameters that have to be included. There are also public services like Etherscan to execute the task of reading, yet it’s more useful to have only one 3rd party API to fulfill all tasks such as wallet creation, custodian service, and reading API.

For that, we at Tangany have released our own reading solution. That can be used with our existing unified API. Easy, reliable, and scalable.

Receive the latest news

Tangany Newsletter