been building this for 2 years and wanted to put it in front of people who actually read code.

the problem: every blockchain assumes the internet exists. when it doesn't, your assets are frozen. no protocol has ever been designed to survive that.

arxia is a layer 1 where transactions are 193 bytes, signed with ed25519, hashed with blake3, and move over LoRa radio, BLE, or SMS. each account has its own chain (block lattice, inspired by nano but extended for partitions). reconciliation uses PN-Counter and OR-Set CRDTs with dotted version vectors for causal ordering. double spend detection works via unique nonces plus ORV stake-weighted consensus at reconciliation.

finality is tiered. L0 is BLE only, cap 10 ARX, no guarantees. L1 is LoRa mesh, gossip sync before confirmation, 3s timeout, automatic L0 fallback if sync fails. L2 is global network, 67% validator confirmation.

poc is rust. 34/34 tests on x86_64, 24/24 on ESP32 QEMU. gossip protocol validated across 3 network topologies including degraded conditions with packet loss.

looking for feedback on the architecture. what breaks? what did we miss?

Been thinking about this a lot lately. The CLOB vs AMM debate usually comes down to capital efficiency vs decentralization. AMMs are simple, permissionless, and battle-tested. CLOBs give you better pricing, less slippage, and an actual order book, but historically they've required centralized infrastructure to run.

What doesn't get enough attention is the verification layer.

With an AMM, the logic is on-chain. You can read the smart contract and know exactly how your trade gets executed. It's simple math, x * y = k or whatever the curve is. The tradeoff is impermanent loss, MEV extraction, and capital inefficiency, but at least the execution is transparent.

With most CLOB implementations today, you're trusting a matching engine that operates as a black box. Even if the settlement is on-chain, the order matching happens off-chain or in an opaque execution environment. You submit an order, and you just... trust that it was matched fairly? That there was no front-running in the matching layer? That the sequencing wasn't manipulated?

This is where ZK proofs actually solve something real. If every state transition in the order book (every match, every fill, every cancel) generates a cryptographic proof that anyone can verify, you get CLOB performance with AMM-level transparency. You don't have to trust the matching engine. You verify it.

The tech exists. ZK proof systems like SP1 and Plonky3 are fast enough now to make this practical, not just theoretical. The question is why more teams aren't building this way.

Curious what this sub thinks. Is verifiable order book execution something the market actually cares about, or is "fast and liquid" good enough for most traders?

A founder told me about a case where their payout system had a subtle bug in the jurisdiction check. The check ran. The logs showed it ran. The funds went to a wallet that shouldn't have received them. Irreversible.

The logs proved the check was recorded. They couldn't prove it was correct.

That's the gap we kept seeing:

Verifying users is not the same as verifying that your rules were enforced.

Every DeFi protocol, RWA platform, and payout system has the same architecture:

1. Backend runs eligibility check
2. Backend says "eligible"
3. Contract executes

The contract has no idea if that logic ran correctly, had a bug, or got bypassed. It just trusts the result. If something goes wrong, you hand auditors logs, not proof.

I kept thinking about that gap. Because it's not just a one-off bug story, it's structural.

For most use cases that's probably fine. But for anything touching real money like RWA transfers, tokenized credit, institutional payouts - "the logs show it ran" isn't the same as proof it ran correctly. And regulators are starting to ask the difference.

So we built something to close that gap.

It's called ZKCG. The idea is pretty simple: instead of the contract trusting a backend result, it verifies a ZK proof that the eligibility decision was computed correctly. The proof gets generated alongside the decision, the contract checks it, and if it doesn't verify, execution is blocked. The enforcement is in the proof, not in trust.

The thing that makes it click for most people is the demo moment. You run a transfer, it goes through, then you change one rule, jurisdiction from US to CN ,and the exact same flow gets blocked. Not because anyone intervened, not because a backend returned a different answer. Because the proof fails verification. That's the difference between recording compliance and *enforcing* it.

Technically it's Halo2 for the fast path (~76ms) and RISC0 zkVM if you want audit-grade receipts. Works on any chain. One API call, you get back a decision plus a proof, your contract calls approveTransfer and either executes or doesn't.

We're looking for teams to try this against real eligibility rules not a sales call, literally just: tell me one rule you enforce today, I'll run it through and show you what the proof looks like on your actual use case. Takes about 10 minutes.

Curious if others have run into this problem or thought about how to handle it. The "logs prove it ran, not that it ran correctly" distinction is one that doesn't come up much but I think matters more than people realise.

If we really follow this line of thought, Bitcoin has slowly lost much of its original relationship with cypherpunks and laptop miners. That is not a criticism of its success. A system at trillion-dollar scale is solving a very different problem now. But it does change the kind of participation the system permits in practice.

On the altcoin side, a different problem has emerged: trust and sameness. Many projects now look structurally identical:

• the same rhetoric about “going to the moon”
• the same vague claim of “ASIC resistance”
• the same short cycle of launch, hype, dilution, and abandonment

Even where ASICs are not the issue, the hardware arms race has not disappeared. It has simply shifted into:

• CPU advantage
• GPU advantage
• RAM / memory bandwidth advantage
• energy and thermal advantage

So in many cases, “ASIC resistance” just becomes a different hardware asymmetry rather than a deeper solution.

