Proposal “dash-org-dec-replace“ (Completed)Back
Title: | Dash.org purchase - December Payment Replacement |
Owner: | babygiraffe |
Monthly amount: | 702 DASH (41107 USD) |
Completed payments: | 3 totaling in 2105 DASH (0 month remaining) |
Payment start/end: | 2016-04-06 / 2016-07-21 (added on 2016-03-29) |
Final voting deadline: | in passed |
Votes: | 868 Yes / 51 No / 0 Abstain |
External information: | www.dashwhale.org/p/dash-org-dec-replace |
Proposal description
As you may know, the month of December no budget payments were made. This affected all budgets.
One item that was slated to start in December was the reimbursement for the Dash.org acquisition. So payment #1 of 4 was never paid to reimburse Evan and Daniel for the expense the domain.
The missing payment was 2,100 Dash. We don't have room in the budget this month for the full 2,100, so I decided to split this payment of 2,100 Dash (plus 5 Dash for the proposal cost) into 3 payments from April to June.
babygiraffe
One item that was slated to start in December was the reimbursement for the Dash.org acquisition. So payment #1 of 4 was never paid to reimburse Evan and Daniel for the expense the domain.
The missing payment was 2,100 Dash. We don't have room in the budget this month for the full 2,100, so I decided to split this payment of 2,100 Dash (plus 5 Dash for the proposal cost) into 3 payments from April to June.
babygiraffe
Show full description ...
Discussion: Should we fund this proposal?
Submit comment
No comments so far?
Be the first to start the discussion! |
1) The network bears the exchange rate risk
2) The team member bears the exchange rate risk
If #1, there will ALWAYS be a difference from the time the expense is submitted and the time the network makes one or more payments. In order to "settle up" with the network properly, the team member would have to return any "excess" funds at the time of payment if they received too much Dash, or submit ANOTHER proposal to cover the shortfall at the time of payment in a potentially endless cycle if the exchange rates result in them receiving too little Dash to cover the expense. This is neither practical nor efficient.
If #2, the risk of the exchange rate going down before the member is paid can only be fair to that member if they also reap the benefits when the exchange rate increases.
These are contracts... when a British company signs a contract to pay in USD, it still has to pay in USD even though it makes its money in GBP. These proposals are much like contracts with the team member. The team member is committing to a USD expense today only if the network agrees to pay it back with the equivalent amount of Dash at that point in time. They are entering into a contract that is essentially PURCHASING Dash at the CURRENT exchange rate by incurring an expense on behalf of the network.
In this particular instance, the expenses were originally paid by selling Dash, so Dash is owed back to the member, so it's really irrelevant for this proposal. But I want to make this clear so there isn't confusion in the future about who is accepting the downside risk in these proposals, and therefore the upside "risk" as well. It should not matter whether they sold Dash first to pay the expense or if they pay the expense out of their own pocket. What a team member does to raise the fiat (whether they borrow from a friend, sell a masternode, etc) is neither relevant nor any of the network's business, nor is it even verifiable that they sold Dash first.
In fact, I would argue that by differentiating, we open ourselves up to potential abuse of the system. The team member could sell Dash to fund an expense, but not specify the source of funding until after the Dash payment was made to him. If the exchange rate had declined, the member could then lie and claim that they funded with fiat from their bank account and are therefore owed more money (and there would be no way to disprove this). Whereas if the exchange rate had increased, he could then produce proof of the Dash sale to fund the expense and keep the full amount.
Let's keep this simple. Team members bear all risk.