AWS Architecture Blog
How Anchorage Digital and Turnkey verify code with AWS Nitro Enclaves
This post is co-written with Prasanna Gautam from Anchorage Digital and Arnaud Brousseau from Turnkey.
In crypto, trust is a liability. A wallet often delegates computation to a third party to parse a transaction, evaluate a policy, or manage key material. Each time, it raises a question: how do you know the service ran the code it claims to have run? Contractual trust, network perimeter security, and reputation don’t provide a cryptographic answer. Verifiable infrastructure built on AWS Nitro Enclaves does.
Anchorage Digital is home to America’s first federally regulated digital asset bank. Turnkey is a verifiable key management infrastructure provider whose platform secures millions of wallets. Together, they built that cryptographic answer on top of AWS Nitro Enclaves. Their collaboration produced VisualSign, an open source, cross-chain transaction parser that runs inside Nitro Enclaves and returns results with attestation-backed proof of what software produced them. The immediate application protects users from phishing attacks by making complex transactions human-readable, and the architecture is a blueprint for verifiable infrastructure that extends well beyond blockchain.
This post describes the architecture and design decisions behind the system, including why AWS Nitro Enclaves are foundational to the trust model. It also shows how the same pattern applies to any high-trust workflow, not only Web3 or crypto.
The problem: Blind signing and phishing in Web3
Cryptocurrency phishing attacks exploit a basic limitation of wallets: they can’t natively parse the full semantics of complex transactions. Blind signing is the approval of a transaction whose full effects the wallet can’t display, and it’s what attackers depend on. A user interacting with a decentralized finance (DeFi) protocol might receive a request to sign a transaction, but the wallet displays only a raw hex payload or a partial summary. Attackers craft malicious transactions that look benign at the surface level but contain hidden operations: token approvals to attacker-controlled addresses, unexpected contract interactions, or fund transfers disguised within multi-step operations.
The industry has attempted to make transactions readable with simulation services and transaction decoders. These approaches typically require the wallet to trust a third-party service without a way to verify which code the service ran or that the result came back unmodified.
A transaction parser needs two guarantees:
- Correctness: The parsing logic is the exact, unmodified code that was audited and approved.
- Integrity: The parsed output hasn’t been tampered with between the parser and the wallet.
The solution: VisualSign on Turnkey Verifiable Cloud, powered by AWS Nitro Enclaves
VisualSign Parser is an open source Rust codebase developed by Anchorage Digital. It converts raw blockchain transactions into structured, human-readable JSON. As of this writing, it supports Ethereum and its layer 2 networks (L2s), including Arbitrum, Optimism, Base, and Polygon. It also supports Solana, Sui, and Tron, with additional chains in development.
Consider a Uniswap Universal Router transaction: the uniswap-v2swap.input fixture in the visualsign-parser test suite is 2,470 characters of raw hex. VisualSign turns it into a clear hierarchical breakdown: a Permit2 approval, a V2 swap with specific token amounts and minimum outputs, a fee payment, and a WETH unwrap. Each step lists explicit addresses, amounts, and expiration dates.
Turnkey Verifiable Cloud
The collaboration between Anchorage Digital and Turnkey began after Turnkey published its whitepaper in January 2025. The whitepaper details how Turnkey uses AWS Nitro Enclaves to secure wallets and private keys at scale. Turnkey has detailed this implementation and AWS architecture in the post Building secure, verifiable blockchain key management on AWS Nitro Enclaves at Turnkey.
Anchorage Digital now uses Turnkey Verifiable Cloud (TVC) to outsource computation verifiably. Rather than running transaction parsing logic in its own infrastructure, Anchorage Digital deployed VisualSign Parser within Turnkey-deployed AWS Nitro Enclaves.
Anchorage Digital and Turnkey documented the full verification workflow in the Wallet Integration Guide so that other wallet providers can use VisualSign Parser in the same way.
With VisualSign Parser, crypto wallets, typically limited in their ability to run complex logic, can verifiably parse complex cryptocurrency transactions. This helps prevent phishing attacks that rely on users approving signatures for malicious transactions without understanding them.
Beyond VisualSign, TVC supports running any high-trust workflow inside verifiable, isolated infrastructure, including policy evaluation, compliance checks, and transaction classification. You can now build with cryptographic proof instead of relying on trust for your most sensitive operations.
Architecture: How VisualSign runs inside AWS Nitro Enclaves
The following diagram shows how a parsing request travels from the wallet client to the enclave and back, and where attestation enters the flow.
The flow works as follows:
- A wallet client sends a raw transaction payload to the Turnkey API.
- The Turnkey API forwards the request to any AWS Nitro Enclave-supported EC2 instance running QuorumOS. QuorumOS is the open source operating system Turnkey uses to run enclaves, and the VisualSign Parser binary.
- The parser converts the raw transaction into structured, human-readable output.
- The enclave signs the response with an ephemeral P-256 key and requests an AWS Nitro attestation document from the Nitro Hypervisor.
- The wallet client verifies the attestation and signature, confirming the response came from the expected software running in a genuine Nitro Enclave.
Anchorage Digital doesn’t need to trust Turnkey: ephemeral key signatures and AWS Nitro attestation documents prove that enclaves are provisioned with the correct software. The attestation document contains Platform Configuration Registers (PCRs), which are cryptographic measurements of the enclave image, kernel, and application. The wallet client compares PCRs and other attestation fields against the values derived from reproducible builds. Reproducible builds compile the same source code into byte-identical binaries every time, regardless of who runs the build or where. Because the binary is always identical, its PCR measurements are deterministic, so the trusted values stay constant across rebuilds and verification policies never need to be updated. Reproducibility allows any party to independently verify that the enclave runs the expected QuorumOS version, as well as the exact, unmodified VisualSign Parser code.
Why AWS Nitro Enclaves
AWS Nitro Enclaves provide several properties that are essential to this architecture:
- Hardware and software-based isolation – Nitro Enclaves use the same Nitro Hypervisor technology that provides CPU and memory isolation for Amazon Elastic Compute Cloud (Amazon EC2) instances to isolate the vCPUs and memory for an enclave from a parent instance. The Nitro Hypervisor ensures that the parent instance has no access to the isolated vCPUs and memory of the enclave.
- No persistent storage or external networking – Enclaves communicate only with the parent instance over a local
vsockchannel. No persistent storage, no network interface, no DNS, no metadata service. - Cryptographic attestation – Attestation is a feature unique to AWS Nitro Enclaves. The Nitro Hypervisor produces signed attestation documents that include PCR measurements of the enclave image, signed by the AWS Nitro Attestation PKI, proving the enclave’s identity to external services.
- No operator access – No single AWS, Turnkey, or Anchorage Digital operator can access customer data within the enclave.
These properties make Nitro Enclaves well-suited for workloads where the computation itself must be verifiable: not only the inputs and outputs, but the guarantee that a specific, known program produced the result.
Advancing Go tooling for Nitro Enclave verification
Attestation verification in production is difficult to implement correctly. The attestation document specification is a CBOR Object Signing and Encryption (COSE) Sign1 structure whose payload carries an X.509 certificate chain, PCR measurements, and optional fields such as UserData and PublicKey. Correct verification means parsing CBOR, validating the COSE signature, and walking the certificate chain back to the AWS Nitro root certificate. It also means checking expiration and comparing PCR values, with clear error handling at each step.
awsnitroverifier: A purpose-built Go library for Nitro attestation
Anchorage Digital built and open-sourced awsnitroverifier, a Go library for validating AWS Nitro Enclave attestation documents with complete chain-of-trust verification. The team designed it to address the gaps they encountered while building the VisualSign verification workflow. The library implements built-in PCR validation and separates parsing errors from validation failures, instead of leaving that to the caller. Handling it in the library makes the cause of an error easier to determine. The library’s clear two-tier error handling separates malformed input (err != nil) from validation failures (result.Valid == false). Each validation failure includes a specific, actionable error message (PCR mismatch, expired certificate, chain verification failure) rather than a generic “verification failed.”
The library also gives direct access to the UserData, PublicKey, and Nonce fields, the root certificate fingerprint, and chain trust status to validate the Nitro Enclave used for the request. The library comes with tests covering the verification package. Developers also have the option to write continuous integration and continuous delivery (CI/CD) tests without having to spin up a Nitro Enclave by using offline/test mode. There’s also an included migration guide for users currently using nitrite, a widely used open-source AWS Nitro Enclave Go attestation library.
visualsign-turnkeyclient: End-to-end verification built on awsnitroverifier
On top of awsnitroverifier, Anchorage Digital built and open sourced visualsign-turnkeyclient, a Go client that performs end-to-end verification of transactions parsed in Nitro Enclaves. The awsnitroverifier library handles the low-level attestation document validation. The Turnkey client adds the application-level workflow.
You can adopt the verification levels in increasing order of complexity:
- Basic P-256 signature verification – Confirms that a key inside Turnkey’s infrastructure signed the response.
- Boot attestation with PCR validation – Uses awsnitroverifier to verify the enclave image and configuration match expected values.
- Complete manifest verification – Full QuorumOS manifest validation including the specific application binary hash.
This layered approach separates a focused attestation library from an application-level client, so you can build non-blockchain use cases on Nitro Enclaves by excluding blockchain-specific dependencies.
Beyond blockchain: Verifiable compute for any high-trust workflow
VisualSign is a blockchain product, but the infrastructure underneath it isn’t. Turnkey and Anchorage Digital built that architecture on reproducible builds, enclave-hosted computation, and attestation-gated access. It’s a general-purpose pattern for any scenario where you need cryptographic proof that a specific program processed specific data. Without the blockchain specifics, the architecture provides a verifiable compute building block.
The core pattern: Attestation-gated access
The key insight from Anchorage Digital’s implementation is that an enclave attestation document can serve as an access credential. Rather than granting access to sensitive resources based on network identity, API keys, or operator trust, the system grants access based on proof of what code is running. The principle is keeping the computation away from the sensitive data and using attestation to bridge the gap.
At Anchorage Digital, hardware security modules (HSMs) protect sensitive key materials. The VisualSign Parser runs in a separate Nitro Enclave, and the HSM grants access based on verified attestation, not based on trusting the network, the operator, or the host machine. The Anchorage Digital engineering team’s philosophy is that this pattern applies to any application that handles sensitive information or uses third-party libraries. The goal is to keep the computation away from the sensitive data. The following diagram shows the generalized form of the pattern. An untrusted input enters an enclave-hosted application, the enclave returns a signed bundle with an attestation document, and the HSM releases key material only after that attestation is verified.
Several non-crypto workflows fit this pattern. A financial institution can run sanctions screening or anti-money laundering (AML) checks inside a Nitro Enclave built from a reproducible image. This produces cryptographically verifiable proof that the exact audited screening software processed the data. A healthcare provider can run a diagnostic model against patient data inside an enclave that has no persistent storage and no network access. Attestation confirms that the approved model binary ran, and the model operator has no path to copy the data out. Any application that relies on third-party libraries for sensitive operations can run that code inside an enclave with a pinned, reproducible build.
This architecture also supports an organizational separation of concerns that maps naturally to team expertise. As Anchorage Digital describes it: “someone with expertise in evaluating blockchain transactions uses first-party blockchain tools to vet them, while the team managing sensitive data focuses on verifying correct validation and applying policies.”
In practice, Anchorage Digital splits ownership of the system between two teams:
- Blockchain domain experts build and maintain the VisualSign Parser using first-party blockchain tools and deep protocol knowledge. They understand Ethereum opcodes, Solana instruction formats, and DeFi protocol semantics.
- Security and infrastructure teams focus on attestation verification, HSM policy enforcement, and access control around sensitive key materials. They understand PCR validation, certificate chains, and key management.
Neither team needs to operate in the other’s domain. The blockchain team doesn’t need access to key materials. The security team doesn’t need to understand Solana’s account model. The Nitro Enclave attestation serves as the machine-verifiable contract between the two teams that says, “This exact code ran, and here’s the proof.”
Conclusion
In this post, we showed how Anchorage Digital and Turnkey use AWS Nitro Enclaves to run the open source VisualSign Parser inside an attested enclave, so wallets can cryptographically verify which code parsed a transaction. The collaboration between Turnkey and Anchorage Digital started with a specific problem: making crypto transactions human-readable with cryptographic proof of correctness. What they built applies well beyond blockchain. The architecture pattern of reproducible builds, enclave-hosted computation, and attestation-gated access can serve as a general-purpose building block for verifiable compute.
To get started building verifiable applications, the VisualSign ecosystem and its underlying verification tooling are fully open source. Follow the documentation to spin up AWS Nitro Enclaves for your sensitive workloads that require cryptographic attestation. Use the awsnitroverifier Go library to implement AWS Nitro Enclave attestation validation. For blockchain applications, the VisualSign Turnkey Client and Wallet Integration Guide handle end-to-end attestation validation and wallet integration.
If you want to run your own workloads on Turnkey Verifiable Cloud, TVC is in private beta as of this writing. To get a more in-depth understanding of how Turnkey architected this solution, refer to the post Building secure, verifiable blockchain key management on AWS Nitro Enclaves at Turnkey.

