R&D into the technical requirements for making FIO a Layer 2 resolver for ENS.

• Article: A general-purpose bridge for Ethereum Layer 2s: https://medium.com/the-ethereum-name-service/a-general-purpose-bridge-for-ethereum-layer-2s-e28810ec1d88

• Video: How ENS is going to scale. https://www.pscp.tv/w/1MnxnlarXweGO

Overview

There are different ideas as to what an ENS Layer 2 solution might look like. Refer to the

• From Eric: Implement FIO as an "L2" solution where the FIO gateway controls all of the registration of the "subdomains" (which would be the FIO domains, e.g., edge.fio.eth ). It would enable FIO getter information (e.g., a "record" like btc.eric.edge.fio.eth) to be resolved using the ENS L2 api (if/when that becomes available) which would 1) do a lookup on fio.eth using ENS, 2) "redirect" to the FIO Gateway to do the lookup of the mapping, and 3) validate the response from the FIO gateway via a second call to the L2 API.

• There is a question as to whether we should try to get a FIO TLD instead of using the ETH TLD.

R&D Tasks

• What does an Ethereum resolver contract look like and what is the level of effort to build it?

• What would a FIO Gateway look like?

• Flesh out how the Client > Resolver Contract > Gateway interaction would work (see Article above).