# Introduction to SlinkyLayer

The Private Access Layer for AI, Powered by x402.

SlinkyLayer is a private interface for working with AI models and specialist tools from one conversation. Users can ask a question, search the live web, conduct deeper research, examine markets, query blockchain data, and prepare onchain actions without managing separate provider accounts, API keys, or subscriptions.

When a request needs an external tool, SlinkyLayer prepares a focused version of the task instead of forwarding the entire conversation. Unrelated messages and identity information are excluded by default, and outbound requests are routed through Tor. The selected provider receives the information required to complete the task, but not the user’s direct network origin or full conversation history.

Tools are available through a growing network and can be discovered as they come online. Paid resources use x402, allowing users and agents to pay for individual requests rather than maintaining subscriptions or prepaid balances with each provider. Prices and payment requirements are presented as part of the request flow.

SlinkyLayer does not claim that every interaction is anonymous. A tool must still receive the information needed to answer a question, and activity submitted to a public blockchain remains visible onchain. The goal is practical privacy: disclose less, limit what each provider receives, and give users clearer control over when data is shared, money is spent, or an action is performed.

SlinkyLayer is currently in Public Beta. The interface, tool network, supported capabilities, pricing, and request formats will continue to develop as new providers and use cases are added.


# Using SlinkyLayer

Most people will use SlinkyLayer through the chat. You do not have to choose a provider before asking a question. Describe the result you need, and the chat will either answer directly or suggest a tool that is better suited to the task.<br>

1. **Ask the question -** Continue the conversation until the request is specific enough to run.
2. **Review the proposed tool -** Check what the tool will receive and how much the request costs.
3. **Approve the request -** Authorize the x402 payment if you want the tool to run.
4. **Read the result -** The output, sources and payment information return to the same conversation.

> Why did the probability of an ETH staking ETF approval change today? Compare current reporting with prediction-market activity.

A question like this can use current web information and market data. SlinkyLayer can separate those jobs, send each tool only the part it needs, and bring the results back into one conversation.

{% hint style="info" %}
**Before approval**

Remove names, addresses, credentials and other details that are not needed for the task. The selected tool can read the task it has been asked to perform.
{% endhint %}


# Public Beta status

The chat, routing path, tool discovery and x402 payment flow are working parts of the product. The exact set of tools and the details of individual resources will continue to change during the beta.

A tool may be added or removed, an opaque route identifier may rotate, and a request body may gain fields. Prices, supported networks, accepted assets and rate limits can also differ between resources.

For this reason, clients should discover resources at runtime and match them by capability suffix. Do not keep the full URL of a discovered resource as permanent configuration.


# How requests are routed

The chat and the tool network serve different purposes. The chat holds the conversation. A downstream tool should receive a specific job that it can complete, not every message that led to that job.

For example, a market-data request for the current ETH price needs an asset, quote currency and time window. It does not need earlier discussion about another asset, a private investment thesis or a wallet label.<br>

<div data-with-frame="true"><figure><img src="/files/8cYCn9oKIFwh5W5D9cie" alt=""><figcaption></figcaption></figure></div>

{% hint style="info" %}
The routing step keeps the fields needed for the job and excludes unrelated context.
{% endhint %}

#### What the router does

1. Identifies the capability needed for the next part of the task.
2. Extracts the fields and instructions relevant to that capability.
3. Excludes unrelated history and identity labels by default.
4. Sends the prepared request through the Tor egress path.
5. Returns the result to the original conversation.

This is selective disclosure, not automatic removal of every sensitive fact. If a user asks a tool to investigate a named person or wallet, that name or address is part of the task and the tool will receive it.


# The SlinkyLayer tool network

SlinkyLayer provides one private interface for working with AI models and specialist tools. A user can begin with an ordinary question, then bring in live web search, research, market data, blockchain data or another capability when the task requires it.

The tool network is designed to grow without making the interface more complicated. New services can be added behind the same conversation instead of asking users to create another account, purchase another subscription or manage another API key.

### How it works

A question does not automatically go to every available tool. SlinkyLayer first determines whether an external capability is needed and selects a suitable resource from the network.

For a tool-assisted request, SlinkyLayer:

1. Identifies the capability required by the task.
2. Prepares a focused request for the selected tool.
3. Removes unrelated conversation history and identity information by default.
4. Routes the outbound request through Tor.
5. Presents any x402 payment requirement.
6. Runs the tool after payment or authorization is approved.
7. Returns the result to the original conversation.

The selected tool receives the information it needs to complete its assignment. It does not receive the full conversation by default.

For example, a market-data provider may need an asset symbol, quote currency and time range. It does not need unrelated messages about another asset, the user's broader investment thesis or an earlier research conversation.

### Available capabilities

The network is not limited to a fixed set of providers. Tools may be added, updated or removed as the product develops.

Current capability areas include:

| Capability         | Typical use                                                         |
| ------------------ | ------------------------------------------------------------------- |
| AI models          | Reasoning, writing, coding, analysis and synthesis                  |
| Live web           | Current reporting, announcements and primary sources                |
| Deep research      | Multi-source investigations, citations and evidence review          |
| Market data        | Prices, liquidity, volume, positioning and market activity          |
| Prediction markets | Probabilities, market disagreement and changing odds                |
| Blockchain data    | Wallet activity, token flows, governance and protocol state         |
| RWA intelligence   | Tokenized assets, issuers, yields and underlying markets            |
| Agents             | Monitoring, automation and multi-step workflows                     |
| Execution          | Preparing orders, transactions, alerts and other authorized actions |

These categories describe the network rather than a permanent list of products. The live discovery document is the source to use when checking what is currently available.

### Live tool discovery

The current tool catalog is published at:

