For the complete documentation index, see llms.txt. This page is also available as Markdown.

Security and Integration Notes

MOSS is designed around a hosted iframe model, which gives partner apps a clear separation between application UI and wallet UI.

Security Model

  • The wallet host runs in an iframe appended to the parent document.

  • Penpal is configured with an explicit allowed origin based on the selected wallet host.

  • The wallet iframe receives feature permissions for clipboard write and public key credential APIs.

  • The parent app does not directly handle key material — it requests actions from the hosted wallet surface.

MOSS UI and Silent Execution

MOSS UI is the approval and security boundary for first-time connect, signing, permission grants, and transactions. Apps shouldn't assume those approval surfaces can be bypassed for first-time actions. Lower-prompt UX comes from Smart Approvals session grants and scoped delegated execution — this is the intended path to reduce friction while preserving explicit user trust boundaries.

Use silent: true only after valid permissions exist for the exact { to, signature } scope.

Partner Best Practices

  • Initialise once and keep wallet access behind clear user intent.

  • Request only the permissions required for the current feature.

  • Explain high-trust actions before opening the wallet.

  • Log operational failures, but do not store raw signed payloads unless your backend actually needs them.

  • If your app supports multiple networks, make the selected network visible before the wallet flow begins.

  • Do not store long-lived session keys or delegated signing credentials in persistent frontend storage.

  • Keep permission escalation and sponsorship approval logic on the backend.

For session keys, restrictive permission defaults, and shipping checklists, see Best Practices. For independent audits of the on-chain account contract, see Security Audits.

Last updated