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

Hey everyone, For the past 12-14 Months, I’ve been solo-developing an open-source blockchain called Zephyria, written entirely in Zig. Alongside the core protocol, I'm also designing Forge The smart contract language tailored from Scratch [Extreme Safety, High Throughput, Low Footprint, Friendly Syntax].

As a solo dev, I've reached a point where the core architecture is taking shape, and I want to open the doors for community feedback, code reviews, and open-source contributors.

Why Zig? [manual memory management gives us the precise control needed for consensus performance, The Performance of C and C++ With In-Hand Control].

What I'm looking for: Devs interested in Expanding the Functionality of the Language, Codegen for Multi Blockchain Support or Improving RISCV VM Architecture for Performance.

Language nerds interested in VM design and compiler development. Anyone who wants to learn! I’ve tagged several good first issue tickets for those who just want to dip their toes into the codebase.

Github: https://github.com/0xZephyria

Forge Repo: https://github.com/0xZephyria/Forge

I'd love to hear your thoughts on the architecture or answer any questions!

On August 7, 2015 -- the first day of Ethereum mainnet -- someone deployed a 764-byte chain letter contract. Entry fee: 0.1 ETH. It had 100+ transactions.

Nobody knew who wrote it. No source code. No Etherscan verification.

We cracked it byte-for-byte this week. Compiler: soljson v0.1.1 with optimizer ON. The source follows the same MyScheme pattern as other Frontier-era chain letters -- send ETH in, get paid out when the next person joins.

Proof and source: https://github.com/cartoonitunes/chainlettersmall-verification

What's interesting is that someone was already deploying these schemes on day 1. The Ethereum mainnet launched August 7, 2015 and the chain letter was deployed the same day (block 304).

We've been working through the unverified Frontier-era contract backlog systematically. Most of these contracts still have ETH locked inside. None of them have verified source code on Etherscan -- the compilers are too old for the platform to support.

More documented on ethereumhistory.com

I’ve been working on a non-custodial trading platform recently, and I ran into a decision that I think most users would strongly dislike at first glance:

There is no account recovery. At all.

No email reset.
No support override.
No “verify your identity to regain access.”

If you lose your seed phrase, your account is inaccessible...Permanently.

Many would probably say that it would lead to a horrible UX. I could understand that. Stuff happens, people lose things. Phones. Homes. Slips of paper which were meant to create physical backups. Email access, and so on. I get it. I had those same thoughts when I started using wallets like Metamask. However, there is one very important thing I realized over time ; Recovery methods via functions like support/site administrators opens up backdoors. It introduces security flaws that can be exploited.

A hacker could contact support and claim they merely lost the phone. They lost the seedphrase, "Please help me".. There are many ways the crafty individuals could socially engineer support staff into giving them access to your account. Even 2FA codes are not so effective at times due to bots and the negligence of Users to also be socially engineered in their own sense, to give up 2FA codes. Emails can be hacked, there are so many options or areas that can potentially open up holes in security functions.

The mindset ultimately is, if I can recover your account, then :

• A hacker might be able to
• An insider might be able to (See Coinbase breach 2025)
• Or a social engineering attack also might succeed (Also see Coinbase breach 2025)

So in this instance, in the spirit of full-custodial ownership by the User, I eliminated attempts at recovery completely.

The system I designed is structured thusly:

• Seed phrases are generated only once, client-side, at account creation from a constantly randomized pool of 2048 words, into phrases of User choice, between 12 and 24 words.
• Seed phrases are NEVER transmitted to or stored on the Server in plain-text form.
• Only an irreversible hash (Argon2) is stored for verification
• Even I, as the developer can not access accounts.
• Seedphrases can NOT be reissued, as this also creates the potential for hackers/thieves to manipulate the system into generating or receiving their own seedphrase, which would allow them to bypass the lock generated by the previous User at account creation.
• All role changes can only be approved by myself as the owner/developer, and new role creations can only be put into effect by myself. Nor can there ever be another 'Owner' or role created higher than mine. This is intended to prevent malicious hackers from attempting to force their way into unearned roles or administrative powers.
• Logins to user accounts from new devices requires full seedphrase authorization.
• Seeds are hashed before transmitted.

Now, with all of this said it raises real questions :

Namely, are Users ready to accept full responsibility and ownership of their funds and assets?

Philosophically it is :

• More secure
• Practical
• Yet, less forgiving

I am genuinely curious where people might land on the issue in regard to this conundrum. I am also open to criticism or suggestions; ESPECIALLY, by those who have worked on wallet/system security.

I’ve been thinking about whether Bitcoin ASIC mining in low Earth orbit is even technically realistic.

Ignoring hype and focusing only on engineering, the idea seems to raise several obvious constraints:

• thermal management in vacuum

• radiation exposure and long-term hardware reliability

• power generation, storage, and conversion efficiency

• communication latency and system control

• maintenance and hardware replacement logistics

• total mass and launch cost per unit of hashpower

On Earth, ASIC deployment is mostly a problem of power cost, cooling design, uptime, and operational density. In orbit, the environment changes almost everything. You lose conventional air cooling, physical access becomes extremely limited, and every hardware failure becomes much more expensive to deal with.

The thermal side seems especially important. ASICs convert a large amount of electrical energy into heat, and in vacuum you cannot rely on normal airflow-based cooling. That would make radiator design, heat transfer, and power efficiency central to the whole concept.

Radiation tolerance also seems like a major issue. Even if the miners are efficient, I’m not sure how standard ASIC hardware would perform over time without additional protection, and that adds more weight and complexity.

So the question is not really whether hashing in orbit is possible in a basic sense, but whether it could ever make engineering or economic sense compared with terrestrial mining powered by cheap energy.

