[ANN] ORA :: NXT 'monetary system' currency

[curT]

You coul do something like this :

Liste C :     balance > 100,000  gets additional  of 50,000
                 balance > 150,000  gets additional  of 75,000
                 balance > 200,000  gets additional  of 100,000
                 balance > 300,000  gets additional  of 125,000
                 ....

keep the rest for later distribution. (3rd round, 4th round,.... )

I like this too, but you have to consider the extra workload that this might involve. Remember there was no IPO for this coin and as such, no paid devs.
Yes they are getting ORA and they believe in the project or they wouldn't be doing it. Also remember that anyone in the community can chip in and help with some of these tasks.

Possible negative amplifier: dumper(s) buy X ORA to gain Y% bonus over other holders. Then dumps everything after receiving the bigger shares.

yeah maybe,
but i think the price  will rise and then it is " too expensive " to buy ORA to gain Y% bonus.
The challange is to find a just  balance between the x balance in list C and the x ORA you get.
And also if there is a later distribution (3rd round, 4th round,.... ) will encourage to hold and buy.

until ora reaches a naturale value.

[DarkhorseofNxt]

Just saw this. This could be the solution. Need to test first though

I made a new release and updated the OP.

Version 5 has the ability to choose the timestamp for dividend calculation and the ability to pay in assets.

[Mac Red]

You coul do something like this :

Liste C :     balance > 100,000  gets additional  of 50,000
                 balance > 150,000  gets additional  of 75,000
                 balance > 200,000  gets additional  of 100,000
                 balance > 300,000  gets additional  of 125,000
                 ....

keep the rest for later distribution. (3rd round, 4th round,.... )

I like this too, but you have to consider the extra workload that this might involve. Remember there was no IPO for this coin and as such, no paid devs.
Yes they are getting ORA and they believe in the project or they wouldn't be doing it. Also remember that anyone in the community can chip in and help with some of these tasks.

Possible negative amplifier: dumper(s) buy X ORA to gain Y% bonus over other holders. Then dumps everything after receiving the bigger shares.

yeah maybe,
but i think the price  will rise and then it is " too expensive " to buy ORA to gain Y% bonus.
The challange is to find a just  balance between the x balance in list C and the x ORA you get.

Ya I dunno personally I'd prefer static volumes, calculated by how many people make it to list C. Sounds most fair if everyone eligible gets equal share instead of handing out more to those who've afforded to buy more. Since not everyone is in an equal economic position but could still be very commited to the project. Keeping X% of one's original stake would be enough "evidence". But yeah of course it should be discussed.

[megashira1]

Just decide on a % increase per 1 ORA held and problem solved.

[curT]

You coul do something like this :

Liste C :     balance > 100,000  gets additional  of 50,000
                 balance > 150,000  gets additional  of 75,000
                 balance > 200,000  gets additional  of 100,000
                 balance > 300,000  gets additional  of 125,000
                 ....

keep the rest for later distribution. (3rd round, 4th round,.... )

I like this too, but you have to consider the extra workload that this might involve. Remember there was no IPO for this coin and as such, no paid devs.
Yes they are getting ORA and they believe in the project or they wouldn't be doing it. Also remember that anyone in the community can chip in and help with some of these tasks.

Possible negative amplifier: dumper(s) buy X ORA to gain Y% bonus over other holders. Then dumps everything after receiving the bigger shares.

yeah maybe,
but i think the price  will rise and then it is " too expensive " to buy ORA to gain Y% bonus.
The challange is to find a just  balance between the x balance in list C and the x ORA you get.

Ya I dunno personally I'd prefer static volumes, calculated by how many people make it to list C. Sounds most fair if everyone eligible gets equal share instead of handing out more to those who've afforded to buy more. But yeah of course it should be discussed.

Yes, i also don't like the idea of the " rich getting richer" but how do we prevent dump and keep ORA value.

[Mac Red]

You coul do something like this :

Liste C :     balance > 100,000  gets additional  of 50,000
                 balance > 150,000  gets additional  of 75,000
                 balance > 200,000  gets additional  of 100,000
                 balance > 300,000  gets additional  of 125,000
                 ....

keep the rest for later distribution. (3rd round, 4th round,.... )

I like this too, but you have to consider the extra workload that this might involve. Remember there was no IPO for this coin and as such, no paid devs.
Yes they are getting ORA and they believe in the project or they wouldn't be doing it. Also remember that anyone in the community can chip in and help with some of these tasks.

