Public indexes map hundreds of thousands of addresses to "claimable" balances in dead protocols. Almost none of those numbers are checked against the contract that would pay them, and three failure modes recur.

1. Token counts labelled as ETH. One 2016 index lists 81,295 "ETH" for 4,836 addresses in a DAO wrapper. The wrapper does hold 81,287 ETH, but the top listed holder has 10,200 DAO tokens, not 10,200 ETH, and withdraw() reverts for that address. The file's own header says balance_source: token.

2. A getter that does not answer. One game contract is indexed at 163.42 ETH for its top holder; balanceOf(0x0, holder) returns zero. The pool holds 2,424 ETH, so the money is real and the address mapping is wrong.

3. A payout that is not the getter. Another indexed 141.97 ETH for its top holder, while the contract's own curve function returns 87.83 ETH. A token count was priced as if 1:1.

The method that catches all three, in order:

- Denomination. Only eth-sourced balances count as ETH. Token, weth and vault sources need a per-pool rate and must never be summed into an ETH total.

- Selector provenance. Pull PUSH4 constants out of the deployed runtime bytecode and match them to signatures. Do not trust an ABI, and do not trust an index's stated claim path.

- Getter read. Ask the contract what it owes a specific address.

- Claim simulation. eth_call the actual withdrawal from the holder's address. A revert means there is nothing collectable there, whatever the index says.

- Executor. Decide whether the claim is owner-only (pays msg.sender) or third-party (anyone can trigger payout to the registered recipient, as with merkle airdrops and bridge finalisations). This single axis decides whether a public-good claimer is even possible.

Run against a 2020-era exchange contract, this verified a pool holding 15,673 ETH across 119,430 addresses, with a 946 ETH top holder whose withdrawal simulates cleanly at 42,077 gas, using a different claim selector than the better-known EtherDelta-style contract it resembles.

The uncomfortable part is economics, not cryptography. Where the claim pays msg.sender, no relayer or incentive contract can collect for someone else. Of the 400 largest holders, 97% signed a transaction historically but only 4.5% have signed one in the last year. Chain state cannot distinguish a lost key from indifference, and a lost key makes the balance permanently unrecoverable.

I have a read-only checker that runs the whole read in one call and prints the exact transaction per claim. Not linking it here given the self-promotion rules - comment or message me and I will send it with the raw JSON-RPC body so you can replay it against your own node.

On most chains a transaction is broadcast in full and sits in a public mempool until it's mined, which is what makes mempool front-running and sandwiching possible. Midstate, a small post-quantum PoW chain, makes every spend a two-phase commit-reveal at the consensus level instead. I'd like to hear where people think this falls short.

How it works

1. Commit. The wallet builds the full transaction, then broadcasts only a 32-byte BLAKE3 hash over a network tag, the input coin IDs, the output hashes and a random 32-byte salt, plus a 64-bit nonce. The commit pays no fee. Instead the nonce needs at least 24 leading zero bits of proof of work, tied to a block hash no more than 1,000 blocks back. The mempool raises that toward 30 bits as its commit lane (capped at 1,000) fills up.
2. Wait. The wallet waits until the commitment is in chain state, not just the mempool, and adds a random delay before revealing (5 to 15 seconds, or 30 to 120 with a privacy option) so timing alone pairs commits and reveals less easily.
3. Reveal. The full transaction (inputs, outputs, salt, signatures, fee) goes out. Nodes recompute the hash and reject it unless a matching commitment is on chain and less than 1,000 blocks old. The signatures sign the commitment itself, so nobody can swap the outputs.

Miners are paid to include zero-fee commits through fork-choice weight: each commit adds 2²⁴ to the chain weight, capped at a quarter of the block's own work. Each block can carry up to 2,000 commits and 500 reveals.

Known limits

• The reveal is public, and miners still order reveals inside a block.
• A commit and its reveal can share a block, so a miner who also trades could in principle act on a reveal straight away.
• Commits don't lock coins. For shared coins, like an open covenant order anyone may fill, the first valid reveal mined wins.
• It hides contents, not activity or timing.

Questions for the sub

• Is paying for commits with capped fork-choice weight sound, or is there a cheap way to game it?
• For shared-coin cases like on-chain limit orders, is there a better defence against a miner reordering reveals?
• Is per-transaction commit-reveal worth at least one extra block of latency, compared with encrypted mempools or threshold-decryption schemes?

Code: https://github.com/ciphernom/midstate (see src/core/types.rs, src/core/transaction.rs and src/mempool.rs)