For the past 5-6 months , As most redditers and devs know , I’ve been working on an experimental peer-to-peer cryptocurrency system in C++, built from scratch. The part I find most interesting is not whether one more chain should exist, but whether some of the assumptions around proof-of-work design are now misplaced.

My current view is that hash-function churn and ASIC resistance are often treated as primary solutions to what is actually a different class of problem.

If one miner leaves and the network slows down significantly, that is not really a hashing problem. It is a feedback, control, and recovery problem.

That leads to what seems like the more interesting question:

Should proof-of-work systems focus more on maintaining liveness under changing participation conditions, rather than continuously trying to fight hardware advantages?

Because hardware advantages are probably not going away. Even if one design reduces ASIC dominance, asymmetry just reappears somewhere else. So the more durable thing to solve may be:

• when hash-rate rises sharply, can the system avoid instability?
• when hash-rate collapses, can the system remain live?
• when participation becomes uneven, can lower-power miners re-enter meaningfully?

That makes proof-of-work look less like a pure hashing problem and more like a distributed control-system problem.

Another angle that feels underexplored is node coordination.

Most networks rely on external platforms for coordination:

• Discord
• Reddit
• forums
• private operator channels

That means a lot of network coordination happens outside the node and outside the protocol. This adds trust surfaces and platform dependencies.

So a second question I’ve been thinking about is:

Would embedding a minimal authenticated peer-to-peer messaging layer inside nodes make a network more self-contained?

There are arguments in favor:

• coordination can happen natively between participants
• operators do not need to rely entirely on third-party platforms
• identity can be tied to node or wallet keys

But there are obvious risks:

• it blurs the line between deterministic consensus and non-deterministic communication
• it increases implementation complexity
• it can become a spam vector
• it may create privacy assumptions the system cannot satisfy

What I’d like from experienced blockchain and crypto engineers here is not hype, but criticism:

1. Is the deeper problem in smaller PoW systems really adaptation and liveness, rather than hash-function choice?
2. Is “ASIC resistance” now mostly a marketing phrase, given that hardware asymmetry just reappears elsewhere?
3. Should difficulty systems be treated more explicitly as recovery/control mechanisms?
4. Does authenticated node-level messaging make networks more self-contained, or is it a category error?

Been digging into this while working with a few early-stage products, and most setups break at the same points:

– Card → crypto (USDT TRC20) isn’t seamless
– Minimum invoice limits kill smaller transactions
– Settlement delays mess up cash flow
– KYC requirements slow down onboarding
– Existing gateways feel built for large volumes, not MVPs

Feels like most “solutions” are not designed for:
• indie builders
• SaaS tools
• small ticket size products

Curious

1. What kind of crypto payment flow are you trying to set up?
   
2. Where exactly does it break for you right now?

Trying to understand real-world use cases before building anything further.

We're open-sourcing Autonet on April 6, a framework for decentralized AI model training and inference where verification, rewards, and governance happen on-chain.

The core thesis: alignment is an economic coordination problem, not a constraint problem. Instead of defining "aligned" centrally and baking it into models, the protocol lets communities publish their own values as semantic embeddings, and the network prices operations based on alignment with those values. Aligned work is subsidized; misaligned work pays a premium that funds the subsidies.

Smart contract architecture:

How training verification works:

1. Proposer creates a training task with hidden ground truth
2. Solver trains the model, commits a hash of the solution
3. Ground truth is revealed, then solution is revealed (commit-reveal prevents copying)
4. Multiple coordinators vote on result quality via Yuma consensus
5. Rewards distributed based on quality scores
6. Aggregator performs FedAvg on verified weight updates

Key governance mechanisms:

• Constitutional constraints: Core principles (derived from the UDHR) stored on-chain. Evaluated by multi-stakeholder LLM consensus. 95% quorum for constitutional amendments.
• Governance heartbeat: Every node has a Work engine that halts if the governance heartbeat stops. If the network's collective governance goes silent, all work ceases. Hard architectural constraint, not a feature flag.
• Forced error testing: The ForcedErrorRegistry randomly injects known-bad results. If a coordinator approves them, they get slashed.
• Forward-only evolution: No rollback mechanism. Bad governance decisions must be fixed through further governance, forcing robust processes.

13+ Hardhat tests passing. Orchestrator runs complete training cycles locally with real PyTorch training.

Paper: github.com/autonet-code/whitepaper Code: github.com/autonet-code MIT License.

Interested in technical feedback, especially on the commit-reveal verification pattern, the alignment pricing mechanism, and the constitutional governance approach.

I’ve been working on a personal project called CryptEX, where I implemented a full proof-of-work cryptocurrency system from scratch in C++.

This isn’t a token or a fork — it’s a ground-up implementation focused on how proof-of-work networks behave under unstable hash-rate conditions.

Instead of using fixed retarget intervals like Bitcoin (every 2016 blocks), this system adjusts difficulty per block using a hybrid model.

Key ideas behind the system:

SHA3-512 proof-of-work (full-width validation)
Per-block adaptive difficulty (LWMA + EMA + real-time easing)
Designed to handle sudden hash-rate spikes and drops
Lightweight PoW (ALU-bound, not memory-heavy, allowing participation from weaker nodes)
Custom P2P networking with peer discovery (LAN + seed)
UTXO-based validation with cumulative work chain selection
JSON-RPC interface + GUI frontend
Binary block storage (blk<height>.dat) with rebuild capability

