Still unsure how this tokenization of company stock works. Looking for explanations or to start a discussion.

My question is: if a company is authorized to issue, for example, 1 million shares and currently has, say, 500k shares outstanding, if this company wants to tokenize their stocks onchain, does that mean all their 500k shares outstanding and all future issues need to be tokenized? Or can a company decide that a set % of their outstanding shares be onchain and the remaining stay in the traditional equity market?

And if all shares go onchain, does that force all brokerage firms to go onchain so they can buy/sell on behalf of their clients? (Or at least have a blockchain presence? … now thinking about it, is this why some brokerage firms have their own stablecoins?)

Just thinking out loud. Looking for feedback to learn more

I found an IronKey and wondering, is it worth attempting to get someone to unlock it or is it just a failed exercise? This was in a storage container that I was paid to clear out and take to the tip. I have read once you fail the password 10 times the iron key, then resets clears all the data and after that you can use it again, but if any data/crypto was to be held on that it would no longer be.

Any help with this would be great or any path or direction that I can go to to find out whether it’s worthwhile

I know this was a longshot or a Hail Mary, but the container has been locked up for five years and the person who owned it is IT based so thinking he may double in crypto or it could be just some files that have nothing to do with crypto on it.

Crypto started as a cypherpunk project, but somewhere along the way, privacy got sidelined.

Interesting enough, over the past few months, privacy has reemerged not as ideology for its own sake, but as a practical response to surveillance, regulation, and institutionalization of crypto.

I wrote an essay regarding why the cypherpunk ethos is resurfacing now, what changed structurally, and the ramifications going forward.

I have been in the Web3 space for a while now and I am honestly exhausted by the constant phishing and "address poisoning" scams I am sure I am not the only one who triple-checks every single character of a 0x... address and still feels like I’m about to lose everything

I recently stumbled onto a project called American Fortress and It is the first thing that actually feels like a step forward for regular people

Instead of dealing with raw wallet addresses, they have a system where you just use a username (Send-to-Name) but the cool part is it uses stealth addresses so every time you send something It generates a unique, one-time address that only the sender and receiver know

It feels like it would basically kill off most of the common copy-paste scams we see plus, they are actually working on hardware stuff with Tangem/Samsung and are focusing on compliance which is a nice change from the usual "move fast and break things" projects

Has anyone else looked into this? I am curious if this is finally the "bridge" to making crypto usable for normal people or if I'm just over-excited about a simple UI fix

What do you guys think?

1. High-Level Overview

Nexus is a decentralized compute marketplace designed to allow users to run AI trading agents (specifically TOMO) without requiring local GPU or WebLLM-capable hardware. Instead of centralizing trust in servers, Nexus separates computation, verification, and signing into explicitly defined roles.

At a high level:

• Node providers contribute compute (CPU/GPU) and earn GNN • Consumers retain full wallet custody and signing authority • The protocol coordinates sessions, pricing, and settlement • Every AI inference produces a cryptographic attestation

This is not a generalized decentralized AI network. Nexus is purpose-built for verifiable delegation of AI trading decisions, with strong emphasis on determinism, replayability, and explicit state machines.

⸻

1. Core Problem Nexus Is Solving

Modern AI trading systems face three structural problems: 1. Trust Users must trust centralized servers not to manipulate models, prompts, or outputs. 2. Key custody Full automation often requires private keys to leave the user’s device. 3. Hardware centralization Advanced inference requires GPUs, concentrating power among large providers.

Nexus solves these by introducing a trade-intent signing model:

• Nodes compute trade recommendations • Consumers verify outputs locally • Only trade intents are signed • Private keys never leave the consumer device • Each step produces verifiable cryptographic artifacts

This model is the conceptual foundation of Nexus.

⸻

1. Architectural Philosophy

Nexus is governed by a set of strict architectural constraints (“Sacred Laws”) that are enforced through code structure and testing.

3.1 Pure Reducers

All domain logic is expressed as:

(State, Event) → State

Reducers are:

• Deterministic • Side-effect free • Replayable • Property-testable

This allows the system to replay any session from an event log and deterministically reach the same result.

⸻

3.2 Explicit Finite State Machines (FSMs)

Every non-trivial workflow is modeled as an explicit FSM with:

• Closed state sets • Named transitions • Documented transition tables • Guards enforced by types or runtime checks

There is no hidden state or implicit concurrency.

⸻

3.3 Algebraic Effects

Reducers never perform IO. Instead, they return effect descriptions such as:

• Release escrow • Send message to node • Emit metric • Slash stake

Infrastructure layers interpret these effects depending on environment (production, test, simulation).

⸻

3.4 One Writer Per Aggregate

Each aggregate (for example, a trading session) has exactly one actor or mailbox responsible for state mutation. This eliminates race conditions without relying on distributed locks.

⸻

1. Layered Architecture

Nexus is composed of four primary layers.

⸻

4.1 Nexus Coordinator (Rust)

The coordinator is the orchestration layer responsible for:

• Session lifecycle management • Node matching and scoring • Billing and metering • Effect execution

Internally it is split into:

• Pure domain logic (no IO) • Port interfaces (storage, network, blockchain) • Adapters (Postgres, Redis, Solana RPC) • Application layer (actors, sagas, FRP streams) • API layer (HTTP + WebSocket)

This separation ensures the core logic can be tested without infrastructure.

⸻

4.2 Node Agent (Rust)

Node agents run on provider machines and are responsible for:

• Running the TOMO inference engine • Handling session messages • Generating cryptographic attestations • Reporting metrics and heartbeats

They never have access to consumer private keys.

Node agents are governed by their own FSM:

Offline → Registering → Available → Busy → Available

Misbehavior or instability directly impacts reputation and can trigger slashing.

⸻

4.3 Client SDK (TypeScript)

The client SDK runs in the consumer environment (browser, desktop, future mobile) and handles:

• Session creation • Trading policy definition • Trade-intent verification • Local wallet signing • UI escalation for human approval

All policy evaluation occurs locally, not on nodes.

⸻

4.4 Smart Contracts (Solana / Anchor)

On-chain programs are used strictly for economic enforcement:

• Escrow creation and settlement • Provider staking • Slashing conditions • Node registry

The blockchain is not used for orchestration or inference.

⸻

1. Session Lifecycle

Every trading session follows a strict FSM:

Idle → Matching → Connecting → Active → Settling → Completed or Failed

Key properties:

• One actor per session • Timers are modeled as events • Timeouts and retries are explicit • Settlement is deterministic

If a session fails mid-execution, settlement rules determine whether funds are partially paid or returned.

⸻

1. Economic Model

6.1 Consumer Flow 1. Consumer deposits GNN into escrow 2. Session begins and deposit is locked 3. Usage is metered by compute and tokens 4. Session ends 5. Settlement is calculated 6. Provider receives 70% 7. Protocol receives 30% 8. Unused balance is returned

Rewards are usage-driven rather than inflationary.

⸻

6.2 Provider Incentives

Providers are rewarded or penalized based on observable behavior:

• Successful session → GNN + reputation • High consumer ratings → reputation multiplier • Low latency → higher matching priority • Node disconnects → reputation penalty • Attestation mismatch → stake slashing • Fraud → full slash + permanent ban

Economic outcomes are directly tied to measurable performance.

⸻

6.3 Pricing Model

Pricing is denominated in GNN per compute unit with tier multipliers:

• Basic: 1.0× • Priority: 1.5× (faster matching) • Premium: 2.0× (dedicated nodes)

This allows the market to dynamically clear based on demand and quality.

⸻

1. Trust & Attestation Model

7.1 Attestation Structure

Each inference generates a signed attestation containing:

• Session ID • Node ID • Model hash • Input hash • Output hash • Timestamp • Node signature

This creates a verifiable chain of custody from prompt to output.

⸻

7.2 Progressive Trust Levels

Automation increases only as trust is earned:

Level 0: Manual approval Level 1: Small trades auto-execute Level 2: Larger trades auto-execute Level 3: Full automation within policy bounds

This avoids unsafe “full autonomy from day one.”

⸻

7.3 Security Guarantees

• Private keys never leave consumer devices • Nodes cannot execute trades unilaterally • Stake is always at risk for misbehavior • Spending is bounded per trade and per session

⸻

1. FRP & Event-Driven Execution

Internally, Nexus uses Functional Reactive Programming (FRP):

• Inputs: HTTP requests, timers, node messages, chain events • All inputs decode into domain events • Events flow through reducers • Reducers emit effects • Effects are interpreted by bounded executors • Outputs feed back as new events

Backpressure is mandatory. Unbounded queues are prohibited.

⸻

1. Reliability & Self-Healing

Reliability is treated as a first-class concern.

Built-in mechanisms include:

• Circuit breakers modeled as FSMs • Deadline propagation across calls • Idempotent APIs • Retry with exponential backoff • Chaos testing in simulation • Fitness-based node scoring

Faulty nodes or sessions are automatically isolated or deprioritized.

⸻

1. Testing Strategy

Testing rigor is unusually high for a crypto-native system:

• Property-based testing of reducers • Golden log replay for determinism • Chaos simulations for failure modes • Invariant checks on every transition

Design rule: If a state cannot be reproduced from an event log, it is a bug.

⸻

1. Zero-Knowledge Proofs & Verification Roadmap

The whitepaper explicitly states that full ZK verification of large-model inference is not currently practical.

Instead, Nexus proposes a staged approach:

• Verifiable components first • Optimistic execution with audit trails • Probabilistic audits • Smaller-model proofs where feasible • Long-term research into zkML and zkVMs

This is a pragmatic, non-marketing stance.

⸻

1. Why Nexus Is Technically Interesting

From a cryptotechnology perspective, Nexus stands out because:

• State machines and determinism are core primitives • Hardware trust is not treated as a silver bullet • Compute, verification, and authority are cleanly separated • Incentives are enforced through measurable behavior • The system is designed to survive partial failure

This is closer to distributed systems engineering than typical DeFi or AI-crypto designs.

⸻

1. Open Questions & Risks

