# Architecture

SlinkyLayer takes a standard API endpoint and turns it into a pay-per-call, on-chain resource. Instead of forcing providers to build billing systems, account logic, payout pipelines, and trust layers around their API, SlinkyLayer wraps the endpoint in a machine-native payment and reputation flow.

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

At a high level, the system does three things.

First, it lets providers publish an API and define a price per call.

Second, it lets apps and agents discover that API, call it, and pay for each request through x402.

Third, it records post-call reputation in a portable on-chain registry, so trust is not trapped inside a single platform.

The result is that an API stops looking like a closed SaaS product and starts behaving more like open infrastructure: discoverable, payable, and reputation-aware by default.

### The basic flow

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

#### 1. A provider connects an API

The provider starts with an existing endpoint. They publish that endpoint through SlinkyLayer and define the price for each call.

SlinkyLayer then wraps the endpoint in a pay-per-use x402 interface. That means the provider does not need to bolt a payment system onto the API manually. The API remains the provider’s service, but the access layer becomes machine-readable and payable per request.

#### 2. An app or agent discovers the API

Once listed, the API becomes available to consumers such as apps, bots, or autonomous agents.

A consumer can discover the endpoint, understand that it is paid, and initiate a call through SlinkyLayer. This is important because discovery and payment are part of the same system. The consumer is not being redirected into a separate commercial workflow just to use the API.

#### 3. The request is executed and paid for

When the consumer calls the endpoint, the request triggers a pay-per-call transaction using x402.

This is the core shift in the product. Payment is not handled through a monthly invoice, prepaid credits, or a platform balance. It happens at the moment the call is made.

That makes the system much better suited to on-demand usage, low-friction integrations, and agent-driven behavior. A user or agent pays exactly for the request being executed, no more and no less.

#### 4. The response is returned

Once payment is satisfied, the request is routed to the provider’s endpoint and the response is returned to the consumer.

This means SlinkyLayer sits in the middle as an access, payment, and trust layer, while the provider still owns the underlying service itself.

#### 5. Reputation grows after the call

After the response is delivered, the consumer can rate the API response.

Those ratings feed into an ERC-8004 reputation system, creating portable and verifiable reputation over time. Instead of trust being trapped inside a single API marketplace, reputation becomes part of the resource itself.

***

In the old world, an API is usually locked behind accounts, subscriptions, balances, and platform-specific ratings.

In SlinkyLayer, the API becomes:

* callable on demand
* payable per request
* trustable through portable reputation
* usable by both humans and autonomous software

That makes it better infrastructure for the next generation of software, especially agents that need to discover and use external services in real time.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.slinky.network/functional-details/architecture.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
