docs: add AetherNet grant proposal

"Hi @nycnewman, I recently submitted this proposal to bridge AetherNet's Post-Quantum Cryptography (ML-DSA) execution layer with Canton, aligning with the H2 2026 PQC roadmap we discussed on the Discourse. The automated bot closed the PR requesting more information. Given your expertise in Canton's cryptographic API and synchronizer architecture, would you be open to championing this proposal or pointing me toward the specific structural formatting the Tech & Ops committee is looking for so we can move this into the review stage?"

Canton Network uses 3.5 or later. 2.7.9 is a very old version of Daml V2.

Canton Network doesn't have a mempool so not clear what risk you are trying to solve for. How does the proposal solve m2m payment rails (vf other implementations of X402 AI payment protocol). HNDL only applies if the data on chain has real long time value so better clarity of what use cases you are aware of that have this would be useful.

Canton has no public mempool. Not clear from this description what risks you are trying to solve for. How does identity of agent map to on-chain identities if it passes through this layer.

Hi @nycnewman,

Thanks for the feedback and for reviewing the proposal! You make a fair and accurate point: Canton natively provides sub-transaction privacy and direct participant routing, so there is no public mempool or on-chain MEV within Canton itself.

To clarify, when we reference "mempool protection and MEV elimination" in the context of AetherNet, we are addressing two specific execution boundaries:

1. Protocols Migrating from Public L1s/L2s: Many of the enterprise AI agents and DeFi protocols we work with currently operate on public mempool chains (Solana, Base, Ethereum) where front-running and MEV extraction are severe. AetherNet gives them a familiar off-ledger execution perimeter that safely bridges their intent into Canton's private, non-mempool architecture.
2. Pre-Ledger Transport & Edge Execution: Securing the off-ledger M2M communication and AP2/MCP negotiations at the edge before commands reach the Canton Ledger API.

Risks Solved at the Execution Edge

• Pre-Ledger PQC Transport (Harvest Now, Decrypt Later): While waiting for native PQC at the synchronizer level, AetherNet secures off-chain agent negotiations, AP2 payloads, and MCP context objects using NIST FIPS-203/204 (ML-KEM / ML-DSA) at the edge.
• Rogue Agent Containment: Before an autonomous AI agent exercises a Daml choice, its execution logic runs inside a hardware-isolated Rust TEE. The TEE validates that the agent’s intent complies with pre-approved risk parameters, preventing LLM hallucinations or unauthorized payload mutations from ever reaching the Canton ledger API.
• Off-Ledger Secure Vector Memory (AetherNet KVS): Agents require continuous semantic memory (e.g., counterparty risk histories, vector embeddings). We maintain this off-ledger in a PQC-hardened Rust vector database, keeping bulky ephemeral data off Canton while preserving post-quantum security.

Agent-to-On-Chain Identity Mapping

Regarding how agent DIDs map to Daml Party IDs:

1. Off-Ledger KYA & Attestation: The external agent signs its payload with its FIPS-204 key. The AetherNet Rust TEE verifies the signature and checks hardware remote attestation (PCR hash).
2. Delegation / Proxy Pattern: Once verified, the TEE gateway maps the authenticated agent DID to a provisioned Daml Party managed by the gateway's Ledger API client.
3. Ledger Command Submission: The TEE exercises choices on Daml delegation contracts (e.g., exercising a SubmitValidatedMandate choice where the Party acts as a signatory/observer), ensuring the ledger state transition is explicitly bound to the TEE's attestation quote and the agent's pre-delegated authority.

As a quick side note regarding AetherNet's trajectory on Canton: We recently refactored our Daml architecture from a hardcoded stablecoin whitelist to a dynamic CurrencyRegistry factory. This upgrade was specifically designed to support the native Canton deployment of our Standard Inference Token (SIT). We view raw algorithmic compute as the core commodity of the agentic economy, and we intend to utilize AetherNet's post-quantum edge to settle SIT-denominated compute futures and agentic trades into Canton's privacy pools.

