B&C exchange(below abbreviated BCE), originates from Peershare and Nu, has been a Distributed Autonomous Company(DAC) or decentralized autonomous organization (DAO) since its production blockchain operation.
In the foreseeable future, unlike Nu DAC, the BCE’s revenue is solely from cryptocurrency trading and related activity. The main expenditure is reputed signers reward(salary) besides software development and marketing. Similar with any profit organization on this planet, the revenue/expenditure subject is of primary importance and closely related to B&C investors interest.
Try to keep revenue greater than expenditure is a common sense when you want to run a successful company in real world. So is it in cryptoworld. Those reputed signers who themeselves may or may not be big BKS holders are hired by BCE being voted by shareholders. They get their salary by recieving cryptoassets such as bitcoin, peercoin, BKS, BKC, NBT etc. Whichever crypto they will recieve is always company’s expenditure. Thus it is crutial to adjust their salary level on the basis of company financial situation which will probably fluctuate with crypto world market.
We believe it is careless and irresponsible to reward reputed signer with the amount regardless of BCE’s real time income, furthermore those reputed signers may have less incentive to improve their service and try to make BCE a succeful company.
Motion RIPEMD160 hash:
=##=##=##=##=##=## Motion hash starts after this line ##=##=##=##=##=##=
This motion confirms BlockShareholders’ desire to link reputed signers’ reward to B&C exchange real time revenue when BCE begins to operate. BlockShareholders demand the right of changing reputed signers’ reward as shareholder’s wish at any time. Shareholders can either change quantity of new issued BKS sent to reputed signers or distribute a certain pecentage of BCE revenue as reward via dividend procedure or use any other method which can adjust reputed signers reward.
=##=##=##=##=##=## Motion hash ends before this line ##=##=##=##=##=##=
I understand what you are trying to do, and I’m wrestling with the two hats. That of a responsible shareholder trying to prevent losses and that of a potential reputed signer role. Although I’m still on the fence whether I would take that role one of the main considerations is of course the cost and time.
A server able to host only the 40Gb+ Bitcoin blockchain will cost around US$80/month at a random cloud provider (maybe you can get better deals with some shopping though). That is excluding setting up that server, registering domain names and SSL certificates, updating the clients of the blockchain software on a regular bases, wandering through error logs and protecting it e.g. with Cloudflare or the likes which also attracts monthly fees. Just to name the most likely costs. This based on my experience with setting up and running the LiquidBits and NuDroid servers.
I think we will need to kick-start with a few reputed signers otherwise we will face a chicken and egg situation not having any sales as there are not enough reputed signers. Therefore I would advocate to provide a grant for e.g. the first 3 or 5 providers to get started. I believe your motion is not helping to kickstart operations but may be valid after a few months of successful operations with 5+ reputed signers. Then it would make business sense to exchange a fixed fee policy for one directly related on sales.
I think it’s the next step. The first thing I wanna make sure is that whether we can change the reward or not? If we cannot, we hand over the control to software developers. Although myself trust Jordan and Sigmike now, it is always good to take control in our own hands.
Shareholders also can vote a higher reward to signers when our business kicks start. Eg, we can even vote to dispatch 100% revenue to our signers in the first three months.
We know that in early days our company may not cover its expenditure, it’s very usual in real world. What I try to do is to give the flexibility of reward control, I am afraid that a fixed reward rate hard coded in software cannot cope with a fast changing and chanllenging market.
Shareholder protect themselves by avioding overpaying signers, on the other hands, shareholders can also protect signers by avioding underpaying signers which will harm our business. This kind of adjust work can only be done by humanbeing because the software itself cannot perceive real world situation.
I’m also not a fan of hard coding rates, but it might make sense for the first few months (as per design?) and then add this feature. Same as we did with the fees for the NBT network. Would be interesting to hear from the developers whether this can be changed without a lot of additional coding potentially delaying the start of operations.
Another thing, I don’t like the idea of paying signers with BlockShares, as that only dilutes shareholders and our market cap. I believe that all payments to reputed signers should be taken from the proceeds of the BlockCredits we sell. For example, let’s say our BlockCredit custodians sell their whole lot of credits. Shareholders would then direct that custodian through a motion to send a portion of their proceeds to our signers as payment for their services and then the rest of the proceeds would get distributed like usual as profit for shareholders. This means that signers would end up receiving Bitcoin, Peercoin or NuBits, whatever the custodian received as payment from selling the BlockCredits. If signers request a specific crypto then the custodian would need to convert before sending payment. Only sending payment from the proceeds collected from BlockCredit sales would prevent BlockShare dilution. I know @BCExchange said that all of the proceeds are supposed to be sent to shareholders, however I don’t agree with that. I believe signer expenses should only be taken from our revenue from BlockCredit sales. What do others think about this?
If the signer reward were a fixed amount of BKC per block the signers would compete for it, because the total signer reward is designed to be distributed between signers (according to their reputation: page 14, chapter “Reputed signer incentives”).
The first signer would get the complete reward, once the second is there, they need to share it and so forth.
This would help kickstarting the signer operation.
In case the reward would be insufficient to attract the total number of signers competing for positions adjusting the BKC per block could do the trick.
As @Nagalim said, Would be a continuous blockchain vote for the BKS signer reward amount.
Yes we can pass a motion which modifies the reward level, and sigmike begin to work on a new client version, and so on, that’s not good.I want the reward being adjusted by vote like fee vote or parking rate.
Is that posssible that dev team says “No, the signers reward rate is hard coded in software, and cannot be modified by shareholders just like minting reward.”
One more thing, I am sure that some BKS holders want to reward reputed signers with BTC revenue from BKC sale, Can we vote a ratio to split our revenue into three categories?
miscellaneous fund for software development & Marketing and share repurchase
I don’t think all BKS holders are so greedy and short sighted to fetch 100% revenue for dividend. Of course we can vote any item in a motion, but it will be tedious work. Is it possible to automatically arrange our revenue by voting a distribution like 60:20:20 so that our revenue naturally flows into these three categories?
Share repurchase is common in real world, our revenue can be used to buy BKS on free market to protect shareholders from price drop and reward employees with those BKS in future.
To conclude, we may have two procedures:
issue new BKS or spend repurchased shares to reward signers
distribute BTC revenue to them
It is very convenient to switch from one to the other or keep both at same time . For example, we vote for 0 BKS reward and 30% BTC revenue to our signers. In real world, both FIAT and shares are suitable to reward employees.
Put up a motion instituting a daily btc reward that will be rewarded to the signer who receives the most signer rewards (I.e. votes) for the day. Then, once that’s up and running, vote for 0 BKS reward. No developer changes necessary.
How about 2 signer reward votes, one for the BKS reward and one for the bkc reward? I don’t like the signer reward being bkc, but a lot of people do and it would make sense to put it to vote.
Edit: Sigmike already mentioned voting on both and laid out the difficulties associated with that. Possible, but a little messy.
The added recurring cost of being a signer compared with being a minter is basically the server cost, which is about $25/mo. I think the reward should reflect it. Signers shouldn’t expect to get rich by signing.
The reward needs to consider maintaining the server (time), calculatory costs for the deposited security and the risk of operating all the stuff without being compensated due to lack of reputation.
Signers shouldn’t expect to get rich by signing, right, but they won’t do it if they need to invest more than they earn from the compensation.
Luckily BKS holders have an incentive to do the signer job (because it’s crucial for the success of the company they own shares of) and some might already have some reputation before they even start a signing operation.
I’m speaking of people who already have a track record from the Nu network who now are BKS holders.
So the compensation won’t need to be far above the server costs to attract some signers, I guess.
The 101 delegates of bitshare are getting rich and ordinary Bts holders are being robbed.
If we cannot avoid this, may I call the signer reward factor as “stupidness index” of bks holders? Either overpay or underpay Signers is stupid. That may gauge the avarage IQ of shareholders. As low as BTS community? I believe we can vote a proper value.
One big difference between minting reward and signers reward is that every shareholder can mint and avoid being diluted but only 20 signers while BKS holders may become hundreds/thousands.
You are double counting “all the stuff” — “all the stuff” is what we are talking about.
Anyway I think the signing setup for a BCE signer is slightly more complicated than a TLLP / ALP ooperator setup. It’s basically a bot which is supposed to run automatically once set up, until manual upgrade. Thet initial set up may well take time and effort, but in the long term it should not take a lot of attention.