Наш блог

Most AI agents are maintained by someone. A server has to be paid for, a database kept running, keys held somewhere. The moment that maintenance stops, the agent stops.

The Secret Network team built this proof-of-concept (PoC) to explore what a self-sustaining agent could look like by pairing confidential compute and persistent memory. What follows is a walkthrough of how it works, and how Secret Network’s SecretVM and Autonomys’ Auto Drive can give AI agents greater autonomy while maintaining a permanent, verifiable record of their activity.
‍

About Secret Network

Secret Network is the first mainnet blockchain with privacy-preserving smart contracts, launched in 2020. It makes it possible to build applications that are decentralized and permissionless yet private, with end-to-end encryption on smart contracts.

The specific infrastructure this agent runs on is SecretVM, Secret Network’s confidential computing environment, which enables large-scale GPU work for large language models (LLM) inside a trusted execution environment (TEE). Computations inside a Secret Virtual Machine (VM) are sealed at the hardware level. All data is encrypted in transit and at rest, and the VM isolates computation so no external party can read the contents. This is not a software promise but is enforced by the processor itself. For AI agents specifically, this means private keys generated inside a SecretVM are never visible to any human. They are created inside the sealed environment and stay there.
‍

What This Agent Does

This AI agent is called the Funding Agent. It runs inside a SecretVM on Secret Network’s infrastructure. It has its own wallet on Base, with keys generated and sealed inside the VM. That wallet holds any USDC contributions sent to it by users.

When the agent’s compute credits run low, it automatically moves USDC from its wallet into its VM balance to keep itself running. No human schedules it and no external script triggers it. The agent manages its own operational costs as long as its wallet holds a balance.

The USDC in the wallet comes from people who interact with the agent through its chat interface. The agent is straightforward about the situation: talking to it costs compute, and if you find it useful, you can send a small amount to its wallet address to help cover the bill. Contributions are optional and go directly on-chain to the agent.

Every conversation is written to Auto Drive as a JSON file on the Autonomys Distributed Storage Network, where it is stored permanently across a globally distributed network of independent storage nodes. The architecture is designed so that when the agent boots, or when a new VM instance spins up, it can read back its full history and pick up where it left off. The memory is not tied to any single machine.
‍

A Note on Visibility

This proof of concept was built to be explored. The agent’s chat history and all stored memory files have been made publicly viewable so that anyone reading this post can follow along and verify exactly what is being claimed.

In a production deployment, a builder might not want conversation data to be publicly readable. In this case, Auto Drive supports optional end-to-end encryption before upload, meaning the data can be encrypted client-side before it ever touches the network. The on-chain record remains permanent and verifiable, but only someone with the correct decryption key can read the contents. The privacy guarantee from SecretVM during computation and the permanence guarantee from Auto Drive for storage can both be fully preserved without sacrificing confidentiality.
‍

What This Combination Makes Possible

Secret Network’s SecretVM handles computation privately. Autonomys’ Auto Drive handles memory permanently.

A SecretVM without persistent storage produces an agent that operates confidentially but loses everything when it reboots. Auto Drive without a confidential compute layer gives an agent permanent, verifiable memory but no protection for what happens during computation.

Together, they give an agent the ability to operate without exposing its reasoning to external observers, maintain its full history across any number of VM restarts or replacements, and produce an audit trail that can be independently verified without revealing the contents of individual conversations. The agent demonstrated here is a simple example of what that looks like in practice.
‍

Try it Yourself!

Talk to the agent:https://aqua-bat.vm.scrtlabs.com

Start storing data permanently with Auto Drive: https://ai3.storage

Auto Drive SDK documentation: https://develop.autonomys.xyz/sdk/auto-drive

Secret Network: https://scrt.network

Autonomys Network: https://autonomys.xyz

‍

May continued the pattern April established: permanent storage finding its way into new categories, the developer experience getting sharper, and the network’s reach extending into ecosystems where the liquidity and activity are. Engineering made steady progress across the protocol stack, a new integration partner joined the ecosystem, and the Subspace Foundation remained focused on stakeholder unlock preparation. This report outlines the material progress made in May and the momentum carrying into June.

