Transactions

Kchannels has a notion of transactions that is distinct from the transactions on Layer1 Mainnet. A Kchannels transaction is a transfer of one or more assets from one user to another user. Both users are simply addresses of the same type and format as those on Layer1 Mainnet, and in the context of Kchannels merely indicate sender/owner of a sender channel transferring assets into a channel owned by the recipient address.

A transaction is always initiated by the user (specifically, any one of the sender addresses in the channel definition). A zone can never initiate a transaction on behalf of a user.

Given a recipient identity, the sender zone will attempt to discover a channel definition with the recipient as an owner, and then attempt to draft a transaction against it, and return it to the sending user for review. This is how most transactions begin.

A transaction must always terminate at another user's channel. This means that a transaction involves not one, but two, channels, which "come together" briefly during the course of a transaction. A transaction temporarily locks both the sender and recipient channels, and no other transactions are possible on those channels until the first transaction completes. For more information, see Channels.

The sender and recipient channels may belong to the same or different zones. In the latter case the two zones internally work together to make sure they are on the same page regarding the transaction. In all situations a user talks to the zone with which he has an open channel. There is no need for route discovery as all zones can directly interact with each other over a private network.

Finality

Once a transaction completes, there are no additional steps required to ensure it "sticks". There is no ambiguity at any point in time whether or not the transaction has taken place; once a properly-executed transaction is observed, it constitutes a complete and non-repudiated proof that a payment has been made. At this point, a merchant can safely hand over the goods or provide the services being paid for as there is no situation where an action not initiated by the merchant themselves will result in it being "voided".

Kchannels' notion of finality extends to Layer1 as well because assets transferred by a transaction can be immediately withdrawn from the deployment if desired. Also, Kchannels actively shields a user from the "finality fuzziness" of a PoW blockchain, creating a very familiar, consistent, and deterministic user experience in all situations.

Fees

A transaction is assessed a fee as specified by the rating ID in the channel definition. Fees are intended to be competitive with Mainnet gas and indeed with the fees in the legacy financial system. With Kchannels needing less upkeep than other payment channel implementations, those fees will also be competitive with those of other Layer2 systems.

A transaction between two channels will have two sets of channel definitions with two distinct rating IDs. The two rating IDs are fed into a rule engine inside the sender zone, which then calculates the fee owed, as well as who owes it. It is possible to attribute the entire fee to sender, or the recipient, or to split it between the two. It is also possible to monetize by a fixed fee charged "per use", or by commission, or even via a flat fee for a given period of time. It is also possible to have a completely free channel.

There are a few exceptions to the usual handling of fees:

• Incoming asset transfers are always free (the channel owner is already paying gas fees).

• Transfers between channels belonging to the same owner are always free.

• Transfers from a channel to a Layer1 recipient are charged our best gas fee estimate to submit a transaction to the blockchain.

Transaction fees charged are final once the user signs the transaction; it is the zone's responsibility to estimate and quote a correct and sufficient transaction fee to pay for gas in the first place. Kchannels does not seek to profit from gas charges, though it being an estimate until the transaction actually posts, the final gas fees paid might end up being different by a tiny amount. Kchannels is not interested in profiting from gas charges.

Modes

In Light Mode, the communication goes as follows: sender > sender zone > recipient zone. A Light Mode transaction contains three signatures, one from each of these actors. In Light Mode, the user has delegated his Zone to receive transactions on his behalf, so his channel can be completely unattended and still receive assets.

In Watchtower Mode, the communication also includes the recipient: sender > sender zone > recipient zone > recipient. It therefore contains four signatures. The user is responsible for maintaining his watchtower software, and if it is for some reason unavailable during the transaction, then the transaction fails.

External transactions

Kchannels also has a notion of external transactions. In an external transaction, a user transfers one or more of their assets to an address on the blockchain, which means that their in-channel transaction results into a Layer1 blockchain transaction. An external transaction is signed by the user and by his zone, and it necessarily triggers one or more assets to be transferred out of the Kchannels smart contract.

A Kchannels user trying to interact with someone not part of the Kchannels deployment, would result channel discovery to draft an external transaction. In addition to this, a user may force an outgoing transaction to go on the blockchain, possibly to withdraw assets from Kchannels. Whatever the reason, external transactions make it easy to interact with the blockchain from within a channel. This is effectively turning your channel into a wallet in the cloud.

A zones makes every effort to ensure an external transaction is mined, including resending the same transaction with a higher gas price if it is not mined. If a transaction cannot be delivered to the blockchain for whatever reason, its assets will finally be returned to the channel.