I’d be glad to update the proposal markdown file in this PR to reflect these clarifications, or jump on a brief technical sync to walk through the gRPC sequence diagrams if helpful. Let me know what you think!

Hi @nycnewman,

These are excellent points, and you are completely correct regarding Canton's architecture. Canton natively provides sub-transaction privacy and direct participant routing, meaning there is no public mempool or on-chain MEV within Canton itself.

To clarify the scope of the proposal, AetherNet is not trying to fix Canton’s internal ledger consensus. We are providing a Pre-Ledger Execution Gateway that solves specific off-chain risks before commands hit the Canton Ledger API.

Here is the exact breakdown of the risks we solve, how we differ from x402, and the high-value use cases driving this architecture:

1. If Canton has no mempool, what risk is AetherNet solving?

We are solving for Pre-Ledger Transport & Edge Execution. As the agentic economy scales, many AI agents and enterprise protocols are migrating from public mempool chains (Solana, Base) where front-running and MEV are severe. AetherNet provides a hardware-isolated edge gateway (Rust TEE) that intercepts off-chain M2M negotiations and MCP payloads, validates the agent's intent, and acts as a secure proxy to route that intent into Canton's private, non-mempool architecture. We also contain rogue agent execution (LLM hallucinations) inside the TEE before it can exercise a Daml choice.

2. M2M Payment Rails: AetherNet (AP2) vs. x402

The Linux Foundation/Coinbase x402 protocol is a phenomenal innovation for the open web, but it is structurally a consumer-grade rail.

• x402 is optimized for $0.001 API micropayments. It utilizes standard ECDSA cryptography and settles on public L2s (Base, Solana), meaning the transaction amounts and counterparty wallets are permanently broadcast to public block explorers.
• AetherNet utilizes the Agent Payments Protocol (AP2) and Daml to serve as an institutional-grade rail. Instead of simple unidirectional token transfers, AetherNet processes Turing-complete institutional escrows, multi-party conditionality, and strict Cryptographic KYA (Know Your Agent). By pairing this with Canton, we ensure the M2M settlement maintains absolute sub-transaction privacy—something x402 fundamentally cannot provide.

3. The "Harvest Now, Decrypt Later" (HNDL) Use Cases

You are exactly right: HNDL only matters if the data has long-term value. While a $0.05 LLM inference charge doesn't need PQC, AetherNet is built for the institutional use cases currently migrating to Canton where a quantum decryption event would be catastrophic:

• Tokenized RWAs & Canton PCP (Programmable Credit Protocol): When institutional capital aggregators negotiate multi-million dollar tokenized repos or yield strategies, that historical trade data has decades-long competitive value. If an adversary decrypts the off-chain transport layer in 5 years, they reverse-engineer an institution's entire algorithmic alpha.
• Healthcare Adjudication (SMART on FHIR / EDI 837): We are utilizing AetherNet to process M2M healthcare claims between provider agents and payer agents. This data contains deeply sensitive Protected Health Information (PHI) with a lifelong confidentiality shelf-life mandated by HIPAA.
• Defense & Sovereign IoT: Managing autonomous supply chain mandates where exposing agent identity logic or network topology threatens operational security.

I’d be glad to update the proposal markdown file in this PR to reflect these specific use cases and structural clarifications, ensuring it aligns perfectly with the Tech & Ops Committee's review standards. Let me know if this clears up the execution boundaries!

Canton has no public mempool. Not clear from this description what risks you are trying to solve for. How does identity of agent map to on-chain identities if it passes through this layer.

Hi @nycnewman,

To provide full clarity on both the specific risk model we solve for and how off-chain agent identities map to on-chain Daml identities, here is the architectural breakdown:

1. What Specific Risks Does AetherNet Solve For?

