Stsh.fi - Independently developed ZK protocol on ICRC Standards

Developers
1

Hey All

Very excited to announce more publicly a project being built ‘STSH protocol’

www.stsh.fi

Starting with STSH token - a native ICRC privacy and treasury protocol on the Internet Computer.

Separately, Menese’s recently published Hivemind repository addresses some of the same underlying shielded-ledger problems, although the systems use independently developed circuit and protocol architectures.

From what I’ve seen; Hivemind publishes a two-input/two-output Groth16 circuit over BLS12-381, with eight public inputs and a custom in-canister Motoko verifier. STSH currently uses a one-input/two-output Groth16 circuit over BN254, with nine public signals that explicitly bind its Merkle anchor, nullifier, output leaves, public amount, fee, recipient principal and recipient subaccount.

STSH additionally domain-separates notes and nullifiers by the pool deployment, asset, circuit version and network. Its Merkle leaves bind the private note value directly because the circuit is designed as part of a wider fixed-supply ICRC asset, escrow, solvency and private-liability accounting system.

Both projects have converged independently on Groth16, Poseidon commitments, nullifier replay protection, browser-side proving and recipient-bound ICRC withdrawals.

However, STSH is specifically designed around an auditable private assets and digital-treasury model rather than as a general shielded-ledger implementation.

It is encouraging to see independent ICP teams converging on the need for private financial infrastructure on ICP.

The reason for the post; We’ve already had a couple of independent security reviews and have come back encouragingly positive following over a dozen structured internal security-review and adversarial-testing passes and are in the stages of locking in the final auditability and monitoring features.

As I’m completing a 2nd ceremony before launch, currently the ZK ceremony was completed by 1 person, myself. To encourage community conviction I’m looking for any support on 1 or 2 things.

To strengthen confidence in the protocol before launch, I’m looking for support in two areas:

1. Ceremony & Security

I’m looking for experienced contributors interested in participating in the second ceremony, independent security review, adversarial testing, or broader protocol validation.

A limited allocation of pre-seed tokens has been reserved to recognise meaningful strategic contributions, such as security research, ceremony participation, or ecosystem development.

2. Ecosystem & Launch

As an independently funded project, STSH is also open to discussions around strategic technical collaboration, ecosystem partnerships, and launch support.

Any potential token allocation or funding discussions will be conducted privately, individually, and subject to the applicable legal and regulatory requirements. Nothing in this post constitutes an offer, solicitation, or invitation to acquire tokens.

If you’re interested in contributing to the protocol, feel free to reach out. Please do your own research before engaging with the project.

Look forward to hearing any feedback!
If you’re interested in getting involved drop me a message and we can discuss contributions / repo access etc.

Still tuning the website around the new launch plan (full privacy pool from day 1, not 'public token → pool). So excuse any odd typos on the website!

2

Great work! We would be interested definitely in contributing to the ceremony, can add 6-7 people easily to your list. We are still refining our work and would recommend looking into the PIR system it would help if you are planning to do private look ups(we made it pretty cool how 100m scalable kind of a beast), also check on memory allocation and watermark in upgrades at scale..those things have bitten us a few times, our work is still in progress we would be down to take a look and give feedback if you would like

3

Very cool, can I ask what your plans are regarding decentralisation of the protocol and/or immutability of the protocol or some of its components (such that users can have confidence in the integrity of the protocol into the future)?

4

Thanks, I’d very much welcome additional participants for a stronger ceremony. The internal security testing has been pushed about as far as I can take it myself.

I’ve also had a second independent review which came back encouragingly robust, but I’d certainly welcome any feedback around things like memory allocation, upgrade strategies, watermarking or any other lessons your team would be happy to share which you’ve learned from building a production platform.

5

Hey, thanks for the question. Long term the goal is progressive decentralisation through governance of the STSH Protocol.

initially I intend to remain an accountable operator while security, audits, monitoring and ecosystem integrations mature.
Over time, governance responsibilities and protocol critical components are intended to transition towards community management. Components that are fundamental to trust, proving system, verification logic and cryptographic security aim to become fully open source.

That said, some of the enterprise treasury products and commercial infrastructure may remain proprietary where appropriate, as those are products built on top of the protocol rather than the protocol itself.

The objective is to maximise trust and integrity without unnecessarily giving away every piece of intellectual property.

But this also why I’m here, open to community feedback, technical discussion and individual contributions that would improve the protocol

6

My understanding was that you’re aiming to deliver verifiability rather than trust. I don’t mean for this to come across as a snarky comment, I’m genuinely a bit confused (if it’s closed source until some undisclosed point in the future, and mutable by a centralised controller, what would drive people to want to use this? Or how do you get the ball rolling?).

7

There’s an important nuance between verifiability and governance.

First and main priority is that users can verify that the protocol behaves exactly as claimed through independent audits and publicly reviewable protocol components.

Governance is a separate, more complex question in my opinion. Personally, I don’t think it’s responsible to fully decentralise a protocol before it has reached a reasonable level of maturity, simply for the sake of having a “decentralised” stamp.

Over time, I don’t expect to remain the only accountable operator. Governance has been considered from the foundation and staking will form part of that. As the protocol matures, the community grows and governance proves itself, reducing my level of control becomes the ideal solution