Skip to content

Add recipient substitution with co-signer approval #226

Description

@Kingsman-99

Label: complexity: high
Points: 200

Description

There's no way to swap out a recipient after invoice creation (e.g. a recipient's address was compromised) without co-signer oversight for invoices that have one configured. This issue adds a guarded recipient substitution path.

Technical Context

Involves lib.rssubstitute_recipient(env, invoice_id, old_recipient: Address, new_recipient: Address). If co_signers is non-empty, require the same required_signatures threshold of fresh approvals specifically for this substitution (separate signature set from release approvals); if no co-signers configured, allow the creator alone.

Acceptance Criteria

  • With co-signers configured, requires a fresh round of required_signatures approvals distinct from release-approval signatures
  • Without co-signers, creator auth alone suffices
  • Recipient's corresponding amounts/claimed/tokens entries carry over unchanged to the new address
  • Panics with "recipient not found" if old_recipient isn't currently a recipient
  • Test: co-signed invoice requires approvals before substitution applies; non-co-signed invoice substitutes immediately on creator call
  • All existing cargo tests pass
  • cargo clippy passes with zero warnings

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

Stellar WaveIssues in the Stellar wave programcomplexity: highComplex feature requiring deep knowledge - 200 pts

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions