Jump to content

Xrpl payment channels


Recommended Posts

Payment channels do not currently support IOUs; they can only transfer XRP. If someone was interested in coding up IOU support and submitting the changeset as a PR, that'd be cool.

Link to comment
Share on other sites

If a payment channel is used, can there be Information ( e.g. destination tags) included for each micropayment or only for the summary of the payments if the channel is closed ?

Link to comment
Share on other sites

Thank you for the Information-link!

But i could not find if it is possible to send some Information along with each micropayment before the channel is closed.

Link to comment
Share on other sites

The idea is following:

Two companies or institutions establish a payment-channel for a certain amount of time and forward multiple payments of different customers through the channel. Is it then possible to add some Information to each single payment to assign it to different customers correctly?

Link to comment
Share on other sites

The details for each claim (e.g. "micropayment") are created using the channel_authorize method: https://xrpl.org/channel_authorize.html. There's no option there to include a memo or other identifying information.

In any case, the claims are sent off-ledger, so I guess the idea is that whatever system is sending and receiving the claims, should also keep track of what each claim refers to?

Link to comment
Share on other sites

Thank you nikb and at3n for your reply!

I think at the moment and in the near future the xrpl has enough capacity to handle every incoming transaction. But in a few years from now, paymentchannels will be very important to deliver the capacity to process millions of transactions per second, when every thinkable value will be transfered through the xrpl.

Therefore in my opinion some amendments have to be added (paymentchannels for iou's and Memos for every "micropayment" as long the channel is active). Then the capacity for payments is endless, if you think of networks of paymentchannels operating parallel with the xrpl settlement!

Link to comment
Share on other sites

1 hour ago, dibbru said:

Thank you nikb and at3n for your reply!

I think at the moment and in the near future the xrpl has enough capacity to handle every incoming transaction. But in a few years from now, paymentchannels will be very important to deliver the capacity to process millions of transactions per second, when every thinkable value will be transfered through the xrpl.

Therefore in my opinion some amendments have to be added (paymentchannels for iou's and Memos for every "micropayment" as long the channel is active). Then the capacity for payments is endless, if you think of networks of paymentchannels operating parallel with the xrpl settlement!

Why would you need an amendment? Individual "micropayments" never hit the ledger. The micropayment information is exchanged entirely off-ledger. That's the whole point of payment channels.

Link to comment
Share on other sites

The transacting companies could manage their customerdata off the xrpl ( i think e.g. revolut does not activate one xrpl account for each customer) and only the sum of the customer balances is shown on xrpl, but they need the paymentinfo to assign the payment to the right customer in their database.

Link to comment
Share on other sites

But as Nik said, the micropayments are never seen on the ledger; only a relatively small number of claims are redeemed, which each bundle a lot of micropayments together. The only time anything is recorded publicly is when the micropayments are redeemed in bulk, and that's done by the recipient of the XRP, not the sender.

If the sender was able to include an arbitrary reference with each claim, that doesn't really add much value anyway - all it would do would enable the recipient (not the public) to see the transaction reference. But the sender and receiver are already communicating, so why not just have the sender send the transaction reference alongside the claim using whatever messaging protocol they're already using? No need to cryptographically sign that information. Only the data relevant to the value of the claim needs to be signed, because that gives assurance to the recipient that they will definitely receive the value, as long as they redeem it on time.

Link to comment
Share on other sites

Posted (edited)

Ok, an additional messaging channel would be a possibility ( could be xcurrent ?). But payment-channels for IOU's (also think of CBDCs) would be an improvement.

Edited by dibbru
Link to comment
Share on other sites

50 minutes ago, dibbru said:

Ok, an additional messaging channel would be a possibility ( could be xcurrent ?). But payment-channels for IOU's (also think of CBDCs) would be an improvement.

It should be relatively simple to add such functionality, and I’d welcome someone submitting the PR.

The challenge is that asset issuers would have to add support for such channels to ensure that their accounting of outstanding issued assets continues to be valid.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share



×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.