Privacy architecture
How SlinkyLayer protects the original conversation, limits what specialist tools receive, and separates private requests from public settlement.
SlinkyLayer does not wait for a tool call before applying privacy protections. The original conversation is protected from the beginning.
Model requests from the chat are routed through Tor to an endpoint operating under zero-data-retention terms. If the conversation later needs a specialist tool, SlinkyLayer creates a separate request containing only the information required for that task.
This produces two protected request paths:
The original chat is Tor-routed to a zero-data-retention model endpoint.
Specialist tools receive scoped requests through a separate Tor-routed path.
Payments and onchain actions remain a third, distinct path because public blockchain activity has different privacy properties.
The original chat and specialist tools use separate request paths. Public settlement remains outside the private processing boundary.
The original chat path
A SlinkyLayer session begins with the conversation itself. The model needs enough conversation context to understand the question and produce a useful response, but the request does not need to be associated with a persistent provider account, API key or direct user IP address.
The original model request is sent through Tor. The model endpoint receives the conversation content required for inference, but the connection arrives through the Tor network rather than directly from the user.
The endpoint also operates under zero-data-retention terms. It processes the prompt and generates a response, but it is configured not to retain the prompt or output after the request has been completed.
Zero data retention does not mean that the model cannot read the prompt. The model must process the conversation during inference. ZDR limits what happens to that content after processing.
The specialist tool path
Most questions do not require every available tool. When a tool is needed, it rarely needs the full conversation.
A market-data tool may need an asset, quote currency and time range. A web-search tool may need a query and freshness requirement. A blockchain-data tool may need a network, address and requested activity.
Before calling a specialist tool, SlinkyLayer prepares a smaller request containing only the relevant task and parameters. Unrelated conversation history is excluded by default.
The scoped request is then sent through a separate Tor route. The tool receives the information needed to perform its assignment, but it does not receive the original conversation or direct user IP address by default.
The tool result returns to the private session, where it can be interpreted alongside the rest of the conversation.
Three controls with different purposes
SlinkyLayer combines several privacy controls because no single control solves every problem.
Tor routing
Reduces direct IP address and network-origin exposure to model and tool providers
Zero data retention
Prevents the original prompt and response from being retained by the configured model endpoint
Scoped context
Limits the conversation information disclosed to a specialist tool
Explicit authorization
Separates research from payments and state-changing actions
No persistent provider account
Reduces long-lived identity linkage across requests
Tor protects the network route. ZDR governs retention at the model endpoint. Context routing controls what a specialist tool receives.
These controls complement one another, but they are not interchangeable.
Request lifecycle
A typical request follows this sequence:
The user asks a question in the private chat.
SlinkyLayer sends the model request through Tor to a ZDR endpoint.
The model processes the conversation and determines whether an external capability is useful.
If no tool is needed, the response returns directly to the session.
If a tool is needed, the context router prepares a task-specific request.
The selected tool and any payment requirement are presented for approval.
The scoped request is sent through a separate Tor route.
The tool result returns to the original conversation.
Any payment or onchain action remains subject to its own authorization policy.
A question can use more than one specialist tool. Each tool should receive its own scoped request rather than inheriting the complete transcript.
Information visible at each boundary
Different parts of the system need access to different information.
ZDR model endpoint
Conversation content required for inference
Direct user IP address and provider-side retention after completion
Specialist tool
Scoped task and required parameters
Full conversation, unrelated history and direct user IP address
Public blockchain
Wallet addresses, payments and submitted transactions
Private chat content, unless a user explicitly places it onchain
User session
Conversation, tool results and approval decisions
Persistent provider credentials are not required
The selected model or tool must still receive the content needed to perform its work. Privacy comes from reducing unnecessary disclosure, protecting the network route and limiting retention.
Payments and public activity
x402 payments are separate from private model and tool processing. A payment may expose a wallet address, settlement amount, network and transaction record on a public blockchain.
Tor does not remove information already published onchain. Zero data retention at a model endpoint also has no effect on public wallet history.
Users and agents should therefore treat wallets as potentially persistent identifiers. Spending limits, wallet selection and approval policies should be managed independently of chat privacy.
Practical limits
SlinkyLayer is designed to minimize identity exposure, not to promise perfect anonymity.
A model sees the conversation content while producing a response. A specialist tool sees the scoped task it has been asked to complete. A public blockchain can expose settlement and transaction data.
Users should avoid including personal or confidential information unless it is necessary for the task. They should also review payment requirements and transaction details before authorizing an action.
The objective is to give each component the minimum information required for its role while preventing that information from spreading across the entire tool network.
Last updated