keep-starknet-strange / unruggable.meme

☣️ A framework for building safer memecoins 💸

⚡ Unruggable Meme ⚡

☣️ A framework for building safer memecoins 💸

https://unruggable.meme

Tired of getting rugpulled? Introducing Unruggable Meme, a project designed with security and transparency at its core. Our innovative contracts and safeguards ensure a fair and secure experience for all users.

Become a meme lord and launch your own safe memecoin with Unruggable Meme!

And as a memecoin tradoor, you can use Unruggable Meme to check if a memecoin is safu before investing.

Become unruggable!

⚠️⚠️⚠️

While we have made every effort to ensure the security and integrity of the Unruggable Memecoin contracts, it's important to note that they have not yet undergone security audits. As with any smart contract, there remains a possibility of undiscovered vulnerabilities. Our approach is more secure than tokens launched without locked Liquidity Pool (LP) tokens or without safeguards on token supply allocation, but this does not imply that the contracts are bug-free or that investments in tokens launched using Unruggable Memecoin framework are risk-free. Investors and users should exercise due diligence and caution. This is not financial advice. Do your own research. And remember, don't invest more than you can afford to lose. Stay safe!

⚠️⚠️⚠️

Project structure

Contracts

The contracts are located in the contracts/ directory. It's a scarb project, so you can use the scarb CLI to build it.

It uses Starknet Foundry for tests.

See the contracts README for more information.

Frontend

See the frontend README for more information.

📖 License

This project is licensed under the MIT license. See LICENSE for more information.

Contributing

First off, thanks for taking the time to contribute! Contributions are what make the open-source community such an amazing place to learn, inspire, and create. Any contributions you make will benefit everybody else and are greatly appreciated.

Please read our contribution guidelines, and thank you for being involved!

Telegram -> https://t.me/UnruggableMeme

Contributors ✨

Thanks goes to these wonderful people (emoji key):

Abdel @ StarkWare 💻	Charles Lanier 💻	Francesco Ceccon 💻	Mathieu 💻	megumii 💻	Pjewels 💻	rmzlb 💻
odin free 💻	Darlington Nnam 💻	Fricoben 💻	akhercha 💻	retroboy 💻	Credence 💻	0xNac 💻
Maxime Servais 💻	Antoine 💻	Erim 💻	mananbordia 💻	Akashneelesh 💻	Mohiiit 💻	Bal7hazar 💻
Tristan 💻	Uğur Eren 💻

This project follows the all-contributors specification. Contributions of any kind welcome!

unruggable.meme's Issues

bug: `limit_delay` value is hardcoded in factory contract, while it shouldn't

Factory contract uses 1000 for limit_delay value, without naming it.
Is it the desired behaviour to fix limit_delay to 1000 seconds?

• If not, we should add one more parameter to serialize_calldata function.
• if yes, we should declare a limit_delay variable to make the code easier to understand.

@enitrat @abdelhamidbakhta i can do this refactoring, just tell me which option is the good one.

[frontend] feat: explanation page

Issue: Unruggable meme frontend needs an about section and tutorials

Description

The page should clearly describe what the intention behind unruggable.meme is. i.e. don't get rekt. It should have clear links to this repository and, when it comes to it, to verified contract links on the explorers.

Requirements

