Location: contracts/account_factory/src/lib.rs:66-72 vs contracts/shared/src/types.rs:37-41 (AccountInitRequest)
Root cause / scenario:
client.try_initialize(&creator, &request.expiry_ledger, &request.recovery_address, &creator, &creator) passes creator for both the authorized_controller and admin parameters of EphemeralAccountContract::initialize. AccountInitRequest only carries expiry_ledger and recovery_address — there is no field anywhere in the batch-initialize path to specify a different controller (such as the deployed SweepController contract's address) or admin.
Impact:
docs/security.md's Best Practices section explicitly instructs integrators to 'Always use SweepController::execute_sweep to perform sweeps' and EphemeralAccountContract::sweep_claim's own doc comment describes it as being 'used by SweepController.claim()... requiring the sweep controller as the invoker.' But sweep_claim's controller.require_auth() check reads authorized_controller from storage — which, for every factory-created account, is the plain creator address, not the SweepController contract. This means SweepController.claim() can never successfully authorize a sweep_claim call against a factory-created account, since controller.require_auth() would require the creator's signature, not the SweepController contract's own authorization context.
Suggested fix:
Add authorized_controller (and admin, if it should vary per-account) fields to AccountInitRequest, and thread them through batch_initialize's call to try_initialize instead of hardcoding creator for both.
Found by reading the contract source directly and cross-checking docs/security.md and docs/reentrancy-analysis.md (item 24/32).
Location:
contracts/account_factory/src/lib.rs:66-72 vs contracts/shared/src/types.rs:37-41 (AccountInitRequest)Root cause / scenario:
client.try_initialize(&creator, &request.expiry_ledger, &request.recovery_address, &creator, &creator) passes creator for both the authorized_controller and admin parameters of EphemeralAccountContract::initialize. AccountInitRequest only carries expiry_ledger and recovery_address — there is no field anywhere in the batch-initialize path to specify a different controller (such as the deployed SweepController contract's address) or admin.
Impact:
docs/security.md's Best Practices section explicitly instructs integrators to 'Always use SweepController::execute_sweep to perform sweeps' and EphemeralAccountContract::sweep_claim's own doc comment describes it as being 'used by SweepController.claim()... requiring the sweep controller as the invoker.' But sweep_claim's controller.require_auth() check reads authorized_controller from storage — which, for every factory-created account, is the plain creator address, not the SweepController contract. This means SweepController.claim() can never successfully authorize a sweep_claim call against a factory-created account, since controller.require_auth() would require the creator's signature, not the SweepController contract's own authorization context.
Suggested fix:
Add authorized_controller (and admin, if it should vary per-account) fields to AccountInitRequest, and thread them through batch_initialize's call to try_initialize instead of hardcoding creator for both.
Found by reading the contract source directly and cross-checking docs/security.md and docs/reentrancy-analysis.md (item 24/32).