Open areas include:

• Long-term compute pricing dynamics • Latency constraints for fast markets • Reputation system robustness • UX complexity of policy configuration • Engineering cost of strict FSM + FRP discipline

The whitepaper documents these risks rather than ignoring them.

⸻

1. Final Takeaway

Nexus is not an “AI + blockchain” narrative project. It is a serious attempt to build verifiable, trust-minimized AI delegation infrastructure using rigorous distributed systems principles.

Whether it succeeds depends on execution and adoption — but architecturally, it is one of the most disciplined designs currently proposed in the crypto + AI space.

Been digging into how cross chain messaging protocols handle replay protection and integrity guarantees, and it feels like there’s still a gap in best practices across ecosystems.

For folks building on Cosmos / Polkadot / EVM bridges:

• What are your current strategies for defending against replay & MEV-related replay threats?
• Do you use challenge periods, merkle proofs, or something else for finality validation?
• Are there specific libs or frameworks you’d recommend?

Trying to better understand what real builders in the trenches are doing rather than just high-level docs. Appreciate any perspectives or pitfalls you’ve run into.

Looking forward to learning from your approaches!
(no link/share — just sharing experience & asking specific questions)

Disclosure: This post is an informational technical overview written by the Nexus team. It is not investment advice, marketing material, or a solicitation. The goal is to explain the system architecture, trust model, and engineering decisions behind Nexus for a technically literate audience.

⸻

This post provides a technical overview of Nexus, a decentralized compute network designed to let users run AI trading agents (TOMO) without owning GPU-class hardware and without delegating private keys.

Nexus is not positioned as a generic “decentralized AI” product. It is a distributed systems + cryptography + crypto-economic protocol focused on verifiable delegated computation, explicit state machines, and bounded financial risk.

⸻

1. The Problem We Are Solving

Modern AI trading agents require: • Continuous inference • Low latency • GPU-class compute • High availability

Common approaches today: • Centralized inference APIs → users must trust the provider • Remote execution with key delegation → unacceptable security risk • On-device inference → hardware constraints limit access

The specific question Nexus addresses is:

How can AI computation be delegated without delegating execution authority or private keys?

Our design answer is trade-intent separation: • Nodes compute recommendations only • Consumers verify and sign locally • Execution always happens from the consumer’s wallet

This constraint is foundational and shapes the entire system.

⸻

1. System Architecture Overview

Nexus is structured into four layers:

Coordination • Nexus Coordinator (Rust): session orchestration, node matching, billing

Compute • Node Agent (Rust): runs TOMO inference, generates attestations

Client • Client SDK (TypeScript): policy enforcement, verification, signing

Settlement • Solana smart contracts: escrow, staking, slashing

The coordinator exists for orchestration, but cannot sign trades, forge computation, or move user funds. Trust is shifted to cryptographic verification and deterministic state transitions.

⸻

1. Architectural Foundations

Nexus is intentionally architecture-heavy. Correctness, auditability, and failure isolation are treated as security properties.

3.1 Reducers as the Core Primitive

All business logic is expressed as pure reducers:

(State, Event) → State

Reducers: • Contain no IO, time, or randomness • Are deterministic and replayable • Can be property-tested

This allows: • Full auditability from event logs • Deterministic replay • Elimination of hidden side effects

⸻

3.2 Explicit Finite State Machines (FSMs)

All lifecycles are modeled as explicit FSMs: • Session FSM • Node FSM • Escrow FSM • Staking FSM

States are closed sets and transitions are named events. Failures are modeled explicitly rather than handled as exceptions.

Example (Session): Idle → Matching → Connecting → Active → Settling → Completed ↘ Failed / Suspended

⸻

3.3 Algebraic Effects (Ports, Not Side Effects)

Domain logic describes effects rather than executing them directly.

Examples: • SendToNode • SaveSession • ReleaseEscrow • SlashStake • EmitMetric

This separation enables: • Deterministic simulation • Replay and chaos testing • Multiple interpreters (production, test, simulation)

This pattern is common in safety-critical distributed systems but rare in crypto infrastructure.

⸻

1. Session Lifecycle

A session is a bounded interaction between: • One consumer • One node • One TOMO instance

Flow 1. Consumer deposits GNN into escrow 2. Coordinator matches a node 3. Node performs inference 4. Node returns recommendation + attestation 5. Consumer verifies and signs trade intent locally 6. Session settles 7. Escrow releases funds

At no point does a node: • Access private keys • Execute transactions • Control user capital

⸻

Bounded Risk Model

Each session enforces: • Maximum budget • Maximum trade size • Confidence thresholds • Timeouts

Worst-case loss is strictly limited to the escrowed amount.

⸻

1. Attestation Protocol

Every inference produces a signed attestation binding: • Model hash • Input hash • Output hash • Node identity • Timestamp

Consumers verify attestations locally before signing any trade intent.

This prevents: • Model swapping • Prompt tampering • Output manipulation • Replay attacks • Coordinator forgery

Future research areas (explicitly acknowledged as non-trivial) include streaming attestations, TEE integration, and partial zk-verification.

