Announcement: Swaptacular is ready for production

[Evgeni Pandurski]

https://swaptacular.github.io/2025/09/18/ready-for-production/

If you are interested in deploying your own set of Swaptacular
nodes, do not hesitate to contact me here or at my personal email.

--
Evgeni Pandurski
Github: https://github.com/epandurski | PGP public key:
https://raw.githubusercontent.com/epandurski/myfiles/master/public.asc

[Johan Nygren]

Evgeni, would something similar to what Michiel De Long uses in Ledger Loops make sense for your vision?

Michiel does the multi-lateral clearing entirely decentralized, by using "chunked clearing" with 2-phase commit (similar to what Interledger wanted to use for payments but there it does not work as you need to guarantee bandwidth, for example, whereas in clearing it does not matter). I think.

If it would make sense, you might be interested in that my path-based redistribution automatically also clears loops. The tax hops from person to person until it reaches people without income. So if there is a multi-lateral clearing loop, you get it cleared by the redistribution.

It is like two birds in one stone. I noticed this many years ago, and in the tests I published here when I first built my implementation, you would see such looping.

In my Ripple+Resilience implementation, my direct payments currently have a credit limit. If I just remove that, people can do multilateral clearing payments too (without need for a credit limit, the credit limits are mainly for the multihop to avoid "transitivity of trust" problem of people abusing from many hops away). It then does equivalent to Ledger Loops but with Resilience for the clearing. Thus people could have credit limits for those they trust a lot, but use multi lateral clearing (to people where their credit limit is set to 0) with more peripheral people in the community.

And a stand-alone version of multilateral clearing by tax redistribution is roughly half the code of Ripple with tax redistribution. Much simpler.

I don't know how you do the clearing in your architecture, but maybe you find the idea to clear by... redistribution of basic income, interesting.

Each person decides the tax themselves in Resilience, it sets the "width" of their IOU links, and people compete to "steer" or govern (kyber...) the redistribution based on the width. Thus paying no tax, you are excluded from the governing of the redistribution flow (but can still make payments...)

Johan

[Evgeni Pandurski]

Johan Nygren <joha...@gmail.com> writes:

> Evgeni, would something similar to what Michiel De Long uses in
> Ledger Loops make sense for your vision?

From what I have read about Ledger Loops, it is basically the same
concept that Circular Multilateral Barter (and Swaptacular) use.
Ledger Loops insists on being decentralized, and this is a good
thing, but the technical difficulties of implementing a
decentralized solution are big, and make such a solution
impractical in the beginning. Once the concept is proven in
practice, maybe solving these difficulties will be feasible.

>
> Michiel does the multi-lateral clearing entirely decentralized,
> by using "chunked clearing" with 2-phase commit
> (similar to what Interledger wanted to use for payments but
> there it does not work as you need to guarantee
> bandwidth, for example, whereas in clearing it does not matter).
> I think.
>

In my experience, when people talk about multi-hop transactions,
they think either about payments, or circular clearing of debts.
I believe this is a huge oversight.

I believe having decentralized payments and decentralized circular
clearing of debts would be good things, but they are not *the
important thing*. And the important thing (the elephant in the
rum) is *the mechanism of money issuing*. Nobody cares if payments
and debt clearings are decentralized, if the mechanism of money
issuing is inefficient (that is: centralized, unjust, or
unreliable).

The goal of Swaptacular is to use circular trades (loops) to allow
money to be issued in a decentralized network. A dumbed down
picture of this would be: money is created in virtual loops, and
gets spent in the real economy. The important thing to notice is
that this scheme is exactly the opposite of debt clearing.