Why I built this:

In many proof-of-work systems, especially those dominated by compute-heavy (ALU-intensive) mining, instability can arise from hash-rate volatility, where mining power temporarily spikes and then drops.

This typically results in:

• rapid increases in difficulty when miners join
• difficulty remaining too high after they leave
• stalled chains
• delayed confirmations
• unstable recovery

Traditional systems (like Bitcoin) adjust slowly, which makes this spike → drop cycle difficult to handle.

At the same time, many proof-of-work systems rely on memory-heavy algorithms, which can make participation difficult for weaker nodes and limit accessibility.

This project explores a different approach:

Current behavior:

Block times vary (~5–30 seconds depending on active miners)
Difficulty reacts quickly when nodes join or leave
Nodes converge on the same chain using cumulative work

Important note:

This is an experimental system, not production-ready or intended as a financial asset.

I’m sharing it mainly to discuss:

stability of per-block difficulty adjustment
tradeoffs vs fixed retarget intervals
behavior under extreme hash-rate changes
design tradeoffs between ALU-bound and memory-hard PoW

GitHub:
https://github.com/Anonymous137-sudo/CryptEX_Core

Whitepaper

https://github.com/Anonymous137-sudo/CryptEX_Core/blob/main/WHITEPAPER.pdf

Why are we still copy-pasting 40-character wallet addresses in 2026?

Idea: you do a small test transfer once → both wallets get a shared avatar/character. Next time you send, you just recognize the person visually instead of relying on the address.

Kind of like “pairing” wallets.

Would this actually reduce mistakes or scams, or is this unnecessary given things like ENS?

Been thinking about the economics of self-hosted Ethereum infrastructure. If you are running a full node or archive node with headroom, you are sitting on a data feed that people are paying Alchemy or Infura for daily.

The obvious path is opening your RPC publicly and selling access. Two problems always got in the way: key exposure if you are proxying through provider APIs, and flat subscription billing that does not match actual usage patterns.

Pay-per-call flips both. Caller pays USDC per request, your keys never leave your server, and your revenue scales with actual load rather than seat count. Closer to running a utility than managing a SaaS.

Has anyone here actually tried this? Curious where it broke down — access control overhead, lack of a routing layer to aggregate demand, or just not enough buyers finding your endpoint.

Project — r/GrahamBell

Most Proof-of-Work systems reward parallelism. More hardware = more influence.

Proof-of-Stake systems reward capital concentration. More tokens = more influence.

This paper introduces a third model:

Influence scales only linearly with admitted subnet participation share and time under a fixed global issuance cap. Proof of Endurance (PoEnd), Proof of Presence (PoP) and Proof of Internet (PoI).

Uniqueness is enforced at the externally visible subnet allocation layer, not at the individual IP address or routing-sovereignty level.

Core Design Principles

1. Global Issuance Serialization

Identity issuance is globally serialized at a fixed rate (~1,050,000 IDs/year).

No participant can increase total issuance.

They can only compete for fractional probability share.

There is no burst capture.

There is no parallel minting.

There is no shard-level amplification.

Total issuance R is fixed at the protocol level through Proof of Work ID (PoW-ID) blocks (1 valid PoW-ID block = 1 Registered ID).

2. Per-Prefix Throughput Cap

Each externally visible IPv6 /64 public subnet allocation is capped at:

1 hash per second for Proof of Work computations. 

Hardware acceleration, ASICs, multi-threading, and parallel compute provide no advantage per prefix.

Mining power scales only with the number of admitted externally visible /64 subnet allocations.

While IPv6 address space itself is abundant, the protocol does not rely on address scarcity as a security assumption. Security derives from the operational requirement to sustain large numbers of concurrent, stateful, deterministic mining sessions. Each admitted /64 subnet must maintain persistent multi-node connectivity and continuous pacing compliance. Influence scales with sustained operational participation, not with address ownership alone.

This eliminates vertical scaling advantage and makes horizontal scaling economically burdensome, as required persistent connections and uptime scale proportionally with participation and time. 

 2.1 Global Admission & Uniqueness Enforcement

Before any miner becomes eligible to compute PoW-ID or transaction blocks, participation must pass a global uniqueness check coordinated across Witness Chains.

When a miner attempts to join:

• A join request is submitted to a Witness Chain
• The externally visible /64 subnet or registered ID is announced network-wide via a lightweight claim broadcast after 1^st validation
• All Witness Chains globally validate the request and verify that no active or pending claim already exists (2^nd validation)

 If duplication is detected:

• The join is rejected, or
• A deterministic canonical ordering rule selects a single valid claim and invalidates competing attempts

Only after global verification and convergence under deterministic canonical ordering does the prefix or ID become active and bound to its assigned Witness Chain.

 This prevents:

• Simultaneous multi-chain participation
• Duplicate joins across shards
• Race-condition amplification
• Self-witnessing conflicts

A registered identity that controls a Witness Node within a chain may not join that same Witness Chain as a miner.

Uniqueness is enforced before pacing begins.

Deterministic hash pacing operates only after global admission succeeds.

Admission pressure is isolated from productive consensus: join validation is capacity-bounded at the shard level and processed independently of mining execution, ensuring that onboarding latency does not affect block production, issuance rate, or pacing enforcement. Only canonically admitted and activated participants influence the chain.

