Crowd Employment Contract (aka the Charity-with-Strings-Attached Pattern)


I want to work on XYZ full time, but I can't afford to do so without income. XYZ doesn't earn anyone any money directly, but provides value to individuals (or not). Bob & others want to invest in XYZ, but not give their money away completely and lose total control of the situation.

So I need some amount of security that any income I have won't vanish.
Bob wants to fund XYZ in some way, but he wants some security that the funding won't vanish without any progress.


A Proposed Solution:

Contract rules are drafted for an 'employment contract' which govern the use of the contract funds in a way that allows for all parties to have partial control of 'their' funds. (Remember savings wallets from the whitepaper?)

- I am allowed to withdraw N funds every time period, according to the needs of the specific contract.

- Bob is allowed to withdraw M funds from his contribution every time period, (probably) where M>N.

- M and N can be ether amounts, percentage of the total fund, some sort of combination of both, etc.

- Withdrawls > N could be voted on by Bob & co. or be time-locked, allowing Bob to pull more funding in a disagreement, or just not be allowed at all..

So I can work with income within the limits set in the contract, having some security that the money can't be pulled immediately, and Bob has the security that I can't run away with all of his money. Bob can still pull all his funds over time if he loses faith in XYZ.



Putting my code where my mouth is:

Note: this contract doesn't implement any withdrawls > than limit rules.


PS: This was framed as an employment contract for relatablity, but this same pattern can be used for specific projects, project tasks, communities, etc... In fact, it seems less risky to use a multitude of funds with different rules and purposes: short term and long term, experimental and more concrete, risky and safer, project-based and personal-based. (Never hinge your livelihood on a single contract -- single point of failure ;) )

PPS: Link these 'employment contracts' up with reputation/identity/name contract systems and/or Kickstarter-esque listing contracts for added benefit.


  • JasperJasper Eindhoven, the NetherlandsMember Posts: 514 ✭✭✭
    Good job :) If you want to test it i suggest cll-sim.

    If it is a wage, i think it is better to every access automatically first send WAGE*(last_access_time-block.timestamp), where last_access_time is kept track of in storage. That way, the donation recipients are by design equally assertive about their funds, so they dont have to put energy in being assertive or not. There are also fewer parameters in that concept.

    I wrote something like this; 'gitbittip', also untested. It is from the point of view of senders.

    Generally, things seem to be simpler if you basically stuff everything into constants. Thats why the pov of 1-sender 1-recipient is easier, because you can put both sender and donator as constants. But then you need new contracts for different things, or rewrite the contract to change something. I think that might make the fees of operation higher than having fewer, more complicated contracts.(not entirely sure, it may depend) I think i should make the 'gitbittip' contract from the point of view of the recipient..

    About connecting stuff like reputation/identity/name/judges contract systems, i wonder if it is better to change the contract, or to have the contract be exactly the same, but just have another script talk to it.

    For instance there could be a 'judges contract' that you put infront of the crowd-employment contract. People donating send to the judges contract, which sends it along and keeps track of who donated. If the judges decide to take money out, it goes to the script first, and is automatically redistributed to donators.
  • wemeetagainwemeetagain Member Posts: 30
    @Jasper? Thanks for the link, yeah none of it has been tested :P

    For the wage, the contract was made much more complicated by letting both 'employee' and 'funders' withdraw multiple times up to the wage limit per 'pay period'. It does store the 'last_access_time' and 'current_period_withdrawal_amt' to figure that out.

    I've been under the assumption that you can use contract storage at the index of the sender address to allow for many participants to store data and not need constants for each participant.
    ex:[tx.sender] = X

    For the recipient/owner/single-participant-type-per-contract, I've just been using arbitrary low-ish indexes to store necessary data.
    ex:[500] = X
    Perhaps this is better suited as a constant, at least for readability's sake.

    Can you repost the gitbittip link? Looks empty.
  • JasperJasper Eindhoven, the NetherlandsMember Posts: 514 ✭✭✭
    edited March 2014
    does it work now? I probably forgot the quotes in the html.
Sign In or Register to comment.