keep-starknet-strange / unruggable.meme Goto Github PK
View Code? Open in Web Editor NEW☣️ A framework for building safer memecoins 💸
Home Page: https://unruggable.meme
License: MIT License
☣️ A framework for building safer memecoins 💸
Home Page: https://unruggable.meme
License: MIT License
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.
This issue adds a new protection for the users as it forces the devs to launch with unruggable.
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
Factory contract uses 1000
for limit_delay
value, without naming it.
Is it the desired behaviour to fix limit_delay
to 1000 seconds?
serialize_calldata
function.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.
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:
token_locks
that maps ContractAddresses to a List (internal IDs)token_locks_length
and token_locked_at
entrypointsremove_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
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.
launch_memecoin
function is called.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
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
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.
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.
Will there be an airdrop for users who have been active on the Starknet network?
Complete CSS update to support every screen sizes on every part on the FE
Test this feature
https://github.com/keep-starknet-strange/unruggable.meme/pull/83/files
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:
TokenLocker
contract with a min_lock_time
set to 6 months (15_721_200
seconds)UnruggableMemecoin
contract to get its class hashFactory
contract with:
(SupportedExchange, ContractAddress)
)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.
get_lp_details(token: ContractAddress)
;transfer_lp_ownership
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.
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.
The current header/nav is not responsive at all
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.
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.
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.
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.
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.
To mitigate risks associated with multicall attacks where limits can be bypassed through multiple smart contract calls in the same transaction.
get_tx_info
: Incorporate the use of get_tx_info
in the transaction validation logic to retrieve the transaction hash.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.
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.10%
limit.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.
launch_memecoin
FunctionWe 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.
launch_memecoin
to create a trading pair for Memecoin and a counterparty token (e.g., USDT, ETH) on the selected AMM platform.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.0xAA
.1000 MT
tokens and 1000 USDC
to address 0xAA
.launch_memecoin
function utilizes these internal balances (1000 MT
and 1000 USDC
) to add liquidity to the MT/USDC pair on the selected AMM.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
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.
display deployed tokens from zustand slice (created after #42) in /manage
each token card should be clickable and redirect to /manage/[tokenAddress]
Using the component will give us access to OZ's internal function and reduce the boilerplate code of the contract.
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.
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.
MAX_HOLDERS_BEFORE_LAUNCH
, set to 10
. This will be the maximum number of holders allowed before the memecoin is launched.false
at deployment and set to true
when the launch_memecoin
function is called.10
) is reached before the token is launched, disable transfers. Ensure that transfers are only re-enabled after the token launch.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.
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.
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.
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.
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.
announce date when unruggable will be on mainnet
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:
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:
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.
Once #112 is merged, we should renounce the ownership of the memecoin upon launching a memecoin.
This issue focuses on having an index.ts
page that presents the project so retail is not lost (atm we have nothing).
We need a Numerical input displaying the value with a bit of formatting like 42,000.00
add a .tool-versions file to have scarb automatically use Cairo 2.3.1 and Starknet-Foundry 0.12
Redesign the UnruggableMemecoin
_initializer
method.
owner
, initial_recipient
, name
and symbol
unused params.initial_holders
and initial_holders_amounts
len check from the constructor here.Description:
I'd like to add a favicon to the web app using the project's logo for improved branding and user experience.
Is there any sample contract memecoin that uses unruggable framework? can you provide a simple contract/ERC20 with this feature?
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.
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.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.
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.
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:
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.
As memecoins are all about attention, this achieves that from the onset.
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.
Allow the launch form to actually deploy a token. The contract address should be stored in local storage through zustand persisting slice.
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.
launch_memecoin
function later. Include a button to auto-fill with the current connected address.A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.