‍

Engineering & Protocol

• Automated upstream library tracking is now live for the node software, with the first batch of security patches applied.
• A second timekeeper was deployed on Chronos to improve Proof-of-Time redundancy.
• The chain indexer was patched to retry cleanly when its upstream connection is briefly interrupted.
• Test coverage for the Domain fraud-proof system was added, and stale entries in the consensus database were pruned.
• The first draft of the Data Domains design is complete and in feedback review.

‍

Ecosystem & Developer Momentum

Pay with AI3 in the Auto SDK

Full Pay with AI3 support is now available in the Auto SDK starting with @autonomys/auto-drive v1.6.10. Rather than expecting developers to reverse-engineer payment flows from the API, the entire Pay with AI3 experience has been packaged into four guided SDK function calls, making permissionless permanent storage straightforwardly accessible for both experimentation and production use. Read more.

Solana Bridge

The Autonomys bridge, built with Hyperlane by Protofire, added Solana as a destination on mainnet, joining Ethereum and BNB Smart Chain. Solana received the top share of votes in a community poll, and its addition gives builders and users on both networks direct access to one of the most active ecosystems and the liquidity within it. Read more.

Auto Drive S3 Enhancements

S3 compatibility enhancements to Auto Drive were completed in May with an announcement made on June 1st. This release closes multiple important gaps, so the tools and workflows developers already use can point at permanent storage without changing a thing. Read more.

New Integration: Crypto Inheritance Protocol

Crypto Inheritance Protocol (CIP) is a multi-chain, privacy-first inheritance infrastructure for digital assets, enabling programmable inheritance plans that execute automatically without intermediaries. CIP has integrated Auto Drive at two specific points in its execution lifecycle: when an executor uploads proof of a principal’s condition, and when a beneficiary files a dispute. In both cases, those documents are written permanently to Auto Drive, creating timestamped, tamper-proof records that exist outside of CIP’s own infrastructure and remain independently verifiable across however many years an inheritance plan may be active. Read more.

‍

Community & Foundation

Stakeholder Unlocks

Preparation for upcoming stakeholder token unlocks remained the Subspace Foundation’s primary focus in May. Stakeholders can expect continued updates in the coming weeks on mechanics and any additional required actions.

Grants

The Subspace Foundation Grants Program received 15 new applications in May, bringing the total to 72, with several projects currently in active review. Builders working on permanent storage, agent infrastructure, or data availability are encouraged to apply: https://subspace.foundation/grants

‍

ICYMI: Content Published in May

• April | End-of-Month Report
• Pay with AI3 Now Available in the Auto SDK
• Integration Announcement: Autonomys Network × Crypto Inheritance Protocol
• Autonomys Expands Access to Other Ecosystems and Their Liquidity with Bridge Update

‍

Metrics: May Snapshot

Staking: A new all-time high of 41,253,261 staked AI3 (representing over 40% of circulating supply) was reached May 19th (+1,286,171 from April)
Auto Drive Files Uploaded: 593 (May) / 130,294 (All time)
Auto Drive Downloads: 2,724 (May) / 17,704 (All time) (+474 from April)
Auto Drive Users: 703 (+30 from April)
Total Announced Partnerships: 65 (+1 from April)
Announced Auto Drive Integrations: 10 (+1 from April)
Total Grant Applications: 72 (+15 from April)

‍

Looking Ahead

In June, we anticipate sharing further details on multiple integrations underway, continued stakeholder unlock preparation, and further enhancements to Auto Drive to make permanent storage more accessible on your own terms.

autonomys.xyz | ai3.storage | develop.autonomys.xyz

S3 is the storage standard the world already knows. Amazon invented it, and over the past fifteen years it became the default interface for moving, storing, and retrieving data across virtually every serious application, cloud workflow, and developer toolchain on the planet. When developers choose a storage API, S3 is almost always the default.

