Take https://github.com/superfluid-finance/protocol-monorepo/blob/dev/packages/ethereum-contracts/contracts/tokens/MaticBridgedNativeSuperToken.sol away from ethereum-contracts repo.

Previous work: superfluid-finance/protocol-monorepo#494

Upgrade project to use Hardhat

Background: currently none of our custom super token examples show that you can make custom super token logic upgradable. This is the ticket to address that.

Notes

Different techniques:

1. decouple from Superfluid managed super token logic (GoodDollar way).
2. custom routing table: bespoke solutions (chained, "artificial" diamond) vs. diamond pattern.
   a) see eip-1967

Important factors:

1. etherscan readability: Technique (1) EASY; Technique (2) POSSIBLE
2. tooling support: ??
3. auditability.

After supporting Toki with the creation of a custom Pure SuperToken, this are some observations of potential pitfalls / sources of confusion:

• SuperTokenBase is not a very descriptive name / the role of that contract isn't explained well enough. Users of it should understand it's a proxy and contains storage paddings. Also don't assume everybody is already familiar with proxy, link to a good explanation of the concept.
• The internal functions in SuperTokenBase may be more confusing than helpful. If kept, it should be well documented what this is and how it works. Explain that with the proxy constructions, this external calls are kind of like super.x() calls into base contracts in "normal" contracts.
• The token contracts should probaby be named Proxy
• In ethers.js there may be confusion between SuperTokenFactory (the contract) and SuperToken factory (the factory for instantiating SuperToken instances)
• Provide a recommendation for how to add a custom implementation. Fork the repo and implement alongside existing tokens? What else?

• Make compatible with current ethereum-contracts release
• Make sure new releases of ethereum-contracts validates examples to make sure we update examples as needed.
• Revamp of the project structure:
• multi-projects repo: e.g. hardhat-example/ hardhat full examples, and foundry-example/ minimum foundry example.
• migrate from truffle to hardhat for the main project.
• Make the pattern of defining ICustomSuperToken (See ISETHCustom as an example) explicit in all pure super token examples.
  • Some base functionalities are exposed through SuperToken self-functions, such as selfMint, selfBurn, selfTransfer, etc.
  • For the off-chain code, the CustomSuperTokenProxy address should be casted to the corresponding ICustomSuperToken interface to be useful.
• Adding an example of how to override existing SuperToken functions (e.g. GoodDollar overrides transfer)
• Adding an example where custom super token exempts from managed super token logic upgrade process:
  • This a necessary step before opt-in for an entire different deployment of custom super token logic.
  • Should this be even part of a new SuperToken factory option?
• Stretch goal: minimum CI.

Please start to reuse the utils/SuperfluidFrameworkDeployer.sol from the ethereum-contracts 1.2.1 release.
See test/foundry/FoundrySuperfluidTester.sol for its example usage.

I was able to easily deploy a supertoken using these scripts but unfortnuately verify the contracts is proving to be difficult. I'm creating this issue to report that and to ask if you know how to verify these contract @ngmachado. I think it stems from using web3tx. Without easy verification it makes working with the token on mumbai polygonscan difficult.

And remove scripts/utils/constants.js

closes #26

Vijay: seems like Etherscan have stopped supporting the automatic proxy verification, you might have to click "is this a proxy?" and letting it match the default one for super token wrappers for etherscan interactions for a while...

https://discord.com/channels/752490247643725875/752493319657095168/1089949208464867418

Could this be why I'm suddenly having an issue verifying supertokens on Goerli?

$ npx truffle run --network goerli verify BurnMintSuperToken@0xA862f128b3ffE9719948869cc1C7CBC21860Cd9a --custom-proxy BurnMintSuperToken

Verifying contracts on etherscan
   Verifying BurnMintSuperToken@0xA862f128b3ffE9719948869cc1C7CBC21860Cd9a
   Verifying custom proxy contract BurnMintSuperToken at 0xA862f128b3ffE9719948869cc1C7CBC21860Cd9a
   Verifying proxy implementation BurnMintSuperToken at 0xdcde53f3b5e275109ff105f4dcab6925fc62791a
   Invalid constructor arguments provided. Please verify that they are in ABI-encoded format
   Failed to verify 1 contract(s): BurnMintSuperToken@0xA862f128b3ffE9719948869cc1C7CBC21860Cd9a

Or is this something related to how constructor args might have been done on token deployment. I think I might have done something wrong on deployment.

We need to fix the tests.

Also from the logs, i see a lot of compiler downloading attempts.

See: https://github.com/superfluid-finance/protocol-monorepo/wiki/About-Super-Token-Classification

This repo has JS code without semicolons and tab indentation, enforced by a commit hook.
Should be changed to reflect the code style in other SF repos.

Also, we may want a more conventional setup with eslint instead of this somewhat opaque setup with husky in a commit hook (or at least document it).

[EXTERNAL] Super Token Wizard

Problem

• As a developer or someone who wants to try out Superfluid, I’d like to be able to deploy a Super Token easily without having to hunt for the right contracts and parameters or manually configuring all of them
• I’d like to be able to quickly get a customized Super Token contract for my needs
• Ideally I’d like to be able to export to remix for further customization and deployment
• I can switch networks in the interface
• I’d like to deploy a Super Token contract directly from the interface, initiating a transaction in my wallet
• The UI should show me the deployed address afterwards

Appetite

This project should take 4 weeks of development time to get to a functional MVP

Solution

• The solution may take the form of a utility like the OpenZeppelin contract wizard https://wizard.openzeppelin.com/
• An MVP would generate contract code based on a few select inputs:
  • Token name
  • Token symbol
  • Premint quantity
  • Premint destination (default: deployer address)
  • Ad-hoc mint function (Ownable)

https://whimsical.com/super-token-wizard-FxPFgUiRnQthXs6VHdXeaT

Acceptance Criteria

• The app is available in a web interface
• I can input a few parameters to customize the
  • Name
  • Token symbol
  • Premint amount
• I can enable or disable the following features
  • Mintable
  • Ownable (for the Mintable method)
• I can copy and paste the contract code into remix and deploy
• I can switch networks in the interface
• I can 1-click deploy and initiate a wallet transaction from the deploy button
• The UI should show me the deployed address afterwards

Bounty Amount

$1000 in USDC on Polygon

Rabbit holes

• In MVP, this feature does not need to include any other token configuration options aside from the above, however, these will be considered for follow-on bounties

Notes

• Documentation on how to construct the Pure Super Token contracts is located here https://docs.superfluid.finance/superfluid/developers/super-tokens/deploy-a-super-token/deploying-a-pure-super-token
• Some example Super Tokens are available at https://github.com/superfluid-finance/custom-supertokens