Liquidity is one of our greatest issues.  One possible solution would be to use the power to dilute to create more bitassets to hold the peg. 

We could create a worker proposal that sends funds to the committee account.  We could design a bot that will short assets into existence and sell them at a prescribed rate above the peg.  This would still require a majority of committee members to approve each transaction.  this approval could also be automated.

We could through the committee have a market maker that holds the peg of smartcoins to within a couple of percentage points of the feed price.  We could even branch out into other derivatives such as individual stocks. 

Once again I am looking for community input.  Please argue your point.  If there are specific parameters that would be deal breakers please mention them as well.   You may change your vote if you have changed your mind.

Thank you for your input.

I think a return to dividends per share would be good..

I don't think these profits should do through the committee account

What's your opinion on the discussion of liquidity in the committee telegram channel alt?

I don't understand your issue or your solution alt.  Not all fees belong to the committee.  Only the fee pool conversions as far as I know.  You are definitely more knowledgeable than I. Let me know if my understanding is incorrect. 

Also I don't get your solution.  Please expand.

FYI we had some discussions about how to efficiently pay dividends long time ago, a claim model.
https://bitsharestalk.org/index.php?topic=14785.msg191711#msg191711

Basically, distributing fees among referrers/registrars is an operation which cost linear to the amount of operations within a maintenance interval, but distributing funds among asset holders is linear to the amount of holders. The former is doable in the maintenance interval, but the latter is not.

Thanks abit.  I'll read through this.

Instead of pushing dividends, couldn't the process be a pull. When a dividend is available, a claim button is enabled in the gui that shows amount available to claim.  The holder of the asset can decide when to claim the dividend. This way the process can happen over a period on time instead of one interval.

That's what I was hoping for.  My belief was based upon the bug we had where different nodes would show different vested balances for different VBO's.  I assumed that this was due to vesting balances being derived from the blockchain state, but not implicit.  I thought this could save us some overhead. 

I was thinking that each FBA would have an object that contained all hodlers and the percentage of total asset they hodl.  It seems we should need this to determine the top 5 hodlers anyways.

If crediting each hodlers VBO in real time would take too much processing power could we do it during the maintenance interval?

It seems to me that a credit to a VBO is different than a normal transaction output.  Its kept in memory, and not written to the blockchain until withdrawal right?

I was looking through the docs, and I found the section on creating vesting balance objects.  Wouldn't that be a better way of distributing the revenue of a fee backed asset than with a buybay?  What are the fees to deposit to a vesting object?  Could a FBA deposit to the same VBO that is used for cashback, or would each FBA need to create its own VBO?  We could require that a potential hodler of a FBA registers a VBO for it.  95bts once, plus 2bts per withdrawal seems like a better deal than having to place orders for a buyback. 


        Public Members

        uint64_t fee

            the cost to register the cheapest non-free account

struct vesting_balance_create_operation
    #include <vesting.hpp>

    Create a vesting balance.

    The chain allows a user to create a vesting balance. Normally, vesting balances are created automatically as part of cashback and worker operations. This operation allows vesting balances to be created manually as well.

    Manual creation of vesting balances can be used by a stakeholder to publicly demonstrate that they are committed to the chain. It can also be used as a building block to create transactions that function like public debt. Finally, it is useful for testing vesting balance functionality.

    Return
        ID of newly created vesting_balance_object

    Public Members

    account_id_type creator

        Who provides funds initially.

    account_id_type owner

        Who is able to withdraw the balance.

class vesting_balance_object
    #include <vesting_balance_object.hpp>

    Vesting balance object is a balance that is locked by the blockchain for a period of time.

    Public Functions

    void deposit(const fc::time_point_sec &now, const asset &amount)

        Deposit amount into vesting balance, requiring it to vest before withdrawal.

    void deposit_vested(const fc::time_point_sec &now, const asset &amount)

        Deposit amount into vesting balance, making the new funds vest immediately.

    void withdraw(const fc::time_point_sec &now, const asset &amount)

        Used to remove a vesting balance from the VBO. As well as the balance field, coin_seconds_earned and coin_seconds_earned_last_update fields are updated.

        The money doesn’t “go” anywhere; the caller is responsible for crediting it to the proper account.

    asset get_allowed_withdraw(const time_point_sec &now) const

        Get amount of allowed withdrawal.

    Public Members

    account_id_type owner

        Account which owns and may withdraw from this vesting balance.

    asset balance

        Total amount remaining in this vesting balance Includes the unvested funds, and the vested funds which have not yet been withdrawn

    vesting_policy policy

        The vesting policy stores details on when funds vest, and controls when they may be withdrawn.

struct vesting_balance_withdraw_operation
    #include <vesting.hpp>

    Withdraw from a vesting balance.

    Withdrawal from a not-completely-mature vesting balance will result in paying fees.

    Return
        Nothing


Am I missing something?

So.  the consensus seems to be option 1.  Starting at 15% over feed and reducing daily until all funds are gone.  I would also suggest a hard lower limit of 105%

As Xeroc mentioned the difficulty with that is that the committee account cannot place orders in real time.  We need to submit a proposal, and have it approved by the majority of the committee.  We are a very diverse set of people from around the globe, and coordinating that could be difficult.

I still think leaving these funds in the hands of the committee is the best option if we can pull it off.  If we set the proposal for somewhere between a 2 and 4 hour window everyday, we should be able to find a time where all committee members can log in and approve.

Does anyone else think I should reset the results of the poll?  Enough people in this thread have stated that they voted for the wrong thing in the poll.