Ask Abraxas whether one venue action may proceed

Architecture

holder -> Abraxas hosted /partner/verify
Abraxas -> signed eligibility receipt
venue server -> GET /api/receipts/{id}/public
venue server -> AbraxasPartnerKit.evaluateFetchedReceipt
venue adapter -> issue action contract (type, scope, expiry, nonce)
venue adapter -> preflight enable_market_access
lifecycle / webhook -> re-fetch public receipt, never grant from the event body
browser <- { allowed, reason, action_binding, expires_at }

Policy pack → hosted Partner Flow → minimum approved receipt → venue preflight → lifecycle or webhook re-check. A webhook body is never a grant.

Receipt verification is AbraxasPartnerKit plus GET /api/receipts/{id}/public. This adapter does not implement a second verifier.

The Trading Venue Adapter never creates a trade, submits an order, opens a wallet, mints a token, or moves funds. It answers whether one named action may proceed.

Action contract

The venue server issues a contract with partner, policy and version, action type, a narrow scope, expiry, and a one-time nonce. The only sandbox action is Enable market access. Wallet binding stays not_attached so a later Wallet Standard attachment can sit on the binding without changing receipt semantics.

Privacy contract

• Google sign in creates an Abraxas account. It does not prove age, identity, residency, or eligibility.
• A webhook event is not authorization. Fetch GET /api/receipts/{id}/public and verify the signed receipt on your server before granting access.
• The Solana Partner Adapter never creates a transaction, mints a token, or moves funds. It binds an allow or deny result to a partner action only. It remains an eligibility gate and does not consume the portable action-contract nonce store.
• Partners receive only allow or deny, a safe reason code, action binding, and expiry.
• Browser responses must not include receipts, signatures, claims, PII, wallet addresses, trading history, or provider payloads.

Server side preflight

import { AbraxasTradingVenueAdapter } from "@/lib/partner/tradingVenue";

const adapter = new AbraxasTradingVenueAdapter({
  partnerId: process.env.ABRAXAS_PARTNER_ID!,
  policyId: process.env.ABRAXAS_POLICY_ID!,
  policyVersion: 1,
  requirePolicyVersion: true,
  environment: "sandbox",
  venueProfileId: "generic_trading_venue",
});

export function startVenueCheck(returnUrl: string) {
  return adapter.startPolicyVerification(returnUrl);
}

export async function enableMarketAccess(receiptId: string) {
  const contract = adapter.issueActionContract({
    action_type: "enable_market_access",
    action_scope: "sandbox:market_access",
  });
  if ("ok" in contract && contract.ok === false) {
    return { allowed: false, reason: contract.reason };
  }
  const verified = await adapter.verifySignedReceipt(receiptId);
  // Client JSON is allow/deny, reason, action binding, and expiry only.
  return await adapter.preflight({ result: verified, contract });
}

Studio: Integration Studio · Kit: Partner Integration Kit · Profiles: Venue integration profiles · Reference: Enable market access example

Hyperliquid-class profile

`hyperliquid_trading_venue` is a sandbox preflight profile for enable_market_access. Abraxas provides private eligibility preflight only. The venue retains account access, wallet handling, market data, risk, orders, and execution. A webhook is never a grant. Re-fetch a current receipt before each permitted action. Named venue labels describe integration posture only. They do not imply that any venue endorses, uses, or partners with Abraxas.

Abraxas does not call Hyperliquid APIs, read accounts or positions, fetch market data, submit orders, or imply that Hyperliquid endorses, uses, or partners with Abraxas. Keep `generic_trading_venue` for existing sandbox integrations.

Future live venue integration

1. The venue remains the execution system. Abraxas only answers a preflight for one named action.
2. Production access stays on the reviewed Launchpad upgrade path. No self-serve live keys from this adapter.
3. Pin partner_id, policy_id, and policy_version. Fail closed on draft, deprecated, missing, or mismatched versions.
4. Issue a server-authoritative action contract (type, narrow scope, expiry, one-time nonce) before each grant.
5. Verify the current public receipt on the server. Do not trust callbacks, webhooks, or client flags.
6. Consume the nonce on the first permitted preflight. Replay the same nonce as deny.
7. Return only allow or deny, a safe reason, action binding, and expiry. Never return receipt material.
8. Wallet binding stays optional unless the venue sets required. Do not collect private keys or expose wallet addresses.
9. Do not submit orders, route liquidity, custody assets, or connect to a live exchange from Abraxas.
10. Name no implied venue partnership in product copy. Integrate only after a written venue agreement and production review.