# Partner security

## Principles

1. **Non-custodial** — Sika never holds end-user private keys; partners must not either.  
2. **Server-side secrets** — mint secrets and org API keys never ship in apps or frontends.  
3. **User signs** — every value transfer requires an in-wallet confirmation.  
4. **Apply for access** — no anonymous self-serve production mint keys.  
5. **Least publish** — integrate with the public pay-intent + deep-link contract; do not depend on undocumented internal BFF routes.

## Credential handling

- Store mint secrets in your secrets manager / server env only  
- Prefer the merchant portal (`/partners/login`) to rotate/revoke after approval — plaintext is shown **once** on create/rotate  
- Rotate on staff offboarding or suspected leak  
- Prefer separate sandbox vs production secrets  
- HTTPS everywhere (passkeys and secure cookies require it)
- Portal magic links go only to the approved contact email; do not forward login links to shared inboxes

## What partners must not do

- Ask users for seed phrases or private keys  
- Proxy signing through your servers  
- Lower or omit the platform fee client-side  
- Call BoundIdentity / settlement / Twilio with Sika’s org credentials  
- Scrape or automate the wallet UI instead of the documented API  

## Abuse controls

- Mint and verify endpoints are rate-limited  
- Intent TTL is capped (30–3600 seconds)  
- Access-request form is rate-limited and does not return API keys  
- Rate-limit counters are **in-process** (per server instance, reset on deploy). Multi-instance deploys need a shared store for strict global caps.

## Reporting

Report security issues privately to the maintainers. Do not include production secrets or user private keys in tickets.