[Worker Proposal] Percentage-based transfer fees

[Pheonike]

Can the the flat/percentage be dynamic? What I mean is the system checks to see which fee is cheapest in terms of a default reference fiat (USD,CNY,EUR).  So in addition to setting the flat fee and percent, the issue er can also set a parameter like "if flat fee) > X in fiat terms then use percentage fee. Maybe even charge the issue er a fee for extra resources to compute the fee if they choose this option.

[abit]

I wonder whether one change is possible.

as I found the endless debate on transfer fee mainly come from the different business culture around the world, in China referral program is just a trouble maker, but maybe it works in US and western europe. so I also consider to split the transfer fee charging mode in order to fit the difference. the flat fee mode will be irrelevant with referral program, all the fee go to network, while for percent-based-fee mode, some part of the fee will go to the referrer.

is it possible to make the flat fee mode irrelevant with referral program?

Technically I can write code like this. But whether to do it should be decided by stake holders.

[abit]

@jakub, I understand why fees need to be charged in BTS.  But why are you not defining a target minimum fee in terms of a stable currency so that when BTS goes up ten-fold, we don't have this minimum fee also going up ten-fold?  Surely you realized that having a moving target like this means that a business model that works today may not work tomorrow.  And some users that are happy with the fees today, will not be happy tomorrow.  You are ensuring uncertainty when it comes fees, which will likely wreak major havoc.  Why are you doing that?  It seems misguided and very unnecessary.  Unless I'm missing something.  Care to explain?

From what I understood, the floor and cap is defined by each issuer and can be changed on a per asset bases as frequently as needed ..

With current BSIP, global floor/cap/percentage is defined by the committee, issuers can not define them. Otherwise the issuer will be able to game the referral program.

No, I believe the 6BTS floor is the mandatory minimum that must be paid to the network, anything above that would be split between the network and referrers.  I hope I'm missing something, otherwise this is just idiotic and will put me right near my wit's end with all of this.

6 go to the network .. everything above 6 goes to referral program

Yes, that's exactly what I said already -- the minimum to the network is 6BTS.  But the point is, what does 6BTS mean to users or to a business?  Today it means about $.02.  In a few months it could mean $.20.  How can a business build around that?  One of the rationales of this proposal is to preserve the referral program.  Yet the referrers now have much more uncertainty.  In fact, based on today's BTS value in USD, if this proposal goes through, a $200 transfer with a .1% fee would generate the equivalent of a $.20 fee, or about 60BTS.  The network would keep 6BTS plus 20% of the remaining 14BTS, leaving the other 80% of the 14BTS for the referrer. 

Now let's say, just as an example, the value of BTS goes up 10X in the coming months.  Now that same transaction fee of .20 would be the equivalent of 6BTS, so the network would take 100% and the referrer would get nothing.  So much for protecting the referral program. 

Not to mention, if the value of BTS goes up any further than that, the actual rate to the user would go up.  Or for a business built atop Bitshares, their costs would be higher due to the increased fees, potentially making their model non-viable.   

Again, unless I'm missing something, I have to say WTF are we doing here?!

The committee is responsible to adjust the global floor/cap when BTS price arise/drop by x%.

[tbone]

No, I believe the 6BTS floor is the mandatory minimum that must be paid to the network, anything above that would be split between the network and referrers.  I hope I'm missing something, otherwise this is just idiotic and will put me right near my wit's end with all of this.

6 go to the network .. everything above 6 goes to referral program

Yes, that's exactly what I said already -- the minimum to the network is 6BTS.  But the point is, what does 6BTS mean to users or to a business?  Today it means about $.02.  In a few months it could mean $.20.  How can a business build around that?  One of the rationales of this proposal is to preserve the referral program.  Yet the referrers now have much more uncertainty.  In fact, based on today's BTS value in USD, if this proposal goes through, a $200 transfer with a .1% fee would generate the equivalent of a $.20 fee, or about 60BTS.  The network would keep 6BTS plus 20% of the remaining 14BTS, leaving the other 80% of the 14BTS for the referrer. 

Now let's say, just as an example, the value of BTS goes up 10X in the coming months.  Now that same transaction fee of .20 would be the equivalent of 6BTS, so the network would take 100% and the referrer would get nothing.  So much for protecting the referral program. 

