Pseudonym Pairs is built around a simple schedule, and all actions are contained within the period your "proof-of-personhood" is valid. In the reference implementation I am writing, a modifier

The code for issuing "border tokens", giving a random person the ability to issue one more. This mechanism is used to allow the swarm to grow as fast as it wants. Think a colony of bacteria,

The game theory in Pseudonym Pairs is that pairs are broken if there is a conflict. As long as people play nice, people only meet 1 on 1. Mob rule is only introduced if there is a conflict, 2 over 1. That

uint genesisEvent = 1580540400; uint[] clockwork; uint hour; struct Reg { bool rank; uint id; } mapping(address => Reg) accountID; uint[][2] index; uint[][2] courtUtility; function incrementCourtUtility()

Roughly how I'm structuring the Pseudonym Pairs reference implementation at the moment. I'm not a coder, I'm learning as I go along. To implement this is harder for me than for an experienced person. The

When the event begins, people are in index[registry[msg.sender]]/2, floored. uint[] index; function register() { registry[msg.sender] = index.length; uint link; if(index.length != 0) link = getRandomNumber()

uint pseudonymEvent = 1578726000; uint hour; uint[] clockwork; function eventScheduler() internal { pseudonymEvent += 28 days; if(clockwork.length == 0) { for(uint i = 0; i<24; i++) { clockwork.length++;

new one, lets people join continuously, everyone ends up in a pair, and people who opt-in can assign themselves to pairs continuously as well. the optIn() function has a few lines that need to be added

another one. good thing about this one is that every person sorted ends up in a pair, except if there is an uneven number. and, no need to index anything beforehand.

This here does scheduling. No input needed except for the people using the system. Once deployed it operates with no other input than the people it mediates. Gas cost per person for scheduling, per pseudonym