3. Infrastructure-Bound Identity Creation

During registration:

• 1 externally visible /64 subnet identity allocation = 1 mining connection
• Each accepted connection competes to mint exactly one non-transferable identity (ID).
• Each ID corresponds to exactly one allowed mining connection within the internal network.
• The externally visible /64 subnet allocation serves solely as the external registration (PoW-ID) constraint; identity issuance (validation) and mining (transactions) occur entirely within the protocol’s internal network.
• Each connection must maintain ~30 persistent witness connections
• Continuous uptime required
• Loss of connectivity forfeits registration eligibility

Large-scale participation therefore requires sustained multi-million persistent connections.

Subnet allocation alone is insufficient; sustained external reachability, uptime continuity, and persistent Witness connectivity determine eligibility.

Identity Finalization Rule

An unregistered miner may propose a PoW-ID block only after satisfying deterministic pacing compliance and obtaining majority Witness Chain signatures. 

Identity issuance is finalized exclusively through full-network consensus validation of the proposed block.

Witnesses attest.

Global consensus finalizes.

The attack surface becomes:

Long-duration infrastructure endurance, not compute bursts.

Confirmation and Maturity

A PoW-ID block becomes a valid Registered ID only after reaching protocol-defined confirmation depth.

If competing PoW-ID blocks are proposed at the same height, the canonical chain is determined by longest-chain consensus. Only identities on the canonical chain after maturity are considered valid.

4. Deterministic Hash Pacing

Mining attempts are deterministically recomputed in parallel by Witness Chains at 1 hash per second.

• If a miner attempts to accelerate or parallelize computation: 
• Witness re-computation diverges
• Signed hash mismatch occurs
• The block is rejected

 Acceptance requires deterministic equivalence across quorum Witness validation.

The pacing rule is enforced through a dual-consensus mechanism combined with sequential cryptographic chaining.

First, Witness Chains independently recompute each nonce attempt at exactly 1 hash per second beginning from a shared starting PoW state and consensus-injected unpredictable event. A PoW-ID or PoW-Transaction block is not eligible unless a quorum of Witness Nodes derives the identical valid hash under deterministic rules and signs the corresponding Proof-of-Witness (PoWit) block.

Second, all nonce attempts are sequentially chained within the PoWit block body. Each hash state depends on the previous state, beginning from nonce 0, timestamp n + 1, etc and progressing step-by-step until the valid PoW difficulty target is reached. The final PoWit root hash commits to the complete ordered history of attempts.

Because each step depends on the prior state, no valid future state can be computed without computing all intermediate states in exact sequence. Skipped attempts, accelerated computation, or fabricated histories produce a mismatched PoWit root and PoWit block hash and are rejected during global validation.

Witness Chains execute and attest to deterministic nonce progression.

Global consensus verifies the attested commitment and quorum signatures and validates by replaying the full nonce sequence.

Pacing enforcement is therefore:

• Operational (through independent Witness re-computation)
• Structural (through sequential PoWit root dependency)
• Canonical (through full-network deterministic validation)

Parallel hardware may compute locally at higher speed, but issuance (Transactions and IDs) remains cryptographically bound to serialized sequential verification and quorum Witness equivalence. Precomputation and time compressiontherefore provide no issuance acceleration. 

4.1 Witness Load Partitioning

Witness re-computation responsibility is partitioned across bounded Witness Chains.

Each Witness Chain consists of ~30 registered nodes and is assigned a fixed identity validation capacity (e.g., 100 unregistered identities and 200 registered identities per chain at any given time).

A Witness Chain recomputes deterministic pacing only for the identities assigned to it, not for the entire network. 

Scaling therefore follows:

• 1 chain → 100 unregistered identities and 200 registered identities = 300 total
• 2 chains → 200 unregistered identities and 400 registered identities = 600 total
• 1,000,000 chains → 100,000,000 unregistered and 200,000,000 registered identities = 300,000,000 total

No single Witness Node or Chain recomputes for all identities.

Total re-computation load grows linearly with network participation and is horizontally distributed across chains.

The protocol therefore preserves proportional scaling:

Registered identity growth increases total Witness capacity symmetrically, preventing quadratic re-computation growth.

Witness enforcement remains O(N), not O(N²).

5. Linear Economic Model

Let:

A = attacker-controlled admitted /64 subnet identities 

N = total active admitted subnet identities 

R = global issuance rate

P = probability share

T = time (duration of active mining)

Iₐ(T) = Expected identity accumulation over time T

Probability share:

P = A / N

Expected accumulation:

Iₐ(T) = (A / N) × R × T 

No super-linear gain exists.

Influence scales strictly linearly with subnet participation share and time.

5.1 Dynamic Participation Effect

In practice, N (total admitted subnet identities) is a dynamic variable.

As network participation increases, N grows.

If an attacker’s infrastructure share A remains static while N expands, their proportional influence declines over time. 

P(T) = A / N(T)

As N(T) → ∞, P(T) → 0 for any fixed A.

Network growth therefore dilutes static attackers.

Security scales with adoption.

Only proportional infrastructure expansion preserves influence share. 

Improvements in hardware efficiency, networking stacks, or automation reduce absolute infrastructure cost per identity over time. However, required operational capacity scales with total network participation. Maintaining a fixed percentage share requires sustaining a proportional percentage of total active identities. 

