Upcoming token sale for Circles

Circles general
#1

There is a project out there (will share the name when confirmed) that is intending to do a token sale. Most of the tokens will be sold for xDAI via a auction - but currently the idea is to sell some of the token for Circles.

While I was initially exploring the idea of using Group Currencies for this, there seems to be a simpler way: There can be an “organisational wallet” that can trust a number of Circles accounts. The project would set up this account. They would announce how much of their tokens they are willing to sell for Circles: e.g. 100.000 tokens. Now they would need to define a sales period (e.g. 1 week). During this week anyone can send Circles (directly if directly trusted or transitive otherwise) to this wallet via the regular circles.garden interface.

At the end of the sales period the tokens are distributed evenly to all sales participants. E.g. of in total 20.000 Circles were raised it would mean that everyone who send Circles would receive 5 tokens per Circles they send.

To make this happen:

  1. TheGraph, pathfinder and Circles.garden needs to support organizational wallets.
  2. Somehow the project needs to come up with a list of Circles they accept. Note that this also limits the numbers of Circles they can theoretically receive at max. Since Circles is only a few month old each Circles account has only ~1000 Circles in existence. So if they trust 10 accounts the maximum number of Circles they could receive would be 10,000. To not have that a limiting factor they should probably at least trust 1000 accounts.

My suggestion would be to start with 5-20 manually selected/ verified accounts and then do a graph analysis. E.g. “median graph distance” to those 5-20 starting points and select the 1000 nodes that are closest in the graph.

@alculexum or Christian R. - would that be something you could do with your tooling? (create a list of something like the 1000 most trusted Circles accounts?)

2 Likes
#2

This sounds like a very interesting project!

I made some analyses on the graph. The results are still very preliminary, though. The graph I considered was the graph between accounts who trust each other in both directions.

Then I selected an account at random and computed the set of reachable accounts in rounds until there were more than 10000 accounts.

I repeated this 100 times and printed all accounts that occurred at least 25 times.

In other words, I computed the set of accounts that have a 25% probability to be among the ~10000 closest accounts to randomly selected accounts.

This resulted in about 2000 accounts and was more or less stable: The output of two runs of the program coincided on about 80-90% of the accounts.

I spot-checked 20-30 accounts from that list, but none of the accounts nor any of their direct neighbours looked familiar to me. Some, if not most of them rather looked like fake accounts, but I might be mistaken there.

Maybe we can do the same starting from a specific set of accounts and see what we get.

1 Like
#3

Can you share the final resulting list? Then I could see if Cypher statements on the GraphDB give similar results.

#4

Here you are:

#5

Thanks, I did only a very quick analysis and I saw the same phenomenon: there seem to be huge Circles which are kind of isolated. So the approach probably doesn’t work. Maybe the “start-with-well-known-accounts” approach and then iterating the hops until enough accounts (with mutual trusts?) are found?

#6

Here is an alternative strategy to come up with a list of e.g. 1000 accounts.

The project that is doing the sell (or in general any vendor that is expecting to sell something for large quantities of Circles) should manually select n trusted accounts. Those should be accounts where they expect that there is some chance that they might later be able to buy something from the person - generally speaking people they interact with.

Those n trusted accounts are likely to little as selecting n accounts limits the total number of Circles you can receive to n *Circles per account. So the correct strategy would be to accept other Circles that are most likely to be spendable against those n accounts. The strategy to calculate this is:

  1. create an organizational wallet o and trust those n accounts
  2. iterate over all other Circles accounts:
    a) set the balance of that Circles account temporarily to infinity
    b) check how much of those (personal) Circles are spendable against o
    c) this will result in a number (trust distance) between 0 and n * Circles per account
  3. select the top m (e.g. 1000) accounts that score the highest trust distance

If it is not feasible to calculate the trust distance for all Circles accounts a simple strategy might be used to calculate it only for the “most promising accounts” - e.g.: start with all accounts that are reachable with 1 hop from the n accounts, 2 hops, …

#7

Here is another hackmd that contains all accounts with bidirectional trust distance at most 3 to @martin_koeppelmann :

After creating these three hackmds, I realized that I incorrectly included trust connections with trust percentage zero, somehow such edges appear in the database.

#8

Oh and there is a significant overlap between the initial two sets and this third set, so I fear that the first two sets are not really isolated.

#9

I created a Cypher statement which (hopefully) returns:

Find all Users trusted via 1…3 hops by Martin with all trusts > 0 (so currently trusted).

This results in these 2800 Users: https://gist.githubusercontent.com/ice09/87509a1ecafd9ddd73e02c6ebc5b005d/raw/aaf813ac80957133454f65d7663a080224653667/users_trusted_by_Martin.csv

Hope that helps.

Query:

MATCH path = (tr:User {name:'Martin'})-[t:TRUSTS*1..3]->(te:User)
WHERE ALL(r IN relationships(path) WHERE r.amount > 0)
RETURN DISTINCT(te)`
#10

Thank you Alex - this is a good start.
The weakness of that query is that it is susceptible to fairly simply attacks - it does not consider a more complex measure of “connectives”. Consider the following example:

Just one attacker A (or just not so careful person that might too easily give away trust) can introduce unlimited accounts with a “hop 3 distance”. In reality the total amounts of Circles that can be spend from all the “fake accounts” on the right side is however limited to the Circles A holds (as A is the only path between the 2 clusters). So ideally the distance measure takes those things into account.

Again - in my very first post I tried to describe that - that we should take into account the total amount of Circles a person can spend as a distance measure. In this graph that would be a small number for all the accounts on the right and larger for all the accounts on the left despite the “hop distance” being equal.

Screen Shot 2021-04-01 at 14.44.05
Screen Shot 2021-04-01 at 14.44.05652×751 183 KB

#11

Finally the drawing helped me understanding that approach!

Ok, makes sense to me, I can only do this in a “static” way as I initially misunderstood the amount as a real amount and not percentage - the DB has no clue of real balances of the users. However, being more than 50 means more than one connections must exists if I get this correctly. So this would be my take:

Find all Users who trust Martin with 1 to 3 hops, do not consider self-trust, and display the max accumulated amount of trust for each User (amount here being percentage of balance)

With this result: https://gist.githubusercontent.com/ice09/87509a1ecafd9ddd73e02c6ebc5b005d/raw/8b23e325b11d35358fa1ced2de3aff2ddaa9fb2a/users_who_trust_Martin_max_distance.csv

Query:

MATCH path = (tr:User)-[t:TRUSTS*1..3]->(te:User {name:"Martin"})
WHERE ALL(r IN relationships(path) WHERE r.amount > 0 AND NOT (startNode(r) = endNode(r)))
RETURN distinct(tr), (max(reduce(totalAmt = 0, t IN relationships(path) | totalAmt + t.amount))) as maxamt
ORDER BY maxamt DESC