Not to mention, if the value of BTS goes up any further than that, the actual rate to the user would go up.  Or for a business built atop Bitshares, their costs would be higher due to the increased fees, potentially making their model non-viable.   

Again, unless I'm missing something, I have to say WTF are we doing here?!

[Ben Mason]

This is so important and you've put in a great deal of effort to do it right. You have my full support. Thank you.

Bitcrab, thank you for your input, sincerity and being open to all ideas.

[xeroc]

No, I believe the 6BTS floor is the mandatory minimum that must be paid to the network, anything above that would be split between the network and referrers.  I hope I'm missing something, otherwise this is just idiotic and will put me right near my wit's end with all of this.

6 go to the network .. everything above 6 goes to referral program

[tbone]

@jakub, I understand why fees need to be charged in BTS.  But why are you not defining a target minimum fee in terms of a stable currency so that when BTS goes up ten-fold, we don't have this minimum fee also going up ten-fold?  Surely you realized that having a moving target like this means that a business model that works today may not work tomorrow.  And some users that are happy with the fees today, will not be happy tomorrow.  You are ensuring uncertainty when it comes fees, which will likely wreak major havoc.  Why are you doing that?  It seems misguided and very unnecessary.  Unless I'm missing something.  Care to explain?

From what I understood, the floor and cap is defined by each issuer and can be changed on a per asset bases as frequently as needed ..

No, I believe the 6BTS floor is the mandatory minimum that must be paid to the network, anything above that would be split between the network and referrers.  I hope I'm missing something, otherwise this is just idiotic and will put me right near my wit's end with all of this.

[xeroc]

@jakub, I understand why fees need to be charged in BTS.  But why are you not defining a target minimum fee in terms of a stable currency so that when BTS goes up ten-fold, we don't have this minimum fee also going up ten-fold?  Surely you realized that having a moving target like this means that a business model that works today may not work tomorrow.  And some users that are happy with the fees today, will not be happy tomorrow.  You are ensuring uncertainty when it comes fees, which will likely wreak major havoc.  Why are you doing that?  It seems misguided and very unnecessary.  Unless I'm missing something.  Care to explain?

From what I understood, the floor and cap is defined by each issuer and can be changed on a per asset bases as frequently as needed ..

[tbone]

@jakub, I understand why fees need to be charged in BTS.  But why are you not defining a target minimum fee in terms of a stable currency so that when BTS goes up ten-fold, we don't have this minimum fee also going up ten-fold?  Surely you realized that having a moving target like this means that a business model that works today may not work tomorrow.  And some users that are happy with the fees today, will not be happy tomorrow.  You are ensuring uncertainty when it comes fees, which will likely wreak major havoc.  Why are you doing that?  It seems misguided and very unnecessary.  Unless I'm missing something.  Care to explain?

[kenCode]

Great work @jakub you guys have my/our full support.

[bitcrab]

I wonder whether one change is possible.

as I found the endless debate on transfer fee mainly come from the different business culture around the world, in China referral program is just a trouble maker, but maybe it works in US and western europe. so I also consider to split the transfer fee charging mode in order to fit the difference. the flat fee mode will be irrelevant with referral program, all the fee go to network, while for percent-based-fee mode, some part of the fee will go to the referrer.

is it possible to make the flat fee mode irrelevant with referral program?

 

[jakub]

As suggested by xeroc, I've amended the BSIP to make this issue clear:

The choice of the fee model is not meant to be permanent.
The issuer is always free to change his mind and switch back and forth between flat and percentage-based modes.

The only thing the issuer needs to consider, is the marketing aspect.

[xeroc]

I just want to emphasize one important aspect: this worker proposal is
the first ever attempt to introduce a significant new feature to
Graphene (and BitShares) without the direct involvement from CNX. If we
are successful, this proposal will pave the way for other entrepreneurs
and developers to follow in our footsteps and make BitShares less
dependent on CNX.

This is a great step forward!

As stated in the BSIP,  we would like to make detailed documentation a
crucial part of this proposal, thus offering an important benefit for
the whole ecosystem. The documentation produced as a result of this work
will help other developers to join the ecosystem and offer worker
proposals for further features.

This is GREAT and I would love to contrinute as much as possible.

