A private AMM can hide too much.

Encrypt the pool state and traders lose the ability to check prices, liquidity, and fee accounting. Publish every wallet interaction and the AMM becomes another financial surveillance feed. Shield Swap takes a sharper position: the market is public, while ownership of market activity is private.

That boundary matters more than the word "privacy." Pool reserves, trade sizes, prices, routes, outputs, refunds, and fees remain available for public inspection. Token records hide who owns the input and output assets. Position records hide who controls each liquidity position. A separate encrypted record carries the compliance data for a trade.

I like the split. It gives traders confidentiality without asking everyone else to trust a black box.

The market stays visible

Shield Swap is a concentrated-liquidity AMM. Its public state resembles the parts of Uniswap v3 that indexers and quoting engines care about: current price, active liquidity, initialized ticks, position ranges, fee growth, and protocol configuration.

Aleo mappings hold that state. Mappings are public key-value stores, readable by any network participant. Shield Swap uses them for pools, prices, ticks, positions, fees, pending outputs, and administrative controls. Anyone can query those values without possessing a wallet view key.

The public side answers market questions:

• What price did the pool reach?
• How much liquidity was available near that price?
• How large was the trade?
• Which fee tier applied?
• Did the state transition follow the AMM's arithmetic?

Those questions need public answers. A market where nobody can independently reconstruct price movement is difficult to monitor and even harder to integrate. An indexer should be able to rebuild candles. A market maker should be able to calculate inventory risk. An auditor should be able to reconcile fee growth against executed volume.

Shield Swap exposes enough data for that work.

Public trade sizes are a deliberate cost. A large order can still signal information, even when observers cannot attach it to a named fund or wallet. Repeated trades with distinctive sizes and timing may also support statistical guesses about a common operator. Zero-knowledge proofs hide cryptographic links; they do not erase human trading habits.

That is an honest tradeoff. Shield Swap protects the financial graph while preserving market observability. It does not promise that every trading strategy becomes invisible.

Records hide ownership

Aleo records carry the private half of the system. A record is an encrypted, UTXO-like object owned by an Aleo address. Spending it publishes a serial number that prevents reuse. Creating a replacement publishes a commitment and encrypted ciphertext.

The commitment and later serial number cannot be linked without the owner's secret material. Validators can confirm that a valid record was consumed, the program rules ran correctly, and no asset was created from thin air. They do not need the owner's identity or the plaintext balance.

Shield Swap applies that model to two kinds of ownership.

Token records represent spendable assets. A trader submits an input token record to the swap flow and receives new token records after settlement. Public AMM accounting records the amounts. The records conceal who controls those amounts and how they fit into the rest of the trader's portfolio.

Liquidity positions use a similar division. The public positions mapping stores the range, liquidity, fee checkpoints, and tokens owed. A private PositionNFT record proves authority over the position. Increasing liquidity, decreasing it, or collecting fees consumes the current ownership record and returns a replacement. Burning the position consumes it permanently.

The range is visible. The owner is not.

Publishing position economics lets the protocol calculate tick liquidity and fee obligations in a common state machine. Hiding the ownership record prevents an observer from trivially grouping every position held by one institution. A public mapping keyed directly by the provider's address would destroy that property.

Aleo's execution split makes the arrangement possible. Private records are handled while the caller executes the program and generates a proof. Public mappings change during finalization after validators accept that proof. The proof ties both halves together, so the pool cannot update unless the private asset operation was valid.

For developers, the design rule is plain: put shared market facts in mappings and ownership claims in records. Mixing those categories usually creates either an opaque market or a public portfolio database.

A swap has two settlements

Shield Swap's trader flow uses two Aleo transactions rather than pretending one broadcast completes everything.

1. swap consumes the trader's input token record and updates public AMM state.
2. Finalization writes the calculated output and any unused input into the public swap_outputs state.
3. claim reads the pending result and creates output and refund token records for the signer.
4. The wallet stores the returned records and marks the trade complete.

A finalized swap with no accepted claim is still unsettled from the user's perspective. The pool has moved, yet the wallet does not hold the final spendable records.

That two-transaction boundary is slightly awkward. Wallets need recovery logic, agents need a pending-claim state, and interfaces must avoid announcing success too early. I would rather deal with that explicit state machine than bury settlement inside an API server and call the system non-custodial.

The public pending output also explains why Shield Swap can expose trade amounts while hiding balances. Observers can see that a swap produced a particular amount. They cannot automatically connect the resulting encrypted token record to the trader's earlier records, later payments, or other positions.

An agent integrating the SDK should track at least these states:

• Input record selected and reserved locally.
• Swap transaction submitted.
• Swap accepted with a pending output identifier.
• Claim submitted and later accepted.
• Output records decrypted, indexed, and made available for spending.