Disclosure: I'm involved with the Midstate project, and I wrote this up with help from an AI assistant working from the code. I'm here for the design discussion, not to talk about the coin.

I have been looking into how high-traffic websites handle crypto deposits. Usually, you have to wait for the network to fully confirm the transaction, which can take a while. But I have noticed that some platforms update your account balance almost immediately after the transaction is broadcasted. From a technical side, how do they safely do this without risking double-spends? Do they just track the transaction in the mempool and accept the risk internally, or is there a safer way they verify it off-chain?

I've been exploring an architectural question around real-world asset tokenisation: can zero-knowledge proofs meaningfully reduce trust in asset verification, or do they simply move the trust assumption to whoever generates the original data?

For example, a protocol could use ZK proofs to verify that an asset meets predefined conditions without exposing confidential ownership records, valuation data, or custody information. However, if the underlying claims originate from a compromised attestor, the proof might be mathematically valid while the real-world information is still false.

Would you separate the system into an attestation layer, a cryptographic verification layer, and an independent dispute-resolution mechanism? Or is there a better way to minimise reliance on trusted data providers?

I'm particularly interested in whether combining ZK proofs with threshold signatures, slashing mechanisms, and verifiable credential systems actually improves security or merely creates more complex failure points.

For those designing production-grade RWA infrastructure, which trust assumptions would you eliminate cryptographically, and which would you explicitly accept as unavoidable?

Hey everyone! I’m building a wallet that lets users delegate actions to an AI agent, and I’m researching wallet infrastructure providers to get started. I’m currently looking at Privy, Turnkey, Dynamic, and Web3Auth.

If you’ve built with any of these, what did you like most, and what limitations did you run into? I really appriciate any suggestions～

ing up treasury management for a small DAO and every comparison I find is written by someone selling one of the two. Unsurprisingly, they all conclude their own approach is better.

Here's where I've got to on my own. Multisig lives onchain so the rules are public and anyone can verify the threshold. The downsides are chain specific implementations, higher costs, and a setup that's visible to everyone. MPC splits a key into shares, so the chain only sees a normal signature. That makes it cheaper, portable across chains and more private. The catch is that you're trusting an implementation you probably can't audit, and share management happens entirely off chain

Recovery is the part I don't understand well. Rotating a multisig signer seems clear. Rotating MPC shares feels like a black box

Is anyone running either for real funds, and what made you pick one? Is anyone running both for different jobs, say MPC for daily operations and multisig for the treasury?

I’ve been playing around with MCP integrations and the payment side is where I keep getting stuck.

I’m comfortable with an agent being able to request a purchase, but I don’t love the idea of the same model deciding what it can spend and then executing the payment on its own. That feels like too much authority sitting in one place.

The setup that makes the most sense to me is keeping approval separate: the agent submits the purchase details, the user approves it, then a single-use payment method is created for that exact transaction.

For anyone building MCP payment flows already, where are you drawing the line? Do you require approval for every payment, use spending limits, issue one-time cards, or something else?

I shorted ETH with $100 at 20x leverage on Kraken and paid:

$16 opening fee
$16 closing fee
$5 margin fee

Made $7 gross but lost $30 after fees. A $1482 price drop breaks even but that doesn't even happen in a year...

Ideally, I want to short BTC from $80,144 to $79,673 (red to blue line in screenshot) using $100 at 20x leverage. That’s $11.76 gross profit, but Kraken’s fees wipe it out.

Any platforms that allow shorting with zero or very low fees so I can keep most of the profit?

I'm developing V-DAP, an experimental Rust engine that measures cryptographic execution timing. I'm trying to determine whether those measurements provide useful diagnostic information beyond conventional observability tools.

The practical problem I'm investigating is this: when a service experiences latency spikes, can measurements of cryptographic execution help distinguish between possible sources of delay, or do standard metrics, tracing and profiling already provide the same information?

My current experiments are preliminary. In a controlled HTTP pilot, I observed a strong correlation between the measured cryptographic interval and total request latency. In a separate experiment, I introduced a deliberate delay outside that interval and observed the request latency increase. These results demonstrate temporal decomposition in those test conditions, not scheduler causality or a proven diagnostic advantage.

What I want to validate next:

• Can V-DAP help distinguish two known causes of latency?
• Does it improve diagnostic accuracy or time-to-diagnosis compared with conventional tools alone?
• What confounders and measurement overhead should I investigate?
• What experiment would convince you that this has practical engineering value?