Because Canton natively eliminates public mempools and provides sub-transaction privacy, AetherNet does not alter Canton’s internal consensus. Instead, it acts as a Pre-Ledger Execution Perimeter solving three distinct off-chain risks before commands reach the Canton Ledger API:

• Rogue Agent Containment (Off-Ledger Policy Enforcement): Canton executes valid Daml commands submitted to its API, but it cannot detect if an off-chain LLM hallucinated or suffered a prompt injection. AetherNet executes agent decisioning inside a hardware-isolated Rust TEE, mathematically enforcing spending limits and policy invariants before constructing a transaction.
• Pre-Ledger Quantum Exposure (HNDL on Edge Payloads): Agent-to-agent negotiations, Model Context Protocol (MCP) context objects, and AP2 payment intents occur off-chain across the edge. AetherNet secures this pre-ledger transport using NIST FIPS-203 (ML-KEM) and FIPS-204 (ML-DSA), preventing "Harvest Now, Decrypt Later" exploitation of long-lived corporate data.
• Off-Ledger Secure Semantic Memory (AetherNet KVS): High-frequency agent memory (KYA records, counterparty risk embeddings) cannot live directly on-ledger due to storage overhead. AetherNet maintains this in a hardware-isolated, PQC-hardened vector store (KVS) rather than exposing it to unprotected third-party vector databases.
• Bridge for Public L1/L2 Migrations: For protocols transitioning from Ethereum, Base, or Solana to Canton, AetherNet provides a familiar execution gateway that routes their agent workflows safely out of MEV-heavy environments into Canton's private architecture.

2. How External Agent Identities Map to On-Chain Daml Identities

The identity translation from an off-chain autonomous agent to a Canton Party operates across four discrete stages:

1. Off-Chain Identity (DID & PQC Keypair):

   • The external agent signs its intent/mandate using its NIST FIPS-204 (ML-DSA) private key.

2. Off-Ledger Verification & KYA:

   • The AetherNet Rust TEE ingests the payload, verifies the cryptographic signature against the agent's registered public key, and validates the hardware remote attestation quote.

3. Participant User & Party Mapping:

   • The enterprise principal or agent maps to a specific Daml Party provisioned on the Canton participant node via the Ledger API User Management Service.
   • The AetherNet Gateway acts as an authenticated Ledger API client holding scoped JWT credentials to act on behalf of that Party.

4. Daml Smart Contract Execution:

   • The Gateway submits commands via gRPC exercising choices on Daml delegation/escrow templates (e.g., MintEscrow via a dynamic CurrencyRegistry or DelegationMandate).
   • The verified off-chain metadata (e.g., agent_did, intent_ref, attestation hash) is stored immutably in contract parameters, binding on-chain state to the cryptographically verified agent identity while preserving Daml authorization rules.

I would be glad to update the PR proposal file with this refined scope and sequence flow if this addresses the committee's technical questions.

Hi @nycnewman,

Great catch—you are absolutely right. We initially locked our smart contract environment to Daml SDK 2.7.9 to ensure stability during our early Proof-of-Concept phase and to maintain compatibility with our earlier Canton 2.x Docker container baseline.

Now that the core Rust TEE integration and off-ledger ML-DSA cryptography are fully functioning, migrating the Daml smart contract suite to the latest Daml 3.x SDK is our immediate next step. While the core Daml language syntax is highly compatible, we recognize this transition requires a coordinated infrastructure lift—specifically updating our Rust TEE gRPC protobuf bindings to target Ledger API v2 and deploying against a modern Canton 3.x participant node.

I will update the proposal's Acceptance Criteria in this PR to explicitly mandate that:

• All smart contracts (including the dynamic CurrencyRegistry and ServiceEscrow) must compile cleanly under the latest stable Daml 3.x SDK.
• The Rust TEE integration and Ledger API clients will be fully upgraded to target Ledger API v2 against a modern Canton 3.x node environment.

Thanks for pointing this out. We want to ensure this infrastructure is built on Digital Asset's most current and performant standards!