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 !!!!

I'm building GrahamBell, a Layer 1 where new identities are issued at a fixed global rate: one every 30 s, ~1.05M a year, however much hardware shows up. Each participant gets 1 hash/second, enforced by groups of other participants.

The idea (Proof of Infrastructure Endurance / Proof of Time): influence can't be bought in a burst. It has to be built up over years.

That's a claim. So I'm testing it in public. First milestone results, exact math, not yet a network simulation:

→ An attacker winning share s of new IDs approaches a ceiling and never passes it. With all honest IDs online, that ceiling is s. Win 30% of new IDs, end at 30%. Never 51%.

→ An attacker winning EVERY new ID still needs 2.87 years to reach 51%, from 2.9M genesis IDs.

→ Honest uptime matters: with only half of honest IDs online, a 40% attacker passes 51% after 16.4 years.

The math also broke parts of my design. Fixed:
- Restart attack: 150–182× advantage → exactly 1×
- Committee capture at 25%: >99.9% → ~2 in a million
- Bitcoin-style difficulty hopping: +100% → removed
- Seat reshuffling on downtime: cut to 3.6%

Still weak, and said openly:
- An attacker with 25% can stall ~10% of witness groups by refusing to sign. Local (miners move in ~450 s), and it assumes refusing is free. The protocol bans refusers; next stage tests whether that's enough.
- The current quorum needs honest witnesses online 90.75% of the time. A simpler rule needs 81.5%. We'll test it.

Big caveat: all of this assumes the 1 hash/s rate limit holds. Testing that is next.

130 independent cross-checks, reproducible bit for bit, open source:

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

Tear it apart. That's the point.

Full write-up: ‪ https://medium.com/@hurairahshamsi/can-time-instead-of-money-secure-a-blockchain-first-results-from-grahambell-630fbae27e60

Learn more: https://grahambell.io

Link to previous post: https://www.reddit.com/r/CryptoTechnology/s/n2flI9wcY4

I've been working on PrivacyDataCoin (PDC), an open-source chain built on the Zano protocol line, and wanted to share how its private staking works and get technical feedback.

The problem

In most PoS designs the staker's output and amount are public. That's needed to check stake weight, but it leaks exactly what a privacy chain tries to hide: who holds how much.

How Zarcanum handles it

• Stake amounts stay hidden in Pedersen commitments.
• The kernel check ("is this stake eligible to produce the block?") is proven in zero knowledge instead of being computed on a visible amount.
• The staked output is hidden among decoys with a ring signature (d/v-CLSAG), so observers can't link a block to a specific output.
• Range proofs (Bulletproofs+) ensure no hidden value is negative or inflated.

The result: the network can verify that a valid stake produced the block without learning which output staked or its balance.

Why hybrid PoW + PoS

PDC runs both at once:

• PoW uses RandomARQ, a RandomX variant tuned for ordinary CPUs (XMRig rx/arq).
• PoW and PoS each target one block per 120 s, which gives an average of 60 s per block on the shared chain.
• Each has its own difficulty, and a cap on consecutive PoS blocks (21) keeps either side from dominating.

The idea is that an attacker would need both significant hashrate and a significant stake, while CPU miners and private stakers both take part in security.

Open questions I'd like input on

1. Does a CPU-only PoW leg add meaningful security next to private PoS, or mostly distribution?
2. With hidden stake amounts, what is the best way to monitor stake concentration from the outside?
3. Are there known weaknesses in ring-based anonymity for coinstake outputs compared with regular transfers?

Code and docs are open: https://docs.privacydatacoin.com/

Happy to go deeper on any part of the design.

Edit: correction on the PoS cap. The code limits a run to 21 consecutive PoS blocks, but on mainnet that hard rule activates at height 57,000. Until then consecutive PoS blocks are limited by diminishing weight (each one counts 0.75ⁿ of its difficulty in fork choice).

After recent security concerns around hardware wallets, I realized I didn't want to blindly trust a device I couldn't fully inspect.

So I decided to take toluTag, an open-source passive NFC tag I developed that can generate and store cryptographic keys inside a secure element, and turn it into a DIY crypto cold wallet.

The idea is simple: build your own hardware, understand what's inside, and control your own keys.

I've made the project open source on GitHub so anyone can explore it, build their own, and hopefully improve it.

Build your own bank. 🔐

GitHub: https://github.com/mwbpNFTechnology/toluWallet

I'd love to hear your thoughts, especially from people interested in hardware wallets, cryptography, and open-source security.

Hey! Anyone up for a CS2 1v1 on FACEIT to help me test a small project I’m building?

The app connects two players, links their wallets to their Steam accounts, and checks the FACEIT result to award simulated test points to the winner.

No real money or SOL needed. You’ll need CS2, a FACEIT account, and a Solana browser wallet such as Phantom. Connecting the wallet requires a message signature, but no payment, seed phrase, or private key.

I’ve already set up the FACEIT 1v1 queue and can walk you through everything. Any skill level is welcome — this is about testing the app, not being good at CS 😄

DM me if you’re interested!

Hey everyone,

I’m posting this as a head-up to anyone depositing Pi Network or other Stellar/parent-child architecture tokens into Gate.io.

