generated: '2026-08-09' method: derived source: openapi/connext-everclear-openapi.yml, https://docs.everclear.org/developers/api.md summary: >- The Everclear ("Chimera") API declares no authentication at all. The merged OpenAPI carries no components.securitySchemes block and no security requirement on any of its 17 operations, and the docs never mention an API key, token, or account. Authorization in Everclear is on-chain: the REST API only reads indexed protocol state and builds unsigned EVM/Solana/Tron TransactionRequest objects, which the caller then signs with their own wallet key and submits to the chain themselves. The signing key never touches Everclear. model: none schemes: [] security_requirements: [] findings: - id: no-security-schemes detail: components.securitySchemes is absent from every one of the 17 published OpenAPI documents. - id: no-operation-security detail: No operation declares a security[] requirement; all 17 are anonymous. - id: authorization-is-on-chain detail: >- POST /intents, POST /solana/intents and POST /tron/intents return a TransactionRequest (to/data/value/chainId or the chain equivalent) for the caller to sign locally. The caller's private key is the only credential in the flow and it is never sent to the API. - id: permit2-signature-in-body detail: >- IntentRequest accepts an optional permit2Params object (nonce, deadline, signature) — an EIP-2612/Permit2 signature produced client-side. This is a token-approval signature carried in the request body, not an API credential. - id: no-oauth-no-oidc detail: >- No /.well-known/openid-configuration or /.well-known/oauth-authorization-server on any host; scopes/ is therefore not applicable and is not emitted. docs: https://docs.everclear.org/developers/api caveat: >- Unverifiable against a live host: https://api.everclear.org returned HTTP 530 on 2026-08-09, so this profile is derived from the published contract only. See lifecycle/connext-lifecycle.yml.