Repository and reproducibility details:
https://github.com/jorgecumbe0077/v-dap-engine

I'm looking for critical technical feedback, including reasons this approach may not be useful. I don't claim that V-DAP is production-ready or that it prevents timeouts.

Pump says 90% of its bridge trades landed before a typical Relay trade in its testing. Are they timing until the funds reach the destination chain, or until the actual token buy has filled? Because if you're comparing trading apps, I'd care about the whole thing from clicking buy to actually receiving the tokens. Failed attempts probably need to count too.

Anyone seen a proper methodology breakdown?

I’ve been developing V-DAP, an experimental Rust engine that measures cryptographic execution timing. I’m now trying to answer a practical question: can these measurements help diagnose request latency in ways that conventional metrics, logs, and traces do not?

So far, I’ve run controlled experiments that explore the relationship between cryptographic execution time and total request latency. The results are preliminary, and I haven’t established that V-DAP provides better diagnostics in real production systems.

I’ve published the source code, reproduction instructions, experimental reports, and current validation criteria.

Repository: https://github.com/jorge-cumbe0077/v-dap-engine

I’d appreciate technical feedback, especially on:

• Whether the measurement methodology is sound.
• What limitations or confounding factors I may be overlooking.
• How to design a fair comparison against conventional observability tools.
• What evidence would be needed to establish a useful real-world application.

I’m particularly interested in critical feedback that could help validate or invalidate the approach.

The problem isn't necessarily whether a quantum computer capable of breaking today's cryptography exists today.

It's whether we can afford to wait until it does.

Cryptographic migrations take time. Wallets need updates. Protocols need new standards. Exchanges, institutions, infrastructure and users all need to migrate.

And once the threat becomes obvious, everyone will be trying to do the same thing at once.

So I'm curious where people here stand:

1. Quantum attacks are still too far away to worry about.
2. We should start preparing now, even if the threat is decades away.
3. Bitcoin and other networks will adapt naturally when the time comes.
4. The quantum threat is being seriously underestimated.

What do you think?

I'm building Finalis, a BFT blockchain in C++20 (open source, testnet only, no token sale). I wanted to share a bug that I think is relevant to anyone using VRFs or Ed25519 point checks in consensus code.

**The setup.** Each block's leader publishes a VRF proof, and its output feeds the chain's randomness. My VRF hashed to the curve with a try-and-increment loop that accepted the first candidate for which libsodium's crypto_core_ed25519_is_valid_point() returned true.

**What the fuzzer found.** The ClusterFuzzLite job (Ubuntu 20.04 image) crashed on startup: a proof my test fixture had just created was rejected. Isolating it: the same key and input gave a *different proof* on Ubuntu 20.04 (libsodium 1.0.18-1) than on Ubuntu 24.04 (1.0.18-1ubuntu0.24.04.1), and each rejected the other's. Both report version 1.0.18, but the point-validation behavior differs between the two packages. In a live network, that's a chain split waiting to happen.

**The fix.** I switched to the standard RFC 9381 ECVRF-EDWARDS25519-SHA512-TAI. Its hash-to-curve multiplies by the cofactor instead of asking "is this point valid?". I decode points and verify proofs with plain big-integer arithmetic, so libsodium's validation never decides the result. Proving still uses libsodium's constant-time code for the secret scalars. Every node checks the three RFC test vectors at startup and refuses to run if it can't reproduce them. Since validators had to agree on new outputs, I reset the testnet instead of shipping it.

**Lessons I took from it:**

- Don't let a library's "is valid" check define consensus behavior unless its exact semantics are pinned.

- The same version string doesn't mean the same behavior. Distro security backports change code without changing the version.

- Run fuzzers and tests on more than one OS image. Mine only caught this because CI used an older base image.

Happy to answer questions, and I'd welcome criticism of the approach. Code: github.com/FinalisCore/finalis-core (src/crypto/vrf.cpp)

Which one would be really more rational in terms of expected value?

I mean like "Liquidation failure" is protected, but "Market price movements" of the collateral aren't on their provider's website, I just don't get where is a difference.

Did anyone try this and run into a liqudation failure? If so how was it classified and why?

Hey everyone,

ECDSA remains widely implemented across asymmetric cryptosystems, but its existential dependency is an unpredictable, uniform ephemeral scalar: the nonce k must never repeat or exhibit bias under the same private key.

When an implementation relies on a broken pseudo-random number generator (such as flaws in random seed generation or low-entropy PRNGs), two signatures generated with an identical nonce allow algebraic recovery of the signer's private key via basic modular arithmetic.

