Core Concepts
Security Model
Goals
- Avoid mixing sponsor key usage with general app logic.
- Minimize exposure of user signing material.
- Keep sponsorship rules explicit and auditable.
- Make failure states observable.
- Keep v1 realistic and shippable.
v1 baseline
- Sponsor keys are only used through the Signer Boundary (isolated service).
- Sponsorship policy is checked before preparing transactions.
- Tenant config defines allowed assets and fee rules.
- All sponsor actions are logged.
- Passkey-backed signing can be enabled where supported.
- Contract-ready flows do not require the platform to hold raw user keys in the normal path.
Key separation
App Frontend → Pollar API → Relay / Sponsor Service → Signer Boundary → Sponsor key use
User signer / passkey → App (separate from Signer Boundary)The user signs with their own signer or passkey; the sponsor key is used only in the Signer Boundary for sponsorship operations.
Threats and mitigations
| Threat | Mitigation |
|---|---|
| Sponsor key leakage | Isolated Signer Boundary, limited access, rotation plan |
| Over-sponsorship | Per-app controls, asset allowlist, analytics and alerts |
| Invalid contract calls | SDK validation, simulation, typed helpers |
| Deferred activation abuse | Idempotent endpoints, wallet status checks, audit logs |