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

[ButtCrack]

Options for Voting

Distribute to existing stakeholders   - 120 (72.7%)
Use to pay for bounties & developers   - 26 (15.8%)
Keep in trust for later distribution   - 19 (11.5%)

Based from Jack's proposal :

1. 10.5% top off to all 1st round stake holders. Each gets appx. 41,666 oras
2. 59.2% allocated to 2nd round registration. Aprx : 208,285,684 oras
3. 5.0% allocated to charity. = 17,591,696 oras
4. 25.3% 1st round stake holders (only accounts verified from spreadsheet) with 166,666 oras gets additional  100,000 oras.

Plus we are also discussing on a possible community project based giveways.

If you have other ideas on voting categories or options to distribute the next round, pls give your suggestions. Your voices will be heard.

Distribute to existing stakeholders makes sense especially the ones that did not sell.
Loyalty is not a bad thing to reward as such and give a solid userbase.

[martismartis]

Simple solution for distributing for existing Ora holders.
1. Let decide date, for example 30th of August, 0h 00 min 00sec.
2. Then get the list of holders at this time at http://www.nxtreporting.com/shareholder.php?a=ORA+%2816194910134118257692%29&show_qnt=
3. Distribute remaining ORA assets with adequate percentage of Ora for every holder account.

The most interesting thing before distribution day will be trades between holders

[ObscureBean]

guys, please a question: I was trying to sell 1000 top distribution in the next wallet. My balance is 1000 but when I try to sell them, it says " not enough funds". Then I tried to sell 100 Ora but it's the same. This wallet is very unfriendly for me. Does someone know what " not enough funds" mean? I m holding my stake, I d like just to know how the wallet works. Thanks in advance for the reply

Do you have NXT in your account? you need 1 nxt for the transaction

Yes. That may be the anwser. You need 1nxt to sell/cancel token

