Skip to content

Security

Your wallet
remains in control

ZeFi never requests or stores seed phrases or private keys. Connected wallets retain custody and sign transactions directly.

Disclosure

Report a vulnerability to security@zefi.ae. Please include reproduction steps and give a reasonable window before public disclosure.

  • ZeFi never holds keys

    There is no wallet client with a private key anywhere in the codebase and no path that transmits key material to a server. Your wallet signs; ZeFi supplies what is to be signed and the reasoning behind it.

    ZeFi never requests or stores seed phrases or private keys.

  • The model writes prose, not values

    Addresses, amounts, decimals, chain ids and contract references come from a curated registry and from validated user input. A language model cannot introduce any of them into a transaction.

    Model output and executable transaction data are structurally separate.

  • A check that did not run is not a check that passed

    Local validation covers chain, asset, decimals, recipient, balance and approval scope. Where a reading is unavailable the check reports “skipped”, and where deep simulation is unconfigured ZeFi says so rather than implying coverage.

    ZeFi never claims a transaction has been fully simulated.

  • Approval is explicit, and specific

    Every transaction requires a separate review screen and a confirm control naming the actual action. Approvals are planned exact-amount; ZeFi will not present an unlimited allowance for signature.

    No plan reaches a wallet without a human reading it first.

Controls

What is actually implemented

Custody

  • No private key or seed phrase is ever requested, transmitted, or stored
  • No server-side wallet client exists in the codebase — signing has no server path
  • ZeFi is not a custodian and holds no user funds at any point
  • Every transaction is signed in the user’s own wallet, in their own browser

Transaction integrity

  • Contract addresses, decimals and chain ids come from a curated registry, never from a model
  • Recipient addresses are EIP-55 checksummed and screened for burn addresses and self-transfers
  • Amounts are validated as decimal strings and converted with BigInt — never through a float
  • Approvals are planned exact-amount; an unlimited allowance is never presented for signature
  • Duplicate submission is prevented by two independent uniqueness constraints plus an idempotency key

Authorisation

  • All /app routes and mutating API routes are protected by middleware
  • Every user-owned query is scoped by the authenticated user’s id — no lookup by primary key alone
  • “Not found” and “belongs to someone else” return the same response, because the difference is information
  • Clerk secret keys are server-only and never reach a browser bundle

AI boundaries

  • Model output is structurally incapable of becoming transaction data
  • User text is sanitised of control characters and bidi overrides, then framed as untrusted data
  • Structured output is obtained through a forced tool call and Zod-validated, with one repair attempt
  • Requests carry explicit timeouts; a failed provider produces an error, never a fixture
  • System prompts live in server-only files and are never shipped to a client

Transport and platform

  • Content-Security-Policy with object-src none, base-uri self and frame-ancestors none
  • HSTS with preload, nosniff, strict-origin-when-cross-origin, and a restrictive Permissions-Policy
  • Rate limiting on the assistant surface, per minute and per day
  • Server-side action logs for every mutation, scoped to the acting user

Known limits

What ZeFi does not claim

A security page that lists only strengths is a marketing page. These are the trade-offs a reviewer would find anyway.

  • The default rate limiter is per-instance

    An in-memory limiter means the effective ceiling on a serverless platform is the configured limit multiplied by the number of live instances. Set UPSTASH_REDIS_REST_URL for a shared limiter when you need a hard guarantee.

  • The CSP permits inline scripts

    Next.js emits an inline bootstrap script for every statically rendered route. A nonce-based policy would force dynamic rendering across the marketing site. The high-value directives are enforced strictly; script-src is the documented compromise.

  • Deep simulation is not configured by default

    Local deterministic validation always runs. Without a simulation provider, ZeFi has not executed the transaction against chain state — and says so on every plan rather than implying coverage it does not have.

  • ZeFi has not been independently audited

    No third-party security audit has been performed on this codebase. Anyone evaluating ZeFi for material value should treat that as a live consideration rather than a formality.

Disclaimer

ZeFi provides informational, technical, and transaction-planning tools. Outputs may contain incomplete assumptions and do not constitute financial, investment, legal, tax, compliance, or security-audit advice.