This repository contains a signature verifier and a set-once registry that, together, let a Cardano Ed25519 key act as an owner of an EVM smart-contract account (a Safe) via ERC-1271. The contracts guard funds. This document states what they defend against and how that defense is tested.

The contract answers one question — did the key bound to this account sign this exact message? — and everything downstream trusts a true. The adversary's goal is therefore to obtain a true for a message the real key never signed, or to bind an account to a key its owner does not control. The full attacker model and the numbered invariants every review measures against live in docs/THREAT_MODEL.md; the exact accepted byte formats in docs/CRYPTO_SPEC.md.

The test suite attacks the contract on purpose: expectations are pinned to libsodium's actual verdicts, the committed corpus includes libsodium-rejected signatures the contract must refuse (acceptance is a build-failing event), and forgery, mutation and differential fuzzing are the normal mode of development here. The complete testing and review discipline is docs/REVIEW.md.

All adversarial testing in this repository targets this repository's own contracts and our own test deployments. Nothing here is built to attack third parties' deployed contracts or systems, and it should not be used that way.

The cryptographic core is vendored, audited third-party code (see THIRD_PARTY_LICENSES.md and the README PINS table), pinned at a commit and never silently edited. Any finding against that core is an upstream issue and should be reported to its maintainers under their disclosure policy, not exploited against live deployments.

If you find a vulnerability in this repository's own code, please report it privately to security@exura.org rather than opening a public issue. We aim to acknowledge reports promptly and to credit reporters who follow responsible disclosure.

Deployed contracts are non-upgradeable by design: there is no proxy, admin, or owner key that can alter verification behavior after deployment. Remediation of a confirmed flaw is a new deployment plus a user-authorized owner rotation, never an in-place patch.