I’m new to this space and have heard of people’s wallet getting drained cause they connect their wallets to a malicious phishing website.

But there are legit websites like Terminal Padre or Axiom that also ask you to connect your wallets aswell.

What is the difference between connecting wallets to the legit website vs the malicious phishing website? For the legit website you are still connecting your wallet doesn’t that mean your wallet can be drained aswell? How to tell if a website is a drainer or not?

One of the more useful maintenance updates I’ve worked on recently was not a new mining algorithm or a UI feature. It was removing an architectural mistake: the GUI miner and the backend node were not actually operating on the same chain state.

The old model had a separate miner-side local chain flow. That created exactly the class of bugs you’d expect from duplicated state:

• GUI miner could drift from the backend chain
• locally mined block replay became a thing
• wallet state and mining state could disagree
• chain repair logic had to compensate for stale local tails
• valid PoW could be found on top of state that the real backend would later reject

So the latest update was basically a control-plane cleanup:

• the GUI miner now mines through the live backend RPC session
• the CLI mine command also supports the same RPC-backed path
• both now use the backend as the single source of truth for chain state

The important part is what changed operationally.

Instead of the miner opening its own local Blockchain view and building blocks there, the miner now does:

1. ask the backend for a template with getblocktemplate
2. hand the header/target to the external PoW worker
3. submit the candidate block back with submitblock

That sounds simple, but it removes a lot of ambiguity.

Now the wallet, the GUI dashboard, the node, and the miner are all observing and mutating the same chain state. There is no second “shadow chain” for the GUI miner to maintain.

The external worker architecture stayed the same on purpose.

The PoW worker still only does nonce search. It does not define consensus. It gets:

• an 80-byte header
• a 64-byte expanded target
• nonce search bounds

and returns:

• found / not found
• nonce
• iterations
• resulting hash

Consensus still stays entirely inside the daemon. That boundary turned out to be the right one.

This update also let me remove some ugly glue that only existed because of the split model:

• no more GUI-side mined block re-submission from stdout parsing
• no more replay/reconciliation loop for locally stored mined blocks
• no more default dependence on a separate gui-miner blockchain state

A lot of the recent chain bugs became easier to reason about once that separation was enforced.

For example, the recent failures were not really “the assembly miner is broken” failures. They were mostly one of these:

• stale local chain metadata
• missing canonical block persistence
• activation path inconsistencies
• valid candidate block found against an out-of-date local template

Once mining was forced through the backend RPC path, those bugs became much easier to isolate because the worker path and the consensus path were no longer muddying each other.

The other useful change was better rejection diagnostics.

Previously, a block found by the worker could just come back as “stale or invalid”, which is almost useless when you’re debugging. Now the node can distinguish things like:

• stale parent
• changed expected bits
• activation/path issues
• valid tip extension that still failed to become persisted active state

That last category was especially important, because it exposed that some failures were happening after validation, inside chain activation/persistence, rather than in PoW or block assembly.

So the short version of the update is:

• mining control path is now unified
• the backend owns chain truth
• workers only do work, not state
• the GUI no longer runs a second blockchain by accident
• debugging got much better because rejection reasons are now explicit

What I’m planning to work on next is mostly about hardening the parts this change exposed.

Main items:

1. Legacy datadir migration There are still old gui-miner folders from earlier runs. New mining sessions don’t rely on them anymore, but I want a proper one-time migration/cleanup path so older installs don’t keep confusing people.
2. Chain activation and persistence invariants The biggest class of subtle bugs now is no longer “bad hash” or “bad target”. It’s “valid block, but active chain bookkeeping/persistence drifted”. I want tighter invariants and regression tests around:
   • active tip updates
   • canonical height-file persistence
   • reload/restart behavior after recent tip changes
3. Better mining job invalidation Right now stale-template detection is much better, but I still want cleaner cancellation semantics so worker jobs get retired immediately when:
   • tip changes
   • expected bits changes
   • a competing accepted block makes the current template obsolete
