How does it work?

Decentralization logic

Escrow Process Illustration
Initiating the Escrow Process:
To initiate an escrow, the buyer is required to establish a new escrow contract by submitting accurate data. Subsequently, both parties must transfer the required amounts into the newly created contract. A pivotal feature of this system is the safety deposit, which is mandatory for both parties prior to activating the escrow. This mechanism is integral to enforcing the protocol’s reconciliation rule. The safety deposit amount is equivalent to the transaction value within the escrow. Consequently, the receiver is obligated to deposit a sum double the value of the escrow, while the provider deposits an amount equal to the escrow value. This process ensures enhanced security and commitment from both parties, aligning with the core principles of decentralized finance and fostering trust in the transaction.
Example: Lets say the escrow amount is x amount of tokens and fee is the protocol fee:
Required amounts to deposit:
Transfered amounts after successfull escrow:
Refunded amounts after mutual refund decision:
Buyer: 2x
(Safety deposit + escrow amount)
Buyer: (x - fee/2)
Buyer: (2x - fee/2)
Seller: x
(Safety deposit)
Seller: (2x - fee/2)
Seller: (x - fee/2)
*Safety deposit is always = escrow amount
Safety deposits are refunded upon the conclusion of the escrow. The protocol fee is equally divided and deducted from these safety deposits. The funds are always withdrawable and not subject to the protocol fee prior to the contract initializing. The contract is initialized when both parties have contributed the necessary amounts, including safety deposits. Once initialized, withdrawals are disabled. However, if one party has not funded the contract, the other party can always withdraw their funds without incurring a protocol fee. The only way to end an escrow contract after initialization and full funding by both parties is, through a mutual decision regarding the escrow's outcome.
Post-Initialization:
After funding and initialization of the contract, there are three potential outcomes. If both participants approve the escrow, the transaction is successfully completed and funds are transferred. If both request a refund, the contract concludes, and each party retrieves their initial deposits, minus the protocol fee. The last scenario involves the escrow tokens remaining in the contract until one of the aforementioned outcomes occurs. Should either or both parties opt to decline, the contract persists, safeguarding the assets until a consensus is reached. This structure compels parties to collaborate towards an optimal resolution, as their assets remain locked until an agreement is made. Elektroscrow achieves full decentralization by obliging participants to resolve disputes autonomously, governed by smart contracts, thereby eliminating the need for a third-party moderator.
All possible scenarios after decisions are made:
Decisions:
Buyer: Accept
Buyer: Refund
Buyer: Accept
Buyer: Refund
Buyer: Decline
Buyer: Accept
Buyer: Refund
Buyer: Decline
Buyer: Decline
Seller: Accept
Seller: Refund
Seller: Refund
Seller: Accept
Seller: Accept
Seller: Decline
Seller: Decline
Seller: Refund
Seller: Decline
Outcomes:
Successfull transfer
Refund
Safekeeping*
Safekeeping*
Safekeeping*
Safekeeping*
Safekeeping*
Safekeeping*
Safekeeping*
Safekeeping*= Funds are securely kept inside the contract until either refund or transfer outcomes occur