I developed an open-source research tool called RSZ-Scanner to parse signature tuples (r, s), extract message digests (z), and identify nonce collisions across signature sets. Here is a brief mathematical overview of the recovery pipeline.

**Mathematical Model**

In standard ECDSA over secp256k1, a signature is the pair (r, s):

r = (k \* G)_x mod n
s = k\^(-1) \* (z + r \* d) mod n

Where:
\- G is the generator point of the elliptic curve group.
\- n is the group order.
\- d is the private scalar (secret key).
\- z is the cryptographic message hash truncated to group order length.
\- k is the ephemeral random scalar in \[1, n - 1\].

**Explicit Recovery on Identical Nonces (k1 = k2)**

If a public key signs two distinct message digests z1 and z2 using the exact same nonce k, both signatures share the identical r parameter:

s1 = k\^(-1) \* (z1 + r \* d) mod n
s2 = k\^(-1) \* (z2 + r \* d) mod n

Subtracting the equations eliminates the secret key d:

s1 - s2 = k\^(-1) \* (z1 - z2) mod n

Solving directly for the ephemeral secret k:

k = (z1 - z2) / (s1 - s2) mod n

Once k is known, the private key d is recovered via direct substitution:

d = (s1 \* k - z1) / r mod n

**Implementation Details: RSZ-Scanner**

RSZ-Scanner was written to demonstrate and evaluate this phenomenon against arbitrary signature dumps:

1. Tuple Extraction: Parses signature structures to extract raw (r, s, z) components.
   
2. Collision Detection: Maps and indexes unique r values against corresponding public keys to detect duplicate nonces across large datasets.
   
3. Modular Solver & Verification: Runs the inverse arithmetic above and validates the derived private scalar against the associated EC public point.
   

4. Discrete Log Search: Includes an implementation of the Baby-Step Giant-Step (BSGS) algorithm to handle bounded partial nonce leakage and small nonce offsets.

   **Repository & Discussion**

The implementation is open-source under the MIT license:
https://github.com/harshjamdar/RSZ-Scanner

I would appreciate feedback on:
\- Numerical optimizations for modular inverse computations when processing large batch sizes.
\- Extending BSGS search ranges or evaluating lattice-based attacks (Hidden Number Problem / Bleichenbacher-style lattices) for biased nonces.
\- Verifying edge-case handling around high-s malleable signatures.

Feedback, theoretical critiques, and contributions are welcome!

I've spent 22 years working in infrastructure and operations, and now run local AI workloads for production apps and creative projects. That background led me to a question about Bitcoin: how much of its resilience depends on being able to replace the machines securing it?

I developed this into a working paper, The Silicon Allocation Thesis. The idea is that AI demand could affect Bitcoin through competition for industrial resources: qualified fabrication capacity, chip-design teams and investment.

Bitcoin ASICs don't become AI accelerators. The possible competition is upstream, where some of the resources needed to produce different chips overlap. That overlap needs to be demonstrated for the specific process and production period; an AI memory shortage doesn't automatically mean a Bitcoin ASIC shortage.

The distinction I focus on is current hashrate versus the ability of independent miners to replenish it. A network could have substantial hashing capacity today while replacement equipment becomes harder to obtain or a future ASIC generation becomes less attractive to fund. Difficulty adjustment helps with block timing, but it cannot manufacture replacement hardware.

Whether that creates a security problem depends on who retains access. An outside attacker buying equipment may face the same shortage. An actor already holding hardware could benefit if independent miners struggle to replace lost capacity. Those are different threat scenarios.

There are also good reasons the effect might be small or go the other way. Foundries can expand. Contracts can protect supply. Older machines can remain competitive longer, helping existing miners. Slower hardware innovation alone doesn't prove weaker security.

The general concern has been raised before; the paper credits that prior work. My contribution is an attempt to connect allocation, hardware renewal and recovery in one framework, and spell out what evidence would support or contradict it. I haven't established that AI is currently reducing Bitcoin's security.

What would you measure to test this? Would procurement lead times and the time needed for independent operators to replace lost capacity tell us something that aggregate hashrate misses?

Full paper: https://paper.facundobarrera.me/silicon-allocation-thesis/

Archived version on Zenodo: https://doi.org/10.5281/zenodo.23557269

Disclosure: I'm the author. This is a theoretical working paper, not peer reviewed.