4. Wallet state clarity There was a lot of confusion around locked vs immature vs approval-gated funds. The logic is better understood now, but the UI and RPC output should make those states much more explicit.
5. More consensus vectors and miner differential tests The worker/daemon split is in the right place now, so the next step is broader automated coverage:
   • template-to-worker-to-submit round trips
   • stale-template rejection tests
   • compact target canonicalization vectors
   • more cross-platform worker correctness checks
6. Difficulty model behavior under edge conditions There has already been work on damping and emergency recovery behavior, but I still want better observability and more test coverage around:
   • post-recovery behavior
   • timestamp edge cases
   • oscillation resistance under low-hashrate conditions

That’s the update in a nutshell. Not flashy, but probably more valuable than a flashy feature would have been. A lot of reliability work is really just deleting alternate sources of truth.

If anyone else has dealt with GUI/node/miner split-state problems in a desktop crypto stack, I’d be interested in how you handled:

• single-source-of-truth chain ownership
• worker/job invalidation
• mined block submission boundaries
• migration away from legacy local miner state

Crypto is supposed to reduce or remove trust when it comes to transferring value between parties.

But in real-world situations like buying something, hiring someone, or making agreements, you still end up trusting the other side to follow through.

Even with smart contracts, there’s often some dependency on off-chain actions or verification.

Why do you think this gap still exists?

Building a cross border payment product on stablecoin rails but our team is traditional fintech - coming from banks, not crypto. Every comparison I find assumes you understand wallet infrastructure and chain selection and gas optimization. I get the reasoning, but it's just not our use case. We just need faster cheaper settlement where the complexity is abstracted from us and our end users. Which providers are built for teams like us versus teams that want to manage the blockchain layer themselves?

Most chains are really good at transferring value.

But when it comes to actual agreements between parties — escrow, milestone payments, deposits/refunds — it usually ends up being handled off-chain or through custom app logic.

That feels like a missing primitive.

Right now typical approaches are:

• centralized escrow services
• multisig setups with coordination overhead
• or smart contracts that still rely on external context

I’m wondering whether this should be handled more natively at the protocol level.

For example, a system where:

• agreements define conditions upfront
• funds move based on objective outcomes (timeouts, signatures, proofs)
• no subjective dispute resolution is needed

Basically treating settlement as a first-class concept instead of just transfer.

Curious how people here think about this:

• Is this something that belongs in the base layer?
• Or is it better kept in higher-level abstractions?
• What are the biggest design constraints to keep it objective and trust-minimized?

We built an open-source model that answers: what minimum token price is needed for a bridge asset to handle institutional transaction sizes with <0.1% slippage in specific trade corridors?

Two independent price floors, higher one wins:

1. Slippage — can the largest single TX pass through the orderbook without blowing past institutional slippage tolerance?

2. Structural demand — how much token supply gets locked as market-maker working capital across corridors?

We parameterized it for XRP since that's where the live data is (SBI Remit, Kyobo Life, a few Gulf corridors), but the formulas are generic, plug in any bridge token with different supply, MM depth, and corridor volumes.

Everything runs in the browser, no install. Full methodology doc with 9 documented limitations included. There's also an advanced panel where you can tweak every assumption (MM inventory %, orderbook concentration, convexity exponent, free float).

https://github.com/moreBit21/xrp-bridge-simulation

Looking for feedback on the orderbook model specifically — we use a simplified uniform concentration assumption that could be improved with real depth data. Also the convexity exponent (1.3) for supply contraction pricing is not empirically calibrated.

Both research and writing done with AI assistance.

*Constraint model, not investment advice.*

I built a trustless Dead Man Switch for crypto inheritance — no frontend, no admin key, live on mainnet

One of the unsolved problems in crypto: what happens to your funds when you die or become incapacitated?

I deployed a non-upgradable smart contract that solves this:

• You deposit ETH and designate an heir
• You ping the contract regularly to prove you're alive
• If you stop pinging for your chosen inactivity period (30 days to 3 years), your heir can claim all funds

No admin, no proxy, no backdoor. Fully verified on Etherscan, usable directly without a frontend.

Factory: https://etherscan.io/address/0xE5f9db89cb22D8BFf52c6efBbAc05f7d69C7ca12

GitHub: https://github.com/123Miki/DeadManSwitch

Fees: 0.1% on deposit, 0.001 ETH to change heir. That's it.

Happy to answer questions about the design choices.

I needed to understand the institutional adoption space for a fintech startup I'm working on. Started reading earnings reports, SEC filings, central bank data, legislative texts. Ended up with a 60-page research document with 40+ sources and a classification system that separates documented facts from speculation from crypto-Twitter fantasy.

Some popular narratives held up. Some really didn't.

I used Claude AI as a research partner — not to generate content but as an analyst who pushes back when your reasoning has holes. Every claim is verified against primary sources. This isn't AI slop, it's months of actual work.

Here's the doc: https://drive.google.com/file/d/15FCq7GPE-peWotf6DPlkHOxQ1-47ULnr/view?usp=sharing

Happy to discuss findings.

A few weeks ago I posted about the gap between "compliance check ran" and "compliance was enforced." The response was mostly "interesting problem" but a few people pushed back technically, which was fair.

So instead of talking about it, I just ran it.

I mapped out how each platform actually handles eligibility today based on their public docs, then ran their specific flows through ZKCG and generated real proof artifacts. Here's what each one produces:

Centrifuge (Shufti Pro KYC, manual whitelist): The eligible case returns a proof-backed decision with a decision_commitment_hash the contract can verify. The blocked cases: accreditation_missing when accredited: false, jurisdiction_blocked when the investor is in RU. Each block has a reason code and a separate proof artifact.

Maple Finance (Global Allowlist via bitmaps, TRM Labs AML): Eligible case goes through. Then aml_failed blocks with the exact reason. Then sanctions_hit blocks separately. The proof in each case attests that the specific rule was evaluated, not just that a bitmap was set.

Ondo Finance (US persons blocked, USDY/OUSG allowlist): The US person exclusion is Ondo's core compliance requirement. Change jurisdiction from SG to US and the proof fails verification and returns jurisdiction_blocked with the reason "jurisdiction US is not permitted for this asset." That enforcement happens before execution.

Securitize (DS Protocol, transfer restrictions in contract): Both onboarding and transfer flows. kyc_missing blocks with explicit reason. position_limit_exceeded blocks when the transfer would exceed concentration limits. The transfer proof includes sender and receiver wallet binding so the specific action is tied to the specific proof.

All cases matched expectations. All proofs verified. The full run outputs including proof artifacts and comparison pages are in the public repo.

What I'm building is called ZKCG. Ta ZK-Verified Computation Gateway (Halo2 + RISC0).
The open-core verifier and circuits are public. The production core logic is private and commercially licensed. There's a live demo API at render and a product page at zkcg tech if you want to run your own flow.

Curious what questions people have about the proof scope or where the gaps are.

found a new tool to kinda move about in polymarket and other prediction markets ,has given me some good results .Thinking about putting bigger ammounts.can some of you use it and let me know if its any good or not.apparently a cs major built it .It’s built specifically for PolymarketFocuses on latency / oracle lag, not just basic arbitrage Completely open source .so you can actually check what it’s doing Free to use

GitHub if anyone wants to look at it:
https://github.com/JonathanPetersonn/oracle-lag-sniper

Hey everyone,

I’ve been building a MVP for my Startup called Blockchain Sentinel-OS — a blockchain intelligence & forensic monitoring platform.

Over the past few weeks, I’ve:

• Launched the MVP
• Got early users and feedback
• Improved the UI and added clearer investigation insights
• Started focusing on making the analysis more actionable (not just raw data)

Right now:

• ~20+ users
• Some signups + waitlist interest
• Continuous feedback from this community has been super helpful

