Potential idGeek SNS launch

[GeekFactory]

Hello ICP community,

We’re seeking your input on a major decision:
Should idGeek move towards decentralisation via SNS?

idGeek, an Internet Identity and SNS neuron marketplace, has been operating for about 18 months, allowing users to transfer and trade their Internet Identities and associated assets. The project has gained significant traction: >1300 transactions, >1000 active listings, 220,000 $ICP value of sold assets. Therefore we think it’s time to consider its next phase and become an SNS DAO.

Why SNS?

1. Blackholing is Not an Option
   Making idGeek immutable (blackholed) isn’t feasible, as we rely on external systems like NNS and SNS. Any changes in these systems could impact our functionality, risking asset loss or service disruption. A DAO structure offers necessary adaptability, with community-driven governance to navigate changes.

2. Community-Led Governance
   idGeek’s service - enabling transfer of locked assets - could have far-reaching impacts on the ICP ecosystem. We believe that such decisions should be guided by the broader community rather than only a small core team.

3. Expanding Contributor Base
   Through a DAO, we can foster greater community participation and grow beyond our current scope. Developers, enthusiasts, and supporters can directly contribute to the project.

4. Funding Future Growth
   Transitioning to an SNS DAO would not only decentralise idGeek but also raise funds for further development. This would support the addition of new features, project expansion, and ensure long-term sustainability.

5. Transparency and Trust
   Becoming an SNS DAO would enhance transparency and create a more trustless system. With open-source code and community-driven governance, all decisions and processes would be visible to the public, ensuring that idGeek operates in a fair, secure and accountable way.

Potential Risks
We acknowledge the risk of a 51% attack if the DAO’s assets exceed the value of governance tokens. It is important to note that the assets under DAO control also include user assets, such as Internet Identities listed for sale or currently held in escrow. This risk isn’t unique to idGeek and also applies to some of the ICP ecosystem projects and the ICP itself. We believe this can be mitigated through a good DAO design and maybe some extra security layers.

Community Polls
Your feedback is crucial. Please participate in the polls and share your thoughts in the comments below. If we receive community support, we will initiate a security audit, open-source the project, and start the preparation for the SNS launch. Let’s shape the future of idGeek together.

1. Do you believe idGeek is beneficial to the ICP ecosystem?

• Yes
• No

2. Do you have any major concerns about idGeek’s decentralisation via SNS? (If yes, please share your comments below)

• Yes
• No

3. If we conduct a security audit, open-source the code, and publish all the necessary details, would you VOTE for idGeek’s SNS launch?

• Yes
• No

---

Thank you for your support!
GeekFactory Team

[yk6]

Hi Geek team,

Do you have any details about SNS?

[senior.joinu]

One of the top teams in the ecosystem.
I would definitely support you, if everything is good with the audit (well known auditor with traceable reputation) and the SNS-config is reasonable.

All the best!

[salman]

let’s do this. solves one of my biggest concern with the platform

[yk6]

Geek is the best application in ic system, hoping the SNS will be success

[Forreal]

I voted yes on everything but the only concern I have is timing. Right now may not be a great time to launch an SNS. This is definitely true for utility heavy based project that don’t have a clear way of showing how investors will make a return on investment.

[Quyho3]

we need more infomation, about tokenomic …

[tcpim]

I like idgeek and will use it when need it. The key to attract people, including me, to participate SNS is a clear path towards token price appreciation. It’s obvious IdGeek is a huge contributor to IC ecosystem, and super valuable to its users. But for SNS participants who are investors, we need to know more about how we can make money from it. That’s the most important aspect. Thanks for all the work team! Will always support project like this

[GeekFactory]

Thanks to everyone who participated in the polls and discussion so far. If you haven’t yet, please jump in - your input is still welcome.

Stay tuned for updates in the coming posts. We’ll be unveiling more info about tokenomics, airdrop mechanics, and other details regarding the potential SNS launch.

[Lorimer]

Thanks @GeekFactory for your open and candid approach to exploring the potential for an SNS launch.

SNSs imply a level of approval by the NNS community, yet the NNS is clearly in favour of preventing NNS neuron transfers. II transfers are also not well supported (hence the niche for IDGeek). II transfers have also been frowned upon (for the same reason that NNS neurons are designed to be non-transferable).

