We’re a verifiably decentralised collective who review IC deltas (changes applied by NNS proposals). We follow a common code:
Look: We observe the details and context of NNS proposals
Test: We test and verify the claims made by those proposals
Automate: We automate as much as possible by building increasingly sophisticated tools that streamline and strengthen the reviewal process.
Every vote cast by CO.DELTA is the result of consensus among diligent, skilled and experienced team members acting independently. The CO.DELTA neuron follows the vote of D-QUORUM on NNS topics that the CO.DELTA team does not handle directly. You can therefore follow CO.DELTA on all NNS topics and rely on a high quality vote.
We’ll begin with the Subnet Management NNS topic. Over time we plan to cover more topics.
We’ll be announcing details of our threshold-canister-controlled neuron soon, which we’ll then propose as a known neuron. Please stay tuned…
We’ll also periodically publish more details regarding NNS topics covered, and team member introductions. In the meantime further information can be found here.
Hi everyone, we’re close to being ready for raising a known neuron proposal for CO.DELTA △ (hopefully after the weekend). We’re finishing up an internal code review (before we open-source our repo). In the meantime you can get in early and start following our team neuron:
Threshold canister testing is being finished up. The threshold canister will be the only controller of the backend canister, and in turn the backend canister and threshold canister will be the only controllers of the frontend canister. The threshold canister will be it’s own controller (no other principal). The threshold canister is what enforces that all canisters are managed in a decentralised manner, requiring a vote from team members in order to upgrade the canisters or disburse voting/reviewer rewards.
CO.DELTA △ aims to provide a highly secure, high quality option for following on all NNS topics. We currently specialise in the Subnet Management NNS topic (helping to protect the IC from collusion, and enforcing the IC Target Topology, along with other more nuanced requirements). In the meantime, CO.DELTA follows D-QUORUM on NNS topics that the current team doesn’t focus on. Consider supporting the growth and development of CO.DELTA by following us and/or check us out!
Thanks for standing by. The CO.DELTA canisters are now decentralised, controlled by our threshold canister. You can call the getSigners method to see the principals with voting rights (currently me, @aligatorr89 and @MalithHatananchchige - but we’ll be onboarding more members over time).
Our threshold canister is a fork of DFINITY’s canister, with several enhancements to make reviewing threshold proposals simpler (coupled with some bash scripts to automate various aspects - see ‘Utils’ folder in our repo, currently under an open PR).
Hi community! As some of you know, my name is Rok, and I’m coming from Slovenia. I’m a developer with 9 years of professional experience. I got into ICP in 2021 and started following the project from the side. I got more and more involved in projects in 2024 and build a lot of connections.
As you can see at CO.DELTA we have done every step without assuming anything, like “trust me bro” scenario. So far we have
Started voting on Subnet Management proposal
decentralize threshold canister which is used to control CO.DELTA canister. It can update its code and call distribute_icp to reviewers. All with proposals without single control.
develop CO.DELTA canister which is used to claim ICP rewards to all 3 members equally. It is controlled by threshold canister as described above.
This is mostly thanks to @Lorimer, who was the architect behind this. It is a new type of cooperation, where no party has control over group funds and capabilities.
Thanks to the community, we are now CO.DELTA - the known neuron.
My forum profile provides a brief bio about me. I’m very proud to be on this team with @aligatorr89 and @MalithHatananchchige. We’ll grow and onboard more members over time. We’re looking forward to making a difference to the NNS!
It’s great to see a community member show deeper interest in CO.DELTA, I’ve cross-posted your question to this thread to keep the other one on topic (I hope that’s okay). NNS neurons are stored by the NNS Governance canister - you can read more about neurons here. Canister-controlled neurons are no different in this respect
I’d be happy to elaborate further. Just let me know.
Thank you for your concern. Rest assured that changes to the CO.DELTA canister are run locally by team members before deploying. Note that the CO.DELTA canister has a very simple job, yet we do have utilities for quickly bootstrapping a local test environment. What test scenario are you concerned about Jefri?
From the code it seems like you hold the private key. So in the end you gain all the VP. Either way you will just have outsized influence in the team anyway, so all the “decentralization” is just marketing. Maybe you can have someone outside audit your code, but you won’t because all you do is talk and talk.
As a code reviewer from CodeGov, I would really like to know how you came to this conclusion. This is a very simple setup, and you should be able to see that everything is transparent, and decentralised.
You, or anyone else, are more than welcome to audit the code. Please do
A decentralised treasury and neuron, yes - simple and effective (it’s never been described as more). The rest of the value comes from the decentralised team members, who each build their own personal automation/tooling for progressively improving the depths and effectiveness of their own reviews.
Like any other canister controlled neuron. Software development is largely an exercise in managing complexity. There are no plans for any further neurons controlled by this canister, so there’s no need for any code to create more neurons. I’m no sure what you’d be expecting.
I appreciate that the README has a lot of information. The bit you’re looking for is near the end →
This allows members of the CO.DELTA team to manage the CO.DELTA known neuron via NNS proposals (here are some examples: 135418, 135438, 135585). This avoids having to re-invent the wheel with the codelta_backend canister regarding neuron management.
You can verify everything about the CO.DELTA neuron via the NNS Governance canister (like any other known neuron). Here are the steps to follow, if that helps:
You’ll notice the controller is the CO.DELTA backend canister, which itself is controlled in a decentralised manner. Canister control keeps the door open to any automation functionality we wish to implement in the future. You can also see all of the neuron followees, including on the Neuron Management topic, which is how the neuron is currently controlled in a decentralised manner by the team. You can therefore verify that there are no points of centralisation, including any hotkeys. You might be interested in what you find if you perform the same checks on the CodeGov neuron, or even the community-controlledSynapse neuron.
Please let us know if you have any further questions or suggestions. We’re always looking for ways to raise the bar with respect to NNS governance and due diligence.
@aligatorr89
As I mentioned, I like the idea, but Lorimer’s aggressive attacks have overshadowed any reasonable communication. I appreciate that you’re engaging now and prefer communicating with you, as you avoid backhanded comments that derail discussions.
Currently, it seems only two members are actively voting: you and Lorimer. On paper, this appears balanced, but with so few members, it’s unclear who truly controls co.delta. Lorimer seems to hold more influence due to his assertive and controlling nature, stopping at nothing to achieve his goals. Ultimately, it feels like his project. To address this, I suggest increasing the number of members, even if some are unpaid, to balance the influence of paid members. Additionally, consider separating paid and unpaid members into distinct lists. The main list should include a diverse group of community members to prevent any single individual, especially the founder, from dominating. In team dynamics, founders often wield disproportionate power, particularly when members avoid conflict.
The concept of team-based canister consensus control is intriguing, much like liquid democracy. It eliminates the single private-key bottleneck but introduces new vulnerabilities through software and human consensus. With every threshold upgrade, the backend risks reintroducing exploitable code paths. Team members must diligently review every diff to prevent a tainted WebAssembly blob from slipping through unchecked. If signers rubber-stamp upgrades, a small colluding group could manipulate the N-of-M threshold. Another is exploiting divisions among members.
Ultimately, the social layer is the decisive factor. I’m curious to see how this unfolds. Thank you again for engaging constructively.