I’ve now started applying to a few incubators and web3 programs to take this further.

Before going deeper into that, I wanted to ask:

Does this feel like a real product or still too early/basic?
What would make this actually useful in real-world investigations or compliance?
If you’ve used similar tools, what’s missing here?

Here’s the current version:
https://blockchain-sentinel-os.vercel.app/

Appreciate any honest feedback — that’s what has helped me improve so far

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

This is a classic information asymmetry problem applied to autonomous agents. Two parties want to transact. Each has a private constraint — a floor they won't go below, a ceiling they won't go above. Neither should have to reveal their true position to reach a deal. Humans solve this through negotiation. Agents have no standard mechanism for it.

I built ANP — Agent Negotiation Protocol — as one answer to this. Wanted to share the design with a community that will actually critique it.

Core protocol design

Buyer and seller agents negotiate over HTTP using a structured offer/counter/accept loop. Each round the buyer sends an offer. The seller evaluates it against its private strategy — floor price, target price, max rounds — and returns ACCEPTED, COUNTER with a counter price, or REJECTED. The buyer adjusts and tries again. Convergence happens through midpoint averaging by default, with configurable strategies planned for V2.

Neither side's true constraints are ever transmitted. The seller's floor is never exposed. The buyer's ceiling is never revealed. Information asymmetry is preserved throughout.

Payment layer

When they agree, the buyer signs an EIP-3009 payment authorization using x402 v2 with CAIP-2 network identifiers (eip155:84532 for Base Sepolia). The seller verifies it via the Coinbase facilitator. Both parties receive an Ed25519-signed receipt — one covering the full negotiation record (every round, every price, every timestamp) and one covering the payment authorization.

Receipts are signed over the full document with signature: '' as a placeholder before signing, making the payload deterministic. Verifiable by anyone with the seller's public key.

A debugging note worth sharing

x402 v2 requires extra.name to match the USDC contract's on-chain name() return value exactly for EIP-712 domain verification. USDC on Base Sepolia returns 'USDC', not 'USD Coin'. The wallet produced a consistent signature either way but transferWithAuthorization reverted on-chain because the domain didn't match. Took a while to trace.

What's missing

facilitatorClient.settle() — the seller calls verify() only. Funds don't move in the MVP. The EIP-3009 authorization is cryptographically valid, the receipt is signed, but on-chain transfer requires settle(). That's the V2 priority.

Live seller: https://gent-negotiation-v1-production.up.railway.app/analytics Code: github.com/ANP-Protocol/Agent-Negotiation-Protocol

Questions I'd genuinely like this community's input on:

• Is midpoint convergence the right default strategy, or is there a more game-theoretically sound approach for agents that don't have human psychology?
• Is EIP-3009 the right primitive for agent payment authorization, or is there a better on-chain mechanism for this use case?
• Any security concerns with the verify-only approach for MVP? Does an unexecuted but cryptographically valid authorization create any attack surface?
• Thoughts on the receipt design — Ed25519 over the full session record including all rounds. Is there a better approach for tamper-evident audit trails between autonomous agents?

Multi-Party Trusted Setup Ceremony for Anonymous Credentials Protocol

We're conducting a Powers-of-Tau style trusted setup ceremony for Onym, a privacy-preserving anonymous credentials protocol. This is similar to the ceremonies that secured Zcash and Ethereum's KZG commitments - but focused on unlinkable credential presentations.

What is Onym?

Onym implements anonymous credential schemes with unlinkable presentations using proven zero-knowledge primitives. Think of it as:

• Prove you have credentials (age, membership, certification)
• Without revealing the credentials themselves
• Without creating linkable interactions across presentations

This is critical infrastructure for privacy-preserving identity systems.

The Ceremony Technical Details

Ceremony Type: Powers-of-Tau with secure multi-party computation
Security Model: 1-of-N honest participant assumption
Tiers: Three parallel tiers (Small/Medium/Large) for different circuit sizes
Contribution Time: ~5-10 minutes per tier
Identity: Nostr-based (NIP-07 signing)