Retrying blindly is dangerous. The agent must distinguish a rejected swap from an accepted swap with a missing claim. It must also avoid selecting the consumed input record for another action while local indexing catches up.

The current Shield Swap documentation warns integrators to bind transactions to a network, program ID, edition, dependency set, and artifact hash. That warning deserves attention. A client using the right function name against the wrong edition can quote one storage layout and submit against another. Concentrated-liquidity math is unforgiving, and the Q128.128 fee-growth layout is part of the deployment boundary.

I would make deployment identity a required field in every agent configuration, then refuse to trade if the discovered program metadata differs. Quiet fallback is the wrong policy for money.

Compliance gets another path

Shield Swap produces an encrypted compliance record for every trade. Supported dollar-denominated stablecoin transfers also generate transaction-specific records.

That record is separate from the public AMM state and the trader's spendable token records. Public mappings prove what happened to the market. Token records prove private ownership. Compliance records carry the participant-level information needed for an authorized review.

Aleo has two useful disclosure scopes. An account view key provides read-only visibility into records associated with an account, including past and future activity. A transaction view key reveals the private inputs and outputs of one transaction. Neither key grants spending authority.

Scope matters. Handing an auditor an account view key may expose far more than a single investigation requires. A transaction-scoped disclosure can reveal one swap without opening unrelated payroll transfers, treasury positions, or later trades.

Shield Swap's public material describes selective disclosure and per-trade encrypted records, but integrators should inspect the deployed record schema and disclosure tooling before promising a specific legal workflow. "Supports compliance" is an architectural property, not a completed compliance program. Retention rules, access approval, key custody, and jurisdiction-specific reporting still belong to the institution operating the venue.

The separation is useful because public disclosure is irreversible. Once a wallet address and its history are posted to a transparent chain, no access policy can pull them back. Encrypted compliance data can be released to a named reviewer under a defined process while the rest of the market sees only the public trade facts.

Consider a fund swapping 2 million USDCx into wrapped bitcoin. The chain can expose the pool, input size, output size, execution price, fee, and resulting tick movement. Other traders can verify slippage and rebuild the pool state.

The fund's legal identity remains outside that public trace. Its remaining USDCx balance, other positions, and prior record links stay encrypted. If an auditor later asks about the trade, the fund can disclose the transaction-level material and the matching compliance record without publishing its entire account history.

The market still learns that somebody moved size. It does not receive the fund's balance sheet.

What agents should assume

Shield Swap sits between a transparent AMM and a conventional dark pool. A transparent AMM publishes market state and participant addresses. A dark pool may hide orders, execution details, or venue identity, then report aggregate data later. A fully shielded AMM can conceal amounts and reserves, which makes independent price reconstruction much harder.

Shield Swap publishes the economic state while encrypting participant ownership.

Agents need to respect both sides of that boundary.

Public quote computation belongs in ordinary infrastructure. An agent can read pools, ticks, liquidity, and fees through the Shield Swap API or directly from Aleo mappings. It should verify the quote against current chain state before proving a transaction.

Private record selection belongs near the signing environment. Sending decrypted records to a remote quote server defeats much of the architecture. A bot holding its own private key can use the Veil client for local accounts, signing, and proving, while the Shield Swap SDK handles pool reads and trade construction.

Record discovery also needs care. Public account balance queries are cheap because mappings are indexed by visible keys. Private balances require scanning, decrypting, and maintaining local record state. The wallet must know which records are unspent, reserved, pending consumption, or newly returned by a claim.

View-key handling should be a separate subsystem. Spending keys belong in the transaction signer. Account view keys deserve broad-read warnings and tight access controls. Transaction-level disclosure material should be indexed by trade identifier so an operations team can answer a narrow request without exporting the wallet's full history.

Earlier, I argued that persistent key storage matters for Shield-era Aleo apps. Shield Swap adds another reason. A trading client now manages proving keys, spendable records, pending claims, and disclosure material across sessions. Losing local state may leave assets recoverable, but recovery can become slow and operationally messy.

The token boundary matters too. Shield Swap depends on token programs and the shared interfaces around them. Why Aleo Needs the Token Registry Before Dynamic Dispatch covers the broader composability problem. An AMM can only support private assets safely when it knows how those assets move, which record shapes they return, and which program editions it is calling.

Builders should test privacy failures as aggressively as arithmetic failures. Query every public mapping after a swap. Inspect transaction inputs and outputs from an observer's position. Check whether deterministic memo fields, repeated trade sizes, API authentication, or logging systems recreate the links the record model removed.

Cryptography can hide a record graph. Your analytics stack can publish it again before lunch.

Shield Swap's design gives developers a clean boundary to defend: public market facts, private ownership state, and scoped compliance disclosure. The remaining work is operational. Wallets and agents have to preserve that boundary through record storage, claim recovery, telemetry, and key access policy.