@frank-thetrader.bsky.social Long time no see — hope all’s good on your end.

SHDW will be part of the Solana Privacy Hackathon on 12 Jan We’re bringing our entire privacy stack, agent-native execution, quantum-safe cryptography, & x402 infrastructure, to test privacy where it matters most: real builders, real constraints, real scale Stay in the dark x.com/shdwapp/stat...

x.com/santiagoroel... Seeing data like this makes it clear why infra on Solana still has huge asymmetry. $SHDW is positioned exactly where the next wave of real demand will hit- storage and on-chain data. One of the few infra plays still severely undervalued relative to where the ecosystem is going

@genesysgo.bsky.social Privacy + storage are leading the market—FIL up 96% shows the demand. SHDW hasn’t even been priced into this rotation yet. The opportunity is wide open once real workloads hit Shadow Drive. What’s your read on this window, @frank-thetrader.bsky.social ?

Never been more excited to sign an NDA before 🔥🔥🔥

And, regardless of what anyone thinks, we will deploy this network so everyone can see what’s possible. After that, everyone can individually decide what they think of it and what they will or will not do with it. Hope that helps!

Oh… it’s literally night and day… one was a dumpster fire and the other actually works and does what it says it does. I’m not at all proud of how v2 went, it was embarrassing. Many many developmental failures, but AI wasn’t good enough yet for me to jump in and do it myself.

Nice progress on cleaning and refining aspects of the gossip network over the past few days!

In building v3’s codebase, I created a dedicated module whose sole purpose is to manage the FFI surfaces. This bridge is how the iOS app initializes the storage runtime on the mobile device. Why this is important is bc when we port to Android, it means simply adding new surfaces to one just module

Keep peepin’ the commits. Scrubbing module by module

Home stretch! Everything runs, the iOS app builds and runs perfectly! Now, it’s just a matter of going module by module to clean up any AI slop remaining and optimize the codebase… but, it all works!

Weeeeee!

I’m pretty excited to announce that the actual storage runtime for shdwDrive v3 is basically done! Steven and I have some bug hunting to finish up, but I’ve moved onto polishing the iOS app. In the coming weeks, I’ll be able to give a more definite time frame as far as an actual release date!

Of course!