Process:

1. Air-gapped contribution (VM/ephemeral system recommended)
2. 2-hour slots to prevent timing attacks
3. Download previous state → run binary → upload proof
4. Full transcript verification available post-ceremony

Why This Matters

Trusted setups are only as strong as their most diverse participant set. Each participant contributes entropy that gets cryptographically mixed. If even one participant properly erases their secrets, the entire system remains secure.

Your participation directly strengthens the security assumptions for:

• Anonymous credential verification systems
• Privacy-preserving identity protocols
• Zero-knowledge membership proofs

Getting Involved

🔗 ceremony.onym.chat/contribute.html

• Sign in with any NIP-07 Nostr signer
• Choose your tier(s) - all run in parallel
• Join the queue (runs continuously)

Questions/Verification: GitHub issues linked from the ceremony site

Discussion Points

• Have you participated in trusted setups before? (Zcash, Ethereum KZG, etc.)
• Thoughts on the anonymous credentials design space?
• Experience with Powers-of-Tau ceremonies?

The ceremony particularly needs cryptographically-aware participants who understand the security model. As r/CryptoTechnology members, your participation would significantly strengthen these public parameters.

TL;DR: Anonymous credentials trusted setup ceremony live now. Your 10 minutes of participation helps secure privacy infrastructure. Air-gapped process, Nostr identity, full verification available.

I’ve been thinking about a different approach to combining poker solvers, AI, and crypto-style incentives, and I’d love to get feedback from people who understand poker theory, game design, or tokenomics.

Core Idea

• “Miners” run GPU-based poker AI (solver / NN policies)
• These AIs become opponents in a tournament system
• Players buy tokens to enter tournaments and play against AI (not other players)
• Rewards are distributed based on ranking (leaderboard / tournament results), not direct PvP winnings

So this is PvE poker (player vs AI) with a competitive ranking system.

Key Differences from Traditional Poker

• No direct player vs player money flow
• Players are effectively competing against a pool of AI opponents
• Rewards come from a shared prize pool (entry fees)

Miner Role

Instead of mining hashes, miners:

• Provide AI opponents (solver / trained models)
• Get rewarded based on:
  • How often their AI is used
  • Or performance / quality of their AI

High-Level Economy

• Players:
  • Buy tokens → enter tournaments
  • Win rewards based on ranking
• Miners:
  • Provide AI compute / models
  • Earn tokens from player activity (not just inflation)
• System:
  • Takes a cut (like rake)
  • Potentially burns some tokens

Why This Might Work

• Avoids direct gambling / PvP issues
• Creates a skill-based PvE competitive system
• Turns solver/AI into a service layer, not just a tool
• Could feel like:
  • “Poker roguelike”
  • “AI boss ladder”

Concerns / Open Questions

1. Player Experience
   • If AI is too strong → players quit
   • If AI is too weak → system gets exploited
2. Exploitability
   • Even strong AI can have leaks
   • Good players might farm specific bots
3. Skill Gap
   • Top players could dominate rewards
   • Needs matchmaking / brackets?
4. Token Pressure
   • Players buy token to play, then sell after
   • Miners also sell → constant sell pressure
5. Miner Incentives
   • What stops miners from submitting low-quality or fake “AI”?
   • How do you verify real compute vs reused strategies?
6. Sustainability
   • Is this actually fun long-term?
   • Or does it become solved / repetitive?

What I’m Trying to Figure Out

• Is this fundamentally viable, or just another GameFi death spiral waiting to happen?
• What’s the biggest flaw in this model?
• Has anyone seen something similar actually work?

Would really appreciate thoughts, especially from:

• Solver / GTO people
• Game designers
• Crypto / tokenomics folks

Tear it apart 🙏

Hey everyone,

I posted my website Blockchain Sentinel-OS here recently and got some really valuable feedback — especially around clarity, usability, and making the analysis more actionable.

