Developers · Chain-verifiable attestations
Onchain protocol gate
Holder proves a narrow result privately. Abraxas issues a short-lived signed authorization. The partner’s own contract or program verifies it. The partner’s own code chooses what action to allow. Abraxas never submits transactions, custodies funds, routes orders, executes payments, or deploys a shared execution contract. A valid attestation is a short-lived eligibility authorization. It is not a payment, transfer, trade, token approval, gas authorization, or transaction.
How it works
holder -> private Partner Flow proof Abraxas -> current public receipt partner backend -> POST /api/v1/chain-attestations (API key) Abraxas -> EIP-712 or Solana eligibility attestation (hashes only) partner verifier contract/program -> trusted signer, domain, expiry, nonce, bindings partner code -> decides what action to allow Abraxas never deploys a shared execution contract and never submits a transaction
Allowed means the partner may perform its own named action. Abraxas never executes the trade, payment, membership grant, wallet connection, or protocol call. A valid attestation is a short-lived eligibility authorization. It is not a payment, transfer, trade, token approval, gas authorization, or transaction. Holder proves a narrow result privately. Abraxas issues a short-lived signed authorization. The partner’s own contract or program verifies it. The partner’s own code chooses what action to allow. Abraxas never submits transactions, custodies funds, routes orders, executes payments, or deploys a shared execution contract.
The partner deploys and owns its AbraxasEligibilityVerifier. Abraxas does not deploy a shared execution contract and does not claim any live Arc, Ethereum, Solana, or Mainnet contract.
EIP-712 domain
Name AbraxasEligibilityVerifier, version 2, plus chainId, verifyingContract, and partnerHash. Primary type ChainEligibilityAttestation.
domain: {
"name": "AbraxasEligibilityVerifier",
"version": "2",
"fields": [
"name",
"version",
"chainId",
"verifyingContract",
"partnerHash"
]
}
message: [
"schemaVersion",
"networkId",
"partnerHash",
"policyHash",
"actionHash",
"subjectHash",
"issuedAt",
"expiresAt",
"nonce",
"attestationId",
"environment",
"signerKeyId",
"organizationCommitment",
"actorCommitment",
"institutionalResultCategory"
]Solana message
Prefix ABRAXAS_CHAIN_ELIGIBILITY_V2 then the same canonical hashes and timestamps. Partners build an Ed25519 verify instruction; Abraxas does not submit SOL transfers or deploy a program.
Partner program interface (reference only; Abraxas does not deploy a program): 1. Receive the canonical message bytes from encodeSolanaEligibilityMessage. 2. Verify Ed25519 against the trusted Abraxas attestation pubkey via the Ed25519 native program. 3. Fail closed unless: - signer matches the trusted key; - network, partner, policy, version, action, and scope hashes match expected bindings; - now < expiresAt; - nonce has not been consumed in partner-owned replay state; - required subjectHash is present when the named network/action requires a wallet binding; - organizationCommitment, actorCommitment, and institutionalResultCategory are present when the reviewed policy requires institutional binding (legacy V1 372-byte messages are rejected). 4. On success, record only an eligibility authorization outcome. Do not transfer SOL or tokens, sign a later transaction, or treat the attestation as payment, trade, or gas authorization. Expected accounts: partner config (trusted signer + expected hashes), durable nonce PDA, clock.
Privacy
- Canonical fields are hashes and timestamps only.
- No PII, evidence, claims, receipt contents, source facts, callback URL, API key, wallet private key, transaction payload, recipient, amount, calldata, or provider data.
- Launchpad and browser views never receive signatures, verifying-contract addresses, or signer material.
Network posture
The EVM verifier is network-agnostic for later Arc/Circle EVM, Ethereum, and other approved EVM networks. Arc Circle Mainnet stays disabled until separately configured and reviewed. EVM Mainnet remains Production-review-required. Circle settlement is a separate explicit-confirmation path and is never imported here.
Partner backend example
import { AbraxasPartnerKit } from "@abraxas/partner-kit";
const kit = new AbraxasPartnerKit({
partnerId: process.env.ABRAXAS_PARTNER_ID!,
policyId: process.env.ABRAXAS_POLICY_ID!,
policyVersion: 1,
requirePolicyVersion: true,
environment: "sandbox",
});
export async function issueOnchainGate(receiptId: string) {
const res = await fetch(process.env.ABRAXAS_BASE_URL + "/api/v1/chain-attestations", {
method: "POST",
headers: {
authorization: "Bearer " + process.env.ABRAXAS_SANDBOX_API_KEY,
"content-type": "application/json",
},
body: JSON.stringify({
receipt_id: receiptId,
action_type: "enable_protocol_access",
action_scope: "sandbox:protocol_access",
network_id: "evm_sandbox",
deployment_ref: process.env.ABRAXAS_GATE_DEPLOYMENT_REF,
}),
});
const issued = await res.json();
if (!issued.allowed) return issued;
// Pass typed_data + signature to YOUR verifier contract.
// A valid attestation is not a payment, transfer, trade, token approval, or transaction.
return issued;
}
Integration Studio · Onchain protocol gate · EVM adapter · Solana adapter · Portable action contract