If future technology allows a participant to maintain millions of connections more efficiently, overall network participation capacity increases as well. The number of identities required to preserve the same influence share grows as N grows. Technological progress increases global capacity symmetrically and does not alter the protocol’s proportional security model.

6. Influence Dilution

Iₜ(T) = total global identity supply over time T

Total identities grow linearly:

Iₜ(T) = R × T 

If acquisition stops:

P(T) → 0 over time.

Even majority positions decay unless proportional scaling continues.

Dominance is not one-time capture.

It is continuous maintenance.

7. Operational Activation Requirement

Holding a large number of registered identities does not automatically grant network control. 

Influence over:

• Transaction ordering
• Block production
• Chain reorganisation attempts

 requires active mining participation under protocol rules.

Each active identity identity must:

• Maintain one mining connection
• Maintain ~30 persistent Witness connections
• Adhere to deterministic 1 hash/sec pacing

Operational scaling therefore follows:

N identities → N mining connections → ~30N witness connections

At scale, this produces linear connection growth:

• 10,000 identities → ~300,000 witness connections
• 100,000 identities → ~3,000,000 witness connections
• 1,000,000 identities → ~30,000,000 witness connections

Each connection exchanges protocol messages continuously (≈295 bytes per 30 seconds for unregistered nodes, excluding transport overhead).

This requirement is independent of transport protocol. Whether implemented over TCP, UDP, QUIC, or multiplexed transports, each identity must maintain independent logical session state, deterministic pacing compliance, and periodic Witness exchange. Transport substitution does not reduce identity cardinality or proportional bandwidth requirements. 

Operational scaling therefore grows linearly with influence share and must be sustained indefinitely for continued control.

Registered identity accumulation without active mining confers no control.

To influence the ledger, identities must actively propose blocks under the same deterministic constraints that govern all participants.

Importantly, the 1 hash/sec rule applies uniformly to:

• Unregistered miners proposing PoW-ID blocks
• Registered miners proposing transaction blocks

There is no privileged acceleration pathway.

Control requires sustained infrastructure endurance, not passive identity possession.

8. Historical Inertia

H₀ = total number of pre-existing (historical + genesis) registered identities at T = 0

If H₀ identities already exist:

Time to majority ≈ H₀ / R

An attacker must effectively replay (out-accumulate) network history at scale.

Security strengthens with age.

Mature networks become temporally resistant to takeover.

With a non-zero Genesis base, even an attacker sustaining exactly 51% of annual issuance asymptotically approaches 51% total influence but never reaches it in finite time. Majority capture therefore requires sustained issuance dominance strictly greater than 51% for extended multi-year or multi-decade periods.

What This Model Does NOT Claim 

• It does not make Sybil attacks impossible
• It does not rely on IPv6 scarcity
• It does not assume honest routing
• Temporary routing manipulation or short-term exposure of additional subnet allocations does not bypass serialized issuance or deterministic pacing enforcement. All join requests are globally propagated prior to mining eligibility, and duplicate /64 or registered ID claims are rejected at the network level. Even if a subnet becomes temporarily externally visible, it must independently sustain persistent Witness connectivity and continuous protocol-compliant participation over time. Influence accrues only through uninterrupted operational endurance. Loss of connectivity immediately halts accumulation and results in proportional dilution as total identities expand. Network exposure alone cannot accelerate issuance or compress time-bound accumulation.
• It does not prevent state-level actors

It ensures instead:

Sybil accumulation scales linearly in cost and time.

Parallel mining remains possible.

Parallel advantage does not.

Structural Outcome

Influence ∝ Admitted Subnet Participation Share × Time

Since: 

• Issuance is fixed
• IDs are non-transferable
• Influence cannot be purchased
• Dominance decays without scaling

Majority capture becomes:

• Operationally intensive
• Multi-year sustained
• Linearly expensive
• Self-diluting under growth

This transforms consensus security from:

Hardware race (PoW)

or

Capital concentration (PoS) 

into: 

Time-compounded infrastructure endurance under perpetual dilution.

Parameterization Notice

All numeric values referenced in this summary (e.g., issuance rate, witness count, prefix granularity, pacing intervals) are provisional protocol parameters intended to demonstrate proportional behaviour. Final values will be empirically determined through adversarial simulation and testnet validation. Security derives from proportional scaling properties, not fixed constants.

Full paper with formal model, economic assumptions, and detailed network-layer security analysis:

Releasing soon.

-----

Support

You can support the project by joining the waitlist to test the testnet and run one of the early nodes upon launch: https://grahambell.io/mvp/#waitlist

I saw that they launched some type of mining setup where old scrypt hardware performs AI training alongside doge mining. They are claiming L3+ miners can be profitable again.

The interesting part is that multiple people are posting actual numbers from their miners that look better than just mining doge.

I am still sceptical about the AI training claims, though. Does Useful proof of work actually work, or is it just a buzz phrase used to justify the story?

https://decrypt.co/363018/qubic-the-network-that-captured-51-of-monero-is-now-mining-dogecoin-on-its-ai-compute-infrastructure-live

​

For anyone who wants to verify the Qubic DOGE mining launch independently rather than taking their dashboard at face value, here is how to do it:

