About Resolver

Background

A resolver is a non-standard name system used by the Superfluid Protocol in order to be able to discovery addresses on all networks regardless the presence of a standard one such as ENS.

The current implementation spawns of from a testing implementation called TestResolver, it only has setter/getter for mapping names and addresses.

The addresses of the resolvers on each network could be found at the Superfluid Network Directory.

Usage of Keys

Superfluid Protocol Discovery

Different protocol release versions of Superfluid Protocol deployment could be registered on the resolver.

The current publicly released protocol release version is "v1".

To discover the Superfluid host contract resolver key Superfluid.${protocol_release_version} is used.

Additional addressed of the core protocol could be then discovered through the host contract itself.

Non-Super Token Listing

• tokens.${non_super_token_symbol} - All non super tokens are stored here.

Super Token Listing

• supertokens.${protocol_release_version}.${super_token_symbol} - Super tokens are registered here.

Admin of the Resolver

• It started as the same as the host governance address.
• Later it devolved to be using a separate multisig.

Framework Loader

We allow multiple instances of the framework to be registered in the resolver, in order to have testing and staging environment during contract development. They are separated through protocol_release_version, of which the public production version is "v1".

The Framework Loader is also implemented on-chain to use view functions to speed up loading sequence.

Initialization sequence

await sf.initialize()

• Superfluid.${protocol_release_version} - Load host contract address.
• ISuperfluid.getAgreementClass(id("org.superfluid-finance.agreements.ConstantFlowAgreement.v1")) - Load CFA contract address.
• ISuperfluid.getAgreementClass(id("org.superfluid-finance.agreements.InstantDistributionAgreement.v1")) - Load IDA contract address.
• ISuperfluid.getSuperTokenFactory() - Load super token factory address.
• Load tokens if specified... see below.

Token Loading Sequence

await sf.load(name_or_address)

• A. If provided as address, then its symbol is loaded and go to step B.
• B. Order of attempts for the names:
• B.1 If nativeTokenSymbol (ETH/xDAI/MATIC) used, then ETHx/xDAIx/MATICx will be the super token key for loading.
• B.2 If underlying token symbol is used (tokens.SYMBOL exists), then TOKENx will be the super token key for loading.
• B.3 If not registered as an underlying token (tokens.SYMBOL does not exist), then it is used as super token key directly.

Listing Test

await sf.isSuperTokenListed(key_or_address)

If an address is used, test if superTokens.${protocol_release_version}.${super_token_symbol} matches the provided super token address.

"Canonical Super Token"

PROBLEM: A ERC20 token can have any number of Super Token Wrappers those have same name/symbol/features. It is a practical problem for smart contract programs to know which one to actually use as the "canonical super token".

CURRENT SOLUTION: it is part of the Super Token Factory feature, by using a specific token factory function, the first-created Super Token Wrapper of the same udnerlying ERC20 token is considered to be the "canonical". The caveat is that the existing super tokens need to be retroactively marked as canonical using the registry information in the resolver.

New Resolver

TODO.

• Same address for all networks? (Might be an assumption that can be false for new type of network)
• Emit logs, in order to be indexed.