[SPIKE] connext bridgeable SuperToken about protocol-monorepo HOT 6 CLOSED

@d10r please post the "secession fork testing" related work here.

After that, the owner of token that wish to secede should create an issue in this repo to request such governance action.

Technical challenges:

• "flag changes"
• "nullifcation" process
• etc.

from protocol-monorepo.

fork test: https://github.com/superfluid-finance/custom-supertokens/blob/bridged-supertoken/test/foundry/BridgedSuperToken.t.sol#L80

Technical challenge with a seceding token:
There's no explicit role assigned to the upgrade privilege, the way it is in e.g. Ownable. Instead, the role is implicitly defined by the implementation contract through the logic of updateCode.
In case of the canonical SuperToken contract, the restriction is that only the host can trigger the update. The host contract can trigger this through updateSuperTokenLogic which can be called by gov only.
So through this indirections, SF gov has exclusive permission to update SuperTokens, but that's not something which can trivially be queried. The best way to check this may be to verify if the logic a SuperToken points to is the canonical one (as defined by SuperTokenFactory.getSuperTokenLogic()) - caveat being that one would have to keep track of all previous versions of canonical logics, or rely on the assumption that all tokens are always updated to the latest one.
In order to facilitate that, we could add a mapping(address => bool) canonicalSuperTokenLogicContracts which returns true for all contracts which ever were (or currently are) the canonical SuperToken implementation.
Alternatively we could rely on off-chain reconstruction, e.g. based on the event SuperTokenFactory.SuperTokenLogicCreated.

An alternative approach for distinguishing SuperTokens using the canonical logic could be to use UUPSProxiable.proxiableUUID - assuming only the canonical deployments return keccak256("org.superfluid-finance.contracts.SuperToken.implementation").
This assumption is however already invalidated by existing non-canonical deployments, e.g. by G$.

from protocol-monorepo.

In case of the canonical SuperToken contract, the restriction is that only the host can trigger the update. The host contract can trigger this through updateSuperTokenLogic which can be called by gov only.

Indeed.

But at the same time, ISuperfluid immutable internal _host; does not imply it has to be our host. A custom super token logic may simply set it to a different when during its construction. Would this work?

from protocol-monorepo.

Yeah, but that would create all kinds of additional implications, imo coming down to requiring a redundant deployment of the protocol. Much simpler to decouple the update privilege from the host in that custom logic.

from protocol-monorepo.

We can do a SuperToken revision around this rule.

from protocol-monorepo.

Added a deployment script.
Waiting for the FRACTION deployer to deploy (important contract params are hardcoded in the logic, so we can't deploy a generic version as is) and request an update.

We can exclude such SuperTokens with custom logic by modifying the upgrade script to compare SuperToken logic addresses against a list of all canonical implementations there existed, can be done by querying the protocol subgraph for

  superTokenLogicCreatedEvents {
    tokenLogic
  }

from protocol-monorepo.