> For the complete documentation index, see [llms.txt](https://docs.slinky.network/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.slinky.network/privacy/tor-and-network-privacy.md).

# Tor and network privacy

Calling an external model or data provider can reveal more than the question being asked. The provider may also receive an IP address, approximate location, request timing and other network metadata.

SlinkyLayer places a Tor route between its private interface and downstream tools. The selected provider receives the request from the Tor network rather than through a direct connection associated with the user.

### What happens to a tool request

Before a request leaves SlinkyLayer, two separate protections are applied:

1. **Context routing** prepares a smaller request containing only the information needed by the selected tool.
2. **Tor routing** sends that request through the Tor network before it reaches the provider.

These protections solve different problems. Context routing limits the data being shared. Tor routing reduces exposure of the request's network origin.

A market-data provider, for example, may receive an asset symbol and time range. It should not receive the user's unrelated conversation history, direct IP address or other tasks discussed during the same session.

### What Tor protects

Tor is used to reduce the network information visible to downstream models and tools.

| Information                | What the downstream tool receives                     |
| -------------------------- | ----------------------------------------------------- |
| Direct user IP address     | Not shared through the Tor-routed tool request        |
| Network origin             | Obscured by the Tor route                             |
| Scoped task                | Visible because the tool needs it to perform the work |
| Full conversation          | Not included by default                               |
| Unrelated identity details | Excluded unless required by the task                  |
| Public wallet activity     | May remain visible onchain                            |

The provider can still observe that a request arrived from the Tor network. It can also read the task it has been asked to complete.

> Tor protects the route taken by a request. It does not make the request content invisible to the tool processing it.

### Privacy has more than one boundary

Network privacy is only one part of the system. A request can be Tor-routed and still contain identifying information if the user includes it in the task.

For example, a research tool will receive a person's name if the user asks it to investigate that person. A blockchain tool will receive a wallet address if the task concerns that wallet.

SlinkyLayer reduces unnecessary disclosure, but it cannot remove information that is essential to the requested work.

### Payments and blockchain activity

x402 payments and other blockchain actions have different privacy properties from Tor-routed tool requests.

Tor can prevent a provider from receiving the user's direct network origin. It does not remove information recorded on a public blockchain. Wallet addresses, payments, transactions and protocol interactions may remain publicly observable after settlement.

Users and agents should treat a public wallet as a persistent identifier. Spending limits, wallet separation and approval policies should be considered independently of Tor routing.

### The scope of this protection

The Tor protection described here applies to outbound requests sent from SlinkyLayer to downstream tools. It should not be interpreted as a guarantee that every part of the user's internet connection, device or blockchain activity is anonymous.

For better privacy:

* Avoid including personal information unless the task requires it.
* Review the scoped request before approving sensitive operations.
* Treat wallet addresses and public transactions as observable.
* Check the selected tool's retention terms.
* Require explicit approval before payments or onchain actions.

SlinkyLayer combines Tor routing with context minimization because neither protection is sufficient on its own. The aim is straightforward: give each tool the information it needs while exposing as little else as possible.