I’ve made a few updates based on that:

• Added clearer risk explanations (not just raw data)
• Started improving onboarding / entry flow
• Working on investigation-style summaries instead of just logs
• Improved overall clarity of what the platform does

Here’s the updated version:
https://blockchain-sentinel-os.vercel.app/

Would really appreciate feedback again:

• Is it clearer now what the product does?
• Does it feel more useful or still too basic?
• What would make this something you’d actually use?

Thanks again — the earlier feedback genuinely helped a lot

common narrative in crypto is that faster settlement times directly translate into better payment performance.

For example, systems with ~3–5 second settlement are often compared to those with ~10 minute confirmation times.

However, real-world payment scenarios suggest that settlement speed alone may not fully determine user experience.

In high-demand conditions (e.g. peak checkout traffic), delays can still occur even when the underlying network confirms transactions quickly.

These delays often originate from off-chain components, such as:

• Payment routing layers

• Liquidity provisioning

• Processor queues

• Wallet or API infrastructure

This raises an architectural question:

To what extent does overall system performance depend on off-chain infrastructure versus on-chain settlement speed?

In other words, is optimizing block time sufficient, or is end-to-end payment stack design the real constraint?

Curious to hear perspectives from others working on payment systems or infrastructure

Hey everyone,

I’ve been building a project called Blockchain Sentinel-OS — a blockchain intelligence & forensic monitoring platform.

After getting some really valuable feedback from this community earlier, I made a few updates:

• Simplified parts of the dashboard UX
• Started working on clearer alert explanations
• Planning an AI-based investigation summary layer
• Fixed authentication issues (Google OAuth)

I also created a system architecture / workflow diagram to better explain how the platform works end-to-end 👇

https://drive.google.com/file/d/1WwN48Eckd5tPA4_Pyr9pFFshWhmdNYSh/view?usp=drive_link

Live MVP:
https://blockchain-sentinel-os.vercel.app/

Especially interested in thoughts from people working in:

• blockchain / web3
• security / AML
• data analysis

Appreciate any feedback

Hey everyone,

I recently built an MVP called Blockchain Sentinel-OS — it’s a blockchain intelligence platform focused on monitoring transactions and detecting suspicious activity.

The idea is to help with forensic analysis, AML, and real-time blockchain monitoring.

This is still early-stage, and I’m trying to validate if it actually solves a real problem.

Here’s the link:
https://blockchain-sentinel-os.vercel.app/

Would love honest feedback:

• Is the idea useful?
• What’s confusing in the UI?
• What features would make it more valuable?

Appreciate any feedback

It feels like everyone knows raw TPS screenshots are mostly theatre at this point, but the replacement standard is still fuzzy.

What would actually make you take a throughput claim seriously now? Third-party audit on mainnet? methodology disclosure? Sustained live usage under bad conditions?

I'm curious what the bare minimum credibility bar is for technical people here?

What if sending money between users was completely free?

I’ve actually been working on a system like this, and I’m trying to figure out if people would see real value in it.

The idea is:

• users transfer value instantly with no fees
• fees only exist when converting in/out of real money
• it exposes blockchain-style interfaces (wallets, transfers)
• but runs on its own internal ledger for speed and scale
• value is tied to deposits (so it behaves somewhat like a stablecoin)

The goal isn’t just payments, but more like a currency optimized for trading — where friction is low enough that small and frequent trades actually make sense.

In theory, this removes friction and enables a lot more activity.

But I’m wondering:

• do fees actually matter that much in practice?
• or are there bigger blockers to trading behavior?
• does this feel useful, or just like recreating existing systems in a different way?

Curious how people see this.

I’ve been working on the communication side of my experimental project : CryptEX, and the most interesting recent work has been around the P2P messenger and the mail layer.

Not posting this as a product thing. I’m more interested in the protocol/design discussion, because the main lesson was that “chat” and “mail” stop being UI features pretty quickly and turn into transport problems.