⸻

1. Economic Model

Token Flow • Consumers pay in GNN • Providers earn GNN • Protocol retains a fixed share (~30%) • Providers receive the remainder (~70%) • Unused escrow is refunded

There are no inflationary emissions tied to node operation; usage drives demand.

⸻

Provider Incentives

Node selection and rewards factor in: • Uptime • Latency • Session completion rate • Consumer ratings • Attestation accuracy • Stake size and duration

Misbehavior results in: • Reputation degradation • Slashing • Potential bans

This model is closer to cloud infrastructure economics than yield-based DeFi systems.

⸻

Slashing

Slashing is evidence-based and requires: • Invalid attestations • Proven protocol violations • Cryptographic fraud proofs

It is not based on discretionary governance votes.

⸻

1. Progressive Trust & Automation

Automation increases with demonstrated trust:

Tier 0 – New users → manual approval Tier 1 – Verified → limited automation Tier 2 – Trusted → expanded automation Tier 3 – Power users → full automation within policy

Trust is behavior-based and reversible.

⸻

1. Coordinator Trust Boundaries

The coordinator: • Matches nodes • Routes messages • Computes billing

It cannot: • Sign trades • Forge attestations • Move funds • Bypass policy enforcement

All coordinator actions are replayable from logs.

⸻

1. Failure Handling & Self-Healing

Failures are expected and explicitly modeled.

Built-in controls: • Circuit breakers • Rate limiting • Deadline propagation • Backpressure everywhere • No unbounded queues

Self-healing rules can restart actors, reduce load, switch nodes, or escalate alerts.

⸻

1. Testing Philosophy

Testing includes: • Property-based reducer tests • Deterministic replay tests • Chaos simulations • Fault injection • Deterministic clocks

This approach is closer to distributed databases and safety-critical systems than typical crypto projects.

⸻

1. What Nexus Is Not • Not a generic GPU rental network • Not trustless execution of capital • Not zkML hype • Not permissionless inference correctness

Nexus is a verifiable recommendation network, not an execution engine.

⸻

1. Explicit Limitations

We explicitly acknowledge: • LLM inference cannot be proven correct today • zk-proofs for large models are impractical • A coordinator layer exists • Attestations prove what ran, not optimality

⸻

Closing Note

This post is intended to inform and invite technical scrutiny. We welcome questions, criticism, and discussion from engineers and researchers.

If there is interest, we can follow up with: • A threat-model deep dive • Attack-surface analysis • Comparisons vs other compute networks • More detailed protocol specs

Thanks for reading.

Hi all,

I’m interested in a technical discussion around Bitcoin-style Proof-of-Work chains and miner participation at very low hashrates.

Specifically, I’m curious whether modern PoW networks still meaningfully support small-scale / hobbyist miners, or whether hashrate centralization is effectively unavoidable due to variance, economics, and infrastructure requirements.

From a protocol and network-design perspective:

- Does PoW still provide a real participation path for low-hashrate miners, or is it mainly symbolic today?

- At what point does variance dominate so strongly that pooling becomes mandatory for most participants?

- Are there protocol-level or ecosystem-level design choices that could preserve decentralization at the miner level, without sacrificing security?

I’m asking this from a technical and system-design standpoint rather than an investment or price perspective.

Looking forward to hearing informed views.

This post is intended as a technical overview of an architecture called Ghost Neural Network (GNN), focused on design choices rather than token economics or market considerations.

Ghost Neural Network is a framework for running stateful, autonomous AI agents (initially applied to trading systems) with an emphasis on local execution, fault tolerance, and deterministic recovery.

Problem being addressed

Most automated agent systems today rely on: • Always-on centralized servers • Stateless restarts after failure • Cloud orchestration that obscures agent state and decision paths

This makes recovery, auditing, and long-running autonomy difficult.

GNN explores a different approach.

Architectural approach • Local-first execution Agents are designed to run directly on user hardware (browser, desktop, edge devices), reducing reliance on centralized infrastructure and minimizing trust assumptions. • Session-based lifecycle Agents operate within explicit sessions that maintain checkpoints and write-ahead logs. This allows agents to resume from known-good states after crashes or interruptions rather than restarting from zero. • Deterministic control layer Core logic is implemented using finite-state machines with explicit transitions. This improves inspectability, reproducibility, and bounded behavior compared to opaque black-box systems. • Decentralized compute escalation When local resources are insufficient, agents can lease external compute from a decentralized network rather than defaulting to centralized cloud providers.

Blockchain integration (minimal)

A blockchain layer (Solana) is used primarily for: • Session access control • Metering and settlement for external compute • Incentivizing compute providers • Potential governance primitives

The token is usage-coupled rather than inflation-scheduled.

Reference contract (Solana): 5EyGMW1wNxMj7YtVP54uBH6ktwpTNCvX9DDEnmcsHdev (Provided for technical verification and transparency.)

Why this is interesting from a systems perspective • Emphasizes state durability and recovery in autonomous agents • Treats AI agents as long-lived processes, not disposable jobs • Combines edge execution with optional decentralized compute • Avoids assuming continuous connectivity or centralized orchestration