• Fun introductory paragraph describing what unruggable.meme is and its two main features: deploying and verifying unruggable contracts
• A clear description of why these coins are unruggable and the technical underpinnings which provide these guarantees. Some of this will seem to obvious to even bother explaining but put on a strong noob hat and go from there. (All contracts are from a verified class; class can / can't be updated, etc.)
• A clear description of what the risks still are (it is still a meme coin, go up go down)

Implementation Notes

The page should be opinionated, fun and info-dense. This is the best way to instil confidence in the legitimacy of this system for the users who come across this page.

bug: underflow issue on locker

The following code will throw a u64 underflow error when time is exceeded:

        fn get_remaining_time(self: @ContractState, lock_id: u128) -> u64 {
            let token_lock = self.locks.read(lock_id);
            let remaining_time = token_lock.unlock_time - get_block_timestamp();
            if remaining_time > 0 {
                return remaining_time;
            } else {
                return 0;
            }
        }

I guess we expect to have 0 if the time is exceeded.

[frontend] allow token import in `/manage`

Users should be able to import token addresses in the /manage page. The import should fail if the connected wallet is not the owner, otherwise the token address can be added to the zustand slice described in #42

[frontend] feat: build a "unruggable meme leaderboard"

Description

Create a leaderboard for tokens under the unruggable meme standard, to be added as a page on the FE. The objective is to bootstrap engagement on Starknet's nascent meme szn; with currently limited interface (3rd party charts eg dexscreener/tools/gecko, explorer, culture, etc), having a hub where people can explore & gauge these tokens will be helpful and ease onboarding.

Requirements

• Include ticker name along with token address; with misc info to be optionally updatable by deployer address: socials, description, logos, misc links, "buy now" link
• Initial statistic filters to include: liquidity, volume traded, holder count, tax
• Implement sorting for each statistic filter

Implementation Notes

• Use aggregate statistics (possibly refer to avnu) for liquidity and volume traded

[contracts] feat: Implement Merkle Airdrop Support for Initial Token Distribution

Issue: Implement Merkle Airdrop Support for Initial Token Distribution

Description

This issue aims to implement Merkle airdrop support for the initial distribution of tokens in the Unruggable Memecoin project. This feature will enable users to claim their allocated tokens by submitting a Merkle proof, verifying their inclusion in the eligibility Merkle tree. The Merkle root for the airdrop eligibility will be provided during the deployment of the token.

Requirements

1. Merkle Root Integration: Include a parameter for the Merkle root in the token deployment process, representing the root of the airdrop eligibility tree.
2. Claim Function: Develop a smart contract function that allows users to claim their tokens by submitting a valid Merkle proof.
3. Verification Process: Implement a verification mechanism in the contract to check the submitted Merkle proof against the stored Merkle root.
4. Efficient Claiming Process: Optimize the claiming process to be gas-efficient and user-friendly.

Implementation Notes

• Ensure the accuracy and security of the Merkle proof verification process.
• The Merkle root should be immutable post-deployment to maintain the integrity of the airdrop.
• Provide clear documentation and examples on how users can generate and submit their Merkle proofs.
• Thoroughly test the claim functionality to handle various cases, including invalid proofs or attempts to claim more than once.

[frontend] deployed tokens mgmt

display deployed tokens from zustand slice (created after #42) in /manage

each token card should be clickable and redirect to /manage/[tokenAddress]

bug: contracts wrongfully implement try/catch mechanism

inside router.cairo in jediswap test-utils

    fn _transfer_token(
        token: ContractAddress, sender: ContractAddress, recipient: ContractAddress, amount: u256
    ) {
        // let tokenDispatcher = IERC20Dispatcher { contract_address: token };
        // tokenDispatcher.transfer_from(sender, recipient, amount) // TODO dispatcher with error handling

        let mut calldata = Default::default();
        Serde::serialize(@sender, ref calldata);
        Serde::serialize(@recipient, ref calldata);
        Serde::serialize(@amount, ref calldata);

        let selector_for_transfer_from =
            1555377517929037318987687899825758707538299441176447799544473656894800517992;
        let selector_for_transferFrom =
            116061167288211781254449158074459916871457383008289084697957612485591092000;

        let mut result = call_contract_syscall(token, selector_for_transfer_from, calldata.span());
        if (result.is_err()) {
            result = call_contract_syscall(token, selector_for_transferFrom, calldata.span());
        }
        result.unwrap_syscall(); // Additional error handling
    }

this will never work, as it's not possible to actually catch an error - the transaction will always revert before.

As it's a test-utils, I guess it's fine and it doesn't have any impact, but I want to raise attention on the fact that this cannot be relied on

dev: lock Cairo version to 2.3.1

add a .tool-versions file to have scarb automatically use Cairo 2.3.1 and Starknet-Foundry 0.12

[contracts] feat: Implement Protection Against Multicall Buys in Memecoin Launch

Issue: Implement Protection Against Multicall Buys in Memecoin Launch

Description

This issue addresses the need for enhanced security measures in the Unruggable Memecoin project to protect against potential attack vectors that could arise from the multicall feature, specifically during the coin launch phase. The proposed solution involves utilizing get_tx_info to limit purchases not just per account address but also per transaction hash.

Objective

To mitigate risks associated with multicall attacks where limits can be bypassed through multiple smart contract calls in the same transaction.

Implementation

1. Utilizing get_tx_info: Incorporate the use of get_tx_info in the transaction validation logic to retrieve the transaction hash.
2. Limit Per Transaction Hash: Implement a mechanism that enforces buying limits per transaction hash, in addition to the existing per-account address limits.
3. Integration with Buying Logic: Ensure this security feature is seamlessly integrated with the current buying logic and does not impede legitimate transactions.

Considerations

• Efficiency: Ensure the solution is gas-efficient and does not significantly increase transaction costs.
• Compatibility: Verify compatibility with existing smart contract functionalities and ensure no conflicts arise.
• Testing: Rigorously test the implementation to validate its effectiveness in preventing multicall buy attacks and to ensure it does not interfere with normal buying processes.

Impact and Benefits

• Enhanced Security: Significantly reduces the risk of multicall buy attacks during the coin launch phase.
• Fairness: Ensures equitable buying opportunities for all participants by enforcing limits consistently.

feat: time-based disabling of multicall-prevention

In the contracts, we prevent multicall-buy to avoid bots taking a good part of the supply at launch.

However, this creates an overhead cost as we store inside a storage var commited to L1 the last tx_hash of the interaction from the sender of the transaction.

To prevent this, we can disable this security feature a certain amount of time after launch. I propose to keep it for the same time as for the buy limit delay, and disable it after.

design: improve multicall mechanism

The multicall mechanism currently protects against a transaction when 1 account buys multiple times and sends to the same recipient.
But it doesn't protect against one buyer sending to N recipients. Thus, it is quite ineffective.

Fair ICO to solve low initial liquidity

Crowfunding method for memecoins to solve the low initial liquidity problem. You don't launch the token directly on AMM, it is beforehand on a "campaign" where the deployer sets a price per token and token supply (%), this part is sold as an ICO. Before the campaign ends, the tokens and eth are locked. The campaign lasts for e.g. 1 day, after this delay if all the tokens were sold the eth is used to create the initial lp and the buyers from the ICO can claim their tokens after some delay (avoid instant dump). If not all the tokens were sold, users can claim back their eth.

test:transfer limit

Test this feature
https://github.com/keep-starknet-strange/unruggable.meme/pull/83/files

token sample

Is there any sample contract memecoin that uses unruggable framework? can you provide a simple contract/ERC20 with this feature?

Smart Contract Implementation Lead for MVP

#99

feat(locker): Track the liquidity locked by token address

The first MVP is supposed to be launched without a backend (i.e. no indexer).

However, the typical way to check whether a LP token has been locked is to search by its token address. If we do not index the TokenLocked events, we can't know if a token has been locked or not efficiently.

As such, we should implement a tracking mechanism - similar to the one that exists to track LP locked by user - but by tokens.

Steps:

• Add a storage variable token_locks that maps ContractAddresses to a List (internal IDs)
• Add token_locks_length and token_locked_at entrypoints
• refactor remove_user_lock into remove_lock_from_list(self: @ContractState, lock_id: u128, list: List<u128>

remove_lock_from_list will remove the id of a lock from the list of locks supplied as parameter. The implementation doesn't change, instead of doing let mut list = self.user_locks.read(owner) inside the function, we will do it before calling the function, and we will pass the correct list instance to remove_lock_from_list.

Of course, you will adapt the test accordingly

Front-End Implementation Lead

#99

[contracts] feat: Add Vesting Options for Initial Team Token Distribution

Issue: Feature Request - Add Vesting Options for Initial Team Token Distribution

Description

This feature request focuses on adding token vesting options for the initial team distribution in the Unruggable Memecoin project. The goal is to integrate a robust and transparent vesting mechanism for team members, ensuring a gradual and scheduled release of tokens. Consideration will be given to utilizing the StarkNet Tokei repository as an external dependency for this implementation.

Requirements

1. Vesting Mechanism Integration: Implement a vesting mechanism for the initial team token distribution. This should allow setting specific vesting schedules (e.g., linear vesting over a set period).
2. Utilization of StarkNet Tokei: Explore the feasibility and benefits of using the StarkNet Tokei repository as an external dependency for implementing the vesting feature.
3. Configurability: Ensure that the vesting terms (such as duration, cliff period, and vesting frequency) are configurable during the token distribution setup.
4. Transparency and Security: The vesting process must be transparent and secure, with clear documentation and visibility for all stakeholders.

Implementation Notes

• Thoroughly evaluate the StarkNet Tokei repository for suitability, security, and compatibility with our project requirements.
• Prioritize a user-friendly interface for setting up vesting schedules for team members.
• Implement comprehensive testing to ensure the reliability and accuracy of the vesting mechanism.
• Ensure the vesting feature adheres to the overall principles of fairness and trust inherent in the Unruggable Memecoin project.

[contract] feat: Ensure liquidity is locked in the constructor.

Issue: Ensure liquidity is locked in the constructor.

The goal of this issue is to find a way to make the deployer lock liquidity in the contract to make sure the devs will indeed create a liquidity pool in an AMM.

Objective

This issue adds a new protection for the users as it forces the devs to launch with unruggable.

[contracts] feat: Implement Locking of Liquidity Provider (LP) Tokens for 6 Months

Issue: Implement Locking of Liquidity Provider (LP) Tokens for 6 Months

Description

The objective of this issue is to implement a feature in the smart contract to lock the Liquidity Provider (LP) tokens for a period of six months. This locking mechanism is intended to enhance the trust and stability of the token by ensuring that liquidity is maintained in the market for a substantial period after launch.

Requirements

1. Locking Mechanism: Develop a smart contract function or module that locks the LP tokens for a period of six months from the date of the liquidity being added to the pool.
2. Time Tracking: Implement a reliable and accurate time-tracking system within the contract to track the 6-month lock period.
3. Unlocking Functionality: After the lock period has elapsed, ensure that there is a secure and efficient mechanism for the LP tokens to be unlocked and made available.
4. Transparency and Security: Ensure that the locking mechanism is transparent and secure, providing confidence to token holders and liquidity providers.

Implementation Notes

• Pay close attention to the accuracy and security of the time-lock mechanism.
• Ensure that the lock and unlock functionalities are resistant to common smart contract vulnerabilities.
• Consider the gas costs associated with these functionalities and optimize where possible.
• Thoroughly test the lock and unlock process, including edge cases around the timing of the lock period expiration.

feat: implement maximum holders before launch safeguard

Issue: Implement Maximum Holders Safeguard in Smart Contract

Description

This issue aims to implement a safeguard in the smart contract to limit the number of holders before the launch of the memecoin. This is crucial to prevent the contract from being launched with an excessively large number of holders, which could potentially lead to issues in distribution and management.

Requirements

1. Max Holders Constant: Define a constant, MAX_HOLDERS_BEFORE_LAUNCH, set to 10. This will be the maximum number of holders allowed before the memecoin is launched.
2. Tracking Launch Status: Implement a boolean variable in the contract's storage to track whether the memecoin has been launched. This variable should be initialized to false at deployment and set to true when the launch_memecoin function is called.
3. Holder Count Logic: Implement logic to track the number of holders. This tracking should only be active before the launch of the token. After the launch, stop tracking the number of holders to optimize for on-chain operation costs.
4. Transfer Restriction: If the maximum number of holders (10) is reached before the token is launched, disable transfers. Ensure that transfers are only re-enabled after the token launch.

Implementation Notes

• Carefully consider the gas costs associated with tracking the number of holders. Optimize where possible.
• Ensure that the logic to disable/enable transfers based on the number of holders and the launch status is secure and efficient.
• Include thorough tests to validate the behavior of the holder limit and the launch status tracking.

Additional Context

The implementation of this safeguard is a preventive measure to maintain the integrity of the token distribution process and to ensure a fair and manageable launch. Post-launch, the holder count tracking will be discontinued to reduce the cost and complexity of on-chain operations.

---

This GitHub issue outlines the task of implementing a safeguard in the Unruggable Memecoin smart contract to limit the number of holders before the launch and to manage the launch status efficiently.

[Frontend] Feat: Add Favicon Based on Logo

Description:
I'd like to add a favicon to the web app using the project's logo for improved branding and user experience.

[contract] feat: Implement Initial Token Distribution in Constructor

Issue: Implement Initial Token Distribution in Constructor

Description

This issue explores the possibility of handling the initial token distribution directly in the constructor of the Unruggable Memecoin contract. The proposal is to pass arrays of holders and their respective token amounts into the constructor, thereby conducting the distribution at the time of deployment. This approach could simplify several aspects of the contract's operation, including transfer restrictions and holder tracking prior to the launch.

Discussion Points

1. Distribution via Constructor: Assess the feasibility and advantages of performing the initial distribution through the contract constructor.
2. Simplification of Transfer Restrictions: Explore how this method simplifies the process of disabling transfers post-initial distribution and until the launch_memecoin function is called.
3. Reduction of On-Chain Tracking Needs: Evaluate the impact on the need for tracking initial holders on-chain.
4. Flexibility in Ownership and Recipient Roles: Consider how this approach maintains flexibility in defining different entities as owners and initial recipients.

Implementation Considerations

• Ensure the constructor can efficiently handle an array of holders and token amounts without exceeding gas limits.
• Develop robust error handling and validation for the input arrays to prevent any discrepancies in the distribution process.
• Thoroughly test the constructor's distribution logic to ensure accuracy and reliability.
• Maintain clarity and transparency in the contract's code and documentation regarding the distribution process.

Pros and Cons

• Pros:
  • Simplifies contract logic by consolidating distribution into deployment.
  • Reduces the need for complex on-chain tracking mechanisms.
  • Maintains flexibility in roles and responsibilities within the contract.
• Cons:
  • Potentially higher deployment gas costs due to the inclusion of distribution logic in the constructor.
  • Requires careful input validation to ensure accurate and fair distribution.

[frontend] feat: build launch form

Issue: Develop Launch Form for Memecoin Deployment

Description

Create a user-friendly launch form interface for the deployment of the memecoin. This form will collect essential information required for deploying the token and setting up initial parameters. The form will culminate in a multi-call action that includes deploying the contract and executing a list of initial token transfers.

Requirements

Form Fields

1. Token Name: A field for the user to input the name of the token.
2. Token Symbol: A field for the user to input the symbol of the token.
3. Initial Recipient Address: A field for the address that will receive the minting supply at deployment. Include a button to auto-fill with the current connected address.
4. Owner Address: A field for the address that will have permissions to call the launch_memecoin function later. Include a button to auto-fill with the current connected address.
5. Initial Holder Distribution: A section for the user to add multiple addresses and specify the number of tokens each will receive. This should adhere to the maximum number of holders allowed before launch.

Functionality

• Implement validation to ensure all inputs are correct and adhere to constraints (e.g., format of addresses, token name and symbol requirements, limits on initial holder distribution).
• The deploy action should bundle:
  • The contract deployment.
  • The list of transfers for initial distribution, based on the input from the initial holder distribution section.

Implementation Notes

• Focus on creating a clear and intuitive user interface.
• Ensure robust error handling and user feedback for form validation.
• Optimize for a smooth and efficient multi-call transaction process.
• Test the form thoroughly, especially the interaction with blockchain transactions.

feat: create pair and add liquidity on AMM in `launch_memecoin` function

Issue: Implement Pair Creation and Liquidity Addition in launch_memecoin Function

Description

We need to enhance the launch_memecoin function to include the creation of a trading pair and the addition of liquidity to an Automated Market Maker (AMM) platform. This process involves using the Memecoin contract's internal balances (both the memecoin itself and a counterparty token like ETH or USDT) to establish the initial liquidity in the trading pool.

Requirements

1. Pair Creation: Implement functionality within launch_memecoin to create a trading pair for Memecoin and a counterparty token (e.g., USDT, ETH) on the selected AMM platform.
2. Liquidity Addition: Modify launch_memecoin to use the internal balances of Memecoin (MT) and the counterparty token, which are sent to the Memecoin contract address, to add liquidity to the newly created trading pair.

Example Workflow

• Memecoin (MT) is deployed at address 0xAA.
• The owner sends 1000 MT tokens and 1000 USDC to address 0xAA.
• The launch_memecoin function utilizes these internal balances (1000 MT and 1000 USDC) to add liquidity to the MT/USDC pair on the selected AMM.

Implementation Notes

• Ensure that the function checks for sufficient balances of both tokens before attempting to add liquidity.
• Consider gas optimization and security practices while implementing the liquidity addition process.
• Implement error handling for scenarios where the pair creation or liquidity addition fails.

[frontend] token deployment

Allow the launch form to actually deploy a token. The contract address should be stored in local storage through zustand persisting slice.

feat: implement maximum team allocation percentage before launch

Issue: Implement Maximum Team Allocation Percentage in Smart Contract

Description

The goal of this issue is to establish a cap on the percentage of the total token supply that can be allocated to the team. This measure is intended to prevent excessive control over the token supply by the team, promoting a more equitable and decentralized token distribution.

Requirements

1. Maximum Team Allocation Constant: Define a constant, MAX_SUPPLY_PERCENTAGE_TEAM_ALLOCATION, and set it to 10%. This will represent the maximum percentage of the total token supply that can be allocated to the team.
2. Implementation in Token Distribution: Ensure that this constant is enforced during the token distribution process. If any allocation attempt exceeds this limit, the transaction should fail with an appropriate error message.
3. Documentation and Comments: Clearly document this constant and its usage in the codebase, explaining its purpose and the rationale behind the 10% limit.

Implementation Notes

• The implementation should be integrated seamlessly with the existing token distribution logic.
• Prioritize security and simplicity in the code to prevent any loopholes or unintended behaviors.
• Include unit tests to validate that the team allocation does not exceed the defined maximum percentage and to ensure that token distribution adheres to this constraint under various scenarios.

Additional Context

Setting a cap on team allocation is a vital aspect of ensuring a fair and balanced ecosystem for the memecoin. It addresses potential concerns about centralization and offers reassurance to the community and investors about the equitable distribution of tokens.

feat: renounce ownership in `launch_memecoin`

Once #112 is merged, we should renounce the ownership of the memecoin upon launching a memecoin.

announce date when unruggable will be on mainnet

announce date when unruggable will be on mainnet

What about token % on launch?

I saw in chat this

is this true ?
This guy saying as if token launch with unrug they must put 90% of tokens into liquidity

[frontend] responsive header/nav

The current header/nav is not responsive at all

feat: disable tx_hash tracker after a certain delay

To prevent multicall buys to the same recipient, we track the tx_hash and prevent to transfer twice to the same recipient in the same tx.

However, this increases the costs of L1 commitment, for very little use past the initial launch.
Therefore, this feature should be disabled once the transfer_limit_delay has expired.

[contract] feat: Disable buy limit check after specific time passes

Issue: feat: Disable buy limit check after specific time passes

The goal is to set a specific timestamp value in constructor on memecoin. Then use this timestamp to check that is there still buy limit or not.

[frontend] responsiveness everywhere !

Complete CSS update to support every screen sizes on every part on the FE

feat: implement maximum buy percentage at launch

Issue: Implement Maximum Buy Percentage at Launch in Smart Contract

Description

This issue focuses on introducing a limit on the maximum percentage of the total memecoin supply that can be bought in a single transaction at the time of launch. This limitation is crucial to prevent large-scale buyouts and ensure a more equitable distribution of tokens during the initial trading phase.

Requirements

1. Maximum Buy Percentage Constant: Define a constant, MAX_PERCENTAGE_BUY_LAUNCH, with a value set to 2%. This constant will determine the maximum percentage of the total token supply that can be purchased in a single transaction during the launch phase.
2. Enforcement in Transaction Logic: Integrate this constant into the transaction logic so that any attempt to buy more than this percentage of the total supply in one transaction is automatically rejected.
3. Clear Error Handling: Implement clear error handling for transactions that exceed this limit, providing an informative message to the user about the breach of the maximum buy percentage.

Implementation Notes

• Ensure that the implementation is efficient and does not add unnecessary gas costs to transactions.
• The logic should be robust and secure, without loopholes that could be exploited to circumvent the buy limit.
• Extensively test this feature to guarantee that it functions correctly under various scenarios, including edge cases.

Additional Context

The implementation of a maximum buy percentage at launch is a strategic measure to promote fairness and prevent market manipulation. It is especially important in the early stages of trading to maintain a healthy and balanced market environment.

[CI] use .tool-versions versions

refactor: use ERC20 OZ component

Using the component will give us access to OZ's internal function and reduce the boilerplate code of the contract.

feat: staking

Staking (or Stacking or Farming, I think Staking is the most miss used term for this) consists in providing the ability to users to lock their tokens into a pool/vault and be rewarded with the same token along a defined period of time.
It helps to reduce the circulating supply and then should artificially increase the price of the token.

The bigger and longer the user stakes, the better the reward they can claim.

Here is what I have in mind, there are 2 scenarios with different UX:

Option A:

As a owner, you want to:

• Deploy a pool with an amount of token amount and a linear distribution between start_time and end_time that cannot be revoked. Also you want to manage the cooldown period the users can withdraw their deposit from the pool.

As a degen, you want to:

• Deposit a quantity of token, receive a non-fungible token corresponding to your share at the timestamp you get in
• Claim your claimable thanks to: your deposit timestamp, claim timestamp and your share (all associated to the token_id), it burns the NFT
• Compound your NFT(s?) which will claim and deposit again (with the new timestamp and a reset on the cooldown)
• Withdraw your position after the cooldown period
• Trade your positions on marketplaces

Option B:

Same but with a fungible $sToken (EIP4626-style), not sure how to handle the locked time reward except if we have a deposit period and another withdraw period so the total locked time period is the same for everyone and rewards can be distributed exclusively based on the user shares.

I personally prefer option A since there is no period in which a user cannot deposit and their is no limited pool size, however the user canno degen++ on its position because it is an NFT.

Add Support for Fractionalized NFTs

As Unruggable provides trusted templates for launching crypto tokens with embedded protections against common exploits, we should extend its capabilities to enable fractionalized NFT offerings tied to the platform.

This would allow artists, creators, collectors, or teams to tokenize ownership stakes in rare NFTs using Unruggable to deploy ERC20 tokens that represent fractional claims. Key functionality would include:

Flexible division of NFTs into tradeable fractions decided by the owner
Automated deployment of ERC20 contracts representing fractional ownership rights
Embedding legal rights directly into smart contracts like transfer approval controls
Ongoing royalties channeled to original owner on trading activity
Inheriting trust assurances of Unruggable like liquidity locking, transfer limits to deter insider dumps, etc.
By expanding Unruggable beyond memecoins into collateralized fractional NFTs, we can greatly broaden relevance to digital artists, gaming assets, virtual worlds, and other creative ecosystems wanting more liquid markets without sacrificing provable scarcity and provenance traceability of crypto-native artifacts.

It further cements Unruggable's role as the go-to platform for launching credible crypto tokens across multiple emerging use cases.

[frontend] feat: Develop Token Screening Page for Analyzing Compliance with Unruggable Memecoin Standards

Issue: Develop Token Screening Page for Analyzing Compliance with Unruggable Memecoin Standards

Description

The aim of this issue is to create a 'Screen Page' feature on our platform. This page will allow users to input a token's address and analyze whether the token complies with the Unruggable Memecoin standards. The analysis will include checks for liquidity lock duration and other essential sanity checks.

Requirements

User Interface

1. Input Field: A simple form where users can enter the address of a token.
2. Submit Button: To initiate the screening process after entering the token address.

Functionality

1. Standard Compliance Check: Determine if the token adheres to the Unruggable Memecoin standards.
2. Liquidity Lock Duration: Display the duration for which the token's liquidity is locked.
3. Sanity Checks: Conduct and present various sanity checks that include:
   • Checking for the maximum number of holders.
   • Verifying maximum transaction amounts.
   • Ensuring there are no hidden mint functions.
   • Confirming the owner's permissions and limitations.

Display of Information

• Clearly present the results of the analysis, indicating compliance or non-compliance with each standard and check.
• Provide a summary or a detailed view of the analysis for user convenience.

Implementation Notes

• Ensure the interface is user-friendly and intuitive.
• The screening process should be efficient and accurate, minimizing the load time for users.
• Prioritize security in the handling of token addresses and in the querying process.
• Implement comprehensive error handling for invalid addresses or tokens that cannot be screened.

feat: add locker functionalities to the EkuboLauncher contract

When the position is created, it is minted to the caller of the EkuboPositions contract, which is our own EkuboLauncher contract.
The liquidity will thus be locked inside this contract, and we need to add locker functionalities to this contract.

• Add entrypoints allowing us to query the LP associated with a token
• Display details about this LP position (owner, current amount of token locked, fees gained). get_lp_details(token: ContractAddress);
• Enable the withdrawing of Counteryparty token fees for this token.
  • We dont want the LP owner to be able to withdraw any base tokens, only counterparty fees.
  • As the LP owner didn't deposit any counterparty tokens, he shouldn't be able to get ownership of his LP position ever
  • The only thing he can do is collect fees in the base token.
  • Only the LP owner can withdraw fees
• Enable the LP owner to transfer the LP to another owner transfer_lp_ownership
• Track the LPs per owner / per token LP

[frontend] token mgmt page

Create the token mgmt page at /manage/[tokenAddress]

if the connected wallet is the owner of the contract, it should display a form, otherwise, we can redirect to /manage

the owner form allows to distribute liquidity (like in the launch page), you can see the safety score of the token based on the amount distributed (the more in the pool, the safer). And you can launch the token on the pool of your choice

Rewarding/ allocating a defined % of unruggable memecoin to addresses that meet specific criteria

Bootstrap your meme community by rewarding ecosystem participants with a defined % of the overall unruggable memecoin allocation.

This idea lets you onboard addresses and bring attention to your unruggable memecoin. At their core, memecoins are about attention. Without attention, no one will trade, or be interested in your unruggable memecoin, as there's no intrinsic value.

What criteria do we use to define allocation?

When creating an unruggable memecoin, a % of the unruggable memecoin can be allocated on historical behaviours, such as: made a specific number of transactions, account value, interacting with specific dapps, account age, transaction volume, or owning a specific NFT.

These seem the most obvious and can be adjusted based on who to target. Not all these criteria have to be set for the unruggable memecoin. It can be as simple as allocating 50% of the supply to addresses that have more than $100 in their address at the time of the unruggable memecoins creation, and every address that meets the criteria receives the same amount of unruggable memecoin.

Other examples include:

• Rewarding a % of the unruggable memecoin to addresses that hold a specific NFT. In this example, the maximum number of eligible addresses is known, so the amount that can be airdropped/ claimed by eligible addresses is known
• Rewarding DeFi power users through account age, transaction volume, dapps used and min wallet balance. In this example, the rewarding/allocation is more targeted to appeal to specific addresses. The amount being rewarding/ allocating can be variable.

What about the claiming process?

The method behind distribution can either be via a direct airdrop which will require gas for the unruggable memecoin creator(s) to distribute tokens, or via a claiming process, akin to typical airdrops, where addresses that meet the criteria can claim their allocation by a specific date. TBD.

Unclaimed tokens can then either be burnt or added to bolster liquidity.

The benefits of rewarding/ allocating a defined % of unruggable memecoin to addresses that meet specific criteria

As memecoins are all about attention, this achieves that from the onset.

1. Interested addresses will claim the airdrop
2. Addresses will either: hold, sell, trade or LP airdrop
3. More activity results in higher volume
4. The more volume means more fees for LPs
5. Attractive fees bring deeper liquidity
6. Deeper liquidity results in a better trading experience and price action
7. The flywheel repeats

This is not a new idea. BONK airdropped 50% of the total supply to members of the Solana ecosystem based on defined criteria and has since become the defacto memecoin of the Solana community.

[frontend] Numerical input

We need a Numerical input displaying the value with a bit of formatting like 42,000.00

feat: deployment scripts of the unruggable contracts

Create deployment scripts using the method of your choice - either StarknetJS or Starknet-Foundry (I am not sure SNFoundry is ready for this ATM, but this can be a good exploration).

These scripts will:

• Deploy the TokenLocker contract with a min_lock_time set to 6 months (15_721_200 seconds)
• Declare the UnruggableMemecoin contract to get its class hash
• Deploy the Factory contract with:
  • the class hash of the unruggable memecoin
  • the list of supported exchanges (type (SupportedExchange, ContractAddress))

feat: enable transfer of EkuboLP ownership

In the EkuboLauncher contract, which handles the launch of a token on ekubo and holds the EkuboLP position, the owner of an LP position can only withdraw the accrued fees of the counterparty token.

In this feature, you will add a mechanism that enables the transfer of the ownership of this position.

Available as soon as the #124 pr is merged

Question

Will there be an airdrop for users who have been active on the Starknet network?

[contracts] Initial tokens distribution redesign

Redesign the UnruggableMemecoin _initializer method.

• Get rid of owner, initial_recipient, name and symbol unused params.
• Move initial_holders and initial_holders_amounts len check from the constructor here.
• Distribute tokens to initial holders, and mint the remaining available supply to the contract

[frontend] feat: make a cool home page

Issue: Make a cool home page for retail understanding

Description

This issue focuses on having an index.ts page that presents the project so retail is not lost (atm we have nothing).