You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Summary\n\nValidate onboarding transactions structurally and semantically before asking a wallet to sign them. Do not trust a transaction merely because it was produced by the SignBox UI or an onboarding API.\n\n## Security impact\n\nAn altered onboarding payload can request unrelated actions, target another contract or chain, grant an excessive permission, install the wrong key, or include hidden authorization changes. Wallet confirmation alone is not a sufficient application-level validation boundary.\n\n## Required checks\n\n- Verify the expected chain ID, contract, action name, actor, permission, and daemon public key.\n- Allow only the documented onboarding action sequence and reject extra actions.\n- Decode action data with the expected ABI and validate every security-relevant field.\n- Reject expired or replayable onboarding intents.\n- Bind the payload to the current user, selected agent, requested permission, and displayed configuration.\n- Display a human-readable summary derived from the final bytes that will be signed.\n- Revalidate after any wallet or RPC transformation and immediately before signing.\n- Never rely on hidden UI fields or unsigned API responses as the source of truth.\n\n## Acceptance criteria\n\n- Payloads with an extra action, changed contract, changed permission, changed key, wrong chain, or stale intent are rejected.\n- The reviewed summary and signed transaction are cryptographically bound to the same serialized payload.\n- ABI decode failures fail closed.\n- Tests cover tampering, replay, wallet mutation, multi-action payloads, and malicious onboarding responses.\n- The UI provides a clear recovery path without encouraging users to bypass validation.
Summary\n\nValidate onboarding transactions structurally and semantically before asking a wallet to sign them. Do not trust a transaction merely because it was produced by the SignBox UI or an onboarding API.\n\n## Security impact\n\nAn altered onboarding payload can request unrelated actions, target another contract or chain, grant an excessive permission, install the wrong key, or include hidden authorization changes. Wallet confirmation alone is not a sufficient application-level validation boundary.\n\n## Required checks\n\n- Verify the expected chain ID, contract, action name, actor, permission, and daemon public key.\n- Allow only the documented onboarding action sequence and reject extra actions.\n- Decode action data with the expected ABI and validate every security-relevant field.\n- Reject expired or replayable onboarding intents.\n- Bind the payload to the current user, selected agent, requested permission, and displayed configuration.\n- Display a human-readable summary derived from the final bytes that will be signed.\n- Revalidate after any wallet or RPC transformation and immediately before signing.\n- Never rely on hidden UI fields or unsigned API responses as the source of truth.\n\n## Acceptance criteria\n\n- Payloads with an extra action, changed contract, changed permission, changed key, wrong chain, or stale intent are rejected.\n- The reviewed summary and signed transaction are cryptographically bound to the same serialized payload.\n- ABI decode failures fail closed.\n- Tests cover tampering, replay, wallet mutation, multi-action payloads, and malicious onboarding responses.\n- The UI provides a clear recovery path without encouraging users to bypass validation.