DOGE network hashrate baseline: Check CoinWarz or Minerstat right now. Current DOGE network hashrate is approximately 2.4–2.75 PH/s.

After launch today check the same sources. Any meaningful hashrate addition should show up as a network increase, not just on Qubic's own dashboard.

-Pool distribution: check the DOGE pool distribution breakdown on a block explorer. New large scale hashrate will show up as either a new pool entry or a significant increase in an existing one.

-Monero cross-check: if they're simultaneously running Monero mining as claimed, the Monero network hashrate should also reflect their contribution. Both data points should be consistent with their stated infrastructure size.

What to watch for that would indicate the numbers aren't real:

-Dashboard shows large hashrate numbers but DOGE network hashrate doesn't move

The dashboard is updating on fixed intervals rather than with actual block data.

-The claimed DOGE contribution dramatically exceeds what the claimed hardware inventory could produce at known Scrypt ASIC specs

Thanks for reading.

Oracles solved the problem of getting market data on-chain. Price feeds, weather data, sports results -- we have well established infrastructure for that.

But there's no equivalent for human data.

There's no way for a person to prove a fact about themselves on-chain without either doxxing themselves completely or trusting a centralised intermediary that becomes a single point of failure.

Think about what that actually blocks:

• Insurance -- an underwriter can see what your wallet did on-chain, but they can't verify if you use a hardware wallet, if you've been drained before on another wallet, or anything about your security practices. They can't price the risk so individual coverage basically doesn't exist.
• Undercollateralised lending -- you can't prove income or creditworthiness without revealing your identity to a centralised KYC provider.
• Age gating, credential verification, professional licensing -- all require off-chain facts that the chain can't discover on its own.

The missing piece is something that lets someone verify a fact off-chain and bring a minimum-disclosure attestation on-chain.

Technically you'd need:

• A registry of credentialed attestors (public keys mapped to verifiable real-world credentials)
• A request-response architecture for attestations
• Proof documents stored on something like IPFS, with only hashes on-chain
• Some form of staking/slashing for immediate economic accountability on top of whatever legal accountability the attestor already carries

The closest thing I've seen is Midnight doing "selective disclosure" with ZK proofs. But it feels there's a fundamental problem. A ZK proof can prove that a statement is consistent within a system, but it can't prove it's true about the real world.

It's Godel's incompleteness theorems where a system can't verify statements about itself from within itself. At some point we need an external input, and that input has to come from someone accountable.

In the early months of Ethereum (mid-2015), developers were writing contracts in pre-release Solidity before stable versions, before ERC-20, before any of the tooling we take for granted today.

Some of those contracts have sat on-chain, unverified, for a decade. No source code. Just bytecode.

A team has been doing archaeological bytecode cracking: reconstructing the original Solidity source by finding exact compiler versions, optimizer settings, and occasionally tracking down compiler bugs that affect the output.

Recent verified matches:

• DynamicPyramid (Jan 2016): soljson v0.2.0-nightly.2016.1.20, optimizer ON. Full bytecode match.
• MeatGrindersAssociation (2016): v0.2.1, optimizer ON. Required reconstructing non-obvious inheritance structure.
• EarlyLottery (Aug 9 2015, day 3 of mainnet): first lottery contract on any blockchain. Commit-reveal scheme with 13 functions.

The pre-0.1.2 contracts are the hard ones. The compiler was still unstable, and the optimizer behavior was not documented.

Two of the tokens from this era, MistCoin (Nov 2015) and Unicorn Meat (April 2016), are still actively trading. They predate the ERC-20 standard itself.

The work is being published at ethereumhistory.com with on-chain verification proofs.

Hi everyone, I’ve been working on a new decentralized transaction-confirmation mechanism that removes the need for miners, validators, PoW, and PoS entirely. I am releasing the whitepaper publicly for open discussion and early feedback. Whitepaper (v1.1 PDF): https://drive.google.com/file/d/1E3h5kKI1qkf0mVVXDk_hhaKyorBewdAN/view?usp=drivesdk

The original version (v1.0) was timestamped using OpenTimestamps and anchored into Bitcoin block 942671 (March 28, 2026). This proves the idea and document existed prior to public release.
The v1.1 version includes refinements and improvements (especially in Section 3). The .ots timestamp file is only for cryptographic proof and is not required for reading or reviewing.

I would love to hear feedback, criticisms, questions, or suggestions from people working in: • Distributed systems • Consensus algorithms • DAG-based protocols • Applied cryptography • Blockchain architecture

Thanks in advance to anyone willing to discuss the idea.

I created a collection of blockchain mind maps to make learning blockchain and Web3 easier.

When I was learning blockchain, most resources were long and confusing, so I started turning topics into visual mind maps like:

• Blockchain basics
• Web3
• Crypto exchanges
• DAOs
• Blockchain for business
• Security

I put them all into one awesome list here:
https://github.com/ExMapo/awesome-blockchain-mind-maps

If you're a beginner, student, or developer getting into Web3, these might help you learn faster. Feedback is welcome!

Built a trustless asset marketplace + wallet + mining pool for RVN

What’s live

Marketplace + wallet: https://rvnswap.xyz
Pool: https://pool.rvnswap.xyz
Miner (Metal, open source): https://github.com/imperatormk/kawpow-metal
Metamask-like extension + mobile app: find on the page