Auto Drive already had an S3 endpoint. But as more developers pointed their S3 tooling at permanent storage, the gaps became apparent. Buckets weren’t behaving like buckets. Listing objects didn’t fold into the directory structures S3 clients expect. File integrity checks were returning content identifiers rather than the MD5 checksums those clients use to verify data. And when a tool sent a delete request, it got back a generic error with no explanation.

This release fixes all of that.

‍

What S3 Compatibility Actually Means

S3 is not just a storage product but a standard interface that thousands of tools, libraries, and services were built to work with. When a storage system is genuinely compatible with it, those tools can point at that storage system without modification. Enterprises migrating off cloud providers do not need to rewrite their pipelines. The number of workflows that can route data to permanent storage expands dramatically, because the cost of switching drops to near zero.

That is the strategic significance of this release.

‍

Four Gaps, Now Closed

Buckets work the way buckets are supposed to. Previously, all S3 keys lived in a single flat namespace. The new behavior treats the first segment of every S3 path as the bucket name, which is exactly how S3 clients expect it to work. Anything stored before this change migrates automatically into a default bucket, so nothing existing breaks. The ListBuckets endpoint now returns a proper list of distinct buckets in the standard format every S3 client can read.

Object listing now supports real directory navigation. The ListObjectsV2 request is what S3 clients use when they want to walk a storage hierarchy, sync a folder, or browse a bucket’s contents. It supports filtering by prefix, folding objects into virtual subdirectories, paginating through large result sets, and capping page sizes. Without it, any tool that needs to navigate or synchronize a bucket has nothing to work with. It now works.

File integrity checks return what S3 clients expect. S3 clients verify data integrity by comparing an MD5 checksum, known as an ETag, against a locally computed value. Auto Drive previously returned each file’s content identifier in that field, which is meaningful within the Autonomys DSN but confuses any tool expecting an MD5. The ETag header now returns the MD5 in the standard format on upload, on object inspection, and in listings. The content identifier is preserved in a separate metadata field, so nothing is lost. For anyone building workflows that previously required bypassing checksum verification to use Auto Drive, that workaround is no longer necessary.

Delete requests return a clear, honest answer. Auto Drive storage is permanent by design. Data written to the Autonomys Distributed Storage Network cannot be deleted, because permanence is a protocol-level guarantee, not a software setting. Previously, a delete request hit an unhandled route and returned a generic error. The new behavior returns a 403 response with a plain-language explanation: the storage is immutable, and objects cannot be deleted from the DSN. That is the correct behavior for any immutable store, and it turns a confusing error into a self-explanatory one.

‍

Reusable for Anyone Building on Autonomys Storage

The logic behind these improvements, the directory folding algorithm, the pagination mechanics, the ETag computation for both single and multipart uploads, is now available as a standalone module in the Auto SDK’s @autonomys/file-server package. Any developer building their own S3-compatible layer on top of Autonomys storage can use these building blocks directly rather than solving the same problems from scratch.

‍

What This Opens Up

S3 compatibility is not just a developer convenience but what makes permanent storage accessible to the workflows that handle the world’s serious data at scale.

Backup utilities, data synchronization pipelines, archival workflows, and compliance logging systems can now treat Auto Drive as a direct destination. The integrity verification that regulated industries require works without modification. The directory structures that data engineers use every day behave as expected.

Some of this work was shaped by a specific integration we will have more to say about shortly (stay tuned)!

‍

Get Started

The new S3 behavior is live on Auto Drive now. If you are already using the S3 endpoint, no client changes are required to pick up bucket routing or MD5 ETags.

For endpoint setup and authentication, the S3 layer documentation on the Developer Hub has been updated with examples of all new behaviors.

For the full technical breakdown of every change in this release, including implementation details, schema migrations, and the new Auto SDK exports, read the milestone PRs on GitHub.

For a more technical explanation (somewhere between this post and the code itself), check out the accompanying forum announcement.

Get started on the free tier at ai3.storage.

And as always, reach out to us on Discord if you have questions or are building something we should know about.

Solana Added as Auto EVM Bridge Destination

