One of the key use cases that Kyber enables is decentralized payments in ETH and ERC20 tokens as recently outlined in a Coindesk article. As we integrate with more services and DApps that use decentralized token payments, one issue we discovered across these applications is the difficulty in tracking payments made by smart contracts, which hinders the adoption of decentralized token payments in the ecosystem.

To address this pain point and help drive adoption, we have created an Ethereum Improvement Proposal (EIP) for ERC1257 that proposes a Proof Of Payment standard to record payments made by both humans and smart contracts. The first implementation recently went live on the mainnet.

In this post we explain the motivation behind this ERC standard, what the specification will provide, and how Kyber will be using it.

We hope that the ecosystem will rally around this standard, resulting in easier sharing of payment and transaction information across the whole ecosystem for both technical and accounting purposes.

The Motivation For ERC1257

To drive greater adoption of decentralized token payments, it would help a lot to have some form of standardization of the record of payment made. Without a unified standard for proof of payment, collaboration and development of important tools such as accounting applications and payment libraries become difficult.

Making It Easier To Track Smart Contract Payments

Currently, online merchants and vendors use transaction hashes and unique deposit addresses to track user payments as payment receipts. This approach comes from bitcoin payment methods where payments are done by humans with a dedicated user interface.

However, this approach cannot apply to payments that are done directly by smart contracts, such as multisig wallets, DAOs and exchange services due to the difficulty in tracing and parsing payments done by “internal transactions”.

While different approaches have been developed to handle payments done by smart contracts, the lack of a unified standard makes it challenging to create tools that require the merging of payment traces from these different solutions.

Removing The Need For Multiple Deposit Addresses

A second motivation for standardization comes from removing the need for multiple deposit addresses. For merchants, simply tracking the amount and transaction hash may not be sufficient. For example a payment may have to reflect the order ID as well. To tackle this problem, one popular method used by merchants is to open unique deposit addresses where one order ID corresponds to one deposit address.

Unfortunately, this method of utilizing multiple deposit addresses for ETH and ERC20 token payments becomes a hassle due to gas issues, where the merchant needs to pay gas for

Sending ETH to these deposit addresses which will be used to pay for gas for step 2 Making an ETH / ERC20 token transfer to a consolidated wallet address once payment is made

Therefore there is a need for a more systematic way to include order information with ETH and ERC20 token payments in addition to logging and recording them so that it does not require multiple deposit addresses to be used.

The ERC1257 Specification

This specification standardizes a set of basic parameters to log payments through an EVM log. The parameters are as follows:

event ProofOfPayment(address indexed _payer, address indexed _payee, address _token, uint _amount, bytes _data)

where

_payer denotes the entity which made the payment _payee denotes the entity which received the payment _token denotes the token the payment was made in _amount denotes the amount paid in basic token units _data denotes application specific auxiliary data

Note that _amount does not include change given back to _payer. It should only be the amount that _payee receives.

With the introduction of this standard, the need for multiple deposit addresses is removed, while facilitating the recording of decentralized token payments from both humans and smart contracts.

Encouraging Ecosystem Collaboration

As mentioned earlier, it would be ideal for all protocols, merchants, and applications developers to be able to independently build their payment mechanisms and related services (Eg. plugins, widgets, accounting applications) while being able to collaborate on the key aspect of transaction tracking and accounting.

Merchants receiving payments via smart contracts can adopt this standard, especially for the ones that incorporate token conversions, where incoming ERC20 token payments are converted to a preferred token, including Ether.

Any entity who makes payments via smart contracts such as multisig wallets, DAOs, and identity proxy contracts can also adopt this standard for their own usage, such as for accounting purposes.

The development of 3rd party applications that rely on transactional information like accounting applications, payment libraries or e-commerce integration toolkits is made smoother should the standard be widely adopted.

How Kyber Will Be Using This Standard

At Kyber, we are committed to encouraging collaboration between various parties and helping to drive the state of decentralized payments forward. As such, we will be working on helping to push this standard along in a variety of ways.

Firstly and most obviously is this EIP. It is supported by a payment contract which implements the ERC1257 standard. Our widget will interact with this payment contract. Whenever an entity makes a payment via the widget, an event log is emitted by the payment contract, which can then be used to track the payment. Hence, companies who have integrated our widget should find it easier to monitor and process payments.

This standard will also be referenced and supported in both current and upcoming tools that power the payment use-case, such as a WooCommerce plugin to enable WooCommerce sites to easily accept ERC20 token payments.

Furthermore, we will be working with all our existing and future partners who use smart contracts payments in their platform to implement this standard as part of their payment flows. This will help drive overall awareness and usage of this standard and highlights the importance of collaboration to improve payment flows.

Conclusion

By working with our existing partners as well as new ones to adopt ERC1257, we are aiming to foster collaboration to improve payment flows within the ecosystem. We believe that when all the different stakeholders work together seamlessly, this will increase adoption of decentralized token payments.

The usage of this standard enables decentralized entities in the ecosystem like DAOs and multisig wallets to conform to a standardized and generic proof of payment, and therefore allows for easier tracking of payments by monitoring events with web3 tools.

You can learn more about the ERC1257 standard on the Ethereum github issue page. We are very excited to see how it can be adopted in your projects.

If you have any feedback or questions, you can find us in the Kyber Developer telegram group.

About Kyber Network

Kyber’s on-chain liquidity protocol allows decentralized token swaps to be integrated into any application, enabling value exchange to be performed seamlessly between all parties in the ecosystem. Using this protocol, developers can build innovative payment flows and applications, including instant token swap services, ERC20 payments, and financial DApps — helping to build a world where any token is usable anywhere.

Telegram group: https://telegram.me/kybernetwork

Reddit: https://www.reddit.com/r/kybernetwork/

Twitter: https://twitter.com/kybernetwork/

Website: https://kyber.network/