Ask Abraxas whether one named protocol action may proceed

Architecture

holder -> Abraxas hosted /partner/verify
Abraxas -> signed eligibility receipt
partner server -> GET /api/receipts/{id}/public
partner server -> AbraxasPartnerKit.evaluateFetchedReceipt
EVM adapter -> issue action contract (type, narrow scope, expiry, nonce)
EVM adapter -> preflight enable_protocol_access | enable_member_access | enable_redemption_access
partner backend -> its own RPC, signer, contract, gas, and execution
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 → EVM preflight for one named action → partner-owned execution. 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.

Optional EVM wallet-control proves message-signed control for one named action. It is not Solana Wallet Standard, login, KYC, custody, a balance read, or transaction signing. Client wallet fields remain rejected.

Supported actions

• enable_protocol_access in sandbox:protocol_access
• enable_member_access in sandbox:member_access
• enable_redemption_access in sandbox:redemption_access

Arbitrary contract methods, calldata, chain IDs, recipient addresses, token amounts, transaction payloads, and wallet fields are rejected.

What allowed means

The client result is only allowed, reason, action_binding, and expires_at. Allowed means the partner backend may perform its own named action. It is never a transaction approval, signature, gas authorization, transfer, or execution. No specific EVM chain, RPC, wallet, protocol, or Mainnet deployment is live from this adapter.

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.
• Allowed is never a transaction approval, signature, gas authorization, transfer, or execution. The partner backend retains its own RPC, signer, contract, gas, transaction construction, and execution.
• Partners receive only allow or deny, a safe reason code, action binding, and expiry.
• Browser responses must not include receipts, signatures, claims, PII, wallets, RPC URLs, calldata, or transaction payloads.

Canonical disclosure: Selective disclosure

Server side preflight

import { AbraxasEvmPartnerAdapter } from "@/lib/partner/evm";

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

export async function enableProtocolAccess(receiptId: string) {
  const contract = adapter.issueActionContract({
    action_type: "enable_protocol_access",
    action_scope: "sandbox:protocol_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.
  // Allowed is never a transaction, signature, gas grant, or execution.
  const preflight = await adapter.preflight({ result: verified, contract });
  if (!preflight.allowed) return preflight;

  // PARTNER EXECUTION BELONGS HERE, IN YOUR BACKEND.
  // Use your own RPC, signer, contract, gas, and transaction construction.
  // Do not send chain IDs, calldata, wallets, or transaction payloads to Abraxas.
  return preflight;
}

Studio: Integration Studio · Kit: Partner Integration Kit · Portable contract: Portable action contract · Wallet control: EVM wallet-control binding

Remaining Mainnet requirements

1. The partner remains the execution system. Abraxas only answers a preflight for one named protocol action.
2. An allowed result is not a transaction approval, signature, gas authorization, transfer, or on-chain execution.
3. Production access stays on the reviewed Launchpad upgrade path. No self-serve live keys from this adapter.
4. Pin partner_id, policy_id, and policy_version. Fail closed on draft, deprecated, missing, or mismatched versions.
5. Issue a server-authoritative action contract (type, narrow scope, expiry, one-time nonce) before each grant.
6. Verify the current public receipt on the server. Do not trust callbacks, webhooks, or client flags.
7. Consume the durable nonce on the first permitted preflight. Replay the same nonce as deny.
8. Return only allow or deny, a safe reason, action binding, and expiry. Never return receipt, RPC, wallet, or transaction material.
9. Reject arbitrary contract methods, calldata, chain IDs, recipient addresses, token amounts, transaction payloads, and wallet fields.
10. EVM Mainnet stays unavailable until reviewed Production access, a supported action, a current receipt, durable replay, and a partner-owned EVM execution integration exist.
11. Do not claim any specific EVM chain, RPC, wallet, protocol, or Mainnet deployment is live.
12. Optional EVM wallet-control is an EIP-191 personal_sign proof for one action. It is not login, KYC, custody, a balance read, or transaction approval.