The other important thing to notice is that the only activity that
*must be* decentralized is the process by which "the network"
issues money (in the form of various peoples' currencies). All
other the activities that the users in the network may participate
in, like making payments *do not need to be decentralized*. Sure,
it would be nice if they are, but this is not critical.

The only thing that is *really critical*, however, is that the
*the mechanism of money issuing* is decentralized. All engineering
choices made in Swaptacular are based on this premise. The most
important properties of Swaptacular as a system are:

1. Money issuers may setup their own servers that manage their
currencies. Thus, they may, but do not need to rely on
public/shared/cryptonized solutions.

2. Circular trades (loops) are the primary mechanism of money
issuing. Circular trades are currently performed on dedicated
servers (although, everybody can run such a server). Note however,
that even if there is only one such server operating in the whole
world, this server will still orchestrates a *decentralized
process by which "the network" issues money*.

To conclude: Making distributed programs is really hard.
Therefore, we should focus on decentralizing only the most
critical aspects of the system. The most critical aspect of every
financial system is money creation. The "Swaptaular network issues
debt-based currencies by performing circular trades (finding
loops).

[Johan Nygren]

If it is multi-lateral clearing where each vertex in graph is a person and not a community, how is money issuance a problem? It is just two people, keeping a balance together. The only problem seems to be Two General's problem and that's solved with making one side the general. There is two options there. Either, give debtor or creditor the authority (and this is what you seem to focus on). Or, you can use a strict turn-taking protocol so that the relationships behaves as a single entity (what I called "Lockstep" and which I used in my first version of my Ripple implementation and it works perfectly). Based on interacting with you and Melvin, I noticed that maybe it was easier for now to limit myself to the unilateral authority approach (debtor/creditor) since it would be too complex for people to follow along the bilateral authority approach (here was when I decided that). But, for any protocol using "collateral" on top of the person-to-person balance, like Lightning Network or Raiden Network, they need to use the strict turn-taking approach, I think, creditor/debtor simplified version is not predictable in sequence of events, I think. My "Lockstep" was inspired by Ryan's model that the "account"/edge is singular (bilateral authority), whereas you Evgeni seem to think of it as the unilateral authority approach (a debtor and a creditor). You are both right, it is different points of view that optimize for different things. I decided to go more with your approach and it made my codebase simpler, fewer parts (but less optimized for "collateral" on top).

[Jorge Timón]

You are wrong. Lightning does not use a "turn taking approach", let alone a "strict turn taking approach". I'm afraid your LLM is lying to you and you're not knowledgeable enough about lightning, ripple and other technologies to notice the lies.

And in the multi-asset lightning (not developed) not even collateral is needed in the traditional sense, because some of the assets (or all of them) can be just credit (aka IOUs, aka "newly issued money").

Good luck, you're going to need it.

--
You received this message because you are subscribed to the Google Groups "Ripple Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rippleusers...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/rippleusers/0b6623f8-9956-4fba-b75e-287589a4bc27n%40googlegroups.com.

[Evgeni Pandurski]

On Sat, Jan 3, 2026, 11:59 Johan Nygren <joha...@gmail.com> wrote:

If it is multi-lateral clearing where each vertex in graph is a person and not a community, how is money issuance a problem?

Money (debt) issuing is always a problem. Do too much or too little of it, and you are screwed. You must always seek for the current optimum.

The point most people do not understand is that you can not optimize for both issuing and payments. This is why multi hop payments can not be free of charge.

--

[Johan Nygren]

Jorge you request to not be mentioned, then you join discussion. It is nonsensical. Be coherent.

To me it seems state channel with "collateral" on top of Ripple does need to have a strict sequence of events so there is no confusion. If it does not, it does not. It is not my main priority and never was (trust-backed "payment channels" are), but the idea was revolutionary. The Two General's problem can be solved both with unilateral authority (creditor/debtor) and bilateral (strict turn-taking).

In this community, I presented at Stephen DeMeulenaere's conference this summer, met with Chris Cook from this community, and with Michiel De Jong as well, and Daniel Levy has also been interested in the advances with the 3-phase commit as well as my implementation of it. These are real people, who have been part of this mailing list (and for Stephen and Chris maybe also the Source Forge one like yourself? Or at least involved in Ripple community since then).

Your opinion on me has been stated loud and clear by yourself many times. Then you pivot to "do not mention me" and then you contradict yourself. Feel free to your opinion, I think it is important people can have different opinions. Maybe you are right (and I somehow tricked quite a few other people as well as formal university certification systems and such), maybe you are wrong. Neutrality is important. Free will is important. You are free to do as you want.

Peace, Johan

[Johan Nygren]

OK Evgeni. You mean like that. I guess either you do "how much to issue" centralized (like Bitcoin, or the World Bank or whatever does that historically, or gold) or you do it decentralized.

If your Swaptacular is community mutual credit banks that use multi-lateral clearing between themselves in an open network, it is not controlling it centrally. So your point of contention seems a bit contradictory to what you are working on.

If hypothetically "how much to issue" does not work decentralized, "collateral" on top of Ripple (ETH, Bitcoin or anything else) does central issuance and decentralized multihop payments.

To me I don't see why it does not self-balance decentralized. But since there is a solution if it does not, also do not see what problem is.

Peace, Johan

[Evgeni Pandurski]

On Sat, Jan 3, 2026, 16:21 Johan Nygren <joha...@gmail.com> wrote:

OK Evgeni. You mean like that. I guess either you do "how much to issue" centralized (like Bitcoin, or the World Bank or whatever does that historically, or gold) or you do it decentralized.

If your Swaptacular is community mutual credit banks that use multi-lateral clearing between themselves in an open network, it is not controlling it centrally. So your point of contention seems a bit contradictory to what you are working on.

If hypothetically "how much to issue" does not work decentralized, "collateral" on top of Ripple (ETH, Bitcoin or anything else) does central issuance and decentralized multihop payments.

To me I don't see why it does not self-balance decentralized. But since there is a solution if it does not, also do not see what problem is.

I do not understand what you are saying.

Just to be clear about the centralized/decentralized issuing. In most financial systems, including the traditional commercial banking, the process of issuing is mostly decentralized, and becomes centralized only when the system is in a severe crisis.

Take Bitcoin for example, it claims to have decentralized the issuing, and this might have been the case for some period of time, but now most of issuing happens not by mining, but by selling hoarded coins in circulation. You may still claim this is a decentralized process, but it definitely is not a productive and just process.

To view this discussion visit https://groups.google.com/d/msgid/rippleusers/5902b51b-3ac5-4b98-9b6d-7a3d2af84e17n%40googlegroups.com.

[Johan Nygren]

Evgeni, Grok AI's analysis is that in your Swaptacular, loops are found by a trusted third party computer that receives single-hop payments from users, and finds loops. And anyone can provide this trusted third party, but you still need everyone who is clearing loops to be using the exact same trusted third party.

This is well, pretty traditionally centralized. Doing same thing with validator alternation (like Cycles is doing) is similar, except it formalizes who the "leader computer" is.

Michiel De Jong's approach to do equivalent of a 2-phase commit multi-hop payment from one person back to themselves (using the debt as "bandwidth") and doing so in small "chunks", if I understand right, is a decentralized alternative. It seems to work well (though same for payments fails, as Interledger tried for a while). So it seems nothing stops your Swaptacular from decentralizing further, if you would want.

Nothing about your Swaptacular seems to control issuing credit centrally. It seems the problem you want to emphasize as the "big problem" is one that has been solved with majority consensus with validator alternation, i.e., nation-state/blockchain. There, you can centrally control issuance. With unilateral authority, i.e., validator alternation. Sure there may be problems but it provides the possibility (otherwise it is impossible more or less, or, gold or natural resource can provide "central" issuance to some extent).

To nitpick on central issuance, you can also issue coins in proportion to people in population via people directly, what I built under my foundation does this, https://panarkistiftelsen.se/PAN.sol (and Gavin Wood who built first version of Ethereum is currently promoting a system that starts to become identical to my https://doc.bitpeople.org that was formalized by 2018) but this is pretty far away from topic on this mailing list. Omar Syed suggested that back in 2011.

I think you seem to identify a problem that (if it is actually a problem) "blockchain" solves, while you seem to dislike blockchain.

I mostly replied to you because multilateral clearing where each node is a person can use Resilience and needs nothing more to clear. This is pretty cool. Extremely minimalistic system. But it does not work when the "vertex" is a community, only when vertex is a person.

Peace, Johan

[Johan Nygren]

*With "multi-lateral"/unanimous authority

[Evgeni Pandurski]

Sorry, I do no understand your point.

However, I am starting to understand Jorge Timón's point about the danger of LLMs.

To view this discussion visit https://groups.google.com/d/msgid/rippleusers/8e14bb73-2f45-4c5f-ac08-3c95c2c70ffen%40googlegroups.com.

[Johan Nygren]

Evgeni,

Michiel De Jong already solved multi-lateral clearing in decentralized way. Thus nothing stops anyone from doing it decentralized.

Swaptacular does not seem to issue currency centralized. Thus it seems it contradicts your concern decentralized currency issuance would be "imbalanced".

Centralized currency issuance has been solved historically. Either via might-of-force (whichever bank got dominant) or formal validator alternation (nation-state/blockchain). You seem do dislike those solutions but they are what solved it.

As for the personal attack on me somehow being incoherent (which anyone can judge if I am) and if so that AI would be the cause (which, well, is a theory like any other), feel free to your opinion.

Peace, Johan

[Evgeni Pandurski]

My point is: all centralized issuing schemes are bad in the long run. Most decentralized schemes are bad too. Swaptacular tries to be an effectively decentralized scheme that is good and stable in the long run.

I am not interested in attacking you. I am mostly interested in assisting people who seek to improve their understanding of financial systems (this includes myself). However, I am not interested in arguing with LLMs.

To view this discussion visit https://groups.google.com/d/msgid/rippleusers/33697a28-980b-4f84-bffb-89cb1b3f4cc1n%40googlegroups.com.

[Johan Nygren]

Evgeni, I apologize for partially siding with unfair critique on your work. I now acknowledge multi-lateral clearing has niche advantages over multi-hop.

Jorge wrote to you "I think you're unreasonably trying to find advantages on circular swap over general ripple that simply can't be there, because circular swap is simply a specific case of the more general ripple." but there is niche advantages of multi-lateral clearing.

Multi-lateral clearing in decentralized way requires less sophisticated coordination mechanism (the 2-phase with "chunked clearing is enough, as Michiel De Jong invented, but for multihop the 3-phase is needed (article), Interledger tried the 2-phase with "chunked payment" but it runs into many problems like bandwidth is not guaranteed for the full payment).

I can see why you and Ryan Fugger connected back when Ryan first conceived of Ripple. Decentralized multi-lateral clearing, and decentralized multihop, are "cousins". The latter is more complex and harder to achieve. The former is more minimalistic, but limited to single-hop, trustwise (and not useful for "collateral" payment channels as many here seem to prioritize...). In multihop, multilateral clearing comes for free, but for this it requires solving multihop which requires the "chunked penalty" Ryan (with you) envisioned in 2006 and this requires the 3-phase commit I invented last spring.

Why I responded to you here is because my swarm redistribution automatically clears multilateral barter circles. I'm building such a standalone system now, 1 command instead of 20+ as in multihop. As a side project or compromise (many like CMB more than multihop...) If you like CMB where each vertex is a person (was that your original idea?), that is what I am now building with guaranteed basic income as the clearing mechanism built-in. I think equilibrium for clearing is, at X% tax, less than X% loose end means net clearing. Loop with a branch, tax goes in full through both, per x * (1 - 1/2^n) which at limit is x. Many loops and many branches probably evens out to, on average, full tax package through loops even if it is spread over many loops. Thus you get clearing if loose ends is below X%. I think.

Worth testing, since it is so simple.

I am not a LLM. In my understanding, your Swaptacular coordinates loop clearing similar to the older "commit register" concept for Ripple, in that it uses a central third party coordinator (albeit any such third party could be used). Since multilateral clearing is not main focus of Ripple group, and the goal of Ripple has been to decentralized computationally (focus shifted to "commit registers" a few years after the 2006 "gradual penalty" could not be made to work), I think it is reasonable that I would use tools to dissect what your work was about. If your work was transparently positioned in the context of Ripple, I would not have had to. Chris Cook originally brought up Swaptacular when I shared my work on reviving the old decentralized Ripple vision, and then too I used AI to try to figure out exactly what that had to do with Ripple... if it had been more transparently communicated, I would not have had to. Ripple has to be some form of lowest common denominator here, this is the Ripple group.

Johan

[Evgeni Pandurski]

Apologies accepted.

Ripple is focused on payments. Swaptacular is focused on issuing (that is, the opposite of clearing). I do not see any benefits from discussing this further.

To view this discussion visit https://groups.google.com/d/msgid/rippleusers/984d81b8-e069-4e39-8199-36a12bb4dfffn%40googlegroups.com.

[Johan Nygren]

Discussing approaches to coordinate multi-lateral clearing (a central computer like you seem to do, or "chunked clearing" as Michiel De Jong invented) seems appropriate if you share your project for such a system in the Ripple group.

That multi-lateral clearing does "issuing" when multihop does not, seems dishonest.

Multi-lateral clearing, in decentralized way, requires a clearing by multihop-mechanism, which is a payment from a person to themselves with debt as the bandwidth. As such is required anyway, the added complexity to go to multihop (not just "payment-to-self" but "payment-to-anyone") is not too big.

I took a few days now to demonstrate how with a single command + response, 300 lines of code in full, Resilience can do "circular multilateral barter" in decentralized way (i.e., the loop clearing): https://gitlab.com/bipedaljoe/p2p/-/blob/main/app/loopsilience.go. It is a third alternative. It also does so in the Ripple+Resilience I built last year which works perfectly since half a year.

Peace, Johan

[Evgeni Pandurski]

Sure. Throwing away 75,000 lines of Swaptacular code and going for your idea seems like the smart thing to do. It is so much more  decentralized. Also, LLMs are so much better programmers than us stupid humans.

To view this discussion visit https://groups.google.com/d/msgid/rippleusers/198085b7-481e-4bfa-b631-8f0e8c457265n%40googlegroups.com.

[Johan Nygren]

I have not said that. Michiel De Jong's approach of "chunked clearing" seems like the reasonable approach to multi-lateral clearing in decentralized way (if that is the goal).

Michiel's approach can probably be done in a 1000 lines of code "app" with a p2p framework of 1500 lines of code (whereas Ripple is 1500 lines of code "app" perhaps).

I have top grades in university in Assembly, C, VHDL/FPGA, electronics, networks, "OOP". Not sure why you suggest I cannot understand software engineer (like Jorge Timon has stated repeatedly as well, alongside some other falsifiable claims), or why I would say "LLMs are so much better programmers than us stupid humans". I also study medical science in med. school, LLM do better diagnosis these days than average MD given a good anamnesis. Does not make the person stupid. For example, I really like Assembly. Compilers have been better than humans long time according to most people. Many would say "using Assembly is meaningless". But I like it. 10 years ago though, I was not very good at software engineering.

That path-based redistribution clears loops (and to what extent it does with different ratio of loose ends to loops to average tax rate) more of a curiosity, as that is just one command, whereas "chunked clearing" would be upwards 10 (and Ripple upwards 20).

Peace, Johan

[Johan Nygren]

Evgeni, you seem to be a pioneer in "loop clearing" back 20 years ago (same category Michiel De Jong works on, you just coordinate the loop clearing differently).

You said to me a year ago you "dislike lone soldier" but if you wrote 75000 lines of code are you not working a lot like a "lone soldier"?

You and Ryan had common ground on that multi-hop clearing and multi-hop payment relies on very similar protocol. Right. And that both are similar, overlapping and ground breaking innovations.

I assume you do not think "chunked clearing" from Michiel is the right protocol. Nor the "cancel-on-timeout" you and Ryan worked on in 2006.

As you may know, I identified the reason Ryan and yours "gradual penalty" failed is because there is not a penalty on all phases, and the "chunked" timeout leads to very long timeout, which undermines the timeout itself as the solution to "reserve payment/clearing attack".

My "3-phase" that this led to, was very complicated (works, but complicated). But, there is a simpler one. I missed it, because the response to me sharing my "finish-on-timeout" here was so aggressive last year. Here it is for loop clearing:



You will also need "gas-per-query" for the loop path finding, as you mentioned when I shared that ("this is it").

Maybe there is a community that could work together on the common goals. Michiel De Jong's project is the same category as yours, for example. Maybe a version with "clear-on-timeout + delay fee" 2-phase commit could reach further towards the goal.

I made this categorization which shows "loop clearing", "circular clearing" as you pioneered is the only one in the "peer-to-peer" paradigm alongside Ryan's Ripple (or, "barter" sort of, but it is singlehop, the other are peer-to-peer for multihop). It shows that to get peer-to-peer multihop in both payment and clearing, you get yours and Ryan's system combined. I don't know to what extent multihop alone clears payments or it also needs your circular clearing. I know Ryan's plan was to use circular clearing but it never got that far.

[Evgeni Pandurski]

For better or worse, there are places which only a lone soldier can conquer.

I am almost done with my lonely research and development journey with Swaptacular. We will see what comes next. I would be happy more developers to join the project. At this stage, however, people with business experience, connections, and vision for the future are much more needed than developers.

To view this discussion visit https://groups.google.com/d/msgid/rippleusers/59b6e4cb-f6fe-4cc4-b8b4-107303bbb297n%40googlegroups.com.

[Johan Nygren]

Evgeni, are you familiar with novation for "multi-lateral barter clearing"?

A Hans-Florian Hoyer has a system that is inspired by "Bill of Exchange" and novation.

He seems to use central membership (thus making it 2-tier) but it should be possible to do with trustlines.

You pioneered p2p multihop clearing with the circular clearing idea (and Michiel De Jong also works on that), and it is necessary across trust boundaries. But maybe it can be combined with p2p singlehop clearing - novation - within trust boundaries.

It makes loop finding easier. Novation can clean up a lot of the links, leaving only inter-trust boundary clearing for circular clearing.

I was not at all aware of this approach until, well, yesterday maybe. That is, that novation can use trustlines, triangles, i.e., has no need for a central community.


The reason to have circular clearing on top of Ripple is if singlehop payments are common enough that people just run out of credit limit otherwise (not enough multihop to clear it). I guess. And why not. If it is 90% singlehop, 10% multihop, maybe circular multilateral clearing is needed too. Which means the combination of your idea and Ryan's is needed (and Hoyer's?).

On a side note, I have now in the past days abandoned (to 99%) my "path-based redistribution" in favor of demurrage now after 13 years. But my old idea that each node sets their own rate likely still works (only p2p approach is that it is per-node). The "trust index" as I called it... For the universal basic income in the p2p money system.

[Evgeni Pandurski]

I was not aware of Hans-Florian Hoyer, or the term "novation". (I
guess my circular trades are a automated mechanism for
"novation".)

I watched this video: https://www.youtube.com/watch?v=jCZZqIR4-k0
of Hans-Florian Hoyer, and it was worth watching. I should
definitely try to reach him and talk about Swaptacular.

I believe the best thing about Swaptacular is that is not a new
idea (as the above mentioned video explains). The only new thing,
I guess, is the idea that the same mechanism that clearing uses,
may be turned "backwards" to do issuing.

It is understandable that at the time merchants were mostly
interested in clearing of debts among themselves before they
disband the trading session. However, if you put the same
mechanism in the hands of producers and consumers, they will use
it mostly for the consumers to obtain IOUs from the producers of
goods. That is: not to clear credit, but to create credit.

On the question if we need both payments (Ripple), and issuing
(CMB): of course we do. However, I think both problems are mostly
orthogonal to each other. The idea that you could implement
CMB/clearing on top of Ripple is not very convincing to me. I do
not believe a Ripple implementation that is generic enough to do
this is technically possible. (I have said this numerous times,
but most people here to not want to believe me.)

I believe the big technical problem with Ripple implementations is
not the chain of payments mechanism (although it is quite
complex), but the distributed path-finding mechanism. Because
multi-hop payments in general must incur some fee (because at
least some of the nodes in the payment chain will have to get
further from their optimal credit exposure), the distributed path
finding becomes a zero-sum game, and therefore, a competitive --
not a cooperative game. I believe this makes the creation of a
decentralized system that is stable in the long run practically
impossible.

Johan Nygren <joha...@gmail.com> writes:

> Evgeni, are you familiar with novation for "multi-lateral barter
> clearing"?
>
> A Hans-Florian Hoyer has a system that is inspired by "Bill of
> Exchange" and novation.
>
> He seems to use central membership (thus making it 2-tier) but
> it should be possible to do with trustlines.
>
> You pioneered p2p multihop clearing with the circular clearing
> idea (and Michiel De Jong also works on that), and it is
> necessary across trust boundaries. But maybe it can be combined
> with p2p singlehop clearing - novation - within trust
> boundaries.
>
> It makes loop finding easier. Novation can clean up a lot of the
> links, leaving only inter-trust boundary clearing for
> circular clearing.
>
> I was not at all aware of this approach until, well, yesterday
> maybe. That is, that novation can use trustlines, triangles,
> i.e., has no need for a central community.
>

> novation.png
> The reason to have circular clearing on top of Ripple is if
> singlehop payments are common enough that people just
> run out of credit limit otherwise (not enough multihop to clear
> it). I guess. And why not. If it is 90% singlehop, 10%
> multihop, maybe circular multilateral clearing is needed too.
> Which means the combination of your idea and Ryan's is
> needed (and Hoyer's?).

> clear.png
>
> You will also need "gas-per-query" for the loop path finding,
> as you mentioned when I shared that ("this is
> it").
>
> Maybe there is a community that could work together on the
> common goals. Michiel De Jong's project is the
> same category as yours, for example. Maybe a version with
> "clear-on-timeout + delay fee" 2-phase commit
> could reach further towards the goal.
>
> I made this categorization which shows "loop clearing",
> "circular clearing" as you pioneered is the only one
> in the "peer-to-peer" paradigm alongside Ryan's Ripple (or,
> "barter" sort of, but it is singlehop, the other are
> peer-to-peer for multihop). It shows that to get peer-to-peer
> multihop in both payment and clearing, you
> get yours and Ryan's system combined. I don't know to what
> extent multihop alone clears payments or it
> also needs your circular clearing. I know Ryan's plan was to
> use circular clearing but it never got that far.
>

[Johan Nygren]

"the distributed path finding becomes a zero-sum game, and therefore, a competitive -- not a cooperative game. I believe this makes the creation of a decentralized system that is stable in the long run practically impossible."

I solve this with the opposite approach everyone else takes. I do it collaboratively. A cooperative game. The sender suggests a transfer fee. During path-finding, those who accept the transfer-fee participate. They do so, based on "transfer rate" they have set (I have lower bound the accept, and what they use themselves, lower bound 0.5x their own fee, here in code). The first path found, is selected.

I invented this for "path-based redistribution" (it was tax rate, not transfer rate) but now that I favour demurrage since... yesterday, it will be used for the transfer rate (it is also used for the delay fee though, to negotiate it, the same mechanism. The delay fee is only paid out in case delay during multihop coordination, it prevents attack where sender and whoever causes delay are both the attacker, and co-incidentally it also enforces the second phase... as I realized a few days ago...).

"I was not aware of Hans-Florian Hoyer, or the term "novation". (I guess my circular trades are a automated mechanism for "novation".)"

How I understand your circular barter idea, it is loop clearing. Similar to what Michiel De Jong works on. It is "multihop" in terms of trust. It is a brilliant idea. Novation on the other hand, if used with trustlines (and I do not think Hans-Florian uses it that way), is singlehop in terms of trust. It is analogous to what a "clearing community" with a central intermediary does, but it has split it apart so each node does its part. The brilliant part is that it does it even if there is no central membership but instead trustlines, I think, and I am not aware of if Hans-Florian has realized that or not. He seems to use a "central meeting" as part of his system which suggests he is doing something centrally, likely the membership or credit limits, but these can be by trustlines.

[Evgeni Pandurski]

Can you post a link to this novation project that you talk about. It seems to be a quote general term.

To view this discussion visit https://groups.google.com/d/msgid/rippleusers/690c26a7-0e3e-4395-b69e-5b442f925fccn%40googlegroups.com.

[Johan Nygren]

Hans-Florian calls it "Twin Tokens" but I'm not sure he has realized it can use trustlines, https://www.google.com/search?q=twin+tokens+hans+florian+hoyer (I have no better link, not sure what the best resource is). Since he uses a "central meeting" periodically, it suggests he has either not realized it can run entirely p2p, or I am missing something.

With a central membership, "novation" (moving debt whenever there is a chain of it) does the same result a clearing community with intermediary does (x:1, y:0 below, a "LETS").

A to B to C here, if you think A to LETS to B to LETS to C, both IOUs go via the LETS, thus it is a "loop". With novation, the result is each member has either all-positive or all-negative balances with their peers, everything else is moved around. It simplifies the debt graph maximally, perhaps, within trust boundaries. Leaving less that has to be managed by the circular clearing you pioneered (so it all scales better, loop finding and such). I think this is the case, but this is new to me.

[Evgeni Pandurski]

Thank you for the link.

You mention LETS, and I believe the way credit is issued in LETS is quite problematic. It is basically a form or a pyramid scheme.

It is not correct to claim that I pioneered circular clearing. It was invented long ago. Using computers to to find circular trades to issue IOUs, this I may have pioneered. But I know at least one person that had the same idea independently from me, so I am definitely not the sole inventor of the idea.

To view this discussion visit https://groups.google.com/d/msgid/rippleusers/2c1d8282-c59b-4aaa-aac1-c7fd9e4d83d3n%40googlegroups.com.

[Johan Nygren]

For circular clearing that is by "mesh" loop finding like you and Ryan envisioned together, you must have been among the first. Such a system would not make sense before the internet.

"LETS" is not peer-to-peer (user == intermediary). Your circular clearing by loop finding is. Ryan's multihop is. Trustline-novation is peer-to-peer though and might be able to fill the niche "LETS" has typically occupied. It seems it could be a single operation on a triangle of three people who trust one another. If you just repeat it, it would remove any chains and loops within trust boundaries. It seems.

[Evgeni Pandurski]

You continue to think on terms of "clearing". The reason I named my project Swaptacular, is that it does multi-hop currency swaps.

You probably have heard of BRICS countries (mainly Russia and China) organizing currency swaps between their central banks - effectively creating IOUs to boost bilateral trade. Swaptacular can do the same but for more than 2 parties. It is not clearing! It is the opposite of clearing! 

To view this discussion visit https://groups.google.com/d/msgid/rippleusers/afd0a73a-77d2-4715-8d68-eef8f6539b4dn%40googlegroups.com.

[Johan Nygren]

Evgeni, I'm discussing in the context of the Ripple project and your role there. Your work with circular barter is important. Swaps/exchange rates, possibly important for the peer-to-peer money system too, I do not understand that topic so cannot comment on it either way.

I attach document on "Twin Tokens" where you can see Hans-Florian Hoyer has described "triad novation", that novation operation can be reduced to always just three people. It is the logical next step in complexity from dyad (barter), i.e., a triad. It is ingenious. But, you can also see he assumes central membership. "Membership is the trustline" he writes. He is 90% to a genius idea, but stuck in the central community thinking.

He also mentions the triad on https://www.academia.edu/95097546/Taking_the_Community_into_Account, but note, he still assumes central membership.

I show here the two columns and rows of the peer-to-peer money system. You and Ryan invented the ones to the right. Hans-Florian Hoyer invented 90% of the clearing in the column to the left, and I may have invented the last 10%.


Triad novation is possibly 400 lines of code without credit limits and receipts. With credit limits and receipts and demurrage for UBI (each node sets their own rate, i.e., p2p) it is 200 lines of code more maybe. I will build it, but may take a few days. Current draft: https://gitlab.com/bipedaljoe/p2p-novation/-/blob/main/app/novation.go.

And for the "multihop column", here is likely what both payments and clearing needs. What I suggested last year ("finish-on-timeout" 2-phase commit with sender-authenticated cancel, instead of "cancel-on-timeout" 2-phase commit with recipient-authenticated commit) but with the delay fee that I had also in my overcomplicated "3-phase" (that met "half-way" with responses from the Lightning Network group here...)

[Johan Nygren]

Here is Hoyer pointing out novation can be reduced to a single operation on three people. But his project then relies on central membership. But it seems it would work perfectly with trustlines + a periodic "tringle finding" routine. And then you can do CMB/Ripple on top of it. 400 lines of code: https://gitlab.com/bipedaljoe/p2p-novation/-/blob/main/app/novation.go.