HomeOur Blog

XYO Adds Auto Drive as a Supported Data Lake in the XYO SDK

Share to Socials

The data behind a proof on XYO Layer One lives outside the chain, in a Data Lake. Developers building on XYO now have a storage option for that data that cannot expire, be deleted, or be altered after the fact.

‍

XYO has added Auto Drive as a supported S3-style Data Lake in the XYO SDK. Developers building on XYO Layer One can now store the data behind their transactions on Auto Drive, the permanent storage gateway from Autonomys Network, using the same SDK modules they already use today. XYO has published a working sample project that runs the complete flow end to end.

Who XYO is

XYO is the original and one of the largest Decentralized Physical Infrastructure Networks (DePIN), with more than 10 million nodes collecting and validating real-world data. Its Proof of Location and Proof of Origin technologies validate that data at the source, which makes XYO a trusted input for AI, geolocation, real-world asset tracking, gaming, and other sectors that depend on knowing what actually happened in the physical world.

‍

XYO has since expanded its ecosystem with XYO Layer One, a blockchain purpose-built for the data demands of DePIN, real-world assets, and AI. XYO Layer One runs on a dual-token model. The XYO token supports the DePIN ecosystem, rewards, staking, and governance. The XL1 token handles transactions and fees inside XYO Layer One itself.

The problem every high-volume chain has to solve

A network that verifies real-world data at XYO's scale produces far more data than any chain should carry. XYO solves this with an architecture first described in its original 2018 white paper: Archivists. The modern, lighter-weight version built for XYO Layer One is called a Data Lake.

‍

The design is simple. XYO Layer One records a compact, verifiable reference to each piece of data. The data itself lives in a Data Lake. Because the reference is derived from the content, anyone who retrieves the data can confirm it is exactly what was recorded, without having to trust whoever is storing it. The chain stays lightweight. The data stays verifiable.

‍

That design puts real weight on the Data Lake. If the stored data disappears, the reference on XYO Layer One still exists, but it points at nothing. If the data is altered, the reference no longer matches, and the record is broken. For applications built on proofs of location and origin, that is not an edge case but the failure that matters most.

What XYO released

The XYO SDK supports several storage backends for Archivists and Data Lakes. S3-compatible object storage is handled by the @xyo-network/archivist-s3 package, and that package now includes a dedicated Auto Drive module. A developer imports createAutoDriveArchivist, supplies an Auto Drive API key, a bucket, and a key prefix, and the SDK handles the rest. There is no custom integration to write and no separate client to maintain.

The published sample project shows the full loop in a single command-line tool. It takes a message, stores it on Auto Drive through the XYO adapter, reads it back to confirm the content and its hash match, signs a transaction with the AriesTools CLI wallet, anchors the reference on XYO Layer One, waits for the transaction to be confirmed as final, and prints a link to it in XYO Explore. Storage is verified before anything is broadcast, and verified again after inclusion.

What this means for developers building on XYO

Auto Drive is built for the job a Data Lake needs done.

The data does not expire. Auto Drive has no pinning, no renewal, and no ongoing fees for data already stored. Once a payload is written, it stays retrievable. There is nothing to renew and nothing to let lapse.

The data cannot be altered or deleted. Auto Drive's S3 interface returns an error on any delete request by design. Re-uploading the same key creates a new object rather than overwriting the old one. A reference recorded on XYO Layer One will always resolve to the same bytes it was created from.

The verification model matches. XYO Data Lakes derive keys from content so that readers can check what they receive. Auto Drive stores every object under a content identifier and returns that identifier with each response. The two systems make the same promise at different layers.

It fits the existing S3 workflow. Auto Drive's S3-compatible layer supports the operations the XYO adapter relies on, including standard and multipart uploads, object retrieval, and listing. Teams already using S3 tooling with XYO do not need to change how they work.

It is free to start. Every Auto Drive account receives 20MB of upload capacity and 5GB of download capacity per month at signup. Beyond that, teams purchase additional storage directly. Companies bringing paying customers to permanent storage can also apply to the Subspace Foundation Grants Program.

Try it

  1. Sign up at ai3.storage and create an API key in the Developers section.
  2. Clone the autodrive-datalake-sample repository and follow the README.
  3. For a first run that needs no XL1 test tokens, pnpm test:live writes a real payload to Auto Drive through the XYO adapter using a disposable local chain and wallet.

Full details on the Auto Drive S3 layer are in the Autonomys Developer Hub. Details on XYO Data Lakes and the XYO SDK are in the XYO documentation and the XYO AI SDK skills repository.

Why this matters to us

XYO has spent years solving one of the hardest problems in infrastructure: proving that real-world data is what it claims to be. That work only holds if the data behind each proof is still there, unchanged, when someone needs to check it. Auto Drive exists to make that guarantee at the storage layer. Seeing it added to the XYO SDK, in released code with a public sample, is exactly the kind of integration Autonomys Network was built for.

We look forward to seeing what XYO developers build on it.
Auto Drive is free to start at ai3.storage.