ERC20Escrow && ERC20RefundableEscrow

General
1

This is a very early work in progress, but I figured I'd start the convo earlier than later. These contracts serve as a trusted entity that temporarily owns ERC20 tokens on behalf of multiple parties.

Important Notes:

  • I deliberately require the guarantor (client) to transfer tokens over to the escrow for ownership as apposed to giving it an allowance. We want to ensure that the funds will be there for the time of payment.

  • There is a concept of "reserved" in ERC20Escrow. This is the maximum credit that an account can use and is different than the actual balance of that account in the ERC20 ledger. The ERC20RefundableEscrow keeps track of how much of the total budget is ALLOWED to be transferred to an individual account. This provides a nice scalable system for a company to limit a budget on a per-employee basis or as a single account for the whole company. You don't want one dude stealing the entire budget then heading down to Mexico...

  • ERC20RefundableEscrow#transfer() takes an amount argument and updates "reserved". This functionality allows an account to get paid in portions instead of paying the full amount in one shot. This is needed in many real-world situations and can easily be overwritten by Primary if the implementer wants it.

  • "reserved" will allow the ability to refund a prorated amount to a client while holding onto the wages of an account that has not yet "withdrawn" their tokens. That functionality will be implemented later.

Important Question: Does anyone know of a way where we can have a callback function that is called when a deposit is made to a ERC20 ledger for the address of ERC20Escrow?

I'm looking for suggestions. Next on my list is to allow for refunds and add more tests. I will also add an extension to this where an arbitrator (lawyer) or arbitrators (lawyers) must first approve the funds to be released to either side of the relationship.

1 Like
2

This is great, and simple enough that it's easy to understand that it works :slight_smile:

There's no way to do so, unfortunately :frowning: The only way is by using an ERC20 extension such as ERC223, but I don't know if any of those has been finalized and has actual use in production.

You also may want to take a look at the escrow-exploration branch, were we added similar contracts. We were not convinced about the API, so it hasn't been merged into master yet, but are interested in making this happen!

1 Like
3

You have some good stuff in the escrow-exploration. What were some of the issues? Perhaps I can tackle the API.

4

@tinchoabbate wrote those contracts, perhaps he can chime in?

iirc those escrows came to be from the need for a generic time lock, and therefore for a generic escrow. One of the issues I remember was that there was a lot of code duplication in the ether and token variants, and we failed to abstract away what the underlying resource was. I’m a bit hazy on the details though, we may want to revisit this soon: if (as I expect it to) usage of stablecoins continues growing, these sort of utilities may prove very useful.

5

Yeah I think the problem was we weren’t happy with the duplication between ether and token variants, or even with having two separate contracts.

It feels like we should be able to build a common abstraction for at least those two types of fungible assets…

6

We’ll probably use some sort of token escrow to fix #1595, so it’d be great if we could come up with a good solution soon.

1 Like
7

As of Solidity compiler v 0.5.0 functions must explicitly use payable, so we can’t duck type. I tried. It would have been so clean and allowed us to merge ERC20Escrow with Escrow, but nope :-(. I’ll circle back on this later. I have some other contracts in the works…