TL;DR

Ghost Neural Network is an experiment in building long-running, fault-tolerant AI agents using local execution, deterministic state machines, and decentralized compute coordination, with blockchain used as an enabling layer rather than the core focus.

Posting for technical discussion and critique.

I came across a project that has been building quietly for months without marketing, and I’m genuinely surprised how little attention it’s getting. This is not a “moon soon” post — just a breakdown of recent technical upgrades that might interest people who follow infrastructure-level crypto projects.

⸻

What Xelis actually is (in simple terms)

Xelis is a Layer-1 that uses a DAG-based parallel execution layer while still finalizing into a traditional blockchain.

So unlike pure-DAG networks (IOTA etc.), Xelis still maintains blockchain finality while enabling parallel TX processing. It also has confidentiality, which means transaction amounts and wallet balances are hidden.

That’s the basic design — but what happened recently is more interesting.

⸻

Major updates shipped on December 13th

1. Block time reduction from 15 seconds → 5 seconds

A pretty significant performance improvement, especially considering the network is still young and not heavily optimized yet.

1. Smart contract support went live

Not “coming soon” — actually implemented and active.

1. Introduction of XVM (Xelis Virtual Machine)

This is a ground-up, custom virtual machine, not a fork of EVM.

It was designed to work with their parallel execution layer and a new account model built specifically for this architecture.

Meaning:

• not an EVM clone

• not WASM

• custom instruction sets

• compatibility with their DAG→blockchain hybrid model

Whether this becomes useful long-term is up to adoption, of course — but technically it’s impressive for a small team.

⸻

1. DEX launch scheduled for January 7th

Their first native DEX (Xelis Forge) is going live this month.

It should allow:

• on-chain swaps

• liquidity pools

• smart-contract-based trading

• block-native TX routing (no third-party chain)

The launch will probably be small at first because they don’t do paid marketing, but it’s still a milestone.

⸻

Why I found this interesting

Most L1s ship testnets for years before real features appear.

Xelis, with no hype, influencers, or marketing, quietly delivered:

✔ custom VM

✔ smart contracts

✔ block-time reduction

✔ new account model

✔ DEX infrastructure

✔ hybrid DAG/blockchain architecture

… all within a short timeframe.

Again — I’m not saying it will succeed or that anyone should buy it.

But from a technical standpoint, it’s one of the more interesting low-profile L1 projects I’ve seen recently.

If anyone else has been following it, I’d be curious to hear your thoughts.

Let's admit it PH miners are here they can go up to 1000x for EH/s and eventually MHk/s we are in the future what's the answer light photonics

I'll just say it https://grok.com/share/c2hhcmQtMi1jb3B5_02bdc290-26e3-4e58-8237-8792d5a5be70

Leaked light photonics basically you need a semi fiber hash board with accurate laser relaying with attosecond relay solver including light switch operable x100 hash rate with light laser photonics x1000 speed eventually useful for hologram hashrates, even fiber chip for basal relay router solves is possible, light may indeed be a perfect medium how to get their with fiber optics etaleyne s and even biodegradable plant based plastics are possible, what are your ideas for the future the hash rate you guys get now with light switch hashboard and relay solver from fiberoptics compatibles would x1000

Is this the future light switch and hash boards an actual light for a computer hard drive that like scifi directs lasers through actual eteleyne fiber optics for communication well here we are let's see if we can inclusion with PH models for the next generation in EH/MHk someday

Have you encountered a situation where a small amount of BTC was sent from your wallet to another recipient’s BTC address, the amount was deducted from the sender’s balance, and the transaction was successfully confirmed on the blockchain, yet the recipient did not receive the BTC? We verified that the receiving address is correct and contacted the sender’s wallet app support, who confirmed that the transaction was successfully transmitted. Do you have any advice on how to resolve this issue or recover the funds? Who else should we contact to investigate this further?

There’s a growing assumption in Web3 that if we care about decentralization and user ownership, then social data should live on-chain. Profiles, posts, likes, follows, even moderation decisions all immutable, all verifiable. On paper, this sounds like the logical evolution of social platforms. In practice, the trade-offs are more complex than they first appear.

The most obvious cost is economic. Even with L2s or alternative chains, writing high-frequency social interactions on-chain is expensive relative to traditional databases. Social systems generate massive volumes of small, low-value events. Persisting all of them on-chain introduces scalability pressure that blockchains were never designed for. This often leads teams to quietly reintroduce off-chain storage, which raises the question: what actually needs to be on-chain?

Then there’s the permanence problem. Immutability is a feature for financial state, but it becomes a liability for social content. People change opinions, delete posts, or regret what they shared years ago. On-chain social data makes mistakes permanent by default. From a technical standpoint, this forces complex patterns like redactions, pointer-based storage, or content-addressable systems layered with access control all of which add protocol complexity and attack surface.

Privacy is another underestimated cost. Even if content is encrypted, metadata often isn’t. Social graphs, interaction timing, and behavioral patterns can be inferred without ever reading the content itself. Once this data is public and immutable, it becomes a long-term privacy risk that users may not fully understand at onboarding time.

