> For the complete documentation index, see [llms.txt](https://docs.syndromics.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.syndromics.xyz/architecture/platform.md).

# Platform

The platform is the reference front-end and relayer for Syndromics. It runs at `/platform` on the main site and is built with Next.js, Privy for authentication and Supabase for the shared order book. Nothing displayed by the platform is hardcoded; markets, prices, parameters, requests, offers, loans and events are all read from Supabase.

## Pages

| Route                 | Audience             | What it shows                                                                                                                                                         |
| --------------------- | -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `/platform`           | Everyone             | Protocol statistics, market table with tier limits and live indicative rates, open requests                                                                           |
| `/platform/borrow`    | Signed in            | Create a borrow request (collateral, principal, max APR, term, deadline) with live LTV, health factor and fee; your requests with fill coverage from the book; settle |
| `/platform/lend`      | Everyone / signed in | Public order book of open requests; post standing or targeted offers with flags; your offers with capacity and cancel                                                 |
| `/platform/positions` | Signed in            | Loans you took (debt, accrued interest, health, repay, top up) and slices you hold                                                                                    |
| `/platform/explorer`  | Everyone             | Loan registry with syndicate and events, concentration by token against caps, parameters in force                                                                     |
| `/platform/settings`  | Signed in            | Profile and the eligibility attestations issued to your wallet                                                                                                        |

## Authentication

Sign-in is handled by Privy (email, Google or any EVM wallet). Users without a wallet get an embedded wallet on Robinhood Chain, and that address is the one requests and offers are signed with.

Supabase does not know Privy natively, so the platform bridges the two:

1. The browser sends the Privy access token to `POST /api/platform/session`.
2. The route verifies it with `@privy-io/server-auth` and mints a short-lived Supabase JWT (`sub` = Privy user id, `role` = `authenticated`) signed with the project's JWT secret.
3. The browser passes that JWT to `@supabase/supabase-js` through the client's `accessToken` option and talks to Supabase directly.

Every row-level policy in the schema compares the JWT subject with the owner column of the row, so a user can only insert their own requests and offers and only read their own profile and attestations. Public data (markets, prices, parameters, the order book, loans, slices, events) is readable without signing in.

## Data model

The schema is in `supabase/schema.sql` and mirrors the on-chain design:

| Table                            | Mirrors on-chain                                          | Written by                    |
| -------------------------------- | --------------------------------------------------------- | ----------------------------- |
| `markets`                        | `ParamController` token and tier config                   | Service role                  |
| `oracle_prices`                  | `OracleRouter.quote()`                                    | Service role (keeper or cron) |
| `protocol_params`                | `ParamController` parameters and the deployment addresses | Service role                  |
| `attestations`                   | `NativeAttestationAdapter`                                | Service role (KYC issuer)     |
| `borrow_requests`                | The relayer's request book                                | Borrowers                     |
| `offers`                         | The relayer's offer book (signed EIP-712 messages)        | Lenders                       |
| `loans`, `slices`, `loan_events` | `LoanSettlement` state                                    | Database functions only       |

State transitions run in `security definer` functions (`settle_request`, `cancel_request`, `cancel_offer`, `record_repayment`, `record_collateral_added`) so the matching rules (term, APR ceiling, tier scope, capacity, minimum fill, expiry, full coverage) are enforced in the database exactly as `LoanSettlement` enforces them on-chain.

## Signing

Offers and requests are signed as EIP-712 typed data with the same struct layout and domain (`Syndromics` / `1` / chain id / `LoanSettlement`) as `contracts/src/libraries/OfferHash.sol`. The typed-data hash is stored alongside the signature so a relayer or the contract can verify it later. Signing is gasless through Privy's `signTypedData`.

## Settlement modes

The `deployment` row in `protocol_params` holds the contract addresses. When `LoanSettlement` is set, settling a request submits a real `settle` transaction through the user's Privy wallet (viem `writeContract`) and records the transaction hash on the loan. When it is not set, settlement is recorded in the book only and the loan is labelled accordingly. Matching is greedy by APR, the same order the documentation describes for the relayer.

## Design

The platform uses the same tokens as the marketing site (`syn-*` colours, Space Grotesk, Inter, JetBrains Mono, the `.panel` and `.btn` primitives) so it reads as one product. A sidebar shell on desktop collapses to a drawer on phones.

## Setup

See `supabase/README.md` and `.env.example` at the repository root. The platform renders a setup notice listing any missing environment variables rather than failing silently.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## 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, and the optional `goal` query parameter:

```
GET https://docs.syndromics.xyz/architecture/platform.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.