This is real i cant to do more

Developers Showcase
1

Hi all,

I’m posting from x39Matrix (canister a6ynb-biaaa-aaaao-ba4gq-cai,
mainnet). What follows is a technical pattern + anti-pattern that
I’d like to see discussed openly here. No tokens, no fundraising,
no roadmap promises — just code, signatures, and verification.

THE ANTI-PATTERN

I keep seeing canisters expose a query endpoint that returns
hardcoded multi-line strings like:

“ECDSA: 75621f3e… TPS: 400 Compute: 0ms Sign: 0ms Status: SEALED”

These are not signatures. They are descriptions of signatures.
The function is free, deterministic, and never invokes
sign_with_ecdsa. Calling it ten thousand times costs the
canister nothing and tells the auditor nothing.

The damage is reputational, not technical: when newcomers see
“0ms ECDSA” repeated everywhere, they assume that’s what
sign_with_ecdsa does on the IC. It isn’t.

THE PATTERN

Three explicit tiers:

  1. audit_b27_local(n: u64) -> AuditReport (query)
    Real Merkle tree of n leaves (capped at 64), canonical SHA-256
    over canonical state, exposes internal counters. Reproducible:
    same n → same merkle_root_hex; different n → different output.
    Fields are explicitly named:
    ecdsa_local_hex // SHA-256, NOT a signature
    ed25519_local_hex // SHA-256, NOT a signature
    clock_logical_ns // ic_cdk::api::time(), real ns

  2. clock_physical_ns() -> u64 (query)
    Just ic_cdk::api::time(). Two calls + sleep gives a real
    nanosecond delta. Demonstrates that subnet time is measured,
    not a logical counter that always reads 0.

  3. audit_full(n: u64) -> Result<SealedReport, String> (update)
    Caller principal must be in a sovereign whitelist. Builds
    a canonical SHA-256 message and calls sign_with_ecdsa
    against the management canister with the canister’s own
    key_1. Returned struct exposes:
    ecdsa_threshold_ic_hex // 64-byte secp256k1 sig
    pubkey_hex // 33-byte compressed pubkey
    message_signed_hex // 32-byte SHA-256 digest
    clock_threshold_*_ns // real timing of the IC sign

    Mainnet latency: ~5–7 seconds per call. That’s the right
    order of magnitude for a threshold-ECDSA round on the IC.

EXTERNAL VERIFICATION (the actual proof)

Anyone can verify offline with python-ecdsa, no IC tooling required:

from ecdsa import VerifyingKey, SECP256k1
from ecdsa.util import sigdecode_string

PUBKEY = "<pubkey_hex>"
MSG    = "<message_signed_hex>"
SIG    = "<ecdsa_threshold_ic_hex>"

vk = VerifyingKey.from_string(bytes.fromhex(PUBKEY), curve=SECP256k1)
vk.verify_digest(bytes.fromhex(SIG), bytes.fromhex(MSG),
                 sigdecode=sigdecode_string)
# silent on success, BadSignatureError on failure

Concrete sample from a real call today:

pubkey = 03989da02dad76682c8f9ed7d8d4bec81f956c64fd174532f6fb6aaefa5de6c3e4
msg = 1b68a4c06b0ac4be8e52c0aef4f44d358d1fd3046fcdba6282e6e3ac8f80b25b
sig = 52963f7c1376e62cd6318474220e98f11ca2b09c34b433b8f1680c394eac09f3
128147e2813f859c976c662324de19c116cd95eb66bc6d5647165008b43f3a06
delta = 5_768_591_055 ns (≈ 5.77 s)

Verifies VALID against secp256k1 + RFC 6979.

TWO NAMING CONVENTIONS THAT HELP

• suffix _local for canonical SHA-256 hashes
• suffix _threshold for actual sign_with_ecdsa results

Mixing them in Candid types is, in my view, the easiest way to
erode trust in sign_with_ecdsa itself.

A CLOSING REMARK

This is the third time I try to share a technical post on this
forum. The two previous ones were removed without explanation.

If this one disappears too, I’d like to know — publicly — which
forum guideline a post about threshold-ECDSA verification, with
no advertising, no token sales, no canister-id promotion, and
externally reproducible cryptographic evidence, manages to break.

If it stays up, I’m happy to share the Rust module (~250 lines,
no rust-bitcoin dep) as a reference for anyone copying the
pattern. Stress-tests on the verification snippet welcome.

-– x39Matrix

2

dude, u need to see a doctor

AI induced Psychosis is real

3

If you don’t make 10 threads with the same thing, making it look like LLM context posioning, I suppose they may not get deleted.

4

That comment is unhelpful. If you have peer‑reviewed evidence for “AI‑induced psychosis,” please share it. Otherwise, avoid personal attacks and focus on the technical topic: verifiable threshold‑ECDSA proofs.

6

Are you sure that is sufficient?

why not _this_is_a_query_call_local ?

example Candid:

my_magic_this_is_a_query_call_local : () -> (Magic) query;

do you think that will make it clear enough that it’s a query call and not going through full consensus?

7

I was checked his codes last weeks, he made a fronted that shows for example 500 errors as successfully initialized or something things like that. this isn’t just AI hallucination. AI coding agents won’t ever do such a things, if you don’t specifically ask for it. the guy is not honest.

8

Thought the same, but there is a way for AI coding agents to produce it - if you give them a messed up initial prompt with something like the artificial gpt4o “spiral” cult. Or use not a very powerful LLM.

I promise none of us have placed that string returning function in your canister to confuse you.

9

Good breakdown, the distinction between fake “descriptive” outputs and real ECDSA signatures really needs to be clearer.