> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tulipai.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Security

> Security model, trust assumptions, and operational guidance for Tulip.

<Warning>
  Tulip v1 is an early production implementation, and its contracts have not been independently audited. Transactions are irreversible, model-credit markets can be volatile, and inference relies on off-chain providers. Verify the network, contract target, approvals, and amounts before signing.
</Warning>

## Contract protections

* Fixed credit supply with no mint authority after construction.
* Deterministic ModelID and one canonical market binding.
* Launch LP NFT minted directly to an immutable locker.
* Locker fee collection checks that position liquidity principal is unchanged.
* Canonical launches use creator-bound commit/reveal protection and require a prior-block commitment.
* Creator LP-fee changes have a one-hour on-chain safety delay and a hard 10% ceiling.
* Only activated tariff versions can settle; replacing a pending tariff permanently leaves the replaced version inactive.
* Closing permits reject usage that starts at or after the close request, and paused models or non-active offers cannot settle.
* Protocol fee checkpoints make inference splits use the fee that applied when the request started.
* Provider tariffs are versioned and delayed.
* Permits are bound to one model and may optionally bind one offer.
* EIP-712 receipts bind the exact request, quote, permit, model, offer, tariff version, usage, wake state, and timestamps.
* Request IDs can settle only once.
* Settlement recomputes the charge from the on-chain tariff.
* Permit closure has a 30-minute delay.
* State-changing custody and settlement paths use reentrancy guards.

## Gateway protections

* All `/v1/*` routes require a Tulip API key.
* Provider onboarding requires an expiring operator signature and a single-use nonce.
* Endpoint origins must be HTTPS subdomains of `endpoints.huggingface.cloud`.
* Public responses omit endpoint URLs and credentials.
* PostgreSQL credentials are encrypted with AES-256-GCM.
* Reservations are atomic when durable PostgreSQL storage is used.
* Streaming requests require terminal usage instead of estimated billing.
* Automatic failover is limited to the period before output is delivered.

## Known trust assumptions

Tulip does not currently provide cryptographic proof that an endpoint executed a model correctly. Users trust:

* The provider to deploy and run the committed model revision.
* Hugging Face, as the v1 endpoint vendor, to host the endpoint and expose truthful operational metadata.
* The Gateway to route correctly, meter usage, and protect its signing key.
* Protocol governance to use pause, fee, quarantine, signer, and treasury controls responsibly.

## Operational requirements

Production operators should use:

* Multisig or governed protocol ownership.
* A managed signer or HSM for usage receipts.
* Private secret storage and rotation.
* PostgreSQL backups and connection encryption.
* Multiple Robinhood RPC providers.
* Gateway, settlement, indexer-lag, and balance monitoring.
* Rate limits, request logging with secret redaction, and abuse controls.
* A public incident response and pause policy.

## Safe production use

* Confirm your wallet is connected to Robinhood Chain, chain ID `4663`.
* Inspect transaction targets and receipts in [Blockscout](https://robinhoodchain.blockscout.com/).
* Use bounded token approvals and inference permits.
* Protect wallet keys, Tulip API keys, and provider credentials.
* Start with small trades and permit balances when using a market for the first time.