Assuming that the NNS would support IDGeek as an SNS, what would this say about NNS neuron transferability? If NNS neuron transferability restrictions were ever lifted by the NNS, what point would there be to IDGeek?

In any case, I’m not clear that there’s a long term future for a product like IDGeek. Staking directly on the NNS is gradually becoming old hat. Better solutions have emerged (such a liquid staking with @WaterNeuron ), and others will no doubt continue to emerge in the future.

^ just my 2 cents

[yk6]

@Lorimer

SNSs imply a level of approval by the NNS community, yet the NNS is clearly in favour of preventing NNS neuron transfers. II transfers are also not well supported (hence the niche for IDGeek). II transfers have also been frowned upon (for the same reason that NNS neurons are designed to be non-transferable).

Assuming that the NNS would support IDGeek as an SNS, what would this say about NNS neuron transferability? If NNS neuron transferability restrictions were ever lifted by the NNS, what point would there be to IDGeek?

In any case, I’m not clear that there’s a long term future for a product like IDGeek. Staking directly on the NNS is gradually becoming old hat. Better solutions have emerged (such a liquid staking with @WaterNeuron ), and others will no doubt continue to emerge in the future.

It just begin, not only for NNS neuron, hoping Geek can be the Amazon of Web3

[GeekFactory]

Thank you @Lorimer for your thoughtful feedback!

idGeek aims to be a versatile marketplace. If ICP neurons ever become transferable, they would need a dedicated marketplace, and idGeek could fill that role.

Regarding liquid staking, we totally agree it will take a significant share from native staking, but we also believe native staking will still have its niche. Plus, a substantial number of neurons are already staked in the NNS, and due to life circumstances, some users may eventually consider selling their stake. Additionally, SNS neurons are transferable by default; while some projects may choose to restrict this, others will likely keep them transferable.

Lastly, we envision idGeek expanding beyond neurons. There’s growing interest from projects seeking to add various assets to the platform, which opens up exciting potential for diverse use cases.

[Lorimer]

Thanks @GeekFactory, fair points. I should add a postive note that, although I’m not a fan of II/neuron transfers, I do like that IDGeek enforces an escrow period

[Lorimer]

Hi IDGeek, would you be able to comment on the negative effectives that a service such as IDGeek has the potential of bringing to the ecosystem (now, and in the future)? Are you mindful of the potential risks? Have you thought about ways of mitigating those risks to align more closely with the NNS status-quo regarding transferable VP?

What do you make of perspectives like this?

[yk6]

Dear Geek team,

Any updates? Looking forward to the SNS come out

[karnaout]

@GeekFactory

Hello ICP community,

We’re seeking your input on a major decision:
Should idGeek move towards decentralisation via SNS?

idGeek, an Internet Identity and SNS neuron marketplace, has been operating for about 18 months, allowing users to transfer and trade their Internet Identities and associated assets. The project has gained significant traction: >1300 transactions, >1000 active listings, 220,000 $ICP value of sold assets. Therefore we think it’s time to consider its next phase and become an SNS DAO.

Why SNS?

1. Blackholing is Not an Option
   Making idGeek immutable (blackholed) isn’t feasible, as we rely on external systems like NNS and SNS. Any changes in these systems could impact our functionality, risking asset loss or service disruption. A DAO structure offers necessary adaptability, with community-driven governance to navigate changes.
2. Community-Led Governance
   idGeek’s service - enabling transfer of locked assets - could have far-reaching impacts on the ICP ecosystem. We believe that such decisions should be guided by the broader community rather than only a small core team.
3. Expanding Contributor Base
   Through a DAO, we can foster greater community participation and grow beyond our current scope. Developers, enthusiasts, and supporters can directly contribute to the project.
4. Funding Future Growth
   Transitioning to an SNS DAO would not only decentralise idGeek but also raise funds for further development. This would support the addition of new features, project expansion, and ensure long-term sustainability.
5. Transparency and Trust
   Becoming an SNS DAO would enhance transparency and create a more trustless system. With open-source code and community-driven governance, all decisions and processes would be visible to the public, ensuring that idGeek operates in a fair, secure and accountable way.