Yup that's it, I had the same problem. You can't place an order unless you have at least 1 NXT in your account. Everything has a 1 NXT fee  
Head over to the NXT faucet and send yourself some, you can get anything between 1-4 NXT. In case you wanna buy NXT, I'd suggest that you don't use Cryptsy (if you're only getting a few) as the minimum withdrawal amount is 50. Polo, you only need to buy 10  

[DarkhorseofNxt]

Options for Voting

Distribute to existing stakeholders   - 120 (72.7%)
Use to pay for bounties & developers   - 26 (15.8%)
Keep in trust for later distribution   - 19 (11.5%)

Based from Jack's proposal :

1. 10.5% top off to all 1st round stake holders. Each gets appx. 41,666 oras
2. 59.2% allocated to 2nd round registration. Aprx : 208,285,684 oras
3. 5.0% allocated to charity. = 17,591,696 oras
4. 25.3% 1st round stake holders (only accounts verified from spreadsheet) with 166,666 oras gets additional  100,000 oras.

Plus we are also discussing on a possible community project based giveways.

If you have other ideas on voting categories or options to distribute the next round, pls give your suggestions. Your voices will be heard.

Well I'm not sure what the most optimal options would be. But here's some important notes to consider/know about:

1. If there'll be a second round of distribution (say to x hundreds users) we'll need to make sure it's plausable first, depending on where we collect the entries from.
For example, if people would vote for giving away ORA to 1000 new BTT users next month without getting flooded with puppets I'd say "good luck". This option need to be realistic. Personally I'd prefer other ways to accept totally new stakeholders, like the video idea.
2. Giving some extra ORA to accounts who are keeping their shares is a very GOOD and reasonable idea IMO.
3. The task I was assigned to do is over (pretty much, say next Thursday). Does this mean I'm going anywhere? NO. But it's something people need to consider. This has also been an extremely stressful time for me personally (nothing at my "IRL" workplace has ever been close to match). I can't promise to manage a second big round for at least 3 months for health reasons (serious). Will I still want to help out with a 2d round if needed? Yes very likely. Do we still have access to the same automatic sockpuppet filtering system as before? Of course. But keep in mind it's naturally not as secure as it was the 1st round now that anybody who applied and didn't make it will surely try other ways to get on the list (some of our edge is gone). Anyway, what I'm saying is just, don't rely on me to collect hundreds of more users anytime soon.

Mac Red has a very valid concern. Sock puppet filtering may not work the 2nd round and will cause more headache.
Well, giving selective account with x number of Ora to more than 500 account will also be very time consuming. Taking the account 1 by 1. I would say give 1 extra stack to all the first round stake holders and get on with it.
Balance of the stake we can distribute with the video idea and with any other practical ways and we can have more timeline for this. Easier to manage.

Reason i keep bringing this topic again and again is because we need a valid justification of what we want to do and some real discussion on this matter.

[testadimerlo]

guys, please a question: I was trying to sell 1000 top distribution in the next wallet. My balance is 1000 but when I try to sell them, it says " not enough funds". Then I tried to sell 100 Ora but it's the same. This wallet is very unfriendly for me. Does someone know what " not enough funds" mean? I m holding my stake, I d like just to know how the wallet works. Thanks in advance for the reply

Do you have NXT in your account? you need 1 nxt for the transaction

thanks to all for the replies. Any nxt faucet address? Thanks again

[Coinr88]

guys, please a question: I was trying to sell 1000 top distribution in the next wallet. My balance is 1000 but when I try to sell them, it says " not enough funds". Then I tried to sell 100 Ora but it's the same. This wallet is very unfriendly for me. Does someone know what " not enough funds" mean? I m holding my stake, I d like just to know how the wallet works. Thanks in advance for the reply

Do you have NXT in your account? you need 1 nxt for the transaction

thanks to all for the replies. Any nxt faucet address? Thanks again

http://nxtra.org/faucet/

[Mac Red]

@DarkhorseofNxt
Ya, it's an important discussion to have and be open about. It's good of you to bring it up!

An idea for how we could potentially tackle a "selective" distribution:
1. List A: Decide a date and/or time. On this date, a copy of the latest list of holders along with their balances is saved (every ORA holder).
2. List B: Save a copy of the final stakeholder list (that is, everyone who has originally received a stake) in the most optimal format for this purpose.
3. We let a program run through and compare both lists. Then let it create list C, consisting of all accounts with a balance of > X from list A and who is also included in list B.
4. Then we could send extra ORA to list C only. With no manual selection/filtering needed.
5. If someone has sold their stake, then buys a new one, they will still be included using this method. We only check current balance. It'd be OK with me. Though it could of course technically be abused.

I don't *think* this would be too difficult to do and could be quite an efficient method. It's an option to think about anyway. Some of it would depend on how easy it is to get an up to date, 100% accurate list of all current holders. We wouldn't want anyone who actually got a good balance and is eligible for the bonus ORA to not receive anything.

[beckham]

@DarkhorseofNxt
Ya, it's an important discussion to have and be open about. It's good of you to bring it up!

An idea for how we could potentially tackle a "selective" distribution:
1. List A: Decide a date and/or time. On this date, a copy of the latest list of holders along with their balances is saved (every ORA holder).
2. List B: Save a copy of the final stakeholder list (that is, everyone who has originally received a stake) in the most optimal format for this purpose.
3. We let a program run through and compare both lists. Then let it create list C, consisting of all accounts with a balance of > X from list A and who is also included in list B.
4. Then we could send extra ORA to list C only. With no manual selection/filtering needed.
5. If someone has sold their stake, then buys a new one, they will still be included using this method. We only check current balance. It'd be OK with me. Though it could of course technically be abused.

I don't *think* this would be too difficult to do and could be quite an efficient method. It's an option to think about anyway. Some of it would depend on how easy it is to get an up to date, 100% accurate list of all current holders. We wouldn't want anyone who actually got a good balance and is eligible for the bonus ORA to not receive anything.

sounds good. If you want to more ORA, don't dump.

[UrsaMajorisBeta]

Waaaaait. So the people who sold a little are going to be excluded from the new distribution?
Any smart John Doe lurking at the btt wild west should think about diversification. I sold about 9k at the peak to buy a few jl777hodl assets. And i decided to keep the rest untouched and every day it's worth less and less and less. Mac Red can confirm this based on my registry at the stakeholder list. I'm happy to own 157k ora's and i will hold them until it reaches 0.
This is just not fair.

[Equate]

@DarkhorseofNxt
Ya, it's an important discussion to have and be open about. It's good of you to bring it up!

An idea for how we could potentially tackle a "selective" distribution:
1. List A: Decide a date and/or time. On this date, a copy of the latest list of holders along with their balances is saved (every ORA holder).
2. List B: Save a copy of the final stakeholder list (that is, everyone who has originally received a stake) in the most optimal format for this purpose.
3. We let a program run through and compare both lists. Then let it create list C, consisting of all accounts with a balance of > X from list A and who is also included in list B.
4. Then we could send extra ORA to list C only. With no manual selection/filtering needed.
5. If someone has sold their stake, then buys a new one, they will still be included using this method. We only check current balance. It'd be OK with me. Though it could of course technically be abused.

I don't *think* this would be too difficult to do and could be quite an efficient method. It's an option to think about anyway. Some of it would depend on how easy it is to get an up to date, 100% accurate list of all current holders. We wouldn't want anyone who actually got a good balance and is eligible for the bonus ORA to not receive anything.

Good idea but how soon can it  be implemented.

[DarkhorseofNxt]

@DarkhorseofNxt
Ya, it's an important discussion to have and be open about. It's good of you to bring it up!

An idea for how we could potentially tackle a "selective" distribution:
1. List A: Decide a date and/or time. On this date, a copy of the latest list of holders along with their balances is saved (every ORA holder).
2. List B: Save a copy of the final stakeholder list (that is, everyone who has originally received a stake) in the most optimal format for this purpose.
3. We let a program run through and compare both lists. Then let it create list C, consisting of all accounts with a balance of > X from list A and who is also included in list B.
4. Then we could send extra ORA to list C only. With no manual selection/filtering needed.
5. If someone has sold their stake, then buys a new one, they will still be included using this method. We only check current balance. It'd be OK with me. Though it could of course technically be abused.

I don't *think* this would be too difficult to do and could be quite an efficient method. It's an option to think about anyway. Some of it would depend on how easy it is to get an up to date, 100% accurate list of all current holders. We wouldn't want anyone who actually got a good balance and is eligible for the bonus ORA to not receive anything.

I kinda figured this is the way to. So i checked the account balances of the asset holders in nxtreporting of some of the accounts. I found a few inaccurate numbers. Hence i posted an enquiry on that in nxtreporting thread earlier today. So i would like to get that fixed first. But i havent done a check in nxtblocks.info. yet. Will do that too.

https://nxtforum.org/news-and-announcements/nxtreporting-com-the-nxt-asset-exchange-portfolio-manager/msg78012/#msg78012

I think that is doable Mac Red.

[fragORA]

Waaaaait. So the people who sold a little are going to be excluded from the new distribution?
Any smart John Doe lurking at the btt wild west should think about diversification. I sold about 9k at the peak to buy a few jl777hodl assets. And i decided to keep the rest untouched and every day it's worth less and less and less. Mac Red can confirm this based on my registry at the stakeholder list. I'm happy to own 157k ora's and i will hold them until it reaches 0.
This is just not fair.

I think you picked it up wrong. you can still buy back 9k to "complete" your stake for less than you sold it for so its a win win

[DarkhorseofNxt]

Waaaaait. So the people who sold a little are going to be excluded from the new distribution?
Any smart John Doe lurking at the btt wild west should think about diversification. I sold about 9k at the peak to buy a few jl777hodl assets. And i decided to keep the rest untouched and every day it's worth less and less and less. Mac Red can confirm this based on my registry at the stakeholder list. I'm happy to own 157k ora's and i will hold them until it reaches 0.
This is just not fair.

That minimum amount is not fixed yet.

[Mac Red]

Waaaaait. So the people who sold a little are going to be excluded from the new distribution?
Any smart John Doe lurking at the btt wild west should think about diversification. I sold about 9k at the peak to buy a few jl777hodl assets. And i decided to keep the rest untouched and every day it's worth less and less and less. Mac Red can confirm this based on my registry at the stakeholder list. I'm happy to own 157k ora's and i will hold them until it reaches 0.
This is just not fair.

Nah I was just giving an example. The reason I included balance in my argument was because people who no longer have any ORA perhaps shouldn't get receive any bonus either. But nothing's decided. Is your stance it'd be better to just distribute to all original stakeholders?

[Mac Red]

@DarkhorseofNxt
Ya, it's an important discussion to have and be open about. It's good of you to bring it up!

An idea for how we could potentially tackle a "selective" distribution:
1. List A: Decide a date and/or time. On this date, a copy of the latest list of holders along with their balances is saved (every ORA holder).
2. List B: Save a copy of the final stakeholder list (that is, everyone who has originally received a stake) in the most optimal format for this purpose.
3. We let a program run through and compare both lists. Then let it create list C, consisting of all accounts with a balance of > X from list A and who is also included in list B.
4. Then we could send extra ORA to list C only. With no manual selection/filtering needed.
5. If someone has sold their stake, then buys a new one, they will still be included using this method. We only check current balance. It'd be OK with me. Though it could of course technically be abused.

I don't *think* this would be too difficult to do and could be quite an efficient method. It's an option to think about anyway. Some of it would depend on how easy it is to get an up to date, 100% accurate list of all current holders. We wouldn't want anyone who actually got a good balance and is eligible for the bonus ORA to not receive anything.

I kinda figured this is the way to. So i checked the account balances of the asset holders in nxtreporting of some of the accounts. I found a few inaccurate numbers. Hence i posted an enquiry on that in nxtreporting thread earlier today. So i would like to get that fixed first. But i havent done a check in nxtblocks.info. yet. Will do that too.

I think that is doable Mac Red.

Yes this is my biggest issue as well. If we can't get a list of balances we know for sure is perfectly accurate it's no point. We need that assurance if we're going to do things the automatic way.

@Equate
As for building the script itself to generate list C it's likely not any huge work. But it'd be done after we've all decided it's what we want.

[curT]

@DarkhorseofNxt
Ya, it's an important discussion to have and be open about. It's good of you to bring it up!

An idea for how we could potentially tackle a "selective" distribution:
1. List A: Decide a date and/or time. On this date, a copy of the latest list of holders along with their balances is saved (every ORA holder).
2. List B: Save a copy of the final stakeholder list (that is, everyone who has originally received a stake) in the most optimal format for this purpose.
3. We let a program run through and compare both lists. Then let it create list C, consisting of all accounts with a balance of > X from list A and who is also included in list B.
4. Then we could send extra ORA to list C only. With no manual selection/filtering needed.
5. If someone has sold their stake, then buys a new one, they will still be included using this method. We only check current balance. It'd be OK with me. Though it could of course technically be abused.

I don't *think* this would be too difficult to do and could be quite an efficient method. It's an option to think about anyway. Some of it would depend on how easy it is to get an up to date, 100% accurate list of all current holders. We wouldn't want anyone who actually got a good balance and is eligible for the bonus ORA to not receive anything.

You could 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,.... )

[tomavbttt]

I compare agree with is allocated according to the share held by the now, this is the love of ORA is a kind of encourage.

[fragORA]

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.

[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.

[poornamelessme]

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.

A possibility. Using comm as an example, there was a dump right after the 2nd round finished up. The coin recovered from that though (at least initially).

It may be easiest to just use a set proportion. Say if a holder held 100%, he gets the full 2nd round. If he held 50% of his initial stakes, he gets half that amount, and so on. Leftovers over can be used for dev work/bounties.

As for dumpers buying X Ora to gain a bonus ... there is a way around it. Don't announce it. Just one day figure out what everyone is holding, then say the 2nd round will be based on that distribution. It won't matter then if dumpers buy extra ORA, as that set calculation will have already taken place.

People may still dump anyway, but the problem of initial dumpers dumping even more coin wouldn't be an issue.