Author Topic: Ideas for a redesig of the fee architecture  (Read 3583 times)

0 Members and 1 Guest are viewing this topic.

Offline abit

  • Committee member
  • Hero Member
  • *
  • Posts: 4664
    • View Profile
    • Abit's Hive Blog
  • BitShares: abit
  • GitHub: abitmore
My preference would be to eliminate all fees and SIMPLIFY the role of committee members not make it more complicated.

Specify what you mean with *all fees*

Everything except market fees.
After the referral system was killed, now it's Mr. OnceOp  ;)
 
BitShares committee member: abit
BitShares witness: in.abit

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
My preference would be to eliminate all fees and SIMPLIFY the role of committee members not make it more complicated.

Specify what you mean with *all fees*

Everything except market fees.
Still, an issue of a "new crypto currency" may want to get a cut of transfer fees ..

Don't we won't to give customers/clients/users more control?

Offline Pheonike


I would say

Market fees
Lifetime/VIP  fee (Lifetime should be give access to certain features like multiple accounts in a wallet or cheaper market fees).



Offline bytemaster

My preference would be to eliminate all fees and SIMPLIFY the role of committee members not make it more complicated.

Specify what you mean with *all fees*

Everything except market fees.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline Bhuz

  • Committee member
  • Sr. Member
  • *
  • Posts: 467
    • View Profile
  • BitShares: bhuz
My preference would be to eliminate all fees and SIMPLIFY the role of committee members not make it more complicated.

Specify what you mean with *all fees*

Offline bytemaster

My preference would be to eliminate all fees and SIMPLIFY the role of committee members not make it more complicated.

For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline Bhuz

  • Committee member
  • Sr. Member
  • *
  • Posts: 467
    • View Profile
  • BitShares: bhuz
My initial thought: these suggestions may be useful, but are contrary to the "no new features / enhancements" approach we discussed with BM in a mumble session recently.

An evaluation needs to be done to estimate the cost of adding these enhancements. Can you do that xeroc? If the cost is relatively minor this may be reasonable to do as a maintenance effort. Even so, there are always risks to changing the code, and if stability and reliability is a high priority any changes need to be made carefully.

IMO, these would impact on one of the core side of BTS. No matter if it is saw as new features or enhancements, it really would be development towards strengthening the core of bts revenue stream... Working with the current fee structure I (and I think all the committee) realize that it really needs some improvements and diversifications to better adapt to different kind of markets and to better improve the overall revenue model.

@abit could probably estimate the cost and time needed for some of the suggested changes

Offline svk

Keep hearing that features are in the protocol but not the GUI. So is adding features to the GUI that exist in protocol considered maintenance or new development?
It's something I do on a regular basis as part of my worker, like the proposed transaction support that was added last week.
Worker: dev.bitsharesblocks

Offline Pheonike

Keep hearing that features are in the protocol but not the GUI. So is adding features to the GUI that exist in protocol considered maintenance or new development?

Offline Thom

My initial thought: these suggestions may be useful, but are contrary to the "no new features / enhancements" approach we discussed with BM in a mumble session recently.

An evaluation needs to be done to estimate the cost of adding these enhancements. Can you do that xeroc? If the cost is relatively minor this may be reasonable to do as a maintenance effort. Even so, there are always risks to changing the code, and if stability and reliability is a high priority any changes need to be made carefully.
Injustice anywhere is a threat to justice everywhere - MLK |  Verbaltech2 Witness Reports: https://bitsharestalk.org/index.php/topic,23902.0.html

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
(This thread does NOT discuss the fee schedule but opens the discussion for new features to allow more granularity in fees)

During the creation of the current fee schedule as few points came up
that could allow more flexibility and a more natural fee schedule if
they were implemented. Here they are:

* Have a way to define which operation requires LTM and which do not.
  For instance, we could say that assets can only be created by LTMs but
  the committee could open up asset creation for basic members for a
  short period of time.

* Give the committee a means to define which operations pay into the
  referral program and which do not. This could even be extended such
  that they can choose a precentage split between: network, referal
  program, FBA, funding account etc. Replace "committee" with issuer in
  the above, we could allow the issue to topup from the network fee and
  allow them to define additional fees for some operations that involve
  their asset and the corresponding fees to be payed not only to the
  network, but also to be split between: the referral program, an
  account or a FBA.

* we need a way to distinguish fees for MPA, UIA, and Prediction markets

* It may be useful to have a way to set the fee for
  withdraw_permission_claim to be either percentage-based on the amount
  to claim, or to be dependend on the time that they vest their
  balance.

Any further ideas?