Potential Risks
We acknowledge the risk of a 51% attack if the DAO’s assets exceed the value of governance tokens. It is important to note that the assets under DAO control also include user assets, such as Internet Identities listed for sale or currently held in escrow. This risk isn’t unique to idGeek and also applies to some of the ICP ecosystem projects and the ICP itself. We believe this can be mitigated through a good DAO design and maybe some extra security layers.

Community Polls
Your feedback is crucial. Please participate in the polls and share your thoughts in the comments below. If we receive community support, we will initiate a security audit, open-source the project, and start the preparation for the SNS launch. Let’s shape the future of idGeek together.

1. Do you believe idGeek is beneficial to the ICP ecosystem?

The proposed transition sounds great and the transparency is a amazing of decentralization. My only concern is making the source code public provides malicious actors with unlimited time to analyze and exploit potential vulnerabilities in the system. Given that idGeek handles high-value, non-recoverable assets like Internet Identities and SNS neurons, this exposure creates a substantial attack surface. Before proceeding with open-sourcing, it would be crucial to implement multiple layers of security beyond basic DAO controls, conduct thorough security audits, and establish a comprehensive bug bounty program to help identify and address vulnerabilities. The focus should be on creating a secure foundation before pursuing complete transparency, as the irreversible nature of blockchain transactions means that any security breach could result in permanent loss of user assets.

[GeekFactory]

Hello ICP Community,

TL;DR

We’ve carefully analyzed what it truly takes to transition idGeek into an SNS DAO. Our goal remains the same: full decentralization while adhering to core Web3 principles. However, we’ve realized that any DAO handling user-held assets faces serious security risks that must be addressed. These risks are not unique to idGeek—they affect all SNS-based projects where users store funds or assets. Below, we outline key challenges and explain how we are adapting our architecture to make SNS work for a platform that handles user assets while keeping them 100% safe and under user control.

Why We Had to Rethink SNS for idGeek

When we first considered transitioning idGeek into an SNS DAO, the idea seemed straightforward: governance would be decentralized, eliminating the need for trust in a central team. However, as we examined the real-world implications of moving a project like idGeek into an SNS structure, we identified a critical problem:

idGeek handles user assets, not just governance decisions.

SNS works well for some types of DAOs, but it introduces serious risks when applied to platforms where users store funds, escrow assets, or rely on smart contracts to manage valuable holdings.

The deeper we looked, the more we realized that these risks affect not just idGeek but any SNS-based project handling user assets, including DEXs, wallets, and marketplaces. For such platforms, governance needs to be structured in a way that guarantees user funds remain completely secure and untouchable by voting outcomes.

The Main Risks of SNS for DAOs Holding User Assets

1. Financial Takeover: When Governance Becomes a Target
If a DAO holds assets more valuable than its governance tokens, it can become a financially profitable attack target. An attacker could buy enough tokens to take control, then pass proposals that put user-held assets at risk—whether by directly seizing them or changing smart contract rules to benefit themselves.

2. Social Engineering: Influence Over Decentralization
Even without a direct takeover, powerful entities can manipulate governance through social influence and marketing. A well-organized group can convince token holders to vote in their favor, even against the best interests of users. Since most voters don’t analyze proposals in-depth, they often follow recommendations without questioning them.

3. Smart Contract Attacks via Governance
SNS allows DAOs to upgrade their smart contracts through governance proposals. While this ensures flexibility, it also introduces a serious risk: what if an update contains hidden vulnerabilities? Most token holders don’t have the technical expertise to review smart contract changes, meaning a single unnoticed exploit could compromise the entire system.

4. Centralized Voting Power
Although SNS is designed for decentralized governance, in practice, many SNS projects are dominated by a small group of key participants who hold the majority of voting power. Even if no attack happens, users must still trust that these few individuals will always act in good faith. This contradicts the trustless nature of Web3—especially for projects where users hold valuable assets.

5. DAO vs. Users: The Problem of Governance Over Assets
DAOs are designed to make governance decisions, but what happens when a DAO can vote on user assets? If governance has the power to impact funds held in escrow, who truly owns those assets? Even well-intentioned proposals could lead to unintended consequences for users. For platforms like idGeek, users must have absolute security that their assets remain under their full control—not the DAO’s.

Why Not Just Make idGeek Fully Immutable?

