The address is the owner EOA
Resolve an owner address and you get that same address back. Nothing is derived, nothing is counterfactual, and an account holds its balances at the address the user already knows.
An account is the owner EOA itself, activated per network by an EIP-7702 authorization.
An account is the owner EOA itself, made programmable by an EIP-7702 delegation — a smart account, or account abstraction, in the industry's terms. There is no separate contract address to create, fund, or deploy, and the arrangement stays non-custodial, or self-custodial: the private key never leaves its owner.
Resolve an owner address and you get that same address back. Nothing is derived, nothing is counterfactual, and an account holds its balances at the address the user already knows.
An account without the required delegation needs an authorization tuple that points its EOA at the account delegate. Read authorizationRequired and authorizationNonce from each prepare response. Attach the authorization when requested; a previously activated account can need it again if its delegation changes.
An authorization is signed for one chain, so activating on one network says nothing about another. GET /account/delegation-status reports every network separately as activated, not_activated, or unsupported.
Avalanche has no chain-level EIP-7702, so accounts there are never activated and delegation-status reports unsupported. ERC-20 operations use the executor rail; native AVAX transfers use the self-funded rail. Both use the same submit and status endpoints, with different signing payloads.