fix(soroban): harden registry/client attestation security

[alex-predicate]

Summary

Adversarial review of the Stellar (Soroban) PredicateRegistry, predicate-client, and the example-compliant-token reference integration surfaced several correctness/robustness issues in the attestation path. This PR fixes the actionable ones.

Findings fixed

HIGH — attestation did not bind the transfer recipient (example-compliant-token)

encoded_sig_and_args was set to sha256("transfer(address,address,i128)") — a constant that only covers the function selector. The recipient to was not covered by the attestation anywhere. Because from.require_auth() gates the call but not the destination, a user could obtain an attestation approved for one recipient and redirect it to any other address at submission time — bypassing the counterparty compliance the attester approved.

Fix: added encode_transfer_call(from, to, amount) which encodes the concrete call (selector + all args) into the signed digest, plus a regression test (test_transfer_redirected_recipient_rejected) proving a redirected recipient is rejected.

HIGH — replay-marker TTL decoupled from attestation lifetime (validation.rs)

Spent UUIDs were marked with a fixed ~30-day TTL. For any attestation whose lifetime exceeds that window, the replay-protection entry can be archived/evicted while the attestation is still valid, re-opening replay.

Fix: extend the UUID marker to the network max TTL (storage().max_ttl()), so the guard lives as long as the ledger allows. Added test_uuid_marker_ttl_extended_to_max.

MEDIUM — attester/policy registration could be silently archived (attesters.rs, policy.rs)

Registration/policy entries used a fixed ~30-day TTL that was never refreshed on reads. A long-lived attester could have its registration archived → validation starts failing (AttesterNotRegistered) — a registry liveness failure.

Fix: register attester/policy entries at max TTL, and refresh the attester's TTL on every successful validation so actively-used attesters are never archived.

LOW — defensive hardening

• token.transfer now checks the bool returned by authorize_transaction and returns NotAuthorized instead of proceeding.
• deregister guards against len() - 1 underflow if the registration flag and the attester list ever diverge.

Not changed (surfaced but out of scope — flagged for follow-up)

• Policy is not enforced on-chain. set_policy_id/get_policy_id are never read by validate; statement.policy is only bound via the attester signature. This may be intentional (off-chain enforcement) — worth confirming vs. the EVM ServiceManager model.
• ed25519_verify panics rather than returning the typed InvalidSignature error (SDK behavior); the error variant is effectively dead.
• Attester storage has two sources of truth (instance Vec + persistent flags). The TTL fixes make divergence far less likely; a full single-source refactor is deferred.

Testing

• cargo test — all 41 tests pass (2 new).
• cargo build --release --target wasm32-unknown-unknown — registry, client, and token build clean.

🤖 Generated with Claude Code

[patrickdappollonio]

I don't know if this is handled from a trait you have to implement in a specific fashion but this is anti-idiomatic Rust. The better option here is to have the enum receive a type and have the authorize_transaction() function return the actual error back (unless the error is sensitive and should not be displayed)

This eats the error otherwise and swaps it with a lesser detailed one.

[alex-predicate]

it looks like enums are not possible due to how Soroban contract errors are structured.
Soroban #[contracterror] enums are #[repr(u32)] and can’t carry a payload

[alex-predicate]

but that's a good call out

[patrickdappollonio]

Oh I don't mean in that line, I am talking about the authorize_transaction() function, you use the !authorized here but you could just be using the error instead