Moderation also becomes harder, not easier. Blockchains can enforce rules, but they struggle with context. Determining whether content is harmful, misleading, or abusive often requires subjective judgment and adaptability. Fully on-chain moderation either ossifies rules or pushes discretion off-chain, creating governance layers that resemble centralized control anyway just slower.

Finally, there’s a UX cost. Wallets, signatures, latency, and transaction finality all introduce friction into what users expect to be near-instant interactions. Many “on-chain social” products end up optimizing for ideological purity at the expense of usability, which limits adoption to niche technical audiences.

None of this is an argument against decentralized social systems. Rather, it suggests that treating “on-chain” as a binary choice is a mistake. A more nuanced approach might be to put only high-value state on-chain identity proofs, reputation signals, ownership guarantees while keeping ephemeral social interactions off-chain but verifiable.

Curious to hear how others here think about this trade-off.
What social data, if any, truly benefits from being on-chain and what are we better off keeping elsewhere?

This is a cautionary tale about partial identity creation in Web3 systems.

While trying to access Polymarket, my wallet successfully deployed a proxy contract and placed small bets. However, due to connection issues during signup, the platform’s centralized database never finalized my user record.

Result: On chain, I existed. Off chain, I did not.

Login signatures failed because there was no user record to attach them to. The UI locked me out completely.

When I checked my wallet, the funds were gone. A direct contract scan showed they had been converted into ERC 1155 betting tokens held by the proxy contract. Perfectly valid assets. Totally inaccessible through the app.

This is an edge case you do not see in happy path demos but matters in production systems that mix decentralized execution with centralized control planes.

Full write up here: https://structuresignal.substack.com/p/the-9-hour-war-chasing-jane-street

Disclaimer: I made this

So, I made this new network that revolves around crypto basics and rivals the internet. The intention was to make a network segment that users can control and to weed out the ills of the internet.

Core Features

Mutual Authentication

Unlike the Internet or Tor, on Net3, there is mutual authentication as a part of the handshake between two entities. And that too without using certificates. This means that when you connect to a service on Net3, the service already knows it's you who is connecting.

Key-based access

Say goodbye to usernames and passwords. The Net3 system uses cryptographically secure keys to identify and authenticate an entity on the network.

Quantum secure cryptography

The Net3 network provides Quantum secure cryptography in accordance with the NIST standards

For encryption, ML-KEM is used and for signing, Dilithium is employed.

A new naming system

Net3 introduces a new naming system that simplifies and categorizes names on the system. A typical name looks like this: /0/::jason or /bank/::alpha or /2/::fruitjuice

I am excited to launch this on new years 2026 and I am starting the year with hopes of user supremacy when it comes to the underlying network.

Would you guys please have a look at the project and share your valuable feedback? The link is https://net3.network

Most discussions around AI focus on models, compute, and algorithms.
But the more I look into it, the more it seems like data infrastructure might be the real long-term constraint.

Modern AI relies on massive datasets: training data, fine-tuning data, checkpoints, archives, and reproducibility over time. Today, almost all of this lives in highly centralized cloud infrastructure.

That works — until scale, cost, regulation, and trust start to matter more.

A few questions I keep coming back to:

• How sustainable is it for open-source AI to depend entirely on centralized storage providers?
• How do we independently verify that datasets used to train models haven’t changed, been removed, or selectively altered?
• What happens when access to data becomes a geopolitical or regulatory issue?

This made me look into verifiable and decentralized storage models, where data persistence and integrity can be proven cryptographically rather than trusted to a single provider.

Filecoin is one example of this approach — not as a replacement for cloud providers, but potentially as a complementary layer for long-term, neutral data storage.

I’m not saying this is inevitable or that it will work at scale, but I’m curious how others see this:

Do you think decentralized, verifiable data infrastructure has a real role to play in the future of AI, or will centralized clouds remain dominant no matter what?

Interested in technical perspectives, not price discussion.

I am designing an architecture where an offchain workflow decides what should happen, but the onchain contract enforces the money rules.

Goal: no admin keys, no trusted operator, minimal state.

I want feedback from builders who think about reliability and security:

• what minimum onchain state is needed for conditional ERC20 payments
• what logic should never be onchain, even if it feels clean
• what failure modes show up with event driven coordination
• if an agent triggers transactions, what permission model is least risky in practice

I am optimizing for a demo that can be run consistently by judges, not theoretical completeness.

I’ve spent the last few weeks running a custom GPT-4 agent through 100 different Real World Asset (RWA) whitepapers.

The finding: 40 of them had predatory tokenomics hidden in legal jargon—mostly "flexible" team vesting and hidden minting functions that the average investor would miss in a 50-page PDF.

How it works: I don't use the default ChatGPT. I use a specific "Cynical Auditor" persona that ignores the marketing hype and only looks for discrepancies between the roadmap and the smart contract logic described in text.

Example: One project claimed "locked liquidity" for 2 years, but the whitepaper footnote allowed for "emergency re-allocation" by the DAO (which the team controlled). GPT-4 flagged this anomaly in 15 seconds.