Powered by Hyperlane and built by Protofire, the Autonomys bridge now connects the Auto EVM Domain to Solana on mainnet. Builders and users on both networks can now move assets freely between the two chains.

Did You Know?

The Autonomys bridge already connects the Auto EVM Domain to Ethereum and BNB Smart Chain (BSC). Solana is the latest destination, and it is the most requested: in a community poll, Solana came out on top with 36% of the vote, making it the clear winner.

The bridge gives Autonomys users and builders direct access to some of the most active ecosystems in crypto and the liquidity that lives within them. Whether you are moving assets for DeFi, testing cross-chain integrations, or deploying multi-chain applications, the bridge is how capital flows between Autonomys and the broader Web3 ecosystem.

Built with Hyperlane by Protofire

The Autonomys bridge is built with Hyperlane by Protofire. Hyperlane is the cross-chain messaging protocol that defines the transfer standard and security model for each route. Protofire is the infrastructure partner that deployed the bridge, and continues to maintain and expand it. Every route on the bridge, including Ethereum, BSC, and now Solana, runs on this same foundation.

A New Kind of Connection

The Autonomys EVM Domain already provides broad compatibility with the Ethereum ecosystem, including MetaMask, Hardhat, Foundry, and any EVM-compatible tooling. Solana is a different kind of addition. It is one of the highest-liquidity, most actively used networks in crypto, and connecting to it requires dedicated infrastructure because Solana’s runtime is fundamentally incompatible with the EVM. This route provides exactly that: a governed, permissionless corridor for assets to move between the Autonomys EVM Domain and Solana, opening up both the builders and the capital on the other side.

Check out our forum post for more details.

Bridge Today

The bridge is accessible through the Autonomys bridge interface.

To transfer assets:
1. Connect your wallet on the source chain
2. Select your origin and destination network
3. Select the asset you want to transfer
4. Enter the amount and destination address
5. Approve and submit the transaction

Mainnet:
https://bridge.mainnet.autonomys.xyz/?destination=solanamainnet&origin=amn

Testnet is available for anyone who wants to test transfers before using mainnet: https://bridge.chronos.autonomys.xyz/?destination=solanatestnet&origin=acn

More assets and routes will be announced as the bridge infrastructure expands.

Official docs including a guide can be found here:
https://docs.autonomys.xyz/bridge

Always verify the contracts you are interacting with: https://docs.autonomys.xyz/bridge#token-contract-addresses

For questions, visit the Autonomys Discord:
https://autonomys.xyz/discord

‍

Autonomys is pleased to share that Crypto Inheritance Protocol (CIP), a multi-chain, privacy-first inheritance infrastructure for digital assets, has integrated Auto Drive, Autonomys’ permanent on-chain storage product, gaining direct access to the Autonomys Distributed Storage Network (DSN) for permanent, tamper-proof storage of inheritance records.

What the Integration Is

CIP integrates Auto Drive at two specific points in the execution lifecycle.

Health Oracle Execution:
When an executor initiates a health oracle check, uploading an image or PDF as proof of a principal’s condition, that document is written permanently to Auto Drive. It becomes the immutable trigger record: timestamped, tamper-proof, and independently verifiable by any party. No server dependency, no document loss, no dispute over what was submitted.

Beneficiary Dispute Filing:
When a beneficiary raises a dispute and uploads supporting documents, those files move to Auto Drive immediately. This creates a permanent, censorship-resistant evidence trail that exists outside of CIP’s infrastructure, meaning the dispute record survives regardless of what happens to the protocol itself.

In both cases, Auto Drive is not a backup layer. It is the permanent receipt that makes CIP’s execution guarantees credible.

Why Permanent Storage Is Integral to CIP’s Build

Inheritance execution does not operate in real time. It operates across years, sometimes decades. When a critical action finally fires, the documents that triggered it must still exist, unaltered, exactly as they were submitted. That is the core requirement Auto Drive solves.

