Technical Specification for MVP Smart Contracts

[AbdelStark]

Unruggable Meme - Technical Specification for MVP Smart Contracts

Introduction

Unruggable Meme is a project designed to enhance the security and transparency of memecoins. This document outlines the technical specifications for the Minimum Viable Product (MVP) of Unruggable Meme smart contracts.

MVP Features

1. Maximum Holders Before Launch Safeguard

• Objective: Limit the number of holders before the official launch to prevent premature distribution.

2. Maximum Team Allocation Percentage Before Launch

• Objective: Restrict the percentage of tokens allocated to the team before launch. limit.

3. Locking of Liquidity Provider (LP) Tokens for 6 Months

• Objective: Lock LP tokens for a fixed period to stabilize liquidity and prevent rug pulls.
• Implementation:
  • A Locker contract to handle the locking mechanism.
  • Functions for depositing LP tokens and timestamp tracking.
  • A release function to unlock tokens after the 6-month period, with validation to ensure release only occurs post-lock period.

4. Implement Initial Token Distribution in Constructor

• Objective: Define initial token distribution upon contract deployment.
• Implementation:
  • Define initial token allocations (for team, marketing, etc.) in the contract constructor.
  • Distribute tokens to predefined wallets during contract deployment.

5. Ensure Liquidity is Locked in the Constructor

• Objective: Lock a portion of liquidity immediately upon contract creation.
• Implementation:
  • Integrate liquidity locking logic in the constructor.
  • Automatically transfer a predefined liquidity amount to the Locker contract.

6. Disable Buy Limit Check After Specific Time Passes

• Objective: Lift buy limit after a defined period to allow larger transactions.
• Implementation:
  • A variable buyLimitEndTime storing the timestamp when the buy limit ends.
  • Modify buy functions to check against buyLimitEndTime before applying limits.

7. Time-Based Disabling of Multicall-Prevention

• Objective: Disable multicall prevention mechanisms after a certain period.
• Implementation:
  • Implement a timestamp-based check in the multicall prevention logic.
  • After a specific time, indicated by a predefined variable, disable the multicall prevention measures.

8. Factory to Deploy Unruggable Meme Tokens

• Objective: Provide a standardized method to deploy Unruggable Meme tokens.
• Implementation:
  • A UnruggableMemeTokenFactory contract to handle token deployments.
  • Functions to set parameters for new tokens and deploy them.
  • Event emission for each token deployment for easy tracking.

9. Proper Testing for All Features

• Objective: Ensure all features work as intended and are secure.

• Implementation:

  • Develop a comprehensive suite of automated tests (using Starknet Foundry and / or plain Cairo tests).
  • Test cases to cover all functionalities, edge cases, and potential security vulnerabilities.
  • Continuous integration setup to run tests automatically.

  Additional notes

Supported AMMs

For the MVP we aim to support JediSwap AMM only. The addresses of the JediSwapFactory and the JediSwapRouter will be known by the Unruggable Meme Factory contract. The Unruggable Meme Factory will have getter functions accessible for the Unruggable Meme tokens launched, in order to retrieve those parameters.

[0xEniotna]

Let me list what we have/don't have yet:
We have:

• 1. Maximum Holders Before Launch Safeguard
• 2.Maximum Team Allocation Percentage Before Launch
• 4. Implement Initial Token Distribution in Constructor
• 8. Factory to Deploy Unruggable Meme Tokens
• 6. Disable Buy Limit Check After Specific Time Passes
• 5. Ensure Liquidity is Locked in the Constructor

Ongoing:

• 3. Locking of Liquidity Provider (LP) Tokens for 6 Months
• 7. Time-Based Disabling of Multicall-Prevention
• 9. Proper Testing for All Features

[enitrat]

Update on requested MVP Features

1. Maximum Holders Before Launch Safeguard

• check_and_allocate_team_supply ensures that initial_holders.len() <= MAX_HOLDERS_BEFORE_LAUNCH, which is a CONSTANT set to 10 in the SC.

2. Maximum Team Allocation Percentage Before Launch

• check_and_allocate_team_supply ensures that the max team allocation is <= 10 % initial_supply, which is a CONSTANT set to 10% in the SC.

3. Locking of Liquidity Provider (LP) Tokens for 6 Months

• Two cases here:
  • The token is launched on Jediswap, in which case the LP tokens are locked by a lock manager contract for a minimal duration that is SET IN THE LOCKER CONSTRUCTOR. Since the lock manager deploys a contract for each lock, the interest fees of the LP position are accrued.
  • The token is launched on Ekubo, in which case the LP position NFT is never sent back to the user. Indeed, if launched on ekubo, there is no need to supply a counterparty token. The LP position is kept inside the EkuboLauncher contract, which has an entrypoint allowing the owner of the LP to withdraw the fees earned in the counterparty token only

4. Implement Initial Token Distribution in Constructor

• Implemented in check_and_allocate_team_supply.

5. Ensure Liquidity is Locked in the Constructor

• The liquidity is locked __in the launch_memecoin_on_* function in the Factory contract, following the process explained in 3.

6. Disable Buy Limit Check After Specific Time Passes

• All transfer restrictions are lifted after the transfer restriction time, which is set during deployment

7. Time-Based Disabling of Multicall-Prevention

• see 6. The design proposed does not seem efficient to me and should be discussed here and in design: improve multicall mechanism #126

8. Factory to Deploy Unruggable Meme Tokens

• Done

9. Proper Testing for All Features

• Should be good overall

Extra features

Ekubo integration

While the requested features above were a good start, I decided to go the extra-mile with this first version and integrate Ekubo to the Unruggable framework. I took this decision because the opportunities that Ekubo gives us regarding launching tokens are quite appealing:

• A token can be launched without requiring the creator to put counterparty token in the initial liquidity. This is a very inefficient UniV2 legacy, in which the initial price of the token was determined by the amount of counterparty tokens deposited in the pool. With Ekubo, we can:
  • Decide at which price the token should start trading - therefore deciding of the initial MarketCap the token should have.
  • Design anti-bot mechanisms that limits the initial liquidity provided at launch, with a gradual release of liquidity in the pool during the first X minutes / hours. This would limit the amount of tokens that bots can buy for example in the first block.
  • Imagine new launching concepts by leveraging ekubo extensions

Because Ekubo don't work with ERC20 Lp tokens but with NFTs representing LP positions, and there is no need to deposit an initial counterparty token, the user will never be able to withdraw the initial LP position. However, we provide entrypoints in the EkuboLauncher contract, allowing a user to withdraw the fees in counterparty token associated to a position. Whether we should allow the withdrawal of fees in launched token should be debated.

Advanced locker

While locking LP tokens is fairly simple to implement, basic lockers don't account for accrual of LP fees associated to a position, resulting in a "burn" of these fees as they're never recoverable. By designing the locking mechanism to be based on a Locker Manager contract, that for each locks deploys another contract which holds the LP position, this enables the accrual of LP fees in the position, that the user will be able to withdraw once the position is unlocked.
The ownership of the lock can be transferred, the locktime can be extended, and if required, the amount of tokens locked can also be increased.