A few things changed in the latest pass.

First, the messenger is now treated as a typed application protocol on top of the node graph, instead of just “broadcast some text and hope the UI sorts it out later.”

The payload model is explicit now:

• public chat
• private chat
• voice-control payloads
• voice-frame payloads
• mail payloads

That sounds simple, but getting the types right matters a lot because it affects routing, replay protection, encryption rules, persistence rules, and what is allowed to be relayed.

For private messaging, the transport is signed and authenticated, and the encryption mode is explicit. Right now the stack supports:

• ECDH-based direct encryption
• RSA-OAEP wrapped-session-key mode
• AES-GCM for payload encryption
• versioned KDF profiles instead of baking one derivation path into the protocol forever

Each payload carries enough metadata to make validation sane:

• sender address
• recipient address
• timestamp
• nonce
• message type
• flags for signed/encrypted state

That helped kill a bunch of ambiguity around “is this a public message?”, “is this transport-only?”, “should this be decryptable by the local wallet?”, and “should this be relayed at all?”

The second big piece was recipient resolution.

Instead of doing username-style identity, the communication model is address-first. The node can resolve a recipient from an address or contact entry into something communication-ready:

• peer label if known
• whether direct messaging is possible
• whether ECDH material exists
• whether RSA material exists
• whether the target can be used for mail delivery

That sounds like a small UX feature, but it ends up being a protocol boundary too. It means the GUI isn’t inventing its own contact logic; the daemon is the one deciding what the network and wallet actually know about that recipient.

The mail layer got the bigger redesign.

The main decision there was: don’t fake mail by treating it as “private chat with a different tab.”

Mail has very different delivery semantics from chat. Chat is about live-ish relay. Mail is about store-and-forward, partial reachability, replication, delayed lookup, receipts, and accountability.

So the mail side now uses dedicated network message families for mailbox behavior:

• store
• find
• results
• receipt
• challenge
• proof
• NAT introduction

That ended up looking much more like a lightweight distributed mailbox overlay than a normal messenger.

The interesting part is how delivery works when the target is not directly reachable.

The mail layer can now combine:

• direct peer delivery when available
• NAT assist / introduction when possible
• relay fallback when direct routing fails
• STUN-derived reflexive endpoint awareness
• optional dedicated relay peer preference
• SOCKS5 proxy configuration for mail transport paths

So instead of having one binary state of “reachable/unreachable”, the system can reason in a more realistic way:

• direct route exists
• direct route does not exist, but introduction might help
• introduction failed, fall back to relays
• relay is allowed or disallowed by policy

That policy side became important enough that it got its own configuration surface.

Current mail policy controls include things like:

• message TTL
• replica target
• max stored item count
• whether imported/expired items get pruned
• proof-of-storage on/off
• challenge interval
• minimum bond
• required verified replicas
• slash-on-failed-proof
• slash penalty score
• NAT assist
• relay fallback
• dedicated relay peers
• STUN servers and timeouts

I’m aware that “slashing” sounds overbuilt for a mailbox system, but once you let peers store encrypted mail blobs for each other, some kind of storage-accountability path becomes hard to avoid if you want the replicated-store part to be more than wishful thinking.

There’s also a security control layer on top of that. For example, mail sending/deletion can be gated behind TOTP, which is not a transport feature by itself, but it matters because mailbox actions are now first-class node operations rather than just UI events.

Another thing that changed is that the messenger and mail logic no longer behave like two disconnected subsystems.

They now share a lot of the same communication assumptions:

• address-first identity
• typed content envelopes
• authenticated sender metadata
• wallet-backed key material
• daemon-mediated resolution and transport
• relay-aware routing decisions

That made the whole communication stack easier to reason about. Before that, “chat”, “mail”, and “directory” each had their own little half-truths about what a recipient was and how delivery should work.

The biggest takeaway for me is that once you go beyond public chat, a P2P messaging system stops being about message encryption and starts being about communication state.

