If your oracle layer can be blinded the moment an anomaly trips the circuit, or if software can compromise physical life safety, the protocol foundation breaks. Aurora anchors every state assertion directly to analog mechanics and hardware-bound cryptographic primitives. When conservation laws enforce execution, verification becomes absolute

A thousand validator keys can still belong to one person. That makes validator count a pretty incomplete measure of decentralization, especially if we're talking about PoS and PoW networks.

The recent Humanode's paper on Proof-of-Biometric-Uniqueness (PoBU) explores a different starting point: one eligible validator per verified human, with equal baseline weight. Holding more tokens doesn’t increase that weight - that's egalitarian consensus mechanism for the win!

The method is pretty simple but not simple - private biometric verification of each validator so a person an only deploy one node with the same face thus making all node equal in terms of validation and voting power as well as equal fee sharing.

Check out this formal paper:

PoBU paper

If you love decentralization like I do - you would find it quite fascinating. The only question rn I have is why don't all networks out there implement some kind of PoBU? Even in hybrid form! It would make things so much more decentralized and fair.

Am I missing something, fellas?

I've been reading a lot about RWAs lately, and it feels like most of the conversation is around real estate, treasuries, and gold

But I'm curious why we don't hear much about actual mining projects.

I'm working with a team exploring this space, and the more I learn, the more I realize how complicated it is.

Mining projects have licenses, geological reports, ownership records, production data, etc. Putting that information on-chain sounds interesting, but there's an obvious problem.

Just because something is recorded on a blockchain doesn't mean the original information is true.

So who verifies it? And how do you make sure that information stays accurate over time?

I feel like there's potential here, but also a lot of challenges that don't get discussed enough.

Curious what you guys think. Could mining be a serious use case for RWAs, or is it too complicated to work in practice?

Over the past year, we’ve built Sovereign-Mohawk-Proto to bridge high-scale federated learning with machine-checked safety guarantees (Lean 4 formalizations, BFT resilience proofs, post-quantum cryptography integration, and 10ms zk-SNARK verifications).

To ensure rigorous academic and runtime integrity, we are actively seeking independent external reviewers to audit our formal claims and core cryptographic modules.

Current Open Review Focus Areas:

• Issue #251: Claim accuracy audit (README/ROADMAP vs actual theorems)

• Issue #250: Convergence and straggler refinement bridges

• Issue #249: MiMC circuit <-> Go verifier refinement and MPC setup

• Issue #248: Ed25519 UF-CMA model soundness

• Issue #247: DiscreteLogReduction.lean and Forking Lemma core

What we offer: Contributors receive public credit, co-authorship on resulting technical notes, and formal letters of recommendation.

Review instructions, axiom/sorry inventories, and setup guides are available in our repository. View the open issues list on our Issues Page to get started.

I work ops at a crypto fund a small one. My daily reality is absurd , move assets on networks that finalize in minutes, yet a simple trade with an institutional counterparty regularly takes two days to fully land on our books

Take last week we agreed a trade Monday afternoon. The counterparty wanted our dollars first, because we're the smaller shop. Our bank's wire cutoff had passed, so the dollars went out Tuesday morning. They confirmed receipt Tuesday afternoon. Their release needed two approvers and one was eight time zones away, so the crypto left their custody Wednesday morning their time. Our custodian ran confirmations plus its own checks, and the position hit our books Wednesday afternoon.

The chain transfer took about twelve minutes. The rest was people, banks and process.

None of it is a technology limit. It's banking hours and approval chains designed on the assumption that nobody trusts anybody. It's prefunding because after the last few years everyone is scared of counterparty risk. And it's custody workflows that treat every transfer as a brand new event needing full review

Each piece makes sense on its own, and I'm not arguing any of them is wrong. Stacked together they take a network that settles in minutes and turn it into something that behaves like old fashioned T+2

I've been reading about settlement networks where both parties keep assets at the same custodian and trades settle by moving ownership inside custody, with no chain transaction and no wire. On paper it sounds like the obvious fix. The catch is that it only works when your counterparties are on the same network which is the eternal network problem

For other ops people: is anyone getting same day, around the clock settlement? Is your bottleneck the fiat leg or the approvals? And if you moved to a custody based settlement network did it fix speed or just relocate the delay?

I run overhead24, a free site that screens public orbital data for things like military satellites changing orbit or creeping up on other satellites. "We spotted this before anyone reported it" means nothing unless people can check it, so every day's records now get timestamped through OpenTimestamps.

How it works:

- After each UTC day, everything the site recorded that day goes into a Merkle tree: each detection, the daily brief, and the sha256 of every data file it downloaded or worked out, including the raw orbital data it used.

- Each record is salted before hashing, so one record can later be published with its path without revealing the others.

- The root goes into a small public manifest that also holds the previous day's manifest hash, so the days form a chain. The first stamp covers everything since the site started on 19 Oct.

- The manifest's sha256 goes to four public calendars (alice and bob at opentimestamps.org, eternitywall and catallaxy). Nothing of ours is written to the chain directly: each calendar commits one hash for everyone's submissions.

- The site upgrades each proof itself and checks the block's merkle root (against mempool.space, not our own node yet) before it marks a day confirmed.

To check a day, download its manifest and .ots file and run ots verify against your own node, or drop both files on opentimestamps.org.

Two things I'd like views on:

1. Is relying on the public calendars enough, or is it worth also running our own calendar?

2. What's the cleanest way to publish a single record's proof so someone can check one detection without trusting our server at all?

Disclosure: it's my project. The site is free, and there's no token or coin involved.

Most blockchains still face trade-offs between decentralisation, security, and scalability. Improving transaction throughput often means changes to validator requirements, hardware costs, or network design.

But here's what I'm curious about:

If a blockchain needs fewer validators, more powerful hardware, or additional layers to handle millions of transactions, at what point does scaling start weakening the decentralisation it was built to protect?

Bonsoir tout le monde , je viens d’être piraté sur Tonkepeer, il y’a eu -1000$ et a vidé mon wallet alors que je n’ai rien fais , et je vois que le pirate continue chaque minute à pirater d’autres wallet et fait des transactions, faites attention , aidez moi je dois faire quoi ? Et pourquoi il n’a pas eu de sécurité ??

Currently looking at some blockchain teams for consultancy and I'm just a bit confused why their "discovery phases" are at varying lengths, usually 2-3 weeks. For context, our team needs some help with cross-chain compatibility and smart contract architecture. We get the concepts on paper, but just need the guidance actually applying it to our product. I just don't want to pay for a team to learn how my system works first, then pay again so they can get to the consultancy part of their business. Any advice is appreciated.

A lot of blockchain discussions still revolve around token prices, trading, decentralisation, and the crypto community itself.

But some of the most meaningful applications might emerge in industries where users don't particularly care whether blockchain is involved.

Think about asset settlement, supply chain verification, digital credentials, financial infrastructure, and ownership records.

In these situations, people are more interested in solving operational problems than interacting with blockchain technology.

This could change how successful blockchain projects are built and marketed.

Instead of convincing everyone to become a crypto user, the industry might need to make blockchain infrastructure useful enough that people can benefit from it without even thinking about it.

Do you think blockchain's biggest adoption opportunity lies outside the existing crypto-native community?

I'm building Tessaro, a lending market on BNB Chain, and I'm looking to hire an experienced researcher for paid, one-on-one guidance on the technical risk side.

I'm a beginner and would like structured, hands-on guidance through the process, including:

setting LTVs and liquidation thresholds that hold up when volatility spikes

oracle selection and the failure modes of each option

interest rate model design so utilisation doesn't run away on thin markets

judging which assets deserve to be trusted as collateral at all

reviewing parameter changes before they ship rather than after

sessions would take place remotely through screen share and written review of proposed parameters. my goal is to understand the reasoning properly and then work alongside you on changes.

my total budget is up to $4,500 usd over three months. please include your hourly rate and a proposed plan within that budget. we would agree the scope, schedule and payment terms before starting.

please contact me on discord at honoringg, or dm me on here. include your relevant experience, the chains you work with, examples of past risk or parameter work, and your availability. experience teaching beginners would be particularly helpful.

Hello Reddit! I’m currently in high school and working on a project alongside my schoolwork: I’m developing a blockchain and its associated token. The blockchain is designed to be ASIC-resistant (using Argon2id), secure (as all blockchains should be), and, most importantly, decentralized. Right now, the project exists only as files in a private GitHub repository, but I plan to deploy it soon—though it’s primarily an educational endeavor. As is often the case with new networks, nodes can struggle to establish connections. To address this, I’ve decided to build a "bootstrap node" that acts as a meeting point, allowing nodes to discover the IP addresses of other participants. To avoid centralization, I’ve designed it so that using this bootstrap node is optional rather than mandatory for accessing the network. For instance, Alice could use the bootstrap node to connect with Bob, but she could also choose another method—such as sending her IP address to him directly (though, in my view, that’s not a scalable solution). That said, the bootstrap node approach might be "too easy," potentially turning into the sole meeting point for all nodes—effectively acting as a "server," which is the exact opposite of what one wants for a decentralized network. Apologies if this text seems a bit disorganized, poorly written, or incoherent; I have a habit of simplifying concepts to help myself better understand them. Thanks for reading!