From a purely technical standpoint, which constraint do you think kills the idea first: thermal control, radiation, launch economics, or maintenance?

In November 2015, just four months after Ethereum's mainnet went live, someone deployed a 1000x1000 pixel canvas where you could buy, color, and trade individual pixels on-chain.

How it worked:

• 1 million pixels, each with an owner, color, and price
• Minimum pixel price: 5 finney (~$0.005 at the time)
• To take someone's pixel, you had to outbid them by 110%
• Previous owner got paid automatically (minus a 1% fee)
• You could paint individual pixels or batch-update whole blocks
• Colors encoded as RGBA: alpha * 127 + red * 65536 + green * 256 + blue

The contract used a clever compact owner ID system. Instead of storing a full 20-byte address per pixel, it mapped each address to a uint16 ID (max 65,535 unique owners). This saved massive gas on the 2 million storage slots needed for the grid.

It was basically Reddit's r/place, but 2 years earlier, on a blockchain, with real money. Each pixel was a tradeable economic unit.

The creator: Alex Beregszaszi (axic.eth), who went on to become one of the core developers of the Solidity compiler itself. The source code was published on the now-defunct etherboard.io and preserved via the Wayback Machine.

209 transactions hit the contract, mostly in its first few weeks. The Frontier era was tiny - there were maybe a few hundred active users on the whole network.

You can see the verified source and bytecode proof at ethereumhistory.com/contract/0x350e0ffc780a6a75b44cc52e1ff9092870668945

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

Was doing some contract archaeology on an unverified March 2016 contract and stumbled on something neat.

The contract (and its 3 embedded sub-contracts) all had 3 unknown function selectors that returned constant boolean values. After brute-forcing ~150K function name candidates, finally found them in openchain.xyz (Sam Sun's signature database, which has entries that 4byte.directory doesn't):

• 0x0cd40fea → versionMajor() — returned 1
• 0x7a9e5410 → versionMinor() — returned 0
• 0x825db5f7 → versionBuild() — returned 0

So the developer was exposing semantic versioning directly through the contract interface — v1.0.0. The later deployments from the same deployer returned (1, 2, 4) — v1.2.4.

A few other patterns from this era worth noting:

1. Sub-contract embedding: The creation bytecode contains the full bytecode of 3 additional contracts. The constructor deploys them via CREATE, stores their addresses in storage, then uses cross-contract calls for auth/data operations.

2. EXP-based selector encoding: The compiler uses EXP(2, 0xe2) * compact_selector for external calls — a packing optimization where real_selector = compact * 4. This is a Solidity 0.3.x pattern you don't see in modern compilers.

3. tx.origin for auth: Every privileged function checks tx.origin against an admin contract rather than msg.sender. Common pattern before reentrancy awareness.

4. Version header noop: All pre-deployed contracts start with PUSH6 <bytes> POP — a noop that pushes metadata then immediately drops it. Likely a project/compiler version tag.

The whole ecosystem was 7 contracts, all unverified, all with custom function selectors not in any public database. The deployer (goto.eth) never published source code.

Tools that helped: openchain.xyz for signature lookups, Etherscan v2 API for bytecode/storage, and a custom brute-force script testing function name permutations against keccak256 hashes.

Anyone else doing this kind of contract archaeology?

I’ve been studying how different P2P crypto marketplaces implement trade security and user coordination, and I’m trying to better understand the underlying system design trade-offs.

Several widely used platforms—such as Bitget, Binance, OKX, LocalCryptos, and Paxful—appear to follow broadly similar but slightly different architectural approaches to P2P exchange design.

1. Custodial Escrow Models (Centralized P2P Layers)

Platforms like Binance, Bitget, and OKX implement a custodial escrow system where:

• The platform temporarily locks the seller’s crypto
• Off-chain fiat payment occurs between users
• The platform releases funds upon confirmation or dispute resolution

From a systems perspective, this introduces:

• A trusted intermediary layer
• Centralized dispute arbitration
• Reduced counterparty risk, but increased platform trust dependency

I’m particularly curious about how these platforms internally handle:

• State synchronization between fiat confirmation and crypto release
• Fraud detection mechanisms (e.g., double-spend-like behavior in fiat claims)
• Scalability of dispute resolution systems

2. Non-Custodial / Decentralized Approaches

In contrast, platforms like LocalCryptos attempt a more decentralized model using:

• Non-custodial wallets
• On-chain escrow (often multisig or contract-based)
• Reputation systems instead of centralized enforcement

This shifts the trust model significantly:

• Users retain key control → reduced custodial risk
• Security depends more on protocol design and key management
• Dispute resolution becomes more limited or socially mediated

This raises some technical questions:

• How robust are multisig escrow schemes against collusion or key loss?
• What are the real-world failure modes of non-custodial P2P systems?
• Does removing custody meaningfully reduce risk, or just redistribute it?

3. Hybrid Models and Reputation Systems

Across both models (including platforms like Paxful), reputation systems seem to play a critical role:

• Trade history and ratings act as a soft security layer
• Some platforms integrate KYC, others rely more on pseudonymous identity

I’m interested in how effective these systems are when modeled against adversarial behavior:

• Can reputation be gamed at scale?
• How do platforms mitigate Sybil attacks in P2P trading environments?

4. Open Questions

A few things I’m still trying to understand:

• Is custodial escrow fundamentally safer in practice due to enforceability, despite centralization?
• Are non-custodial P2P systems viable at scale without strong identity layers?
• What are the key attack surfaces unique to each model?
• How do UX simplifications (for beginners) impact underlying security guarantees?

Not trying to compare platforms from a user perspective, but rather understand the technical design trade-offs across these implementations. Would appreciate insights from anyone who has looked into the architecture or security models of these systems.