What becomes possible
Social recovery, where a set of guardians can rotate the signing key if you lose it. Spending limits and allow-lists enforced by the account itself. Batched operations, so an approval and a swap are one atomic transaction. Sponsored gas, where a paymaster pays and bills you another way.
Session keys are another: a temporary key with narrow permissions that expires, which is a genuinely better model than an unlimited standing allowance.
What it costs
Deployment is a transaction. Every operation is more gas than an ordinary account, because contract logic runs on each one. And the account is code, which means its security is the security of that code plus whoever can upgrade it.
A bug in a smart account is a different and more serious failure than a bug in a wallet interface, because the funds are held by the contract.
The trust questions to ask
Who can upgrade the contract, and is that controlled by a key, a multisig or a timelock? What happens to your funds if the provider disappears — can you still move them with only your own signer? Has the code been audited, and is the deployed bytecode the audited version?
A smart account whose provider can unilaterally upgrade it is closer to custody than its marketing suggests.
Where this stands today
Account abstraction is real and usable on most EVM networks, with wallets offering recovery and batching as standard features. It is not universal, and some protocols still assume a plain key account.
FBT Swap connects to whatever the wallet exposes. If your wallet is a smart account, the transaction it signs is routed the same way; the difference is in how your wallet constructs and authorises it.