Pair Requests

The catalog lists 44 Pair Instruments across bonds, housing, real estate, credit, equities, sectors, commodities, rates and funds. The world has thousands more. When a creator or holder searches for one that is not listed, PairStreet records the search as a Pair RequestPair RequestA user's request for a Pair Instrument the catalog does not list yet. Requests aggregate into measurable demand that drives provider integration. instead of a dead end.

That turns unsupported markets into measurable demand. Each request is a named instrument, optionally a country and a category, a count of distinct people asking for it, and a count of how many of them would launch a coin paired with it. Ranked, those counts tell PairStreet and its providers where integration work pays off.

Three surfaces in the application open the same request form.

• ·The instrument picker in the create flow. A search with no match shows “No Pair currently available for” the search term, with a “Request” button prefilled with it.
• ·Most Requested Pairs on the Pairs page (/pairs#requests). Each row has its own request button, so adding a voice to an existing request is one click.
• ·Market explorer empty states, and the “Request a Pair” link in the site navigation.

The form asks for the market or instrument (3 to 80 characters), an optional country and category, an optional reason (“What exposure should this Pair give holders?”), and a checkbox: “I’d launch a coin with this Pair”.

A request count is only useful if it cannot be inflated by one person pressing a button. The counting rules are strict and tested.

1. Step 01normalized_key
   Normalize the title

   The title is lowercased, every run of non-alphanumeric characters becomes a single hyphen, and leading or trailing separators are dropped. “Manhattan Residential”, “manhattan residential” and “MANHATTAN-RESIDENTIAL!” all resolve to manhattan-residential, so they count toward one request.

2. Step 02voter_key
   Identify the voter

   A connected wallet votes as wallet:<address>. Without a wallet, the voter is an anonymous visitor id stored in an HTTP-only cookie for one year.

3. Step 03UNIQUE (request_id, voter_key)
   Count once

   The vote insert is guarded by a unique index. A repeat submission from the same voter adds nothing and returns the current counts with counted: false. Only a new vote increments request_count, and, when the box is ticked, creator_interest_count.

4. Step 04PAIR_REQUESTED
   Record the event

   Every counted vote writes a PAIR_REQUESTED activity event with the request title and its new count. It is one of the events emitted on mainnet today; see Events.

Insert, vote and increment run in one database transaction. Writes are rate-limited to 10 requests per minute per IP address; past that the API answers 429 with the standard error envelope.

The output of the demand layer is a ranking. The chart below shows its shape. Production request data is still accumulating, so the numbers are an example; the live ranking is on the Pairs page and at GET /api/pair-requests.

The example also shows how listings follow demand. Three of its four markets are in the catalog today: German Bunds, Toronto Housing and Korea Treasury Bonds are Pair Instruments a creator can pair with now. Manhattan Residential remains a request. That is the loop the demand layer exists to run: a request names a market, the count proves interest, and the listing makes it pairable.

Each request carries a status that follows it through review.

A listing is a Pair Instrument record: a provider behind the provider interface, eligibility rules, a status and a settlement asset. Creators can pair with it as soon as it is active. Settlement into its Pair Asset activates when its provider route and Pair Vault custody activate; the event model defines PAIR_INSTRUMENT_ADDED for the moment a new instrument enters the catalog.

For an issuer or a tokenized-asset provider, the demand layer answers the question that usually comes last: is anyone asking for this on Solana? Ranked requests, with country, category and creator intent, show demand before an integration is built. The Providers chapter covers what an integration involves.

Both endpoints are application endpoints used by pairstreet.xyz. They return JSON and use the standard error envelope.

GET /api/pair-requests

Returns the top 20 requests, ordered by request count.

GET /api/pair-requests

200 OK
[
  {
    "id": "<request-uuid>",
    "title": "Manhattan Residential",
    "country": "US",
    "category": "real_estate",
    "description": "Condos and co-ops below 96th Street.",
    "requestCount": 4281,
    "creatorInterestCount": 0,
    "status": "open",
    "createdAt": "<iso-timestamp>"
  }
]

POST /api/pair-requests

Creates a request, or adds a vote to an existing one with the same normalized title.

title

string, 3 to 80 characters. Required.

country

ISO 3166 alpha-2 code, uppercased. Optional.

category

One of the instrument categories (bonds, housing, real_estate, credit, equities, sectors, commodities, rates, funds, crypto, countries, other). Optional.

description

string, up to 500 characters. Optional.

creatorIntent

boolean, default false. True when the requester would launch a coin with this Pair.

wallet

Solana address. Optional; when present, the vote is keyed to the wallet.

POST /api/pair-requests
Content-Type: application/json

{
  "title": "Manhattan Residential",
  "country": "US",
  "category": "real_estate",
  "description": "Condos and co-ops below 96th Street.",
  "creatorIntent": true,
  "wallet": "<solana-address>"
}

201 Created            (first request from this voter)
200 OK                 (repeat: counts returned, nothing added)
{
  "request": { "id": "<request-uuid>", "title": "Manhattan Residential", "requestCount": 4282, "creatorInterestCount": 1, "status": "open", ... },
  "counted": true
}

Invalid input returns 400 with code INVALID_INPUT. The full endpoint list is in API, and the stored fields in Schemas.