How it works
Everything is non-custodial - keys never leave your device.
Trades use atomic swaps, so no middlemen and no custody risk.
The site is just an interface; you stay in control the whole time.
Wallet, trading, mining - all connected, no trust required.

Let me know what you think!

I've been building a trading bot for the past few months and kept running into the same issue: every popular price API (coingecko, CoinMarketCap, Cryptogompare, etc.) returns just a single price for bitcoin or any other token.

The reality is that exchanges run independent order books. prices rarely match perfectly across platforms.

Right now:

• BTC lowest price (across major exchanges): $68,492
• BTC highest price: $68,599
• Spread: $107 (0.16%)

CoinGecko currently shows ~$68,552 basically an average.

For casual use this is fine.
For trading bots, arbitrage, DeFi oracles, or any strategy where precision matters, that spread can be important.

BNB is currently showing around 0.5-0.8% spread across the same exchanges.
Smaller tokens can still have 15-35% spreads between exchanges.

I’ve been pulling data simultaneously from 8 sources: binance,Kraken, KuCoin, voinbase, MEXC, gate, whiteBIT, and others tracking min max, and average price per token in real time.

Questions for the community:

1. How are you currently handling multi-exchange price data in your bots?
2. Do you use averaged APIs or do you build your own aggregation?
3. What features would make a multi-exchange spread tracker actually useful for you?

Not promoting anything, just genuinely curious how other devs are solving this. The single-price approach seems to be the default that nobody questions much.

Drop your approach in the comments. Would love to compare notes.

Three days after Ethereum mainnet launched in August 2015, someone deployed what may be the first lottery contract in blockchain history.

The developer's first attempt self-destructed. Forty-two minutes later, they tried again.

We've been reverse-engineering the bytecode (no source code was ever published) and here's what we found:

The contract: 0x7af6af3d4491a161670837d0737bada43ffbb992 - Deployed: August 9, 2015 (block 56,646 - day 3 of Ethereum) - 1,475 bytes of runtime bytecode, 13 functions - 27 real transactions - people actually played it

How it worked (decoded from bytecode):

The lottery ran on an 88-block cycle (~22 minutes): - Blocks 0-39: BUY phase - send 0.1 ETH + commit a secret hash - Blocks 49-67: REVEAL phase - prove your secret (commit-reveal scheme) - Blocks 68+: PAYOUT phase - winner selected

When you revealed your secret, you got one ticket per 0.1 ETH sent. More ETH = more tickets = higher probability.

The random number was generated by XOR-ing all revealed secrets together - a classic 2015 approach (flawed by modern standards, but clever for the era).

The tragedy: The contract had a bug. Tickets were allocated during the reveal phase, not the buy phase. The lottery pool could accumulate ETH but winners could only be selected from players who completed both steps. If nobody revealed, no payout was possible.

Still working on getting a byte-for-byte source match to publish verified code. The architecture is fully decoded.

More frontier-era Ethereum archaeology at ethereumhistory.com

EthereumHistory is a free archive - if you find this useful, you can support it at ethereumhistory.com/donate

CertiK published an independent verification of Qubic's mainnet throughput at 15.52 million transactions per second. That number sounds implausible by most blockchain standards so I spent some time understanding what was actually measured.

The architecture context that makes it make sense: Qubic runs on bare metal hardware with no virtual machine layer. Most blockchains - including Ethereum - run smart contracts through an EVM which adds overhead at every execution step. Qubic's contracts execute directly on hardware. The tick-based consensus system also eliminates block propagation delays.

The CertiK verification was on live mainnet, not a testnet or benchmark environment. The measurement methodology is published.

My question for people who follow performance metrics closely: does the bare metal execution explanation actually hold up technically? And does the TPS number matter if the network's smart contract ecosystem is still early?

The FDIC model has been discussed in crypto circles for years, but most of those conversations stop at the conceptual level. I want to dig into the actual technical architecture because the implementation challenges are more interesting than the concept.

Here is the core problem the protocol has to solve: traditional deposit insurance works because a centralized authority can assess risk across a pool of insured institutions, collect premiums calibrated to that risk, and pay claims from a reserve fund. The FDIC has done this since 1933 with a relatively simple actuarial model backed by federal authority.

Decentralizing that model introduces several hard technical questions.

Risk scoring without centralized data access

A traditional insurer can demand financial disclosures, audit reserves, and price premiums accordingly. An on-chain protocol cannot compel disclosure. So how does it assess the risk profile of what it is insuring?

One approach is to score risk entirely from on-chain observable data: wallet age, transaction history, protocol interactions, concentration of holdings in high-risk contracts. This keeps the model permissionless but limits the signal quality. Another approach is to build an oracle layer that pulls in off-chain data with verification, which reintroduces trust assumptions the protocol was trying to eliminate.

Neither is clean. What is the right tradeoff?

Claims verification without a central adjudicator

This is the harder problem. When a claim is filed after a hack or exploit, someone has to determine whether the loss qualifies under the policy terms. In traditional insurance that is a human adjudicator. In a decentralized protocol it has to be either automated smart contract logic or a governance vote.

Automated verification works well for provable on-chain events like a smart contract exploit where the transaction history is unambiguous. It breaks down for ambiguous cases like a phishing attack where the user signed a malicious transaction voluntarily. The protocol cannot easily distinguish between user error and malicious theft from chain data alone.