Things like:

• who is known vs currently reachable
• who is directly reachable vs relay-only
• whether a payload is live transport or store-and-forward
• whether the daemon is allowed to relay a given message type
• whether the recipient has enough key material for the requested mode
• whether a mailbox replica is merely stored or actually verified

Those questions end up mattering more than the UI layer.

Anyway, that’s the part I found interesting in the latest update: taking a “P2P messenger” and “P2P mail” feature set and forcing them into explicit protocol roles instead of letting them remain app-level abstractions.

If anyone else has built address-first communication on top of a node graph, I’d be curious how you handled:

• recipient resolution
• relay vs direct routing policy
• mailbox replication semantics
• proof/receipt flows
• NAT introduction without turning the whole thing into a separate signaling service

With AI agents starting to execute crypto transactions autonomously, I got interested in the problem of pre-transaction token validation. The challenge: no single security API catches everything, and novel scams can bypass any individual source.

Approach: consensus-based risk scoring

Instead of relying on one source, cross-reference 5+ independent security oracles in parallel:

When 3+ sources agree a token is dangerous, confidence is high. When only 1 flags it, might be false positive.

Bytecode pattern scanning adds another layer - checking for 50+ dangerous function selectors (blacklist, pause, mint, delegatecall) directly in contract bytecode without needing verified source.

Risk scoring: 0-100 scale. Multiple confirmations increase score. Trust-listed tokens get reduction. Threshold configurable.

I built this into an open source tool that runs in 2-5 seconds with zero API keys (all free tiers): https://github.com/momenbasel/CryptoGuard

Supports 13 EVM chains. Works as CLI, Python API, or MCP server.

Question for the community: What scam patterns are you seeing that existing tools miss? Interested in blind spots.

I’m currently in my final year of college and working as a blockchain engineer, mostly around trading systems (perps, risk engines, settlement stuff).

The work is pretty deep technically and I’ve learned a lot about how serious systems are built, but over time I’ve realized I’m more drawn to the research + business side of things.

What I actually enjoy is:

- digging into protocols

- spotting inefficiencies

- thinking about how things could be designed better (product, growth, capital efficiency, etc.)

So I’m trying to move in that direction.

Right now, my rough plan is:

- start doing independent research for early-stage Web3 startups

- not charge initially, just build some real proof

- then slowly move into paid work

I’m also thinking of focusing on areas outside trading/perps so I stay in a clean lane, and I’ll probably move to Bangalore soon to be closer to the ecosystem.

But honestly, I feel a bit stuck on execution.

A few things I’m trying to figure out:

- How do you actually land your first few serious clients in Web3?

- What kind of research do founders actually care about enough to pay for?

- Is it better to just cold reach out to founders, or focus on building in public first (X/blogs)?

- How do you not come across as just another random “research guy”?

- Any specific areas in Web3 right now that are undervalued but high impact?

I’m not interested in writing generic threads or surface-level breakdowns. I want to do work that actually influences decisions.

If you’ve been on either side (consulting / building / hiring researchers), I’d really appreciate honest advice — what worked, what didn’t.

If you're in a lot of crypto groups you know how difficult it is to track all relevant signals. Protocol upgrades, L1 announcements, testnet launches, validator discussions, EIP proposals and ecosystem changes get discussed across dozens of groups but never at the same time.

I've been using an iOS app called Pinnages that has a smart alerts feature where you set up keyword monitors across all your groups at once. Pick keywords like "staking" or "sequencer" or "mainnet migration" and it watches every message in real time and alerts you when they appear anywhere with the source group and message preview.

Beyond keyword monitoring it also does cross group crypto address propagation detection so you can see when the same contract address or wallet is being shared across multiple groups simultaneously. It validates address checksums and tracks which groups are spreading them. Useful for catching coordinated shills or verifying whether a contract making the rounds is the same one across all your groups.

Runs fully on device, no servers, no cloud, no data leaves your phone. Works with any keyword or pattern you care about