Possible negative amplifier: dumper(s) buy X ORA to gain Y% bonus over other holders. Then dumps everything after receiving the bigger shares.

yeah maybe,
but i think the price  will rise and then it is " too expensive " to buy ORA to gain Y% bonus.
The challange is to find a just  balance between the x balance in list C and the x ORA you get.

Ya I dunno personally I'd prefer static volumes, calculated by how many people make it to list C. Sounds most fair if everyone eligible gets equal share instead of handing out more to those who've afforded to buy more. But yeah of course it should be discussed.

Yes, i also don't like the idea of the " rich getting richer" but how do we prevent dump and keep ORA value.

Dumps will likely happen either way but I'd argue it's perhaps less risky if we give everyone equal share. Don't see the benefit of mixing up bonuses to different stakeholders VS the possible confusion/time/"it's unfair" arguments we might face. If we can keep things as simple as possible that'd be the best road to take IMO.

[DarkhorseofNxt]

Dont care about the price.

[curT]

You coul do something like this :

Liste C :     balance > 100,000  gets additional  of 50,000
                 balance > 150,000  gets additional  of 75,000
                 balance > 200,000  gets additional  of 100,000
                 balance > 300,000  gets additional  of 125,000
                 ....

keep the rest for later distribution. (3rd round, 4th round,.... )

I like this too, but you have to consider the extra workload that this might involve. Remember there was no IPO for this coin and as such, no paid devs.
Yes they are getting ORA and they believe in the project or they wouldn't be doing it. Also remember that anyone in the community can chip in and help with some of these tasks.

Possible negative amplifier: dumper(s) buy X ORA to gain Y% bonus over other holders. Then dumps everything after receiving the bigger shares.

yeah maybe,
but i think the price  will rise and then it is " too expensive " to buy ORA to gain Y% bonus.
The challange is to find a just  balance between the x balance in list C and the x ORA you get.

Ya I dunno personally I'd prefer static volumes, calculated by how many people make it to list C. Sounds most fair if everyone eligible gets equal share instead of handing out more to those who've afforded to buy more. But yeah of course it should be discussed.

Yes, i also don't like the idea of the " rich getting richer" but how do we prevent dump and keep ORA value.

Dumps will likely happen either way but I'd argue it's perhaps less risky if we give everyone equal share. Don't see the benefit over mixing up bonuses to different stakeholders VS the possible confusion/time/"it's unfair" arguments we might face.

Yes that is fair i think.
What about  a later distribution (3rd round, 4th round,5th round,.... ) to keep stakeholders intrested in ORA and not sell (or dump) and leave.

[megashira1]

You coul do something like this :

Liste C :     balance > 100,000  gets additional  of 50,000
                 balance > 150,000  gets additional  of 75,000
                 balance > 200,000  gets additional  of 100,000
                 balance > 300,000  gets additional  of 125,000
                 ....

keep the rest for later distribution. (3rd round, 4th round,.... )

I like this too, but you have to consider the extra workload that this might involve. Remember there was no IPO for this coin and as such, no paid devs.
Yes they are getting ORA and they believe in the project or they wouldn't be doing it. Also remember that anyone in the community can chip in and help with some of these tasks.

Possible negative amplifier: dumper(s) buy X ORA to gain Y% bonus over other holders. Then dumps everything after receiving the bigger shares.

yeah maybe,
but i think the price  will rise and then it is " too expensive " to buy ORA to gain Y% bonus.
The challange is to find a just  balance between the x balance in list C and the x ORA you get.

Ya I dunno personally I'd prefer static volumes, calculated by how many people make it to list C. Sounds most fair if everyone eligible gets equal share instead of handing out more to those who've afforded to buy more. But yeah of course it should be discussed.

Yes, i also don't like the idea of the " rich getting richer" but how do we prevent dump and keep ORA value.

Dumps will likely happen either way but I'd argue it's perhaps less risky if we give everyone equal share. Don't see the benefit over mixing up bonuses to different stakeholders VS the possible confusion/time/"it's unfair" arguments we might face.

Yes that is fair i think.
What about  a later distribution (3rd round, 4th round,5th round,.... ) to keep stakeholders intrested in ORA and not sell (or dump) and leave.

