TrustedStake uses Caution’s verifiable compute platform to prove that its reviewed transaction-signing code is running unmodified in production and to protect its signing keys inside a confidential computing enclave.
About TrustedStake
TrustedStake gives Bittensor holders one-click access to actively managed portfolios of subnets, the network’s AI projects. Delegators choose a strategy, and TrustedStake handles the rest: research, staking allocation across subnets and validators, automated rebalancing, and compounding. Delegators keep ownership of their assets throughout. The platform is non-custodial by design.
TrustedStake was built on the principle that users should never have to give up custody of their assets to access professional staking infrastructure. — Alex Kiriakides, co-founder at TrustedStake
Nearly 80,000 TAO is currently staked across subnets through TrustedStake, representing more than $20 million in delegated capital from over 3,000 delegators. To date, TrustedStake has processed more than 500,000 transactions. As of September 2026, trading activity across its managed portfolios had exceeded $250 million for the year.
Bittensor has grown rapidly into one of the most active staking networks in crypto. As of early 2026, approximately 67% of all TAO in circulation is staked. The ecosystem has expanded from a single subnet in March 2023 to 120+ active subnets, each a distinct AI project competing for emissions, the market TrustedStake’s strategy layer navigates on behalf of delegators.
The problem
A managed portfolio only works because software, not a person, decides where stake goes and then constructs and signs the transactions that move it. That automation and the signing keys are the highest-value target for attackers in the system.
TrustedStake’s signer can only do two things, stake and unstake, because it runs through a restricted proxy. Even if someone compromised it, they couldn’t withdraw delegator funds or move them to another wallet. Stealing the funds outright isn’t possible.
The risk that remains is where the stake goes. A tampered signer can still direct it somewhere that hurts delegators, and the case that does real damage involves a thinly traded subnet an attacker has set up ahead of time. The signer stakes in, the attacker sells into that buying and walks away, and the delegators are left holding a position they can’t exit without losing most of it to slippage.
None of it trips an alarm. The signatures check out and the activity looks normal, and the loss usually becomes visible only after it’s already happened.
The scale of these types of problems across crypto is substantial. In 2024, access control exploits, the category that includes signing key and private key compromise, accounted for 75% of total crypto hack losses, roughly $1.7 billion across the Web3 ecosystem, according to Hacken. In Q1 2024 alone, private key compromises caused $239 million in losses, more than a 1,100% jump in dollar terms over the prior year, according to CertiK.
The threat is not limited to outright key theft. An adversary who modifies a binary, a dependency, or a build artifact can redirect a signer without ever stealing a key, and tampering like that can run undetected for weeks.
Non-custodial architecture closes one gap: the operator cannot abscond with delegator assets. It does not, on its own, close the other. It does not prove that the automation acting on delegators’ behalf is the automation that was reviewed. A compromised signer in a non-custodial system still moves real money.
How Caution fits
TrustedStake runs its transaction construction and signing service on Caution, inside an AWS Nitro Enclave.
Caution allows verifying the full stack the service runs on, not just the application layer, and produces a cryptographic measurement of exactly the code executing. Any change to the signer, the allocation logic, a dependency, or the operating system beneath them alters the measurement and breaks its match against the build TrustedStake audited and deployed.
With Caution, for the first time, we can tell delegators not only that their assets remain under their control, but that the staking operations we perform on their behalf can be cryptographically verified. That’s a massive step forward for subnet staking.
The measurement only means something because of what it ties back to. TrustedStake made its signing service build reproducibly with StageX, the same source-bootstrapped and deterministic tooling Caution itself is built with, so the same source code and build inputs always produce the bit-for-bit identical enclave image. That turns the measurement from an opaque hash into a fingerprint of specific, auditable source: anyone holding that source can rebuild the image and confirm it produces the measurement the running enclave reports.
AWS Nitro Enclaves produce this measurement via Platform Configuration Registers (PCRs): PCR-0 covers the enclave image hash, PCR-1 the kernel and bootstrap hash, and PCR-2 the application hash. Together they form a fingerprint of the full running stack: if even a single bit changes, the measurement changes. The key that signs the attestation document is built into the AWS Nitro hardware, which is what lets the enclave’s measurements chain back to AWS’s root of trust.
Caution runs this on AWS Nitro Enclaves today, with support for additional attestation backends (Intel TDX, AMD SEV-SNP, and TPM 2.0) in active development.
Where it runs
TrustedStake runs the signing service in its own AWS account using Caution’s bring-your-own-compute deployment, rather than in infrastructure Caution operates. Caution manages the enclave lifecycle through a scoped identity limited to the deployment’s own tagged resources, so it cannot reach other resources in the account, escalate its permissions, or touch anything outside the deployment.
This is a control and data-residency choice, not the source of the security guarantee. Because the compute is verifiable, the attestation proves the same thing wherever the enclave runs, in TrustedStake’s account or Caution’s. TrustedStake keeps the deployment in its own account for operational and compliance reasons, and the proof that the audited code is running holds either way.
The result
With Caution, TrustedStake protects its signing keys and lets delegators verify that the software acting on their behalf matches the code it reviewed. The enclave isolates the signing service from the surrounding host, reducing exposure to compromised servers and infrastructure administrators. Reproducible builds and attestation make unauthorized changes to the deployed code detectable.
TrustedStake sees this model extending beyond subnet staking:
Caution’s easy-to-integrate enclaves bring the gold standard of security to where it is needed most: on-chain infrastructure managing real user capital. Their easy-to-integrate attestation infrastructure has the potential to help drive a DeFi renaissance in a post-Mythos world, where transparency, verification, and trust minimization become the default rather than the exception.
We’ve enjoyed working with the TrustedStake team. Their care for delegator security shows in how they’ve built their service, and we’re glad they chose Caution’s verifiable compute platform to help protect it.