Now just need to wire the new runtime together with the iOS app and can submit to Apple for publishing! Then I can finish working on compute (which is about 40% finished. Fun times!

Omg… I think it’s finally where I want it to be! I basically designed a lightweight protocol, perfect for mobile devices, that puts the responsibility for verifying that a node is running authentic unmodified software on the node itself, as opposed to the network.

👀

I mean… why not…

The sheer amount of people on CT who wrecked themselves literally for no reason other than they got their feelings hurt will never cease to amaze me. No wonder ya’ll can’t get ahead… say whatever you want about how emotional I may or may not be… I don’t trade on emotion and neither should you.

As v3 continues to take shape, there are more updates on the way! Including updates regarding a return to Twitter and expansion of social media to other platforms. Stay tuned

You can just do things. It’s literally that easy.

Ultimately, both. I’m building strictly for iOS right now though.

Fired up 13 fully functioning shdwNodes running v3’s storage runtime as Rust processes in Docker containers… this is the full storage runtime with all the bells and whistles… and, as they all started gossiping and sharing files, for the first time ever… I heard my macBook Pro’s fan kick on 🤣🤣🤣

Got 9 simulated iOS devices successfully gossiping and performing storage operations between one another! The network’s properly erasure coding files and distributing the shards amongst the simulated operators. Nodes are even verifying one another using App Attest Certs. So close!

lfg

Not a bad sized commit lol

Weeee modules #2-4 finished and running properly!

- Providing accurate query results for reachability and ancestors - Managing memory through pruning while maintaining data integrity - Performing concurrent writes and maintenance to ensure persistence of the history of the network’s graph - Consistently detecting and pruning Byzantine forks

Disclaimer: Integration tests DO NOT give any insight into how the entire platform comes together and runs. What is exciting though is that it took three developers nearly six weeks to build the v2 equivalent of what v3’s Module #1 does… #AI did it in less than 24 hours… devs are so cooked.

All of this is happening across multiple physical test nodes running on multiple devices connected via different networks (some are on Wifi, some are on cell networks). As said, still have 14 more modules to build before shdwDrive v3’s reworked consensus engine is complete… but off to a good start!

What does operational mean? Well, as we speak it is - Building valid DAGs with multiple nodes creating events - Persistently storing & managing DAG growth on the local device - Handling concurrent event insertions from multiple nodes at once - Processing out-of-order events correctly

Module #1 is fully operational! Here’s what it is solely responsible for: - Maintains the DAG of gossip events - Validates node operator signatures/attestations - Tracks seen relationships - Assigns levels/checkpoints as the DAG grows - Manages local storage of the DAG history and its metadata

One module down, 14 more to go. To be clear, unit tests don’t mean everything will automatically work perfectly fyi. Unit tests verifies that the code is valid and buildable, it does not confirm that the application will “work” when ran. However, the integration tests are also now passing 😈

The existing consensus engine for shdwDrive v2 is garbage (and basically non-existent). Somehow, we went from a fully functioning consensus engine (remember Solana XRoads when we debuted the mobile testnet?) to a barely functional mess. It’s my fault for giving people too much freedom and trust.

Somewhere along the line they strayed tremendously from first principles. By the time shdwDrive v2 launched, the consensus engine for v2 was this aberration that had somehow started using libraries that are widely known for being incompatible with mobile devices… Again, my fault for trusting.

shdwDrive v3’s consensus engine returns to the first principles that I had been championing to our former team for almost two years…

1. Trust Comes from Hardware, Not Humans Nodes prove they’re real and unmodified using hardware-backed attestation, not by holding tokens or credentials. Trust is earned at runtime, not assumed by default.

2. Consensus Should Be Asynchronous and Leaderless DAGGER avoids leaders, rounds, or global sync. Events propagate freely through gossip, enabling continuous progress across disconnected, mobile nodes.

3. Finality Should Be Emergent, Not Imposed Finality happens when enough of the network has observed an event — not because of a round number or election. It emerges from the DAG itself.

4. Every Node Is Equal — Until Trust Expires Every device in the network is an equal participant, but only if it stays active and proves it’s secure via device-level attestation. If a device stops checking in or can’t prove it’s real, the network simply ignores it.

5. Consensus Must Be Mobile-First and Bandwidth-Respectful DAGGER is built for phones. It assumes spotty connections, 5G or Wi-Fi, and limited resources — and still delivers fast, secure consensus.

Thus far, the iOS app works flawlessly and all of the entry points needed to turn on the network work perfectly in tests. Now I’m building out all of the Rust components that drive the actual shdwDrive v3 network itself. Meaning, the consensus mechanism and the gossip network.

The last of the architectural design modules for shdwDrive v3’s newly designed consensus engine are finally finished. Now to get to building them. At some point, I’ll compile all 15 module documents and publish them.

Tell me why “shdwdrive.com” was being hosted using WebFlow for hundreds per month when we literally have nearly unlimited compute and storage resources available… 🙄 This is what happens when I give people too much freedom. The real issue is WebFlow’s vendor-locks…

#AI totally breaks vendor-locks though. Not only was I able to use Claude Code to get all of the assets easily, directly from the web, but CC also updated the codebase to remove all the vendor-locks. Now just waiting on DNS to update and “shdwdrive.com” will be back online.

Seeing memecoin garbage like `Pump.fun`, retardio, Ai16z, GMGN, and more banned across all of X almost makes me want to return to the platform ngl

A shdwDrive Thread: So, it’s completely accurate to say that the deployment of shdwDrive v2 was an utter mess. Many parts of shdwDrive v2’s architecture made absolutely zero sense. However, one of the things that is the most game changing about AI is that nobody can hide bad code anymore.

Getting closer!

Omfg… literally nothing feels more satisfying then seeing, “Build Succeeded” in Xcode 🔥 🔥 🔥

IYKYK