Motivation

Search…
Motivation
Why another payment channel system?
Kchannels is the end result of an observation we made about the Ethereum ecosystem: it has remained largely the domain of tech enthusiasts who actively work towards developing the technology. While this is excellent and much-needed for producing the tools and techniques needed for any feature-rich ecosystem, it does not necessarily mean it is being developed towards addressing the needs of any particular group of business users so it may get a big much-needed boost into the mainstream. At Kchannels we believe the two should go hand-in-hand, and we have developed Kchannels as a system designed to address real-world commerce usecases without sacrificing the user experience both merchants and customers have grown accustomed to and depend on. Our goal is to bring the entire Ethereum ecosystem as another cheap, transparent and accessible, payment network available to merchants and customers to connect with and exchange payments for goods and services. With Kchannels we hope to bring Ethereum payments into the mainstream.
What's different?
Kchannels is a payment channel solution designed for commerce from the ground up. It is the first, and currently only, such solution that brings everything merchants and customers needs to conduct business in the Ethereum ecosystem under one roof without any added burdens. Our goal is to bring the Ethereum ecosystem into the mainstream by offering a comparable, convenient, and affordable alternative to the traditional currencies used for commerce, one backed by the Ethereum ecosystem.
We have identified that commerce usecases demand the following very specific properties of their underlying payment providers, be it a payment channel, or a traditional payment solution, in order to create a sustainable user experience that would be both acceptable to customers, and conductive to large-volume fast-turnaround sales demanded by businesses:
Fast Time to Transaction Confirmation - this is the time it takes for a customer-initiated transaction to receive a confirmation. If a payment solution takes more than 2-3 seconds to make a decision on whether a payment is being properly authorized, the delay becomes noticeable and the customer might get worried, or impatient, or even back out of the sale altogether. Also, in a retail setting there might be a line of customers forming behind the point-of-sale, with the last ones giving up and walking away.
Strong Finality - once a transaction completes there can be no additional steps required to ensure it "sticks". There can be no ambiguity at any point in time whether or not the transaction has taken place: once a properly-executed transaction is observed, it must in itself constitute a complete and non-repudiated proof that a payment has been made and the merchant can now safely hand over the goods, or provide the services being paid for.
Guaranteed Assets - a payment solution, however implemented, must actively protect both parties from loss of assets. It is not acceptable to shift this burden for ensuring asset safety to end users as this would drive them into a more secure form of payment such as cash. Without this important property a payment solution has only limited applications, e.g. low-value payments, as it undermines the confidence users have in the system.
Friction-Free Movement Of Assets - a payment solution must allow the free unimpeded flow of assets in and out. Putting barriers to users' access to their funds creates the impression of them being "locked in", or "locked out", thus undermining the users' confidence in the resulting system. Most users simply won't bother using it and opt for something else.
Multiple-Asset Support - a payment solution should make as few assumptions as possible on the types of assets being transferred in a transaction. Making such an assumption is once again putting barriers to entry for users as they now have to exchange their assets first into something acceptable.
We noticed that only the traditional payment solutions of today manage to fulfill all of these criteria at the same time, and as a result have managed to maintain a near-monopoly over electronic transactions over the years the various blockchains of today have been available. We also noticed that the concept of a blockchain is very attractive to businesses as the costs of doing business this way are often significantly lower, yet there have been very few adoptions of this technology to date for the purposes of commerce.
The concept of a blockchain made the promise of a trustless and decentralized commerce, yet fell short of gaining traction in this regard because of its slow time to transaction confirmation, which is further exacerbated by throughput limitations observed on occasions. It did, however, gain traction as a place to safely store assets, including large-valued assets, in a decentralized trustless environment. Indeed this is the safest way to store digital assets today. "Layer2 technologies", ones performing transactions off-chain but still allowing those transactions to be enforceable on-chain, offered a unique opportunity to remake this user experience to better fit the needs of commerce, but once again existing solutions have failed to gain traction in all but select fringe situations, e.g. high-frequency low-value payments. The problem this time is cumbersome restrictions many of these systems place on their users that once again compromise the required user experience needed for wider commerce:
Always-On Always-Connected Infrastructure: transactions are only "final" if the payment channel users are constantly and policing the blockchain for fraudulent settlement requests against their channels, or else have settled their channels already. Failing to do so may result in loss of assets. This is a significant burden as not all clients are capable of or willing to do so at all times: a mobile device may not have the always-on network, or battery life, to monitor the blockchain for a long period of time; a web browser window may not be able to take action to secure customer assets if accidentally closed.
Locked-In Assets: assets are often "locked in" until a predetermined "dispute period" lapses, or unless both parties happened to cooperate for a faster channel settlement. The latter will not normally be the case as a counterparty in consent has no direct incentive to spend gas, and the former results in lost sales as customers may not be able to engage in commerce while their assets are locked in place.
Locked-Out Assets: assets can only be deposited at the beginning of the interaction with the payment channel, making it very difficult and cumbersome for a business to handle "walk-in" or "upsell" situations: two very important streams of revenue for any business. This limitation is highly problematic.
Amortization Of Blockchain Overhead: with assets not guaranteed unattended, a typical customer interaction changes in order to manage their risk exposure: the use of a payment channel now becomes short-lived. A customer deposits funds they have committed to spend in advance, performs a series of predetermined transactions, then settles their channel and withdraws any remaining funds, all while actively monitoring the blockchain. This makes payment channels very difficult to justify as this process involves at least 2 blockchain transactions and most commerce interactions only involve one or two payments, usually at the end of some sort of a sales flow. This is currently limiting the appeal of payment channels only to situations where a large number of in-channel transactions is expected.
At Kchannels we have built a Layer2 payment channel solution which manages to offer all the necessary features listed above with none of the pitfalls, while still being a trust-minimized non-custodial payment channel solution with a built-in dispute-resolution mechanism. This creates a user experience that allows, for the first time ever, a payment channel to be integrated into a sales flow, right next to more traditional payment methods such as cash, or credit card. It is usable in both a retail setting, by acting as an additional tender at the Point Of Sale, as well as an e-commerce environment, by presenting a very PayPal-like payment flow. All this while still offering all the benefits of the Ethereum ecosystem and the ability to dispute on-chain.
Why the different architecture?
At Kchannels we put the needs of our target business users front and center, and let their requirements drive our architecture from the get-go. Based on our analysis it quickly became very apparent we cannot always follow in the footsteps of the giants in the Layer2 space. We had to go our own way and built a system that works for what we are trying to do. We made different choices and predictably arrived at a different architecture.
Unexpected benefits
We created an architecture to address the needs for commerce, but quickly realized our new architecture can be used to address other problems with payment channels today, as well as the Ethereum ecosystem at large. We ourselves are still discovering all the different ways to harness the full potential of our new architecture, but here is an important one that changes how one thinks about payment channels altogether:
Layer2 as the new default "layer" for users within the Ethereum ecosystem: Onboarding users from fiat into payment channels, where all the interesting commerce happens, today is a truly dreadful experience: First the user has to onboard into the underlying blockchain, which often demands navigating exchanges, gas fees, and blockchain propagation delays. Only then can they onboard into the payment channel by moving their assets into a smart contract: more gas fees, more propagation delays, and more steps to perform. In some cases this can take hours. Kchannels, however, can accommodate on-ramps as users within the deployment directly: they are just another user to us. With our long-lived channels, final transactions, and guaranteed assets, any user can onboard themselves into Kchannels in seconds, often with just a few clicks/taps, and be ready to transact with anyone both on the Ethereum blockchain, and within the Kchannels deployment. With an on-ramp set up as a service within Kchanenls, the process is no different than setting up a coffee card, and a user is immediately enabled to transact with anyone! And, of course, they are still free to exit into the underlying blockchain, or back to fiat, should they ever choose to do so.
Introduction - Previous
Technical overview
Next - Introduction
FAQ
Last modified 1yr ago
Copy link
On this page
Why another payment channel system?
What's different?
Why the different architecture?
Unexpected benefits