Once we identified these risks, we explored possible solutions. The most obvious one was to make idGeek fully immutable (blackholed), removing all governance control.

But this created a new problem:

idGeek relies on external systems like NNS, SNS, token ledgers and so on. If any of these systems change in a way that breaks compatibility, a fully immutable idGeek could lock user assets permanently. A system that cannot adapt to external changes is not a viable long-term solution.

So we had to find a way to keep user assets safe while still allowing the system to evolve.

How We’re Adapting Our Architecture for SNS

To address these challenges, we are implementing a new architecture that allows us to:

Launch an SNS DAO while eliminating governance risks.
Ensure user assets remain 100% under their control—no DAO proposal can impact them.
Make most of the system immutable, so once verified, the code will always run exactly as deployed, with no possibility of modifications.
Introduce an emergency withdrawal mechanism—if external dependencies break, users can still recover their assets.
Allow DAO-driven upgrades, but only in ways that do not affect existing user holdings.
Expand idGeek beyond an Internet Identity marketplace, unlocking new possibilities for the future.
Ensure full transparency—all smart contracts will be open-source, auditable, and verifiable. This means anyone can review the code, verify that deployed contracts match the public repository, and confirm there are no hidden modifications.

This approach preserves decentralization while ensuring that the system remains fully trustless, keeping user assets safe and outside the control of governance.

We Want Your Input

We’re currently implementing this architecture and will share all technical details soon. In the meantime:
• What do you think of these governance risks?
• How do you think DAOs should handle user-held assets?
• Would you trust a DAO where governance can impact user funds?

Let’s discuss!

GeekFactory Team

[skilesare]

This is on reason we attempted to put the subscription utility under NNS control. While the NNS theoretically has the same issues, its size and current makeup makes it an unlikely target for hostile take over. The negatives being that DFINITY has virtual control due to current following config. This was acceptable as trust in the DFINITY acting in the best interests of the platform seemed to be defacto risk anyway.

Unfortunately, DFINITY does not want that responsibility at the moment and has pledged to proactively reject any upgrades canisters controlled by the NNS that they did not develop themselves. I still have plans to propose an alternative to this but it has been buried on my todo list. It likely involves a bit of a hack and a reliance on rolling immutability.

Without this feature it is difficult to create systems that “inherit the security of mainnet” as the L2s in Ethereum are attempting to do.

Once we distribute voting power enough it won’t be an issue, but I don’t see that happening without significant backing and effort from DFINITY. I expect this when they are ready, but there is still a lot of the platform to build.

These are great things to try to figure out in the meant time.

[GeekFactory]

Hello ICP Community,

We’re excited to share an update on idGeek’s journey toward full decentralization. Here’s why we’re making changes, what we’re solving, and how our new architecture will works—step by step.

What’s the Problem? Why Change?
Right now, idGeek relies on a central smart contract controlled by our team. While we’ve built it with care, this setup requires users to trust us—a fundamental conflict with Web3’s philosophy of trustlessness. No matter how reliable we aim to be, centralized control introduces risks and undermines the ownership users deserve.

Why Can’t We Just Transition to an SNS DAO as Is?
Our current architecture uses a single smart contract to manage Internet Identities (or other assets) that users transfer to it for selling. Transitioning this to an SNS DAO would shift control from our team to the DAO, reducing some trust issues—but not all. The DAO itself could still be compromised (as we detailed in our last post), leaving user assets vulnerable. Even a minimized risk is too much when it comes to what you own.

What’s the Solution?
Our answer is simple yet powerful: each asset a user wants to sell gets its own blackholed smart contract. Think of it as a bespoke, standalone contract per asset, per deal. This contract holds the Internet Identity (or other asset) for the duration of the sale. It’s open-source, verifiable, and blackholed—meaning no one, not even us or a DAO, can alter it once deployed. Users trust only the code, not any party.

Where Do These Contracts Come From?
They originate from a trustless, immutable Smart Contract Hub—a starting point for anyone looking to sell an Internet Identity or other asset. Users deploy their own contracts directly from this Hub, ensuring the process is secure and transparent from the moment it begins.