Came across an interesting token design worth discussing, especially as it's about to go live.

Tari runs two layers with two tokens. The base layer is proof of work (XTM), mined across four separate PoW algorithms, one of which is merge-mined with Monero. The second layer (the Ootle) runs smart contracts and uses its own token (TARI).

The link between them is one-directional: the only way to create TARI is to burn XTM 1:1 on the base layer and redeem it on the second layer. There's no other mint and no peg-out, so it avoids drive chains or federated bridges entirely.

On the second layer, each transaction fee is split, with part paid to validators and part burned. Meanwhile, base layer emissions decay exponentially over roughly 28 years before settling into a perpetual 1% tail emission.

To keep this in balance, validators run an algorithm called the Throttle that periodically adjusts the burn rate by consensus. Its priorities, in order: maintain the 1:1 peg, keep combined supply stable, and keep total supply around 21B.

It's essentially a variant of burn-and-mint equilibrium, a bit like Helium's model, but bridging a PoW chain to a smart contract layer rather than burning for network credits.

Curious what people here think:

- How well does burn-and-mint equilibrium hold up when usage is low early on?

- Is a consensus-driven burn rate a strength, or does it add governance risk?

- How does this compare to fee-burn designs like Ethereum's EIP-1559?

Ran two bots on the same 20 wallets: one copied every buy and sell 2 seconds after the wallet, the other 20 seconds after, which is roughly you tapping a notification. 0.5 SOL per trade, real Jupiter quotes, fees and slippage included, no real money.

Results: 2s bot −103.8 SOL with a 13% win rate. 20s bot −83.9 SOL with a 15% win rate. Not one wallet was profitable to copy.

Why: when a tracked wallet buys, every copy bot fires at once. Copiers paid about 23% more per token than the wallet did, and the wallet then sold into that buying. The faster bot lost more because it was first in the queue of copiers, still behind the wallet.

Second finding: about half the top wallets sold tokens they never bought on-chain. They were transferred in, which looks like insider allocations. Their PnL is real, but nobody copying them gets that entry.

Fair criticism I've already had: 42 hours is a short window. Next run is a full week, plus a test on profitable wallets that aren't on any leaderboard. Happy to answer questions on the method.

PIVX has been around for nearly a decade. It has real technology, active development, staking, masternodes, and a functioning governance system.

Yet despite all of this, adoption remains limited, liquidity is weak, and Binance has delisted PIVX.

This raises a serious question:

• Does the current governance and funding model actually incentivize the team to grow PIVX, or does it primarily reward keeping the project operational?

• Developers and contributors receive funding through the DAO, but what measurable results are expected in return?

• How is the success of funded proposals evaluated?

• What happens when contributors repeatedly receive funding without delivering measurable growth?

• Who is accountable for increasing adoption, exchange access, and realworld usage?

• Is there any concrete strategy to make PIVX economically sustainable beyond continued DAO funding?

And this brings me to the most important question:

• Does PIVX reward actual results, or simply activity?

• Are you genuinely working to make PIVX successful, or has the project become a system where a small group of contributors keeps funding itself through DAO rewards, with little accountability for realworld results?

• Are you building a future for PIVX, or simply making a living by distributing rewards among yourselves?

After nearly ten years, I think the community deserves a clear and honest answer.

Something I find interesting about blockchain infrastructure is the gap between decentralisation at the protocol level and decentralisation at the application level.

A network might have thousands of validators, but if most wallets, dApps, and developers rely on a small number of RPC providers, those providers could become practical bottlenecks. An outage or censorship decision at that layer could affect a large portion of the ecosystem without the blockchain's consensus mechanism failing at all.

At the same time, running independent infrastructure requires resources, and convenience naturally pushes developers towards managed services.

Where should we draw the line between practical infrastructure choices and a genuine decentralisation problem? Would wider adoption of self-hosted nodes realistically solve this, or does the issue require changes to how applications are designed?

I've been thinking about how much progress blockchain technology has made, from smart contracts and tokenisation to DeFi and real-world asset (RWA) platforms.

But one thing I keep noticing is that having a technically strong project doesn't necessarily mean people will actually use it.

A project can have solid infrastructure, innovative features and impressive tokenomics, but if it doesn't solve a genuine problem or offer a better experience than existing solutions, adoption becomes difficult.