- unit testing and testnet testing (by abit & jakub, hopefully with the help from xeroc),

Sure thing

As for vesting, initially we intended to make at least 50% of the payout
vest for a year.  However, some of our expenses (e.g. code review or GUI
support) require immediate vesting, so we've concluded that we will
stick to immediate vesting but we will introduce an escrow in the form
of the committee-account, so that no payouts can be made without the
committee agreeing that the goal of this proposal has been achieved.
https://cryptofresh.com/u/bsip10-worker

This is a great idea!

As for the time-frame (assuming the worker proposal gets approved by mid Feb):
- we estimate that 6 weeks are needed to complete the coding
- further 2 weeks are needed to produce unit tests and GUI support
- further 2 weeks should be reserved for code review and potential fixes after the review
- further 2 weeks should be reserved for testing on the public testnet
Therefore a total of 12 weeks is our target.
The process of creating full documentation will be done in parallel and should be complete before deployment.

If you have any questions or concerns, please ask in this thread.
We appreciate your votes for 1.14.29!

I support this. Reasonable price a lot to benefit. I will need to re-read the BSIP first, though

[jakub]

As announced previously in this thread by me and this thread by abit, we have created a worker proposal for percentage-based transfer fees.
You'll find it in the CLI under this id: 1.14.29 and in the GUI under this title: [BSIP10] Percentage-based transfer fee solution based on CER.

A detailed description, in the form of a BSIP, can be found on github:
https://github.com/bitshares/bsips/blob/master/bsip-0010.md

The main goal of this proposal is to make BitShares viable for transferring smaller amounts. The current flat transfer rate is not friendly for small transfers, as for these transfers the flat transfer fee makes up a significant part of the amount being sent. We want to change that by making the fee proportional to the amount being sent, thus strictly related to the usefulness of the transfer as perceived by the user. The important thing is that we will end up with two transfer fee modes (flat and percentage-based) and it will be up to issuers to choose the best option for their assets. So this is an opt-in feature decided by the issuer (committee members in case of public SmartCoins).

Also, our aim is to open up BitShares for micro-payments without doing any damage to the referral program. However, this aspect largely depends on the parameter settings that will ultimately be decided by the committee.

The concept itself, our approach and the expected outcome have all been explained in details in the BSIP so I won't repeat it here.

I just want to emphasize one important aspect: this worker proposal is the first ever attempt to introduce a significant new feature to Graphene (and BitShares) without the direct involvement from CNX. If we are successful, this proposal will pave the way for other entrepreneurs and developers to follow in our footsteps and make BitShares less dependent on CNX.

As stated in the BSIP,  we would like to make detailed documentation a crucial part of this proposal, thus offering an important benefit for the whole ecosystem. The documentation produced as a result of this work will help other developers to join the ecosystem and offer worker proposals for further features.

Our proposal includes the whole package:
- the coding (by abit),
- the code review (by CNX),
- unit testing and testnet testing (by abit & jakub, hopefully with the help from xeroc),
- full documentation & guidelines for similar projects (by jakub),
- GUI support (by svk).

As for known limitations of this proposal, please refer to the BSIP.
The most important one is this: our proposal is unable to cover stealth transfers (due to the very nature of stealth transactions).

Our total budget is 4.4m BTS, with the following split:
- abit: 3000k
- jakub: 800k
- CNX: 350k
- svk: 120k
- budget for testing: 130k

As for vesting, initially we intended to make at least 50% of the payout vest for a year.
However, some of our expenses (e.g. code review or GUI support) require immediate vesting, so we've concluded that we will stick to immediate vesting but we will introduce an escrow in the form of the committee-account, so that no payouts can be made without the committee agreeing that the goal of this proposal has been achieved.
https://cryptofresh.com/u/bsip10-worker

As for the time-frame (assuming the worker proposal gets approved by mid Feb):
- we estimate that 6 weeks are needed to complete the coding
- further 2 weeks are needed to produce unit tests and GUI support
- further 2 weeks should be reserved for code review and potential fixes after the review
- further 2 weeks should be reserved for testing on the public testnet
Therefore a total of 12 weeks is our target.
The process of creating full documentation will be done in parallel and should be complete before deployment.

If you have any questions or concerns, please ask in this thread.
We appreciate your votes for 1.14.29!