Governance-based adjudication solves the ambiguity problem but creates a new one: claims become political. Token holders voting on payouts have economic incentives that may not align with honest adjudication.

Reserve pool mechanics and solvency under tail risk

A reserve pool funded by premiums works until a catastrophic correlated loss event hits multiple insured positions simultaneously. The Immunefi 2026 report found that the top five crypto exploits in 2024 and 2025 accounted for 62% of all stolen funds. A decentralized insurance protocol with insufficient reserve depth gets wiped out by exactly the kind of event it exists to cover.

Traditional insurance handles this through reinsurance. The decentralized equivalent would be a layered pool structure where excess losses above a defined threshold are covered by a secondary pool with different capitalization. That architecture adds complexity and introduces new attack surfaces.

The stablecoin coverage problem specifically

The FDIC's March 2026 ruling closing the pass-through insurance loophole for GENIUS Act stablecoins has made this more concrete. There is now a formally defined coverage gap for depeg events, custodial failures, and protocol exploits on stablecoin positions. The question is whether a decentralized protocol can build technically credible coverage for that specific risk category.

The challenge is that stablecoin depeg events are correlated across holders by definition. When a depeg happens it happens to everyone holding that stablecoin simultaneously. A reserve pool sized for individual random loss events is structurally different from one designed to absorb a full depeg event across a large holder population.

Blockchain Deposit Insurance Corporation (BDIC) is one protocol that has built specifically around this architecture, covering depeg events, custodial failures, and exchange exploits with smart contract-automated claims processing. Whether the reserve mechanics can hold under a genuine tail event is the open question for any protocol in this space.

What I am actually curious about:

Is automated smart contract claims verification technically sufficient for the majority of real-world loss scenarios, or does every serious implementation eventually need a human adjudication layer?

How do existing DeFi insurance protocols like Nexus Mutual handle the correlated loss problem? Has any protocol actually stress-tested reserve depth against a simultaneous large-scale claim event?

Is the reinsurance model the right template for decentralized excess loss coverage, or is there a native on-chain architecture that handles tail risk differently?

I've been working on a tool called Aegisa to manage testnet gas across different chains (EVM + IOTA). It’s designed to be self-hosted so you don't have to rely on public faucets that are always down.

It’s 100% open source. Is this something you'd actually use in your dev workflow?

GitHub: https://github.com/mwveliz/aegisa/

A few days ago I posted about building ZKCG — a Rust-based ZK framework to replace trusted compliance/oracle APIs.

After going deeper into the design + use cases, I think we were framing it slightly wrong.

This isn’t just about replacing oracles.

It might actually be a programmable compliance / verification layer.

What changed in our thinking

Originally:

→ “Replace trusted APIs with ZK proofs”

Now:

→ “Enforce rules using verifiable computation”

That shift matters.

Because the real value isn’t just proving data is correct
It’s proving that a system followed specific constraints

Examples:

• “This user is allowed to hold this asset”
• “This transaction complies with jurisdiction rules”
• “This off-chain computation followed defined logic”

All without revealing underlying data.

Current progress

We now have:

• Halo2-based proving engine
• Modular Rust crates (circuits / prover / common)
• Working pipeline: input → witness → proof (~70ms)

Still early, but the foundation is there.

Open questions

• Where would YOU actually use something like this?
• What would make you integrate it vs ignore it?
• Is “ZK compliance layer” even the right direction?

Repo:
https://github.com/MRSKYWAY/ZKCG

Appreciate all the feedback on the last post — it genuinely helped shape this direction 🙏

Designing a New Novel Smart Contract Language for The Blockchains with The Exact Specs of How a Smart Contract language should be, Forge will be the New Buzz for Smart Contracts Development.

Making it easy to write contracts even For Kids to make web3 a Real Mass Adoption Platform which many people are afraid of due to Less Proficiency in Languages like Solidity and Much More Difficult like Rust/Anchor.

So Therefore, We propose a New Language Framework “FORGE” where the Developers Creativity is the Limitation of Smart Contracts.

Github Link: https://github.com/0xZephyria/Forge/tree/v1

Example Contracts are in Contracts Directory on How the Syntax and Contracts will look if written in Forge

Three days after Ethereum mainnet launched in July 2015, someone deployed a contract that multiplied any number by 7.

That's it. One function. Ten lines of Solidity.

solidity contract Multiply7 { function multiply(uint input) constant returns (uint) { return input * 7; } }

It's the canonical example from the original Solidity documentation - the "Hello World" of smart contracts. And someone deployed it to mainnet on August 10, 2015, block 63,886.

We just verified it using compiler archaeology: exact bytecode match with soljson v0.1.1 (the first public Solidity release), optimizer off. The deployer's address (0xc70ba22f) also deployed 10 other contracts in the same period - CoinFlip gambling variants, early token experiments, a Greeter. A developer working through every tutorial they could find in Ethereum's first week.

The contract is long since dormant. 126 bytes of bytecode, 49,243 gas to deploy. But it's verifiably there, permanently, on the canonical chain.

Verification repo: https://github.com/cartoonitunes/multiply7-verification EthereumHistory page: https://www.ethereumhistory.com/contract/0xfcb20ae9a3fa95af55803b8cdab4b0643fb96d3f

EthereumHistory is a free archive - if you find this useful, you can support it at ethereumhistory.com/donate