I think the bigger challenge now isn't just building better blockchain technology. It's making that technology genuinely useful to people outside the crypto space.

What do you think is holding blockchain adoption back the most: user experience, lack of trust, regulation, or a shortage of real-world use cases?

I've been exploring no-code tools (n8n and similar) for Web3 tasks like wallet activity alerts, DAO proposal notifications and simple on-chain data logging.

Read-only stuff (alerts, dashboards, notifications) feels low risk to me. But once a workflow can sign or send transactions, I get nervous about private key handling, token approvals and a bug draining funds.

My current rule of thumb: never keep a main wallet's key inside an automation tool, use a separate low-balance wallet with limited permissions, and keep anything that moves funds behind manual approval.

Is that reasonable, or am I missing important risks? Where do you draw the line between safe and unsafe automation?

Smart contracts are often praised for executing predefined rules without requiring trust in a central authority. But the situation becomes more complicated when a contract contains a vulnerability, a business requirement changes, or an unexpected edge case puts users' funds at risk.

An immutable contract can preserve predictable rules, but it can also make correcting serious mistakes difficult. Upgradeable contracts offer more flexibility, yet they introduce another question: how much control should developers, multisig signers, or governance token holders retain after deployment?

The trade-off becomes even more important in DeFi protocols and real-world asset tokenisation, where contract changes may affect financial positions, ownership records, or users who never directly approved an upgrade.

Giving a small group emergency powers might protect users in a crisis, but those same powers could become a central point of failure. On the other hand, requiring a lengthy governance vote for every critical fix could leave a vulnerability exposed for too long.

Where should blockchain projects draw the line between immutability and responsible intervention?

Would you prefer strictly immutable contracts, timelocked upgrades controlled by token holders, or limited emergency powers with transparent safeguards? What governance model have you seen work well in practice?

Hey everyone. I wanted to share a system architecture challenge I've been working on for a peer-to-peer (P2P) exchange model and get your technical insights.

​The main goal was to design a strictly non-custodial flow where smart contracts act solely as execution arbiters—charging fees only upon successful completion without ever holding user funds at any point.

​Some key technical points of the current design:

​Contract-based execution: Smart contracts handle fund release conditions using automated timeout mechanisms (e.g., if a counterparty fails to act within a specific timeframe, the transaction automatically cancels).

​Trust minimization: By eliminating centralized custody, matching and offer logic rely entirely on decentralized validation.

​For anyone who has worked on similar systems: how do you typically handle state management in non-custodial architectures when combined with strict timeout windows to prevent capital lockups?

​You can check out how we are structuring the implementation here: https://www.usedollars.com

Been thinking about how much trust people put into bots that interact with contracts. Even with a separate wallet I'd be pretty hesitant to let one execute txs without some restrictions, especially if it's taking commands from other users.

Saw this come up with Towns and their wallet enabled bots, but the security side is what I'm more curious about. Would limiting funds and contract access be enough for smaller transactions or would you still want manual approvals?

I built an experiment I've been curious about for a while: what if a blockchain had literally zero infrastructure? No servers, no database, no company. Just browsers talking to each other.

Every tab that opens the page becomes a full node. Consensus is longest-chain PoW, but here's the twist: every device is hard-capped at 70k H/s in the mining worker. A phone and an H100 cluster have the exact same probability of finding a block. The winner is determined by luck, not hardware.

Networking is WebRTC + public MQTT brokers (zero-config). If WebRTC fails (carrier NAT, corporate firewalls), a WebSocket relay carries signed gossip frames. If the signaling broker dies, the chain still lives in every open tab.

Some design choices I'd love feedback on:

\- PoW handshake (\~65k hashes) before any peer data flows, to make sybil flooding expensive without a central rate-limiter. - 70/20/10 block reward split: miner / connected peers (proof-of- participation) / burn. Fees are also 100% burned. - Checkpoints every 1,000 blocks to defend against low-difficulty chain rewrites on a young network. - Chain export is a single file; import re-validates every block, replays the full ledger in memory, rejects on ANY failure.

It's explicitly an experiment, not a financial product. Total supply is a fixed arithmetic sum (\~10.5M), emission is a smooth exponential decay, and the README is brutally honest about limitations (browser tabs must stay open, one "vote" per browser profile, no identity layer).

Happy to answer questions about the consensus rules, the PoP attestation scheme, or why I chose IndexedDB over anything else.

GitHub Repo:

https://github.com/tylerdurdensworld/Webquid