[Open the live SlinkyLayer tool catalog](https://x402.slinkylayer.ai/.well-known/x402)

```
https://x402.slinkylayer.ai/.well-known/x402
```

The discovery document is machine-readable. Opening it in a browser will normally display JSON rather than a visual tool directory.

Users who prefer a visual interface can browse the available tools here:

[Explore tools in the SlinkyLayer app](https://app.slinkylayer.ai/apis)

### Why the catalog is discovered live

A copied list becomes outdated as soon as a resource changes. Prices, supported networks, request formats and availability can also change independently of the documentation.

Applications and agents should therefore read the discovery document when they need the current catalog. They should not rely on a list copied into source code or documentation.

A short-lived cache may be useful for performance, but clients should refresh it regularly and handle the possibility that a previously available resource has changed.

### Reading the catalog from a terminal

```bash
curl "https://x402.slinkylayer.ai/.well-known/x402"
```

To format the response when `jq` is installed:

```bash
curl --silent \
  "https://x402.slinkylayer.ai/.well-known/x402" |
  jq
```

### Reading the catalog with TypeScript

```typescript
const discoveryUrl =
  "https://x402.slinkylayer.ai/.well-known/x402";

async function getToolCatalog() {
  const response = await fetch(discoveryUrl, {
    headers: {
      Accept: "application/json",
    },
  });

  if (!response.ok) {
    throw new Error(
      `Unable to load tool catalog: ${response.status} ${response.statusText}`
    );
  }

  return response.json();
}

const catalog = await getToolCatalog();

console.dir(catalog, { depth: null });
```

Clients should inspect the returned document instead of assuming that every resource has the same request shape, price or payment requirements.

### Choosing a tool

Tool selection should be based on the job that needs to be completed. A request for current information may require live web search. A request about price or liquidity may require market data. A question involving wallet activity may require a blockchain data resource.

Some questions need more than one step. A research task might search current sources, compare market data and then use a model to organize the findings. Each tool should receive only the context required for its part of the task.

SlinkyLayer can keep the sequence inside one conversation, but the tools remain separate services. An output from one step may become input to the next without exposing the entire conversation to every provider.

### Payments through x402

Some tools are free to call, while others require payment. Paid resources use x402 to present a payment requirement as part of the HTTP request flow.

When a payment is required, the client can review the amount, asset, network and destination before authorizing it. After authorization, the request is repeated with the required payment information.

This makes it possible to pay for an individual request without opening an account or maintaining a subscription with each provider.

Payment does not grant broader permission. Paying for one request does not authorize another tool call, reveal more conversation history or approve an onchain action. Each paid or state-changing operation should be evaluated separately.

### Privacy across the network

Tor routing helps prevent downstream tools from receiving the user's direct IP address and network origin. Scoped requests also reduce the amount of conversation data shared with each provider.

These protections have practical limits. A selected tool must still receive the task information needed to produce a result. If a user asks about a named person, wallet or organization, that information may be part of the scoped request.

Public blockchain activity has its own visibility. Wallet addresses, transactions and other submitted actions may remain observable after they are published onchain. Tor routing does not make public blockchain records private.

SlinkyLayer is designed to reduce unnecessary disclosure. It does not claim that third-party computation or public blockchain activity becomes invisible.

### Building against a changing network

Developers and agents should treat the discovery document as live service data. A reliable integration should:

* Fetch or regularly refresh the catalog.
* Validate the selected resource before calling it.
* Read the current request requirements.
* Inspect the price before authorizing payment.
* Apply spending and network restrictions.
* Handle unavailable or changed resources.
* Set timeouts for external requests.
* Avoid automatically repeating a payment after an uncertain result.
* Require explicit approval before consequential actions.

The network is currently in Public Beta. Resource identifiers, request formats, pricing and supported capabilities may change as new tools are introduced.

### Using the network from SlinkyLayer

Most users do not need to call the discovery endpoint directly. They can ask a question in the SlinkyLayer chat and allow the interface to suggest an appropriate tool.

[Open SlinkyLayer chat](https://app.slinkylayer.ai/chat)

Before a paid tool runs, the interface can present the selected capability and its price. The result is then returned to the same conversation, keeping the research process in one place while limiting what is shared with each external provider.


# Privacy architecture

How SlinkyLayer protects the original conversation, limits what specialist tools receive, and separates private requests from public settlement.

<figure><img src="/files/46PF1LzOJJk34YZScyLu" alt=""><figcaption></figcaption></figure>

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:

1. The original chat is Tor-routed to a zero-data-retention model endpoint.
2. 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.

| Control                        | What it protects                                                                               |
| ------------------------------ | ---------------------------------------------------------------------------------------------- |
| 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:

1. The user asks a question in the private chat.
2. SlinkyLayer sends the model request through Tor to a ZDR endpoint.
3. The model processes the conversation and determines whether an external capability is useful.
4. If no tool is needed, the response returns directly to the session.
5. If a tool is needed, the context router prepares a task-specific request.
6. The selected tool and any payment requirement are presented for approval.
7. The scoped request is sent through a separate Tor route.
8. The tool result returns to the original conversation.
9. 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.

| Boundary           | Information it processes                              | Information excluded by default                                     |
| ------------------ | ----------------------------------------------------- | ------------------------------------------------------------------- |
| 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.


# Data handling

Data classes, expected locations, retention rules, deletion behavior, and telemetry requirements.

### Classify data before choosing storage

Storage policy follows data class rather than convenience. Conversation bodies, payment metadata, operational telemetry, public source material, and configuration changes have different sensitivity, durability, and audit requirements.

<figure><img src="/files/7LxH25xYev1fRAFWzMTO" alt=""><figcaption></figcaption></figure>

### Retention classes and enforcement points

<figure><img src="/files/j9Em2zYYSTFVUn2nlUkV" alt=""><figcaption></figcaption></figure>

### Local-first still needs lifecycle controls

\
Local storage reduces server-side concentration but does not make data invulnerable. The client should expose clear session, persist, export, and delete choices, and it should explain whether browser storage is encrypted, synchronized, backed up, or available to other scripts on the same origin.

High-sensitivity deployments should separate the documentation origin, application origin, and untrusted content rendering origin. Content Security Policy, dependency review, and extension risk guidance matter because the private transcript exists before any network routing control can protect it.

### Observe the service without collecting the conversation

Operational events should contain typed fields such as route identifier, status class, latency bucket, cost, network, adapter version, and opaque request identifier. They should not contain prompt text, result text, source page content, wallet labels, or a stable cross-session user fingerprint.


# Threat model

Assets, adversaries, abuse cases, mitigations, and residual risks for the Slinky request path.

### Protect intent, authority, value, and integrity

The highest-value asset is not only the prompt. The system must also protect tool-selection logic, unpublished research, wallet authority, spending policy, vendor credentials, response provenance, configuration, and the evidence that binds a result to a paid operation.

<figure><img src="/files/MnVtYNSXOxdugDLYV8Xl" alt=""><figcaption></figcaption></figure>

### Assume partial compromise and hostile inputs

Relevant adversaries include a passive network observer, a malicious or compromised provider, an abusive client, a compromised browser, a poisoned web page, a leaked vendor credential, and an operator with excessive production access. The architecture does not assume every external system colludes, but it avoids giving one system enough data by default.

### Primary risks and required controls

| THREAT                                  | CONTROL                                                                                    | RESIDUAL RISK                                                               |
| --------------------------------------- | ------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------- |
| Cross-request identity correlation      | Accountless access, Tor route, identifier stripping, wallet separation guidance            | Unique task text and reused payment addresses can remain linkable           |
| Prompt leakage through logs             | Allowlisted telemetry schema, body redaction, log tests, restricted debug workflow         | Application crashes or third-party middleware can capture unexpected fields |
| Duplicate charge on retry               | Idempotency keys, canonical request hashes, settlement reconciliation                      | Client crash between settlement and local receipt persistence               |
| Prompt injection from retrieved content | Treat sources as data, isolate instructions, tool allowlists, action approval boundary     | A model can still misclassify adversarial content                           |
| Provider credential theft               | Server-side secret manager, scoped keys, egress controls, rotation, usage alerts           | Provider-side compromise remains outside direct control                     |
| Wallet drain through malicious quote    | Destination allowlist, per-call cap, network and asset checks, simulation where applicable | User can explicitly approve a harmful transaction                           |
| Direct-route privacy bypass             | Fail-closed Tor policy, egress verification, route health monitoring                       | Timing and volume analysis may still be possible                            |
| Result tampering                        | TLS, schema validation, source metadata, response hashes, signed receipts where available  | Source publishers can change or remove evidence later                       |

### Communicate what controls cannot remove

Residual risk belongs in product decisions, not only in a security appendix. Clients should warn when a task contains a public wallet address, requests an identifiable personal record, requires a provider with weaker retention terms, or leads to a public transaction.

Risk acceptance must be specific to a route and capability. A broad privacy label cannot replace a tested data flow, a published retention period, or an explicit action confirmation.


# 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.


# How x402 requests work

x402 lets an HTTP resource return a price as part of the request flow. The client can pay for one call without creating a subscription or keeping a prepaid balance with the individual provider.<br>

<figure><img src="/files/tmCBqhzed8XS5zGoK1G0" alt=""><figcaption></figcaption></figure>

1. The client sends a normal request to a discovered resource.
2. The resource returns HTTP `402` and a `PAYMENT-REQUIRED` header.
3. The client checks the amount, network, asset, destination and expiry.
4. A compatible wallet creates the authorization.
5. The client repeats the request with `PAYMENT-SIGNATURE`.
6. The resource returns the result and can include `PAYMENT-RESPONSE`.

Paying for one resource does not grant permission to read more conversation history, call a second paid resource or submit an onchain action. Each additional operation needs its own policy decision.


# Discover and call tools

Read the discovery document when the application starts, when a cached resource returns `404`, or before a long-running agent begins a new job.

```shellscript
curl https://x402.slinkylayer.ai/.well-known/x402
```

The following example discovers the current `/web_search` resource. It accepts a payment-aware fetch function supplied by the caller, which keeps wallet setup separate from discovery.

<pre class="language-typescript"><code class="lang-typescript"><strong>type DiscoveryDocument = {
</strong>  version: number;
  resources: string[];
};

const DISCOVERY_URL =
  "https://x402.slinkylayer.ai/.well-known/x402";

export async function runWebSearch(
  fetchWithPayment: typeof fetch,
  query: string,
) {
  const discoveryResponse = await fetch(DISCOVERY_URL, {
    headers: { accept: "application/json" },
  });

  if (!discoveryResponse.ok) {
    throw new Error(
      "Tool discovery failed: " + discoveryResponse.status,
    );
  }

  const catalog =
    (await discoveryResponse.json()) as DiscoveryDocument;

  const resourceUrl = catalog.resources.find((resource) =>
    resource.endsWith("/web_search"),
  );

  if (!resourceUrl) {
    throw new Error("web_search is not currently available");
  }

  const response = await fetchWithPayment(resourceUrl, {
    method: "POST",
    headers: { "content-type": "application/json" },
    body: JSON.stringify({ query }),
  });

  if (!response.ok) {
    throw new Error("Tool request failed: " + response.status);
  }

  return response.json();
}
</code></pre>

The body illustrates a simple web-search call. Tool inputs can differ, so validate the request shape used by the selected resource before sending production traffic.

{% hint style="info" %}
**Keep signing material out of the browser**

Use a maintained x402 client in a server process or isolated signer. An autonomous agent should use a dedicated wallet with explicit spending limits and an allowlist of resources.
{% endhint %}


# Errors and retries

A failed tool call is not always safe to repeat. Decide what to do from the HTTP status and from whether a payment authorization was created or sent.

<table><thead><tr><th width="103.8402099609375">Status</th><th width="225.02911376953125">Meaning</th><th>Recommended handling</th></tr></thead><tbody><tr><td><code>400</code></td><td>Invalid tool input</td><td>Correct the body. Do not repeat it unchanged.</td></tr><tr><td><code>402</code></td><td>Payment required</td><td>Read the requirement, apply policy and authorize if approved.</td></tr><tr><td><code>404</code></td><td>Resource unavailable</td><td>Refresh discovery and select the current URL.</td></tr><tr><td><code>429</code></td><td>Capacity or rate limit</td><td>Use Retry-After or bounded backoff with jitter.</td></tr><tr><td><code>5xx</code></td><td>Gateway or tool failure</td><td>Check payment state before trying again.</td></tr></tbody></table>

#### After a paid request

Once an authorization has been sent, a timeout does not prove that settlement failed. Repeating the task with a new authorization can lead to duplicate spend. Reuse an idempotency key when supported and reconcile the earlier operation before creating another payment.


# Security checklist

#### Wallets and payment

* Keep private keys in a server-side secret store or isolated signer.
* Set per-request, hourly and daily limits.
* Restrict networks, assets, hosts and capability types.
* Check payment state before retrying an ambiguous request.

#### Requests and output

* Remove details that the selected tool does not need.
* Treat retrieved pages and model output as untrusted.
* Sanitize content before rendering it as HTML.
* Require approval for transfers, orders and other actions.

#### Logs and support

* Log status, timing and payment state instead of prompt bodies.
* Redact authorization headers, cookies and wallet secrets.
* Keep diagnostic capture disabled by default.
* Document access and retention for operational logs.


# Frequently asked questions

<details>

<summary>Is SlinkyLayer anonymous?</summary>

SlinkyLayer is designed to minimize identity exposure, not promise perfect anonymity. It avoids persistent accounts, scopes tool context and routes outbound tool requests through Tor. Selected tools still receive the task they must process, and public blockchain activity remains observable.

</details>

<details open>

<summary>Does every tool receive my full conversation?</summary>

No. The router prepares a scoped task for the selected capability. Unrelated conversation history is not sent by default.

</details>

<details open>

<summary>What does Tor protect?</summary>

Tor helps prevent upstream models and tools from seeing the user's direct IP address and network origin. It does not hide the scoped task from the tool that performs it.

</details>

<details open>

<summary>What does zero retention mean?</summary>

It describes an endpoint configured not to retain prompts or outputs after the request. Handling can vary by tool, so the applicable policy should be visible before approval.

</details>

<details open>

<summary>Why did a tool URL change?</summary>

The tool network is dynamic. Refresh the well-known discovery document and select the current resource by its stable capability suffix.

</details>

<details open>

<summary>What becomes public when I use blockchain features?</summary>

Submitted payments and actions can expose wallet addresses, amounts, application interactions and transaction history on a public network. Tor does not make public ledger activity private.

</details>

<details open>

<summary>Can an autonomous agent use SlinkyLayer?</summary>

Yes. Use a compatible x402 wallet client, strict spending limits, an allowlist of tools and explicit escalation rules for consequential actions.

</details>


# SLINKY Token

SLINKY is the access token for SlinkyLayer. Its primary utility is private-chat bandwidth. Users can begin with a complimentary allowance, then hold SLINKY to unlock continued access to private AI conversations. SLINKY can also unlock designated platform features and selected specialist tools.

The token is not used to pay for external tool calls. Specialist tools are priced separately in USDC on Base and settled through x402.

This page describes how SLINKY functions within the product. It is not an offer to sell or a solicitation to buy SLINKY. Please read [Legal Notices & Risk Factors](https://docs.slinky.network/slinkylayer/legal-notices-and-risk-factors) alongside this page.

#### At a glance

| SlinkyLayer service               | Access requirement                                                                | Payment method                                                                                                     |
| --------------------------------- | --------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ |
| Complimentary private chat        | Available without holding SLINKY, subject to the allowance shown in the interface | No separate tool payment                                                                                           |
| Additional private-chat bandwidth | Hold the amount of SLINKY shown in the interface                                  | SLINKY is held, not spent. Unlocking bandwidth does not transfer, burn, lock, or reduce the user's SLINKY balance. |
| Open specialist tools             | Available to eligible users                                                       | Per-request USDC payment on Base through x402                                                                      |
| Token-gated specialist tools      | Meet the SLINKY holding requirement shown in the interface                        | Per-request USDC payment on Base through x402                                                                      |

#### Private chat bandwidth

Every user can start with a complimentary allowance for private AI conversations. This provides a way to use the chat before holding SLINKY. Once that allowance has been used, holding SLINKY unlocks additional private-chat bandwidth under the active bandwidth schedule.

Private-chat bandwidth covers the services required to run the conversation, including model inference, context processing, response generation, and chat orchestration. It does not cover the price charged by an external tool or API.

The current SLINKY holding requirements, available chat quotas, quota periods, reset conditions, and rate limits are published in the SlinkyLayer interface. The interface displays the rules that apply at the time the service is used.

#### How bandwidth is measured

Private-chat requests do not all require the same amount of computation. A short exchange will generally use less bandwidth than an extended conversation with a large context window or a more computationally intensive reasoning mode.

Bandwidth usage may reflect:

* the model selected for the conversation;
* the length of the prompt and response;
* the amount of conversation context being processed;
* the reasoning mode requested;
* infrastructure and network demand; and
* rate-limit, security, and abuse controls.

The interface shows the user's available quota and relevant usage information. Bandwidth represents access to the private-chat service and should not be understood as a guaranteed number of messages.

#### Specialist tools and x402

SlinkyLayer can route a request from the private chat to a specialist tool for live-web search, research, market data, blockchain data, prediction markets, execution, or another supported capability. These tools operate separately from private-chat bandwidth.

When a tool charges for a request, the interface identifies the selected tool and displays its USDC price. The user then authorizes the payment on Base through x402.

This creates a clear separation between the two service layers:

1. **Private chat:** SLINKY unlocks bandwidth for the conversation, model response, context processing, and routing.
2. **Specialist tool:** USDC pays for the selected tool call through x402.

An x402 payment purchases the identified tool service. It does not purchase SLINKY, reduce the user's SLINKY balance, or create any entitlement to a token distribution.

Specialist tools are operated by third parties. SlinkyLayer routes requests to them and does not guarantee their availability, accuracy, pricing, or continued support. Certain tools may be unavailable in certain jurisdictions or to certain users.

#### Token-gated tools and features

Selected tools and platform features can be reserved for users who meet a stated SLINKY holding requirement. In these cases, SLINKY acts as the access credential. It determines whether the user can invoke the tool, but it does not pay the tool's usage price.

After access is confirmed, the user still authorizes the applicable USDC payment through x402. Other tools may remain available to any eligible user who pays the displayed x402 price.

The SlinkyLayer interface identifies token-gated tools, displays their current SLINKY requirements, and shows the available tool network. Because providers, pricing, coverage, and integrations can change, the interface is the authoritative source for current tool availability and access conditions.

#### What holding SLINKY provides

Under the active product rules displayed in the interface, holding SLINKY can provide:

* additional private-chat bandwidth;
* access to designated chat modes or service tiers;
* eligibility to use selected specialist tools;
* increased chat rate limits; and
* access to other identified platform features.

These are product-access benefits. They do not create a right to money or financial returns.

#### Changes to access requirements

SlinkyLayer sets holding requirements, quotas, quota periods, reset conditions, and rate limits, and can change them. These values are adjusted in response to model pricing, inference and infrastructure costs, service capacity, security and abuse conditions, and product design.

They are not adjusted to manage the market price of SLINKY, to influence trading activity, or to produce a financial outcome for holders.

SlinkyLayer does not commit to maintaining any particular ratio between SLINKY held and bandwidth received. The amount of bandwidth a given quantity of SLINKY unlocks can decrease as well as increase. Current values are always shown in the interface, which is the authoritative source at the time of use.

#### What SLINKY does not provide

SLINKY does not represent:

* equity or ownership in SlinkyLayer or an affiliated entity;
* debt, repayment rights, or a claim against company assets;
* dividends, revenue sharing, profit sharing, interest, or passive yield;
* a promise of liquidity, listing, market support, or price appreciation;
* a guarantee that another person will purchase the token; or
* a right to redeem SLINKY or bandwidth for a particular fiat value.

SLINKY is not a bank account, deposit, stablecoin, stored-value account, or payment account. Private-chat bandwidth is not money, is not transferable, and cannot be redeemed for cash.

#### Acquiring SLINKY

SLINKY is intended to be acquired and held for access to SlinkyLayer services. It should not be acquired for investment purposes, in expectation of profit, or in expectation that SlinkyLayer or any other person will undertake efforts to increase its value.

SlinkyLayer does not offer, sell, or distribute SLINKY through this documentation. Nothing on this page is an offer to sell, a solicitation of an offer to buy, or a recommendation regarding SLINKY or any other asset, and nothing here is investment, financial, legal, tax, or accounting advice.

SLINKY may lose all of its value, and SlinkyLayer may modify, suspend, or discontinue any service at any time. See [Legal Notices & Risk Factors](https://docs.slinky.network/slinkylayer/legal-notices-and-risk-factors).

#### Eligibility and restricted jurisdictions

Access to SlinkyLayer is subject to the Terms of Service. Services are not available to:

* persons located in, ordinarily resident in, or organised under the laws of a jurisdiction subject to comprehensive sanctions administered by OFAC or an equivalent authority;
* persons appearing on any applicable sanctions or restricted-party list; or
* persons in any jurisdiction where use of the services would breach local law.

Users are responsible for determining whether their use of SlinkyLayer, and any holding of SLINKY, is lawful in their jurisdiction.


# SLINKY Tokenomics

{% hint style="danger" %}
SlinkyLayer has not conducted a public sale of SLINKY and does not intend to conduct one.
{% endhint %}

SLINKY is the access token for SlinkyLayer. It is used for private-chat bandwidth and designated platform features. Paid specialist tools operate separately, and when a tool has a usage fee, the user pays that fee in USDC on Base through x402.

This page describes token supply, allocation, and release. It is not an offer to sell or a solicitation to buy SLINKY, and the figures below are not a forecast or projection of price, value, or market performance. Please read [Legal Notices & Risk Factors](https://docs.slinky.network/slinkylayer/legal-notices-and-risk-factors) alongside this page.

#### Supply at a glance

| Item                         | Detail                                                                                                              |
| ---------------------------- | ------------------------------------------------------------------------------------------------------------------- |
| Token                        | SLINKY                                                                                                              |
| Network                      | Base                                                                                                                |
| Token standard               | ERC-20                                                                                                              |
| Contract address             | [0xBB3D6C47379Abb4713Acffffa27483B726ee67dB](https://basescan.org/token/0xbb3d6c47379abb4713acffffa27483b726ee67db) |
| Total supply                 | 1,000,000,000 SLINKY                                                                                                |
| Mint function                | None. Supply is fixed at 1,000,000,000.                                                                             |
| Transfer tax                 | None                                                                                                                |
| Pause or blacklist functions | None                                                                                                                |
| Primary utility              | Private-chat bandwidth and designated SlinkyLayer features                                                          |
| Specialist tool payments     | USDC on Base through x402                                                                                           |

Always verify the contract address above before interacting with any token claiming to be SLINKY. SlinkyLayer will never contact you asking you to send tokens or to connect a wallet in order to claim a distribution.

#### Allocation

<table><thead><tr><th width="195.9261474609375">Allocation</th><th width="146.72723388671875">Tokens</th><th width="112.45458984375">Share</th><th>Vesting</th></tr></thead><tbody><tr><td>Community and ecosystem</td><td>650,000,000</td><td>65%</td><td>No tokens from this allocation are unlocked at TGE. Tokens are held in treasury at <code>0x8d9694251c0bE8C5aFd475Eff8b7af0B6c52EFa6</code></td></tr><tr><td>Liquidity</td><td>157,888,890</td><td>15.8%</td><td>Deployed at TGE to provide trading liquidity</td></tr><tr><td>Team and core contributors</td><td>150,000,000</td><td>15%</td><td>0% TGE, 6-month cliff, 100% linear release over 18 months</td></tr><tr><td>Pre-seed round</td><td>18,666,666</td><td>1.9%</td><td>5% TGE, 3-month cliff, 95% linear release over 15 months</td></tr><tr><td>Seed round</td><td>13,444,444</td><td>1.3%</td><td>10% TGE, 3-month cliff, 90% linear release over 12 months</td></tr><tr><td>Advisors</td><td>10,000,000</td><td>1%</td><td>0% TGE, 6-month cliff, 100% linear release over 18 months</td></tr><tr><td><strong>Total</strong></td><td><strong>1,000,000,000</strong></td><td><strong>100%</strong></td><td></td></tr></tbody></table>

#### Liquidity

The liquidity allocation is deployed to Aerodrome on Base. SlinkyLayer does not commit to maintaining liquidity, to supporting any price level, or to ensuring that SLINKY can be bought or sold at any particular time or price. SLINKY trades on permissionless venues that SlinkyLayer does not control.

#### Important notice

The figures on this page describe token supply and allocation. They are not a forecast, projection, estimate, or representation regarding the price, value, liquidity, or market performance of SLINKY.

SLINKY does not represent equity, debt, dividends, revenue share, profit share, interest, or yield, and does not create any claim against SlinkyLayer or its assets. The full statement is set out under [What SLINKY does not provide](/slinkylayer/slinky-token#what-slinky-does-not-provide).

SlinkyLayer, its team, advisors, and early investors hold SLINKY. Their allocations and vesting terms are set out above, and their interests may differ from those of other holders.

Allocation and vesting terms may be amended. Material changes will be reflected on this page.


# Legal Notices & Risk Factors

This page applies to all SlinkyLayer documentation, including the [SLINKY Token](https://docs.slinky.network/slinkylayer/slinky-token) and [SLINKY Tokenomics](https://docs.slinky.network/slinkylayer/slinky-tokenomics) pages. Please read it before relying on anything in this documentation.

#### No offer or solicitation

This documentation is provided for informational purposes only. It does not constitute an offer to sell, a solicitation of an offer to buy, or a recommendation regarding SLINKY or any other asset, in any jurisdiction in which such an offer, solicitation, or recommendation would be unlawful.

Nothing in this documentation is investment, financial, legal, tax, or accounting advice. You should obtain your own professional advice before acquiring, holding, or using any crypto asset.

#### No investment purpose

SLINKY is intended to be acquired and held for access to SlinkyLayer services. It should not be acquired for investment purposes, in expectation of profit, or in expectation that SlinkyLayer or any other person will undertake efforts to increase its value.

#### Forward-looking statements

This documentation describes current plans, intended functionality, and services that may be developed. Statements about future features, tool integrations, supported models, roadmap items, or product direction are plans rather than commitments. They are subject to change, delay, or cancellation without notice, and SlinkyLayer undertakes no obligation to update them.

No statement in this documentation should be understood as a commitment by SlinkyLayer or any other person to undertake efforts intended to increase the value or price of SLINKY.

#### Risk factors

Holding or using SLINKY involves significant risk, including the following.

**Total loss.** SLINKY may lose all of its value. You may lose the entire amount you paid to acquire it. You should not acquire SLINKY with funds you cannot afford to lose entirely.

**No redemption.** SLINKY cannot be redeemed for cash, for any fixed value, or for any asset. Private-chat bandwidth is not money, is not transferable, and cannot be redeemed.

**Changes to access requirements.** SlinkyLayer sets and may change holding requirements, quotas, and rate limits. The amount of bandwidth or access a given quantity of SLINKY unlocks can decrease as well as increase.

**Service dependency.** SlinkyLayer depends on third-party model providers, infrastructure providers, payment rails, and tool APIs. Their availability, performance, pricing, and terms may change, and those changes may affect the services SlinkyLayer can offer and the access requirements it sets.

**Discontinuation.** SlinkyLayer may modify, suspend, or discontinue any service, including private chat, at any time and without notice. SLINKY would retain no functional utility if the services were discontinued.

**Regulatory.** The legal and regulatory treatment of crypto assets is developing and varies by jurisdiction. Changes in law, regulation, or regulatory interpretation, or actions by a regulator, could restrict the use or transfer of SLINKY, restrict SlinkyLayer's services, or make them unavailable in particular jurisdictions.

**Technical.** Smart contracts may contain vulnerabilities. Blockchain transactions are generally irreversible. Loss or compromise of private keys results in permanent loss of tokens. SlinkyLayer cannot recover lost tokens or reverse transactions.

**Market.** SLINKY trades on permissionless venues that SlinkyLayer does not operate or control. Price may be highly volatile. Liquidity may be thin, may decline, or may cease to exist. There is no assurance that SLINKY can be bought or sold at any particular time or price.

**Concentration.** A significant portion of total supply is held by SlinkyLayer, its team, advisors, and early investors, subject to the vesting terms published on the Tokenomics page. Releases from these allocations may affect the market.

**Third-party statements.** SlinkyLayer is not responsible for statements about SLINKY made by any third party, including exchanges, data aggregators, commentators, community members, or other holders. Only statements published on official SlinkyLayer channels are attributable to SlinkyLayer.

**Tax.** The tax treatment of acquiring, holding, transferring, or using SLINKY depends on your circumstances and jurisdiction. You are responsible for your own tax position.

This is not an exhaustive list of the risks associated with SLINKY or with SlinkyLayer.

#### Interests of SlinkyLayer and related persons

SlinkyLayer, its team, advisors, and early investors hold SLINKY. Their allocations and vesting terms are set out on the [Tokenomics](https://docs.slinky.network/slinkylayer/slinky-tokenomics) page. These parties may transact in SLINKY subject to applicable vesting terms and internal policy. Their interests may differ from, and may conflict with, those of other holders.

#### Eligibility and restricted jurisdictions

Access to SlinkyLayer is subject to the Terms of Service. Services are not available to:

* persons located in, ordinarily resident in, or organised under the laws of a jurisdiction subject to comprehensive sanctions administered by OFAC or an equivalent authority;
* persons appearing on any applicable sanctions or restricted-party list; or
* persons in any jurisdiction where use of the services would breach local law.

You are responsible for determining whether your use of SlinkyLayer, and any holding of SLINKY, is lawful in your jurisdiction.

#### Third-party tools

SlinkyLayer can route requests to specialist tools operated by third parties, including tools for live-web search, research, market data, blockchain data, prediction markets, and execution. SlinkyLayer does not operate these tools and does not guarantee their availability, accuracy, legality in your jurisdiction, pricing, or continued support. Your use of a third-party tool may be subject to that provider's own terms.

Certain tools may be unavailable in certain jurisdictions or to certain users.&#x20;

#### No warranty

SlinkyLayer services and this documentation are provided on an "as is" and "as available" basis, without warranties of any kind to the extent permitted by law. Model outputs may be inaccurate, incomplete, or unsuitable for your purposes, and should not be relied on as professional advice.

#### Changes to this documentation

SlinkyLayer may amend this documentation at any time. Material changes will be reflected on the relevant page together with the date of the change. The version published at the time of use is the applicable version.


# SLINKY Token (old)

SLINKY is the access token for SlinkyLayer. Its primary utility is private-chat bandwidth. Users can begin with a complimentary allowance, then hold SLINKY to unlock continued access to private AI conversations. SLINKY can also unlock designated platform features and selected specialist tools.

The token is not used to pay for external tool calls. Specialist tools are priced separately in USDC on Base and settled through x402.

### At a glance

<table data-header-hidden="false" data-header-sticky><thead><tr><th width="204.36151123046875">SlinkyLayer service</th><th width="297.5653076171875">Access requirement</th><th width="248.9971923828125">Payment method</th></tr></thead><tbody><tr><td>Complimentary private chat</td><td>Available without holding SLINKY, subject to the allowance shown in the interface</td><td>No separate tool payment</td></tr><tr><td>Additional private-chat bandwidth</td><td>Hold the amount of SLINKY shown in the interface</td><td>SLINKY remains in the user's wallet unless the interface expressly states otherwise</td></tr><tr><td>Open specialist tools</td><td>Available to eligible users</td><td>Per-request USDC payment on Base through x402</td></tr><tr><td>Token-gated specialist tools</td><td>Meet the SLINKY holding or access requirement shown in the interface</td><td>Per-request USDC payment on Base through x402</td></tr></tbody></table>

### Private chat bandwidth

Every user can start with a complimentary allowance for private AI conversations. This provides a way to use the chat before holding SLINKY. Once that allowance has been used, holding SLINKY unlocks additional private chat bandwidth under the active bandwidth schedule.

Private-chat bandwidth covers the services required to run the conversation, including model inference, context processing, response generation, and chat orchestration. It does not cover the price charged by an external tool or API.

The current SLINKY holding requirements, available chat quotas, quota periods, reset conditions, and rate limits are published in the SlinkyLayer interface. These values can be updated as supported models, infrastructure costs, service capacity, and product conditions change. The interface displays the rules that apply at the time the service is used.

### How bandwidth is measured

Private-chat requests do not all require the same amount of computation. A short exchange will generally use less bandwidth than an extended conversation with a large context window or a more computationally intensive reasoning mode.

Bandwidth usage may reflect:

* the model selected for the conversation;
* the length of the prompt and response;
* the amount of conversation context being processed;
* the reasoning mode requested;
* infrastructure and network demand; and
* rate-limit, security, and abuse controls.

The interface shows the user's available quota and relevant usage information. Bandwidth represents access to the private-chat service and should not be understood as a guaranteed number of messages.

### Specialist tools and x402

SlinkyLayer can route a request from the private chat to a specialist tool for live-web search, research, market data, blockchain data, prediction markets, execution, or another supported capability. These tools operate separately from private-chat bandwidth.

When a tool charges for a request, the interface identifies the selected tool and displays its USDC price. The user then authorizes the payment on Base through x402.

This creates a clear separation between the two service layers:

1. **Private chat:** SLINKY unlocks bandwidth for the conversation, model response, context processing, and routing.
2. **Specialist tool:** USDC pays for the selected tool call through x402.

An x402 payment purchases the identified tool service. It does not purchase SLINKY, reduce the user's SLINKY balance, or automatically create an entitlement to a token distribution.

### Token-gated tools and features

Selected tools and platform features can be reserved for users who meet a stated SLINKY holding or access requirement. In these cases, SLINKY acts as the access credential. It determines whether the user can invoke the tool, but it does not pay the tool's usage price.

After access is confirmed, the user still authorizes the applicable USDC payment through x402. Other tools may remain available to any eligible user who pays the displayed x402 price.

The SlinkyLayer interface identifies token-gated tools, displays their current SLINKY requirements, and shows the available tool network. Because providers, pricing, coverage, and integrations can change, the interface is the authoritative source for current tool availability and access conditions.

### What holding SLINKY provides

Under the active product rules displayed in the interface, holding SLINKY can provide:

* additional private-chat bandwidth;
* access to designated chat modes or service tiers;
* eligibility to use selected specialist tools;
* increased chat rate limits; and
* access to other identified platform features.

These are product-access benefits. They do not create a right to money or financial returns.

### What SLINKY does not provide

SLINKY does not represent:

* equity or ownership in SlinkyLayer or an affiliated entity;
* debt, repayment rights, or a claim against company assets;
* dividends, revenue sharing, profit sharing, interest, or passive yield;
* a promise of liquidity, listing, market support, or price appreciation;
* a guarantee that another person will purchase the token; or
* a right to redeem SLINKY or bandwidth for a particular fiat value.

SLINKY is not a bank account, deposit, stablecoin, stored-value account, or payment account. Private-chat bandwidth is not money, is not transferable, and cannot be redeemed for cash.


# SLINKY Tokenomics

SLINKY is the access token for SlinkyLayer. It is used for private chat bandwidth and designated platform features. Paid specialist tools operate separately, and when a tool has a usage fee, the user pays that fee in USDC on Base through x402.

### Supply at a glance

<table data-header-hidden data-header-sticky><thead><tr><th>Item</th><th>Detail</th></tr></thead><tbody><tr><td>Token</td><td>SLINKY</td></tr><tr><td>Network</td><td>Base</td></tr><tr><td>Contract Address</td><td>0xBB3D6C47379Abb4713Acffffa27483B726ee67dB</td></tr><tr><td>Total supply</td><td>1,000,000,000 SLINKY</td></tr><tr><td>Primary utility</td><td>Private chat bandwidth and designated SlinkyLayer features</td></tr><tr><td>Specialist tool payments</td><td>USDC on Base through x402</td></tr></tbody></table>

### Allocation

<table data-header-hidden="false" data-header-sticky data-search="false"><thead><tr><th width="229.5675048828125">Allocation</th><th width="146.4232177734375">Tokens</th><th width="91.7762451171875">Share</th><th>Vesting</th></tr></thead><tbody><tr><td>Community and ecosystem</td><td>650,000,000</td><td>65%</td><td>-</td></tr><tr><td>Liquidity</td><td>157,888,890</td><td>15.8%</td><td>-</td></tr><tr><td>Team and core contributors</td><td>150,000,000</td><td>15%</td><td>0% TGE, 6 months cliff, 100% linear release over 18 months</td></tr><tr><td>Pre-seed round</td><td>18,666,666</td><td>1.9%</td><td>5% TGE, 3 months cliff, 95% linear release over 15 months </td></tr><tr><td>Seed round</td><td>13,444,444</td><td>1.3%</td><td>10% TGE, 3 months cliff, 90% linear release over 12 months</td></tr><tr><td>Advisors</td><td>10,000,000</td><td>1%</td><td>0% TGE, 6 months cliff, 100% linear release over 18 months</td></tr><tr><td><strong>Total</strong></td><td><strong>1,000,000,000</strong></td><td><strong>100%</strong></td><td></td></tr></tbody></table>


# SlinkyLayer Roadmap

SlinkyLayer is evolving from a live private AI application into a unified access layer for private models, specialist tools, and programmable digital payments.

### Phase 1: Product Foundation

**Q2 2026 | Completed**

* Beta release of the SlinkyLayer dApp
* Private conversation routing via Tor
* Integration with ZDR NVIDIA Nemotron open weight model
* Introduction of x402 enabled specialist tools for research, markets, blockchain data, and onchain activity
* Support for gasless, per-request USDC payments on Base through x402

### Phase 2: Token and Credits

**Q3 2026 | Current**

* SLINKY token TGE on Base
* Introduce a bandwidth system for private chat usage using SLINKY
* Launch the first phase of the user rewards program
* Add a dashboard for managing credits, rewards, usage, and payments

### Phase 3: Models, Tools, and Payments

**Q4 2026**

* Add support for x402 USDC payments on Solana
* Integrate third party tools from the x402 ecosystem
* Expand ZDR private access to frontier AI models
* Introduce model routing modes
* Improve tool discovery with clearer pricing, capabilities, and provider information
* Launch the SLINKY staking program

### Phase 4: Private AI Everywhere

**Q1 2027**

* Integrate private AI models served from Trusted Execution Environments (TEE)
* Release the SlinkyLayer extension for Google Chrome
* Expand the user rewards program
* Release SlinkyLayer mobile app

Roadmap priorities and release timing may evolve based on user feedback, technical development, and the availability of models and tools across the ecosystem.


# Terms of Service

Effective Date: 14th October, 2025

***

1. Acceptance of Terms\
   By accessing or using SlinkyLayer (“Platform”), you agree to be bound by these Terms of Service (“Terms”). If you do not agree with any of these Terms, you may not use the Platform.<br>
2. Description of Service\
   SlinkyLayer provides infrastructure for users to train, share, and consume crypto-market models and signals. Platform features require an EVM-compatible wallet for login and may evolve or change at any time, at SlinkyLayer’s discretion.<br>
3. Eligibility and Sanctioned Jurisdictions\
   You must be at least 18 years old and have legal capacity to form contracts under applicable law. Users are responsible for ensuring their use of SlinkyLayer complies with all relevant laws, including those governing cryptocurrencies and data. Individuals and entities located in sanctioned or prohibited jurisdictions, as defined by international law, are not permitted to use the Platform, nor participate in any token-based rewards, including initial pre-token-generation-event mining. Attempts to circumvent residency requirements will result in suspension and revocation of rewards.<br>
4. User Accounts and Wallets\
   Users access the Platform through EVM-compatible wallets. You are solely responsible for keeping your wallet credentials secure and for all actions that occur through your wallet connection. SlinkyLayer is not responsible for loss of access, unauthorized transactions, or wallet compromise. Use of the Platform for illegal activities is strictly prohibited.<br>
5. User Content, Model Ownership, and Platform Intellectual Property\
   All models and signals are created by users. You retain rights to use models and signals you create. By making any content public, you grant SlinkyLayer a non-exclusive, worldwide license to display, share, and distribute your public models and signals across the Platform and related services. The underlying source code, training methodology, and Platform infrastructure are proprietary and not accessible to users or creators. No rights are granted over Platform backend or algorithms. SlinkyLayer may remove content that is illegal, violates others’ rights, or fails to meet community standards. Users are solely responsible for their content and any outcomes from making content public.<br>
6. No Financial Advice\
   SlinkyLayer provides only infrastructure and informational content. No part of the Platform constitutes financial advice, investment advice, trading recommendations, or personalized guidance. SlinkyLayer, its developers, owners, and affiliates are not financial advisors. All signals, models, and outputs are user generated and provided for educational purposes. Decisions made based on Platform information are the sole responsibility of the user. SlinkyLayer does not guarantee the accuracy or outcome of any models, signals, or information.<br>
7. Limitation of Liability\
   SlinkyLayer is not liable for any direct, indirect, incidental, special, consequential, or punitive damages arising from use or inability to use the Platform. This includes, but is not limited to, losses resulting from relying on user-generated signals or models, wallet issues, or platform errors. SlinkyLayer makes no warranty or guarantee as to the accuracy, completeness, or reliability of content and outputs.<br>
8. Rewards and Tokens\
   Users may receive tokens or other incentives based on Platform activity. Rewards such as $SLINKY tokens are subject to availability, may change at any time, and may be subject to laws and regulations in your jurisdiction. Users from sanctioned or prohibited jurisdictions are not eligible for any rewards or incentive programs. SlinkyLayer does not guarantee any token’s future value, liquidity, or utility. Circumvention or false representation of jurisdiction will result in loss of eligibility and possible account suspension.<br>
9. Privacy\
   SlinkyLayer collects data including wallet addresses, session activity, and public submissions to ensure Platform functionality. All personal information is handled according to the SlinkyLayer Privacy Policy, which users are encouraged to review for full details.<br>
10. Modification of Terms\
    SlinkyLayer reserves the right to update or change these Terms at any time. Your continued use of the Platform after any modification constitutes acceptance of the revised Terms. Review these Terms regularly for updates.<br>
11. Governing Law\
    These Terms are governed by the laws of BVI. Any dispute related to these Terms or use of the Platform will be resolved exclusively by the courts of BVI.<br>
12. Contact\
    For questions, support, or legal concerns, contact SlinkyLayer at <gm@slinky.network>.

<br>


# Privacy Policy

Effective Date: 14th October, 2025

***

1\. Introduction\
This Privacy Policy describes how SlinkyLayer (“Platform”, “we”, “us”, “our”) collects, uses, shares, and protects information received from users (“you”, “your”) who access or use the Platform.<br>

2.Information We Collect

2.1 Wallet Information\
When you access SlinkyLayer, you authenticate using an EVM-compatible wallet. We collect your public wallet address for user identification, activity tracking, and administration of rewards programs.

2.2 Usage Data\
We collect technical data about your activity and interactions on the Platform, such as logins, model training activity, public model publishing, and interactions with content. Our systems may also capture timestamps, device/browser types, and usage patterns.

2.3 Public Content\
Any models, signals, or other information you choose to make public on the Platform are accessible to other users, indexed for display, and may be featured in platform galleries. This data is stored and shared as part of normal platform operation.

2.4 Communication Data\
If you contact SlinkyLayer for support or submit feedback, we may collect your email address and records of communication to help resolve your requests and improve our services.

3. Use of Information\
   We use collected information for the following purposes:

* Operating and maintaining the Platform
* Identifying users, providing account access, and managing sessions
* Administering rewards, tokens, and participation incentives
* Moderating content and ensuring compliance with our Terms of Service
* Analyzing usage to improve platform features and user experience
* Communicating with users regarding support, updates, or changes<br>

4. Sharing of Information\
   SlinkyLayer does not sell or rent personal information to third parties. We may share aggregated, anonymized usage data for analytics, token distribution, research, or platform development. Personal data may be shared:

* To comply with laws, regulations, or judicial requests
* With service providers who help us operate the platform, under strict confidentiality
* In connection with the sale or transfer of platform assets in the event of a business reorganization<br>

5. Data Retention\
   SlinkyLayer retains wallet addresses, public content, and usage records for as long as necessary to provide platform services and comply with legal obligations. You may request deletion of your public content or contact information by emailing <gm@slinky.network>.<br>
6. Security\
   We use technical and organizational safeguards to protect user data against unauthorized access, loss, or misuse. However, no system can guarantee complete security of information transmitted online or stored digitally.<br>
7. User Rights and Choices\
   Users may contact SlinkyLayer at <gm@slinky.network> to request access, correction, or deletion of their information. Since SlinkyLayer operates on publicly visible blockchain addresses, certain data may be immutable and cannot be deleted.<br>
8. International Users\
   SlinkyLayer is not available to individuals or entities located in sanctioned or prohibited jurisdictions. If you are located in one of these regions, you must not use the Platform, and your data will not be accepted or retained.<br>
9. Children’s Privacy\
   SlinkyLayer is intended for users aged 18 or older. We do not knowingly collect data from minors. If we learn that personal information has been submitted by a minor, we will delete it promptly.<br>
10. Changes to Privacy Policy\
    SlinkyLayer may update this Privacy Policy at any time to reflect changes to our practices or legal requirements. Continued use of the Platform after changes means you accept the updated Privacy Policy. Check back regularly for the latest version.<br>
11. Contact\
    For questions or requests regarding privacy, please contact SlinkyLayer at <gm@slinky.network>.


