Swarm redistribution added to my Ripple Inter Server Protocol version
29 views
Skip to first unread message
Johan Nygren
Mar 4, 2025, 11:01:00 AMMar 4
to Ripple Project
Repository: https://bitbucket.org/bipedaljoe/resilience
Swarm redistribution is an idea of mine from 2012. The main concept is:
1) "tax" flows via credit lines (reducing size of the credit lines) until it reaches a person without "an income" (no incoming credit lines at the moment). That person then gets "guaranteed basic income".
Then, next in importance:
2) The flow of tax favors "clusters" that pay tax. The mechanism: credit lines that pay tax, are favored. At a hop, if there are multiple incoming credit lines, each receives a fragment of the tax in proportion. If the "input" credit line had higher conductance than "output" credit line, only part is propagated (see code here).
I think these are interesting and simple concepts. The first is simplest, the second is still quite simple (it mirrors electricity or flow of liquids).
Then, the last part is: but who pays the tax?
Here the idea in 2012 was originally: the buyer. But for this implementation, I did it differently (partly since it was much simpler to implement). It is reworked from a taxation system into a donation system. It can still achieve point 2 if payment routing is the "trigger" to donate. Thus people donate based on their "donation index" or "trust index" when they participate in payment routing. Set this to zero, no problem but you are cut-off from the "wealth redistribution" or "demurrage". Notes on an attack vector.
1) "tax" flows via credit lines (reducing size of the credit lines) until it reaches a person without "an income" (no incoming credit lines at the moment). That person then gets "guaranteed basic income".
Then, next in importance:
2) The flow of tax favors "clusters" that pay tax. The mechanism: credit lines that pay tax, are favored. At a hop, if there are multiple incoming credit lines, each receives a fragment of the tax in proportion. If the "input" credit line had higher conductance than "output" credit line, only part is propagated (see code here).
I think these are interesting and simple concepts. The first is simplest, the second is still quite simple (it mirrors electricity or flow of liquids).
Then, the last part is: but who pays the tax?
Here the idea in 2012 was originally: the buyer. But for this implementation, I did it differently (partly since it was much simpler to implement). It is reworked from a taxation system into a donation system. It can still achieve point 2 if payment routing is the "trigger" to donate. Thus people donate based on their "donation index" or "trust index" when they participate in payment routing. Set this to zero, no problem but you are cut-off from the "wealth redistribution" or "demurrage". Notes on an attack vector.
Johan Nygren
Mar 19, 2025, 5:12:00 AMMar 19
to Ripple Project
Last part added to Resilience, code available via http://ripple.archi/code.
The "who pays the tax" now uses the pay-it-forward mechanism I conceptualized (I think) in 2014/2015/2016 when "BitNation" started promoting me (I also went on to build https://bitpeople.org under my foundation as I had gotten associated with the bullshit-BitNation and wanted to emphasize I always had pure intentions with my interest in globalization and digitalization of government, so I built a true vision for it under my Panarchy foundation in Sweden).
The pay-it-forward is simple: everyone donates same amount as previous hop. People participate in payments that use tax-rates they tolerate. The rule in the codebase is more than 50% and less than 150% of "trust index". If your "trust index" is 4% tax, you would participate in payments over 2% and below 6%. This rule is a bit arbitrary, the point is that your credit lines get "conductivity" from the tax you pay, and you may not want to participate in 0% payments because you get disconnected from the Resilience network. An attacker also loses nothing from those payments if they just do them back and forth. Thus you might want to refuse to be an intermediary in such payments, and you can then use a lower-bound/upper-bound rule such as the one in my codebase.
Note, the premise of swarm redistribution is it always continues to propagate if someone who receives it also has net positive balance to someone else. Thus only people who have no measurable income in the system get a "net positive" - thus guaranteed basic income...
Also, those who think "swarm redistribution just causes too many messages", yes but the idea has always been that each hop "fills up" like a dam before propagating. This is in the codebase, if you have already queued a swarm redistribution command to an account, you buffer any incoming tax until you sent the previous command (or the buffer is full). So you are right in seeing the problem, but there is also a simple solution: buffering, and it is in the codebase.
Also those who notice "what if the redistribution gets stuck in a circle?". Well, then it clears that circle eventually, thus acting also as a credit-clearing system, for free. So you are right in noticing that, but maybe miss that you actually get the credit clearing more or less for free.
What I have built is what I described in 2012: a truly decentralized - no centralized point of control - swarm-based "welfare system". I was a bit famous for a while, many "crypto" articles on websites such as Cointelegraph mentioned Resilience (but misunderstood the design and misunderstood it being based on Ripple and did not even know what Ripple actually is). I originally used metaphors like "dividend pathways" instead of credit lines to be able to communicate the ideas a bit broader. Seemed like the right thing to do, and in hindsight now that I have built what I promised to build, maybe it was the best path.
Anyone interested feel free to correspond.
Peace Johan
The "who pays the tax" now uses the pay-it-forward mechanism I conceptualized (I think) in 2014/2015/2016 when "BitNation" started promoting me (I also went on to build https://bitpeople.org under my foundation as I had gotten associated with the bullshit-BitNation and wanted to emphasize I always had pure intentions with my interest in globalization and digitalization of government, so I built a true vision for it under my Panarchy foundation in Sweden).
The pay-it-forward is simple: everyone donates same amount as previous hop. People participate in payments that use tax-rates they tolerate. The rule in the codebase is more than 50% and less than 150% of "trust index". If your "trust index" is 4% tax, you would participate in payments over 2% and below 6%. This rule is a bit arbitrary, the point is that your credit lines get "conductivity" from the tax you pay, and you may not want to participate in 0% payments because you get disconnected from the Resilience network. An attacker also loses nothing from those payments if they just do them back and forth. Thus you might want to refuse to be an intermediary in such payments, and you can then use a lower-bound/upper-bound rule such as the one in my codebase.
Note, the premise of swarm redistribution is it always continues to propagate if someone who receives it also has net positive balance to someone else. Thus only people who have no measurable income in the system get a "net positive" - thus guaranteed basic income...
Also, those who think "swarm redistribution just causes too many messages", yes but the idea has always been that each hop "fills up" like a dam before propagating. This is in the codebase, if you have already queued a swarm redistribution command to an account, you buffer any incoming tax until you sent the previous command (or the buffer is full). So you are right in seeing the problem, but there is also a simple solution: buffering, and it is in the codebase.
Also those who notice "what if the redistribution gets stuck in a circle?". Well, then it clears that circle eventually, thus acting also as a credit-clearing system, for free. So you are right in noticing that, but maybe miss that you actually get the credit clearing more or less for free.
What I have built is what I described in 2012: a truly decentralized - no centralized point of control - swarm-based "welfare system". I was a bit famous for a while, many "crypto" articles on websites such as Cointelegraph mentioned Resilience (but misunderstood the design and misunderstood it being based on Ripple and did not even know what Ripple actually is). I originally used metaphors like "dividend pathways" instead of credit lines to be able to communicate the ideas a bit broader. Seemed like the right thing to do, and in hindsight now that I have built what I promised to build, maybe it was the best path.
Anyone interested feel free to correspond.
Peace Johan
Reply all
Reply to author
Forward
0 new messages