Clear Macro by Superfluid
Superfluid's Clear Macro allows users to read, sign, and forward clear intentions of the dapp, in human-readable texts, powered by Superfluid.
Details
Scope
On what chains are the smart contracts going to be deployed?
This smart-contract suite is intended to be deployed on the exhaustive list of networks below :
- Ethereum
- Optimism
- BNB Smart Chain
- Gnosis
- Polygon
- Base
- Arbitrum One
- Celo
- Avalanche
- Scroll
If you are integrating tokens, are you allowing only whitelisted tokens to work with the codebase or any complying with the standard? Are they assumed to have certain properties, e.g. be non-reentrant? Are there any types of weird tokens you want to integrate?
No. However, to be more specific:
The project WILL ONLY integrate a Super Token that Superfluid Core Team will deploy.
The token will be deployed as a plain ERC20 on Ethereum Mainnet, will then be wrapped as SuperToken and bridged to other chains / L2 (as Super Token).
The Super Token that will be used with these contracts is similar to the Super Token at the following address :
https://basescan.org/token/0x2112b92A4f6496B7b2f10850857FfA270464d054For more info regarding SuperTokens, see https://docs.superfluid.finance/docs/category/super-tokens
Are there any limitations on values set by admins (or other roles) in the codebase, including restrictions on array lengths?
- Trusted forwarders, compatible with ERC-2771, whitelisted by the Superfluid DAO/Security council.
- See https://explorer.superfluid.org/base-mainnet/protocol "Enabled forwarders"
- These trusted forwarder contracts
Are there any limitations on values set by admins (or other roles) in protocols you integrate with, including restrictions on array lengths?
There are, but they may not be relevant for the audit:
- IDAv1 has a limitation of up to 256 subscriptions to indexes.
- GDAv1, similar to IDAv1, has a limitation of up to 256 connected pools.
Is the codebase expected to comply with any specific EIPs?
- ERC-2771: Secure Protocol for Native Meta Transactions
The strict compliance is intended, so issues violating EIP-2771 "MUST" statements may be considered valid issue even if the impact is low/info, unless they conflict with common sense.
Are there any off-chain mechanisms involved in the protocol (e.g., keeper bots, arbitrage bots, etc.)? We assume these mechanisms will not misbehave, delay, or go offline unless otherwise specified.
The user signatures, from ERC-712, may be relayed by the off-chain service, aka. clear macro providers.
What properties/invariants do you want to hold even if breaking them has a low/unknown impact?
- Only ERC-712 signer's super tokens can be moved by the "Clear Macro" contract.
Please discuss any design choices you made.
- Payload
- Standard ClearMacro V1 Payload: https://github.com/superfluid-org/protocol-monorepo/pull/2148#issuecomment-4136318750
- ClearMacro V1 with Permit2 (using Permit2's permitWitnessTransferFrom): https://github.com/superfluid-org/protocol-monorepo/pull/2148#issuecomment-4136588574
Please provide links to previous audits (if any) and all the known issues or acceptable risks.
This is new code. There is no previous audit.
Please list any relevant protocol resources.
Additional audit information.
Frozen code's PR: https://github.com/superfluid-org/protocol-monorepo/pull/2148
Total Rewards
Contest Pool
Lead Senior Watson
Judging Pool
Lead Judge
7,000 USDC
4,500 USDC
800 USDC
1,200 USDC
Status
Scope
Start Time
End Time
Judging Rules