URGENT: President Trump is now aware of the Samourai Wallet developers and has stated he will be looking into a pardon. This is a rare opportunity to change the course of history, but we must keep the pressure on to ensure this gets across the finish line. More than ever, we need you to sign the petition and get your friends and family to do the same. Let's make sure they can't ignore us! See President Trump's comment here.

Feels like a lot of crypto apps still rely on separate group chats for everything from support to discussing what's happening onchain.

Would be pretty useful if more of that happened inside the apps themselves, especially when people are already interacting with contracts and using wallets.

Not saying every crypto app needs its own chat, but having messaging and onchain activity connected could open up some interesting possibilities.

Anyone seen projects doing this well or think it's just unnecessary extra stuff?

Hey everyone,

For the last couple of years, I’ve been working on an open-core communication project to solve a gap that kept bugging me.

Most E2EE messengers (Signal, SimpleX, Briar) are great at what they do, but they usually hit three walls:

1. They go completely dead the moment cell towers or ISPs go down.

2. Many still rely purely on classical elliptic-curve crypto, which is exposed to Harvest Now, Decrypt Later (HNDL) quantum threats.

3. They stop at text messages—the moment two people or businesses need to verify solvency, coordinate local mutual aid, or lock an agreement into escrow, they have to leave the chat and trust centralized middlemen or easily faked screenshots.

So we built Gossip (Boltalka) — a self-hostable, zero-knowledge communication platform with a Dual-Engine transport (Internet + Offline BLE Mesh) and an integrated Sovereign Economic Layer.

1. Post-Quantum & Zero-Knowledge Relay

The server acts as a blind cryptographic relay. Even if someone pulls the physical drives out of the host, there are no private keys, no plaintext metadata graphs, and no readable files.

- Hybrid Post-Quantum handshakes combining Curve25519 (X3DH + Double Ratchet) with NIST FIPS 203 ML-KEM-768 (Kyber).

- Group chats powered by PQ-MLS (RFC 9420) with logarithmic key rotation.

- Zero phone number / zero SIM card required: accounts use SRP-6a and 12-word BIP-39 recovery phrases. Keys stay strictly inside client hardware storage (WebCrypto / OPFS / Secure Enclave).

- Includes a Fake-TLS proxy to bypass Deep Packet Inspection (DPI) firewalls and binary attestation (SHA-256) to reject modified clients.

1. Offline Bluetooth Mesh (For off-grid & blackout resilience)

When the internet or cellular grid goes down, the app doesn't brick itself:

- It automatically drops down to custom L2 Bluetooth Low Energy (BLE) Mesh framing (0xFA21) stretching up to 10 km via multi-hop relays.

- Uses Trickle timers (RFC 6206) and CRDTs (LWW / OR-Set) so messages and emergency alerts hop device-to-device without causing broadcast storms or killing batteries.

- Uplink Bridging: if just one device on the edge of a blackout zone catches a weak satellite or cell signal, it acts as a blind Zstd-compressed bridge to sync encrypted mesh packets with the outside world.

1. The Sovereign Economic Layer (Zero-Knowledge Trust & B2B/P2P Settlement)

We built a native settlement layer right into the client so users and businesses can coordinate deals without leaking personal data (Zero-PII):

- Client-side Halo2 ZK-SNARKs (Pasta curves, no trusted setup): You can generate a mathematical Proof of Solvency and Proof of Deposit Age directly in WebAssembly—proving to a counterparty that you have sufficient, seasoned funds for a deal without revealing your actual balance, address, or transaction history.

- Blind O(1) Matchmaking: Broadcast local or B2B intents encoded into Uber H3 spatial hexagons and 128-bit BLAKE3 SimHashes. Matches counterparties in under 1.2 microseconds without exposing identities until a direct Curve25519 handshake occurs.

- 4-Phase Atomic DvP Escrow & Oracles: Staged smart-contract escrow (10-40-30-20 tranches) with collateral slashing and a 3-tier oracle bridge (AIS satellite ship telemetry, PAdES inspection certificates, TLSNotary 2PC-TLS web proofs, and 2-of-3 geo-stamped waybills).

Self-Hosting & Stack:

Backend runs on Python (FastAPI), Envoy, PostgreSQL, ScyllaDB, Redis, and Kafka. Clients are available for Web/PWA, Desktop (Electron), and Android (Capacitor). You can spin up a full node locally in a minute via Docker Compose.

I put the link to the GitHub repository and the RFC-001 through RFC-005 architectural specs in the first comment below so the post doesn't get eaten by the link filter. Would love to get your feedback!