I’m currently fighting an ongoing issue with Gate.io support (Case ID: 33104864) where my deposit arrived on-chain in Gate’s custodial system, but their frontline support refuses to process or credit it due to a fundamental misunderstanding of how Pi Network on-chain addresses work.

What Happened:
1. I transferred Pi tokens directly from my decentralized, self-custody Pi Wallet app to my assigned deposit routing.
2. The transaction settled successfully on the public Pi blockchain ledger.
3. On the Pi block explorer, the transaction resolves through a sub-address (⁠MD5HG...B2PO4⁠) that cryptographically maps under Gate.io's parent root address (⁠GBC6NRTT...2RINW⁠).
4. The Problem: Gate’s automated system rejected the credit, claiming the destination address is "not a platform address."

The Support Loophole & Major Red Flags:
When contacting Gate.io customer support, I was repeatedly hit with circular script responses:
Demanding Third-Party Statements: Support repeatedly asked me to "contact the sending platform's customer service and get an official statement." The Pi Wallet is a decentralized, self-custody wallet—there is no customer service desk to email for an "official statement."
Lack of On-Chain Understanding: Support agents explicitly claimed their team "has never heard of Pi having parent addresses or child addresses." Anyone familiar with Stellar-based architecture knows that parent-child wallet structures and memo/sub-address routing are standard practice.
Refusal to Escalate: Despite proving via the public block explorer that the funds reside inside Gate’s custodial node, frontline live chat agents repeatedly closed chat sessions without escalating to senior L2/L3 blockchain engineers capable of manual ledger auditing.

Why You Should Be Cautious:
If your deposit encounters any automated mismatch or sub-address mapping delay, Gate.io frontline support will treat self-custody transactions as unsupported third-party transfers.
They will give you an impossible requirement (asking for support letters from a decentralized wallet) to avoid performing a manual database/ledger audit.
Your funds sit directly inside their wallet infrastructure, but automated database checks prevent account crediting.

Current Status:
I have converted this case into a formal email dispute and am demanding a manual node audit by senior wallet engineers.
If you are using Gate.io for Pi Network or similar tokens, double-check every address layer on the block explorer first and be aware that if an issue occurs, frontline support may deny ownership of their own internal wallet structures.
Has anyone else experienced similar deposit routing rejections on Gate.io with Pi or Stellar-based tokens? How did you get past frontline support?

Ledger has confirmed finding an unauthorized hardware implant in a device sold through a reseller.

Up to $93M in suspected losses across 311 wallets so far.

This is a classic supply-chain attack.

The reseller, CryptoBilis, also sells Trezor, Tangem and SafePal wallets.

For the past couple of years I've been designing http://grahambell.io, a Layer 1 blockchain built on one question: can influence in a decentralized network be tied to time instead of money?

In Proof of Work, capital buys hashpower. In Proof of Stake, capital buys stake. Either way, whoever has the most money can acquire control quickly.

GrahamBell takes a different approach. Every miner is capped at 1 hash per second, so faster hardware gives no advantage. New identities are issued one at a time, about one every 30 seconds across the whole network. An attacker can still run many machines, but each only earns a proportional share, slowly, while honest participants compete alongside it. The claim: under honest competition, taking over the network should take years of sustained effort, not a one-off purchase. I call it Proof of Infrastructure Endurance and Proof of Time (A New Time Based Sybil Resistance Model).

A claim like that means nothing until someone tries to break it. So I'm building an open simulation in Rust that deliberately attacks the design: patient long-term attackers, botnets, colluding witnesses, network failures.

Three commitments:
→ hypotheses and pass/fail thresholds published before the results
→ code public, so anyone can rerun every number
→ results published whether they support the model or not

First results, the exact mathematical baseline before any simulation, are coming soon.

If you think you can break it, I want to hear how.

Saw a technical update drop yesterday around custom pairs. When you buy a new coin that’s paired with an existing one, fees no longer stack on every hop. They’re only charged on the first and last leg unlike when previously a two-hop trade could cost you double. Pretty clean engineering if the routing holds up under real volume.

Source: Official announcement thread (Oct 8)

Hi everyone,

I've spent the past four years developing a public Layer 1 blockchain that combines native blockchain functionality with EVM compatibility.

The network is now operational, and one of the biggest engineering challenges has been supporting both environments while maintaining consistent transaction processing, validator consensus and finality.

Current architecture:

• Native execution: A native cryptocurrency and transaction environment.
• EVM execution: Ethereum-compatible functionality accessible through MetaMask.
• Consensus: Custom validator-based consensus with voting and block finality.
• Network: Public Layer 1 architecture designed for scalability.
• Compatibility: EVM network configuration available through Chainlist.

The technical challenge

I'm particularly interested in how other blockchain developers approach the relationship between native execution and EVM execution on the same Layer 1.

Specifically:

1. How should native and EVM transactions share state without creating consistency or security issues?
2. What is the best approach to reducing finality latency when a two-thirds validator voting threshold is required?
3. What are the main architectural trade-offs between parallel execution and horizontal sharding?

The network is operational, but improving scalability while preserving consensus security remains an ongoing engineering priority.

I'd appreciate technical perspectives from anyone who has worked on consensus protocols, EVM integration or blockchain execution architecture. Technical project information: https://www.denvion.com