How Do Contracts Get Into the Hub?
The SNS DAO will play a limited role here: it will approve and add contract templates to the Hub. These templates serve as blueprints—users pick one that fits their needs and deploy their own contract. The DAO can’t touch deployed contracts, ever; its job ends at template approval.

Who Creates These Contracts?
Anyone can propose a new contract template to the DAO. Every submission must be fully open-source, so the code is transparent to all. The DAO may appoint auditors to review proposed contracts, but independent auditors can also step in at their own cost, ensuring community-driven scrutiny.

What If Something Goes Wrong Due to Changes in ICP?
No system is immune to external shifts, like updates in ICP’s infrastructure. That’s why each contract includes an emergency mode. If an asset gets stuck, the owner can activate this mode after a set expiration period (fully transparent and verifiable). Until then, the contract remains immutable, locking out interference.

What About the Marketplace?
There’s no need for a centralized marketplace anymore. Transactions, escrow, and ownership transfers happen entirely within the contract itself. Our default marketplace—and any future ones built by others—will function only as read-only storefronts, displaying listings without controlling assets or deals. Marketplace fees will be part of the contract, ensuring any platform that helps facilitate a sale gets rewarded without needing trust or control. Everything you need is baked into the contract, so marketplaces have no control and trust isn’t required.

What Are the Main Benefits?
This approach delivers what Web3 promises:

• No need to trust anyone — not the team, DAO, marketplace, seller, buyer, or anyone else—just the code.
• Custom contracts — templates for any asset, any transaction, any need, far beyond just Internet Identities or sales.
• No risk, even in failure — emergency mode ensures stuck assets can always be recovered.

We’re building a system where trust in people or entities is replaced by trust in transparent, verifiable code. This is idGeek reimagined: a platform where every asset gets its own secure, independent contract, free from centralized risks. We’re working on this now and can’t wait to hear your thoughts!

GeekFactory Team

[GeekFactory]

Hello ICP Community,

We’d like to share the next step in idGeek’s journey toward decentralization—and what to expect in the coming weeks.

Beta Launch of the Smart Contract Hub
We’re getting ready to launch the beta version of the Smart Contract Hub. This will be the place where users can deploy self-contained, blackholed contracts for various use-cases. The Hub will evolve over time, and during the beta phase it won’t be blackholed yet. That means it’s still controlled by GeekFactory team, so we can continue to refine the architecture, add features, and gather feedback from early users.

Because of this, the first contract won’t be the full idGeek 2.0. That contract handles Internet Identities and escrowed assets, which require maximum security. Releasing it while the Hub is still upgradable wouldn’t align with our principles of trust minimization.

The First Contract for Testing
To kick things off, we’re releasing a test contract for ICP neuron followees auto-confirmation. It’s intentionally simple and doesn’t require the same level of security guarantees as Internet Identity wrappers or escrow. The goal is to test the full deployment pipeline and allow users to get hands-on experience with how everything works.

Here’s what this contract does:
• It is a small, blackholed canister that you can add as a hotkey to your ICP neurons.
• The contract will auto-confirm followees automatically, at a frequency you define. Currently it is required every 6 months.
• It’s a backup tool—not a replacement for active participation. This is just for those who want an extra layer of safety to avoid missing rewards.

Why This Contract?
Because:
• The logic is simple and easy to verify.
• It doesn’t need the same level of security as escrow-related contracts.
• It gives us a safe way to test the full flow: deploy → verify hash → check certificate → validate blackhole status.

What You’ll Be Able to Do in the Beta Phase
As a user, you’ll be able to:
• Deploy your own instance of the test contract directly from the Hub.
• Verify the contract hash against the source code on GitHub.
• Check the certificate, which will be set to 100 years—meaning no upgrades or changes until then.
• Confirm that the contract is blackholed (no controllers, no way to change it).

What’s Next
The steps after testing the Hub and the test contract will include:

1. We will open-source the Hub’s code.
2. Then, once we’re confident in its design and stability, we’ll blackhole the Hub .
3. After that, we’ll open-source and launch the full idGeek 2.0 contract —which will handle Internet Identities and asset escrows, trustless and immutable.

That’s where we’re headed. If you’re interested in trying out the beta and helping test the system, keep an eye out—we’ll share the exact launch date and instructions soon.

As always, we welcome your feedback and thoughts.

GeekFactory Team