Milestone 2: real signatures, real hashes, and one weakness we found in our own design.

GrahamBell caps every miner at 1 hash attempt per second. Last week's math assumed that cap can't be gamed. Milestone 2 tested it with real cryptography: real SHA-256 chains, real BLS signatures.

How it works: each round, a miner's header is locked with randomness made from its witnesses' signatures. Every attempt is chained to the last and tied to the next second. You can compute your whole chain instantly, but that only tells you WHEN you'll win. Witnesses sign only when their clocks reach that second, and validators reject blocks that arrive early.

So: can you re-roll the randomness instead?

→ Earlier versions of my design: yes. 4× faster with 4 tries, 15× with 16, 41× with 64.
→ Current design: 1.01× (95% CI 0.93–1.09). BLS signatures are unique, so re-signing gives the same randomness every time.

Also measured:
- Double headers in one round: 500/500 caught, zero false positives
- Old sort-before-hashing rule: 36 headers per hash → replaced with fixed field order
- Withholding a block to re-roll seat placement: ×1.10 at 10% of blocks, and it costs the attacker the block

The weakness we found, said openly:
A witness colluding with a miner can choose to sign or stay silent, giving the miner two randomness options: 1.88× per colluding witness. The fix is threshold BLS (any two-thirds produce the identical signature). Prototype: ~0.5 s setup per member at 40 members. Next stage tests it.

Locked before simulation:
- Pass/fail thresholds for all 9 hypotheses, dated
- Fork-choice loophole closed
- Witness double-signing now bannable

277 tests, 35 cross-checks, byte-identical on a second machine. Open source.

Full write-up: https://medium.com/@hurairahshamsi/can-an-attacker-cheat-the-clock-testing-grahambells-cryptographic-core-c82bea1a0aac

Code: https://github.com/HurairahShamsi/grahambell-simulation

Try to break it.

Next: Milestone 3, the issuance simulator.

Previous post 1: https://www.reddit.com/r/CryptoTechnology/s/k70ZHdfEZ6

Previous Post 2: https://www.reddit.com/r/CryptoTechnology/s/mn2pZD9hFw

Small proof-of-work coins keep getting reorged by people renting hashrate (Bitcoin Gold and Ethereum Classic were both hit more than once). I've been reading about the defenses that have been tried and I'm trying to understand which ones held up in practice:

- Checkpoints signed by developers (works, but adds a trusted party)

- Horizen's delayed-block penalty (penalizes chains that were hidden and published late)

- ETC's MESS (makes deep reorgs require exponentially more work) - Merged mining with a larger chain

- Just asking exchanges to wait for many more confirmations For people who have run or followed small chains: which of these actually stopped attacks, and what did they break? I'm especially curious whether the penalty approaches caused problems during honest network splits.

[ Removed by Reddit on account of violating the content policy. ]

I want to share an open-source Layer-1 protocol written in C++ called FinalisCore and get your architectural feedback. We recently launched our first public testnet (testnet-1).

Our goal is to combine a UTXO model with deterministic finality and privacy from the very first block.

Key Technical Features:

• Deterministic BFT Finality: Blocks are final once signed by a validator committee quorum. There are no chain reorgs and no waiting for multiple confirmations.

• Confidential Transactions: Outputs carry a Pedersen commitment with range proofs using the secp256k1-zkp library. Validators check that inputs and outputs balance without learning the amounts.

• Dynamic Committees: Validators bond coins to join. Committees are dynamically chosen per epoch (every 32 blocks) deterministically from finalized history.

• Tokenomics: Total supply is strictly capped at 7,000,000 FLS.

Questions for the Community:

1. What are the best optimization patterns you've deployed for batch-verifying Pedersen commitments under heavy validator loads to keep block times stable?

2. How do you efficiently handle mempool sync and stale input edge-cases in a UTXO model during rapid validator committee rotations?

The project is fully open source under the MIT license. You can check the code and technical documentation here:

• GitHub Repository: github.com

• Testnet Guide: github.com

(Note: This is a non-financial public testnet. Testnet coins have absolutely no monetary value and are used solely for protocol testing).

Looking forward to your critiques andd review!

Anyone else experienced this:

Price of BTC in there app on the chart 78k €, I sold and I was given price 73k€. 20 days later bitcoin fell down 5%, price on chart 74k€ I buy back for same money I sold earlier and I get much lower btc position… you sell high and they give you low sell rate. Scammers. Stay away !!!!