The Network Nervous System (NNS) wallet is the cornerstone of security and trust on the Internet Computer Protocol (ICP). To enhance its functionality and utility, I propose the addition of a “Lock Function” for manually added tokens in the NNS wallet. This feature would particularly benefit users who participate in pre-SNS sales and other early-stage token distributions, providing them with an added layer of security and trust.
Motivation
Pre-SNS sales and other early token distributions often come with vesting or lockup periods that ensure fair allocation and discourage early dumping. Currently, users have limited options for securely managing these locked assets, forcing them to rely on third-party wallets or less secure mechanisms. Introducing a lock function to the NNS wallet would:
Enhance Security: The NNS wallet is the most trusted wallet on ICP, making it the ideal platform for managing locked tokens.
Boost Trust in ICP Ecosystem: By providing a secure and user-friendly way to handle locked tokens, the NNS wallet strengthens its position as the go-to wallet for ICP users.
Streamline Pre-SNS Sales: A built-in locking mechanism simplifies token distribution processes for projects launching on the Internet Computer.
Proposed Features
Manual Token Locking:
Users & Projects can manually lock any token they have added to their NNS wallet.
Locked tokens will be inaccessible for transfers or other actions until the lock period expires.
Customizable Lock Periods:
Users & Projects can set the duration of the lock period (e.g., specific dates or fixed intervals).
Optionally, pre-SNS projects can define and enforce lock periods for distributed tokens.
Visibility and Transparency:
The wallet interface will display locked tokens separately, showing details such as the locked amount, lock expiration date, and token contract details.
Smart Contract Integration:
The lock function will leverage smart contracts to ensure immutability and transparency of lock terms.
Security and Recovery Measures:
Advanced cryptographic mechanisms to prevent tampering or accidental unlocking.
A failsafe recovery system in case of wallet compromise, adhering to lock terms.
Benefits
For Users:
Peace of mind knowing their tokens are secure and compliant with lockup conditions.
A seamless experience for managing vesting schedules and token distributions.
For Developers:
Simplified token distribution processes, with locking handled natively by the NNS wallet.
Increased trust in their projects by leveraging the ICP’s most secure wallet.
For the ICP Ecosystem:
Enhanced utility of the NNS wallet as a multifunctional asset management tool.
Greater adoption of the wallet and the protocol for DeFi, SNS, and token management use cases.
Conclusion
Adding a lock function for manually added tokens to the NNS wallet is a natural evolution of its functionality, aligning with the needs of both users and developers in the ICP ecosystem. It enhances security, trust, and convenience, solidifying the NNS wallet’s position as the safest and most trusted wallet on the Internet Computer.
By empowering users to manage locked tokens directly within the NNS wallet, we take a significant step toward a more secure and user-friendly decentralized future.
I would have preferred to see discussion on the forum before this proposal was submitted to the NNS. Deliberation often leads to better clarification and scoping of proposals before they are formally submitted as formal NNS proposals. I’ll hold off on voting for this one for a couple of days, but as of now I don’t feel like I have enough perspective on the feasibility or need for this feature request to cast a proper vote. If that clarification doesn’t come via conversation in this forum post by the time I vote, then I will need to vote to reject. It doesn’t mean it’s a bad idea, it just means I didn’t feel like I had enough time and information to properly evaluate the idea since it was submitted before any deliberation occurred.
Genius idea this will help impulsive people and those who are not skilled traders, 10 out of ten, I am a forward thinker but impulsive by nature.
great incentive for new comers to crypto.
Aren’t you describing neurons? You ‘lock’ a token into a neuron (staking it), and start dissolving it so that it becomes transferable again in the future (the point when it becomes transferable depends on the ‘locking’ period that you specified).
Thanks for investing time on this front and igniting the discussion. I will reply here, because this is the one associated with the proposal link (but have read your discussion post as well).
I personally feel this should have been discussed with more time. The important part is to understand the need, then we all can iterate a solution.
You unfortunately came up with an incomplete solution, that I am already afraid it won’t work / be optimal.
A few worries:
you mention locking manual tokens, which tokens if the swap didn’t exist yet? Can’t it always be locking ICP, since it’s the only token accepted on the SNS sale?
the goal of a startup to raise very early on, is to get liquidity to invest on product development, marketing, etc. But if ICP is locked and standing idle waiting for an SNS, what good is it for the core team?
what happens if the team never actually does an SNS Sale (will it be locked for years until expiry without any interest?)
what if canisters for the SNS sale are not meaningful/good? What if the config conditions are much worse than the investor expected?
And I (and others on community) could ask several more questions. Think this is complex, risky and would definitely need a good round of polishing before a formal proposal.
Underneath it all, think you are gravitating into multiple SNS sales of the same token. A need that has been sparkling around more and more, like with WaterNeuron.
All of what you want could actually be solved if multiple sales were possible. Pretty much an SNS would only need to be allowed to propose to NNS for a new swap (giving up of X tokens in Treasury and associating an Y config). This could be doable and a nice extension of the current model.
@bjoernek , @lara , have you ever thought deeper of this possibility, of an existing SNS to be allowed to propose another round of a swap sale?
Hey Lorimer, no i’m not talking about neurons, i’m talking about tokens that have already launched via ICPSwap, ICTO, Bobdotfun etc…
You can add the tokens via Ledger ID on the NNS wallet & I would love to have the feature, for example as a Startup, to already lock some of the Startup tokens onto the NNS.
A locking period for the user/investor isn’t that necessary, because it’s not stacking, only locking.
But locking could be also great for Users/Investors if they are to emotionally traders and really don’t want to touch their tokens for a certain amount of time.
Yes no worries, there should be a discussion first. Its just my first proposal, i’ve created
I’ve ment tokens that already have been launched via various exchanges, launchpads, etc…
Locking ICP for a startup on the NNS shouldn’t be a problem. My proposal is for the native tokens of the startup, to boost more trust and enhance a better security, rather then leave the token on a wallet or launchpad.
The core team don’t have to lock the raised ICP’s, like I’ve mentioned in the previous answer, its more for the native tokens.
I would set the range of the locking period from 6-24 months max. Until then a project should be ready to launch on the SNS.
Yes thats a good question.
The ICRC version should be deployed via the NNS SNS-W Canister.
All joking aside, and assuming the end goal is to bring ICRCs to be nns for an sns swap there is an audited framework that is open source which can be used to safely swap and transfer existing ICRCs with sns tokens and it’s been used by @icsneed and @Dogmi
Thus, if there was an existing project which happened to become an sns, the sns tokens would be sent to the dapp, and users would swap out there ICRCs.
Assuming the goal is just to vest tokens for a set period,
App.sneeddao.com has vesting with time delays as well as hook ups into major dexs on Icp where not only tokens but other positions can be locked in an SNS dao with high voting thresholds so teams can count on the security of the nns.
I prefer to not have more user features in the NNS and let other projects build out user tools like Sneed is doing.
Let Dfinity focus on the roadmap, any other ideas should be community build imo.
Hi all, we would like to explain DFINITY’s point of view and why the Foundation voted to reject this motion proposal even though we agree that this is an interesting feature.
We think the NNS dapp should first and foremost be a tool to interact with and participate in ICP’s built-in governance systems (NNS and SNS) and that it should therefore not be a priority to focus on building out the wallet functionalities.
There is already an existing solution (SneedLock) that addresses this issue developed by the Sneed DAO.
