feat: init ethereum

[pegahcarter]

Needs your review @FortisFortuna @tom2o17. I went off your suggestion @FortisFortuna in #1 with the interfaces structure for this PR and am a fan. Will likely refactor the other dirs to the same once consensus is reached.

[tom2o17]

This Looks good to me.

I am curious if we can just have the latest live implementation be in this repo. Eg FrxUSD3 -> FrxUSD similarly with the interfaces

It would be huge if we could have all other dev repos pull the latest commit of this repo and then not have to worry about refactoring deployment scrips/test cases just to change frxUSD3 -> frxUSD4,

Ideally moving forward we will just extend the exiting ABI so it should be fine

[pegahcarter]

If we do something like: FrxUSD4 is FrxUSD3 and FrxUSD3 is FrxUSD2, the features we add are isolated into their own version. This means that if we want to modify the freeze/thaw functionality, we:

1. modify FrxUSD2
2. change the version of FrxUSD3
3. Redeploy FrxUSD3

Pros:

• code changes are isolated to their version
• test coverage is separated by version

Cons:

• There are multiple existing versions/interfaces

---

With what you're proposing I see the code for each feature existing in the same contract. In this case we:

1. modify FrxUSD
2. change the version of FrxUSD
3. Redeploy FrxUSD

Pros:

• There is a single unified version/interface

Cons:

• ?

---

I think my love for inheritances may be getting the best of me here, and that you may be on to something.

If we go the route you're proposing, how do you suggest we handle the code being audited which inherits older FrxUSD versions? Should we refactor the code to be flat to a single FrxUSD, leave as-is, or something else?

[tom2o17]

@pegahcarter Yes or I am saying that we could just keep the contracts segregated and then just have

contract FrxUSD is FrxUSD4 { // }

and then we just pin the current prod version so this.

We can either do the above or just have FrxUSD be the latest verion.

I think it is less important to have each single contract version as opposed to having a single source of truth for the current production version for all downstream repos which will read in this package.

EG I do not want to have to edit the tests in the downstream child repo when we update from FrxUSD4 -> FrxUSD5

lmk if that makes sense also happy to open a PR on this branch

[pegahcarter]

I totally agree that we shouldn't have to edit tests in the dowstream child repo.

And now I get what you're saying about the single source inheriting the versions.

Yeah, take a stab at it with a PR off this branch! I'd like to see what you'll come up with.

[pegahcarter]

Related conflict: FraxFinance/frax-standard-solidity#31

[tom2o17]

@pegahcarter

Merging init-repo into this branch did not seem to cause any dependency compilation errors.

[pegahcarter]

I'm talking about the conflicts that must be resolved. I think we have to bite the bullet with a unpinned OZ import unless you have any other suggestions.