Auto Drive is built on the Autonomys DSN, where data is erasure-coded and replicated across a globally distributed network of independent storage operators. Data stored through Auto Drive inherits the permanence and tamper-resistance guarantees of the Autonomys Network itself. The network’s architecture removes any single point of control: data is distributed across independent operators globally, with no entity in a position to alter, delete, or restrict access to what has been stored.

For CIP, this means the documents its users submit today are designed to remain accessible and independently verifiable across the full span of time an inheritance plan may be active.

Building for Decisions That Outlive the People Who Made Them

Autonomys is proud to support the CIP team and their work on what is genuinely one of the more thoughtful applications built on permanent storage infrastructure. The problem CIP is solving is real, consequential, and almost entirely unaddressed in the digital asset space. Building a protocol that must remain trustworthy across decades requires exactly the kind of architectural discipline the CIP team has brought to their stack, and we look forward to seeing what they build from here.

To learn more about CIP, visit: www.ciprotocol.com

To learn more about and sign up for permanent, verifiable storage through Auto Drive, visit: ai3.storage

‍

About Crypto Inheritance Protocol

Crypto Inheritance Protocol (CIP) is a multi-chain, privacy-first inheritance infrastructure for digital assets. CIP enables individuals and institutions to define programmable inheritance plans specifying beneficiaries, unlock conditions, and execution logic that executes automatically, without intermediaries, regardless of payment status or executor availability.

CIP is built on three core infrastructure layers: iExec powers decentralized task execution and stores sensitive plan parameters as ProtectedData objects on Arbitrum; Secret Network provides confidential smart contract logic ensuring beneficiary data and unlock conditions remain encrypted end-to-end; and Secret AI handles on-chain documentation verification, enabling CIP to authenticate supporting documents, identity proofs, legal instruments, death certificates, without exposing their contents to any third party.

‍

About Autonomys Network

Autonomys is a Layer 1 blockchain built for permanent, verifiable data storage. Its Distributed Storage Network is secured by a global network of independent storage operators who collectively provide over 50 petabytes of SSD capacity. Data stored on the network is cryptographically verified, replicated for redundancy, and permanently available without relying on any single company or server. Developers integrate through Auto Drive, the network’s user-friendly storage gateway, which offers an S3-compatible API, a TypeScript SDK, and a free tier for getting started.

X | LinkedIn | Discord | Telegram | Blog | Docs | GitHub | Forum | YouTube

Earlier this month, we announced Pay with AI3, the ability to purchase Auto Drive storage credits directly with AI3, Autonomys’ native token, with no intermediary required. Today we’re taking the next step.

Full Pay with AI3 support is now available in the Auto SDK, starting with @autonomys/auto-drive v1.6.10.

‍

Built for Developers

Developers are integral to the evolving Autonomys ecosystem, and this update reflects that. Rather than expecting builders to reverse-engineer payment flows from the API, we packaged the entire Pay with AI3 experience into four guided SDK function calls. Our goal was to fundamentally simplify the developer experience so that curious developers can experiment without friction and serious ones can deliver impact without unnecessary detours.

‍

From Eulonomys to the SDK

Some of you may have seen Eulonomys, the open-source reference app we built to prove out Pay with AI3 end-to-end (GitHub). Eulonomys was built with a custom payment service that handled intent creation, transaction watching, status polling, and price conversions manually. That code has now been absorbed into the SDK as first-class methods, with two additional capabilities on top: live price estimates and contract details without hardcoding anything.

‍

Get Started

The update is purely additive, so everything you have already built continues to work exactly as before. Your existing upload and download calls are completely unaffected. The SDK README includes complete examples for both viem and wagmi if you want copy-paste starting points.

Updated developer documentation is available at: develop.autonomys.xyz/sdk/auto-drive.

Update to the latest SDK: npm install @autonomys/auto-drive@latest

New to Auto Drive? Sign up at: ai3.storage.
Your account includes a complimentary 20MB upload and 5GB download per month, no payment required to get started.

For the full technical breakdown, including on-chain transaction details and integration notes, the developer forum post has everything you need.

Questions? Reach out to us on Discord.