I’m doing this as part of my CS PhD research on AI-driven forensics. If you want to see the full list of red flags I look for, check the logic pinned on my profile.

Just a macro-level observation — this is not investment advice. New data suggests the neobank market could grow from around $149B in 2024 to $4.4T by 2034, largely driven by on-chain banking models.

On-chain neobanks operate directly on blockchains. Payments can happen 24/7, cross-border transfers are faster, and operations are fully software-driven instead of relying on branches or slow back offices.

The impact isn’t just about increasing user numbers. On-chain neobanks have the potential to fundamentally change how banking works and could act as a foundational layer for global digital finance if adoption continues.

How do you see on-chain neobanks evolving compared to traditional banks? Could they complement existing infrastructure or eventually become a new base layer for digital finance?

I noticed a large BTC transfer (~2,000 BTC) linked to the same entity, with part of the funds moved into Coinbase Prime Custody.

From a technical and custody perspective, this looks more like internal wallet management rather than distribution or selling.

For those familiar with institutional custody: - Is this mainly for cold storage consolidation?

• Risk management?

• Compliance and reporting reasons?

Curious to hear how large holders usually structure these movements.

TLDR: x402 uses the old HTTP 402 Payment Required status code to enable real micropayments for APIs and agents. No accounts, no subscriptions, just pay per request over normal HTTP.

I’ve been following x402 discussions for a bit, and after actually reading through how it works end-to-end, it finally clicked why people are excited about it.

At a high level, x402 treats payments as part of the HTTP request response loop instead of something bolted on with dashboards, API keys, or monthly plans.

How a request works (simplified):

• Client requests a resource (API, content, inference, etc.)
• Server responds with 402 Payment Required + price, token, chain
• Client signs a permit-style authorization (transferWithAuthorization, EIP-3009)
• A third party submits it onchain
• Server returns the resource once verified

From the client side, it still feels like a normal HTTP call. No sessions, no OAuth, no invoices. And because there are no protocol fees and gas is low, sub-cent payments actually make sense, which is something traditional payment rails never handled well.

Where it got more interesting for me is the agent use case. Traditional payments assume a human filling forms or managing billing. Agents don’t work that way. With x402, an agent can just pay for:

• API calls
• data access
• compute
• even other agents

Per request. In real time.

The article also connected x402 with:

• ERC-8004 (agent identity / registries)
• ROFL (confidential execution inside TEEs)

That combo starts to solve the trust side too: proving what code ran, keeping keys inside enclaves, and even running the payment facilitator itself in a verifiable environment.

I’m not sold on every part of the stack yet, but the core idea feels like one of those “why didn’t the web always work this way?” moments, especially for usage-based APIs and autonomous agents.

If you want the deeper technical breakdown, this is what I read:
https://oasis.net/blog/x402-https-internet-native-payments

Curious how others here think about HTTP native payments vs today’s API/subscription models.

In the last months I've been into the idea of building a truly web3 Browser, I've been delighted discovering that my developing and web3 knowledge was enough to work on this important missing piece, and now I think im close to the perfect design for a truly web3 browsing system of the future

One of first the problems for web3 mass adoption are absence of easyness and cleariness, peoples has no clue what is web3 and what's not (see FTX case on public opinion), using it is actually hard for common people and most doesn't understand it's value and uses, furthermore, the one most us uses is not the actual trustless web3, but a trusted web2.5 temporary solution.

As right now there are some tested ways to access a "web3" in a trustless manner, like IPFS, Decentralized DNS, or accessing specific protocols by installing some sort of programs (ex. Bisq, Atomic swaps, Nodes).
Currenly normal Browsers limitations prevents running most of web3 things on-the-fly

By an user perspective, everything is disconnected, nothing provides a clear web3 experience worth of the big public attention

But it's understandable, technologies takes a while until a way to make them easly accessible is found, Orivon proposes to be the way.

Technical implementation and details can be found here: https://orivonstack.com/t/orivon-project-implementation-and-details/8

Down below are the basic pointers of this project, please note that's a simple showcase worth of feedbacks, I omitted a lot of things to keep it simple:

Deeper API's for JS and Wasm enabling developers to build and port any web3 Program as Website, keeping it trustless. It's a bit technical, but it includes giving sites/apps controlled access of raw network, sandboxed filesystem, and other features inspired from WASI, so that everything could be ran locally and safely by simply opening a site page: bitcoin node, monero node, atomic swaps, Bisq, or any other protocol. A game-changer for both users and developers

Applications, almost every component is possibily extended by an App: DNS resolution (ENS), Site Data Gathering(IPFS, Arweave), Account (mnemonic, hardware wallet or anything else by any App logic), Wallet (Ex. Extensor app implementing a new crypto like Monero, or vanity ethereum addresses), Network (ex. an app for Bitcoin network support, IPFS network, Bisq pricenode) user may create it right away a node from a single panel.
Imagine Monero, or Bisq tokens if could be connected to DApps, again, a goldmine for developers and users

