Why this matters now:
transfer_from explicitly panics with "token: cannot transfer to self" (added in #67). transfer has no such guard. A self-transfer with transfer is a no-op (balance is correctly maintained due to the two-write pattern reading the already-updated value), but the inconsistency is a security model defect: the justification for rejecting self-transfer in transfer_from (allowance drain without token movement) applies equally to transfer (auth signature without value movement). An auditor reviewing the SEP-0041 implementation will flag this inconsistency. It should be fixed before the formal audit.
Problem / What:
In token.rs, transfer does not check if from == to { panic!(...) }. The function correctly handles the double-write (the test test_transfer_to_self passes and the balance is preserved), but a self-transfer burns the caller's require_auth() credential with no economic effect. The fix is a one-line guard matching transfer_from.
Key Challenges:
- The existing test
test_transfer_to_self asserts that self-transfer succeeds and leaves the balance unchanged — this test must be updated to assert that it panics after the fix.
- Ensure the error message matches the
transfer_from message for consistency: "token: cannot transfer to self".
Acceptance Criteria:
transfer(from, to, amount) panics with "token: cannot transfer to self" when from == to.test_transfer_to_self is rewritten as #[should_panic(expected = "token: cannot transfer to self")].- A new positive test confirms valid transfers (from != to) still work.
cargo test -p eco-token passes.
Relevant files/functions:
contracts/eco-token/src/token.rs — TokenContract::transfercontracts/eco-token/src/token.rs — test_transfer_to_self (test update)
Out of scope: TTL, allowance logic, transfer_from (already fixed).
Why this matters now:
transfer_fromexplicitly panics with"token: cannot transfer to self"(added in #67).transferhas no such guard. A self-transfer withtransferis a no-op (balance is correctly maintained due to the two-write pattern reading the already-updated value), but the inconsistency is a security model defect: the justification for rejecting self-transfer intransfer_from(allowance drain without token movement) applies equally totransfer(auth signature without value movement). An auditor reviewing the SEP-0041 implementation will flag this inconsistency. It should be fixed before the formal audit.Problem / What:
In
token.rs,transferdoes not checkif from == to { panic!(...) }. The function correctly handles the double-write (the testtest_transfer_to_selfpasses and the balance is preserved), but a self-transfer burns the caller'srequire_auth()credential with no economic effect. The fix is a one-line guard matchingtransfer_from.Key Challenges:
test_transfer_to_selfasserts that self-transfer succeeds and leaves the balance unchanged — this test must be updated to assert that it panics after the fix.transfer_frommessage for consistency:"token: cannot transfer to self".Acceptance Criteria:
transfer(from, to, amount)panics with"token: cannot transfer to self"whenfrom == to.test_transfer_to_selfis rewritten as#[should_panic(expected = "token: cannot transfer to self")].cargo test -p eco-tokenpasses.Relevant files/functions:
contracts/eco-token/src/token.rs—TokenContract::transfercontracts/eco-token/src/token.rs—test_transfer_to_self(test update)Out of scope: TTL, allowance logic,
transfer_from(already fixed).