At the core of our platform, we provide the ability to generate smart contracts that represent one well-defined relationship.

Job Contract

The job contract is our main contract and is necessary for MVP. The rest of the platform can really be thought of as a nice UI for a collection of contracts. This is where the meat of the application lives.

• When a user creates a new listing, a contract is created with the following relevant addresses:
  • Owner: EngineerDAO
  • Supplier: Whichever address clicks “Create” and pays the Bounty.
  • Engineer: Starts undefined , later assigned to whichever address clicks “Accept” and pays the Buy-In.
• Timeframe: upon contract creation, the supplier must set a timeframe. This should be encoded in the contract. When the timeframe expires, the contract defaults to pay the engineer bounty + buy-in.
• Awaiting Payment: The engineer address should be able to put the contract in “Awaiting Payment” status. This means they have completed their work and are waiting for the supplier to “Complete” the contract and trigger payment.
• Completion: When a supplier clicks “Complete”, their address should be able to trigger a payout to the engineer address (bounty + buy-in.)

sequenceDiagram
	Supplier->>dApp: Trigger "Complete"
	dApp->>Engineer: Pay Bounty + Buy-In

• Dispute: When a supplier clicks “Dispute”, the dispute resolution workflow starts and the timer stops. The contract can ONLY be directed and modified by EngineerDAO at this point. Upon completion of the dispute resolution workflow, we will trigger a payout. See Dispute Resolution.
• Cancel: If the contract has not yet been accepted, the supplier address should be able to cancel the contract. The bounty is transferred back to the supplier. This closes the contract for any further activity, but obviously still remains part of the public record.
• Cancel (Accepted): If an engineer has already accepted the contract, they can choose to allow a cancellation. The supplier will need to “Request Cancellation”, and the engineer will be asked to confirm. If the engineer confirms, the contract pays the supplier the bounty and the engineer is paid the buy-in.
  • Disapproval: If the engineer refuses to allow the cancellation, the supplier’s only recourse is dispute resolution. Otherwise the contract will timeout and pay the engineer bounty + buy-in.

sequenceDiagram
	Supplier->>dApp: Request "Cancel"
	dApp->>Engineer: Notify of Cancellation Request
  Engineer->>dApp: Approve "Cancel"
  dApp->>Supplier: Payout Bounty
  dApp->>Engineer: Payout Buy-In

• Engineer Cancel: If the engineer chooses to cancel the contract, they will forfeit the buy-in. Buy-in should be transferred to the supplier.

Statuses

• Available
  • Created by supplier.
  • Not yet accepted by engineer.
  • Available for acceptance by engineer.
• Active
  • Accepted by engineer
• Awaiting Payment
  • Engineer has marked the contract complete. Waiting for supplier to Complete.
• Completed
  • The supplier has “Completed” the contract, paying the engineer bounty + buy-in. The contract becomes permanently inactive.
  • At the end of a Dispute Resolution workflow, the contract will also be in Completed status. However, funds may be distributed differently depending on the resulting decision.
• Disputed
  • The supplier has pressed “Dispute” and the contract is in the dispute resolution workflow.
• Close Requested
  • An engineer has accepted the contract, but the supplier wants to close it. If the engineer presses “Close”, bounty goes to supplier, buy-in to engineer, and the contract goes to “Closed” status and is permanently inactive.