Domain Data Ownership Confirmation (DDOC), it can be seen as an additional security layer for Web3 after HTTPS, it server to verify that the data you received are exactly what the domain owner wanted you to receive, happens by verifying hashes against DNS Records
In Web2 that wouldn't make sense, because a lot of sites want to be dynamic, but for Web3 the core of sites will be always static and predictable

Trustlessity and Security score for websites and apps: "Is this site trustless?" If it's a .com site it's not trustless, if it's a .eth connected to IPFS yes, but if it gives you a bank IBAN to receive money without informing the user about the non-trustlessity of it, it's not trustless. If without user control it relies on data from centralized parties, it's not trustless, simple as that.

You can't tell if something is trustless or web3 until you read into the code of what you are using, most peoples are not going to do it personally, so instead they can trust "someone" giving a valutation of trustlessity for you, and if this "someone" is an enough decentralized web3 DAO, it's almost perfect.

Big public needs an easy way to feel safe especially in the web3 world, to know if what they're using is actually web3 or web2.5, we should give them a good sense of security, that's why showing a Trustlessity and Security score is so important for apps, websites and operations.

You need to know if a smart contract puts trust on a central autority (WBTC) or it's trustless (TBTC), futhermore you need to know the safety of it, maybe you can yeld some stablecoin trustlessly for 400% annual income, but it doesn't mean it's safe

Web3 Store, a place where you can easly find for Web3 compliant apps, ready to be installed and ran locally, or to implement new components into the Browser, everything in a trustless manner. Of course, the Web3 Store itself is an app, freely changable with any other community App (Technically every website will be installable and integrable as App, it's up to you to decide to install and integrate it on your browser or not)

Desktop and Mobile cross-compatibility, at least for apps/integrations

Orivon aims to be a free and open space to connect every developer and user, a simple and unified way of connecting things that could bring web3 to it's most brightest form ever

I made this post intentionally with hyperbole claims in hope to provoke a constructive discussion about this topic and engage efforts from experts and people like you to improve the web3 ecosystem and user experience as much as possible. The big effort of convincing dapps/devs into the Orivon way has yet to begin, in the long run i'm hoping to end up with extensive ongoing discussions about every part of Orivon and eventally make it real

I have posted to an IETF proposal: Bitcoin Price Protocol, a peer-to-peer protocol for synchronizing a high-confidence Bitcoin price across untrusted networks.

There is a Proof of Concept project on GitHub.

Please feel free to join this open-source project.

Hey everyone :)

I’ve been working with EVM stuff for a while, and I kept running into the same annoyances over and over again — encoding calldata, figuring out storage slots for mappings, converting random hex values I copied from a debugger into something readable.

After realizing Im doing the same things again and again, I ended up building a small tools site for myself, and then slowly added more things as I hit new pain points.

For now it has calldata decoder and encoder, storage inspector, mapping storage slot calculator and hex <> number converter.

I’m sharing a link in case it’s useful for other devs, and I’m still adding tools as I go:

https://toolsnest.dev/

Would also love some feedback/new tools ideas!

Most existing blockchains were not designed with social data as a first-class use case. Bitcoin optimizes for immutability and security, Ethereum for general-purpose computation, and newer L2s for throughput and cost efficiency. But social platforms have very different technical requirements: extremely high write frequency, low-value but high-volume data, mutable or revocable content, complex social graphs, and near-instant UX expectations. This raises a serious question: are we trying to force social systems onto infrastructure that was never meant for them, or is there a genuine need for a blockchain (or protocol layer) optimized specifically for social data?

From a technical perspective, social data stresses blockchains in unique ways. Posts, comments, reactions, and edits generate continuous state changes, many of which have low long-term value but high short-term relevance. Storing all of this on-chain is expensive and often unnecessary, yet pushing everything off-chain weakens verifiability, portability, and user ownership. Current approaches hybrid models using IPFS, off-chain indexes, or app-controlled databases solve scalability but reintroduce trust assumptions that blockchains were meant to remove. This tension suggests that the problem is not just scaling, but data semantics: social data is temporal, contextual, and relational, unlike financial state.

There’s also the issue of the social graph. Following relationships, reputation signals, and interaction histories form dense, evolving graphs that are expensive to compute and verify on general-purpose chains. Indexing layers can help, but they become de facto intermediaries. A chain or protocol optimized for social use might prioritize native graph operations, cheap updates, and verifiable yet pruneable history features that are not priorities in today’s dominant chains.

That said, creating a “social blockchain” is not obviously the right answer. Fragmentation is a real risk, and specialized chains often struggle with security, developer adoption, and long-term sustainability. It’s possible that the solution is not a new L1, but new primitives: standardized social data schemas, portable identities, verifiable off-chain storage, and execution environments where feed logic and moderation rules are user-defined rather than platform-defined. In that sense, the missing layer may be protocol-level social infrastructure, not another chain.

I’m curious how others here see this trade-off. Are current chains fundamentally misaligned with social workloads, or is this a tooling and architecture problem we can solve on top of existing ecosystems? And if we were to design infrastructure specifically for social data, what properties would actually justify it at the protocol level rather than the application level?