If everyone's stake increases the same proportionally in theory nothing will be dumped as no extra value has been gained.

[Mac Red]

@curT
About later distributions, why not IMO. If we do it once (generate list C) it'd be very easy to replicate for more rounds. At least if the automatic distribution thingy works properly.

[megashira1]

Actually cant you just burn shares to increase share value? This would be the easiest way.

[Equate]

Actually cant you just burn shares to increase share value? This would be the easiest way.

But won't it defeat the purpose of fair distribution to other people who can get stakes in 2nd round of distribution,  as we even couldn't distribute to 1000 users in first round.

[megashira1]

Actually cant you just burn shares to increase share value? This would be the easiest way.

But won't it defeat the purpose of fair distribution to other people who can get stakes in 2nd round of distribution,  as we even couldn't distribute to 1000 users in first round.

The distribution was fair - over 800 stake holders. People who get stakes now will just dump and hurt actual stakeholders who are now invested.

[Grillo]

Actually cant you just burn shares to increase share value? This would be the easiest way.

No, because 1 asset= 1 ORA

[megashira1]

Actually cant you just burn shares to increase share value? This would be the easiest way.

No, because 1 asset= 1 ORA

What does that mean? We're thinking on a way to distribute the remaining coins to the stakeholders. Solution is just burn the remaining assets.

Then when coin distribution comes around deliver coins based on % of supply.

[ZeroTheGreat]

Actually cant you just burn shares to increase share value? This would be the easiest way.

No, because 1 asset= 1 ORA

After "burning" 1 asset will be = 100%/(sum of all assets) of ORA total supply. But I personally like dump-proof addtitional distribution more  

[megashira1]

Actually cant you just burn shares to increase share value? This would be the easiest way.

No, because 1 asset= 1 ORA

After "burning" 1 asset will be = 100%/(sum of all assets) of ORA total supply. But I personally like dump-proof addtitional distribution more  

How would you provide dump proof distribution?

Offer some sort of illiquid claim check on a stake that only materializes after 4 months of holding, and if traded gets void. This will bring supporters on board without hurting the price.

[Kora]

Some great community discussion going on here, well done! I've made my preferences known before, so I'll stay out of the discussion for now. What I would suggest is we start trying to establish what the different  'options' we'll have for the vote.

If you have a strong opinion on how we should distribute the remaining ORA assets (i.e. the left over stakes from the initial distribution) then consider presenting a brief summary of the option for other people to consider. Maybe if everyone uses a common format it'll be easier for the 'collective' to hone in on the proposals with the most consensus. Some people are making general suggestions which are very useful, but some are offering a complete plan.

Maybe present options like this:

ORA distribution option:[YOUR USERNAME] - version X
- blah blah
- blah blah
etc

If you modify your 'option' after getting feedback, repost the modified version with a different version number. Once you're happy change the version number to FINAL

If we follow a process like this it might help. Some of us have a complete plan in mind, but others might choose to support someone else's plan, but suggest a modification.

If ORA is to succeed, and we end up using some form of 'voting' system then we'll need to develop our own processes, similar to how a parliament works I guess.

In most parliamentary systems new 'bills' are submitted for debate, and some will choose to support the bill, some will try and amend it slightly, and some will reject it completely and put up a rival 'bill'. As ORA is leaderless we don't have anything like a government or a President/Prime minister, but we do have a parliament of sorts (i.e. this forum), and so all our 'bills' would be known as a  'private members bill', at least in my country.

If we're to work effectively together then there'll obviously be many different opinions, and if we end up having as many options to vote on as interested people it'll become very difficult to move forward. We need a process that listens to everyone's opinions, and then forms those into a few basic 'options' which can be amended slightly, and then when supporters of the different options are satisfied with their amended final version, we vote.

Let's not fool ourselves, this process WILL be very difficult at times. If the process completely breaks down you can end up with people rejecting the process, and you have a civil war, and maybe a dissolution of your community, or some form of break up, or maybe even a dictator steps in to tell everyone what to do.

It's still worth doing even if it's hard

[megashira1]

Just for clarity how much ORA is intended for distribution purposes?

[DarkhorseofNxt]

Just for clarity how much ORA is intended for distribution purposes?

Balance stakes = (3000(allocated) - 889(first round reg) × 166,666) = 351,831,926. This is the number provided if all 889 receive their stakes.