xChain Accounts are now live, letting EVM wallet users transact on Algorand without setting up a new wallet. This post is for developers who want to understand the Algorand primitive behind it and the authorization model that makes it work.
The primitive: Smart Signature Accounts
On most chains, an account is a keypair. A private key signs, the public key verifies, and the address is derived from the public key. Algorand has that. Standard accounts work exactly this way.
But Algorand also supports another account type, Smart Signature Accounts, often called a Logic Signature (LogicSig).
A Smart Signature Account isn’t a keypair. It’s a small program, written in Algorand TypeScript or Algorand Python, that authorizes transactions for that account.
The address is derived from the compiled program bytes. Each unique compiled program maps to a unique account address. If you change anything in the program, even a single value baked in at compile time, then the address changes too.
When a transaction needs to be authorized by that account, the program runs. It receives the transaction data, applies whatever logic you wrote, and either approves or rejects. There's no separate private Algorand key to manage. The programmatic logic from the EVM Wallet is the authorization.
That's the primitive. The signer isn't separate from the account; the signer controls the account. Anything you can express as "if these conditions hold, approve" is an account on Algorand.
Inside xChain Accounts
When a user connects their EVM wallet to an xChain Accounts-compatible app, the SDK takes their EVM address (say 0x1234…) and bakes it into the LogicSig program as the owner-address template variable. The compiled program produces a unique Algorand address. That's now the user's xChain Account, derived deterministically from their EVM address.
The user signs an EIP-712 typed data message in their EVM wallet, committing to the specific Algorand transaction ID (or group ID, for atomic groups). EIP-712 means the wallet labels what's being signed (primary type "Algorand Transaction," the transaction ID, the requesting domain) instead of presenting a bare hex string with no context.
The signature gets submitted to Algorand alongside the transaction. The LogicSig program runs and verifies four things:
-
The signed digest is the EIP-712 digest of this specific Algorand transaction ID or group ID.
-
ecdsa_pk_recover recovers the secp256k1 public key that produced the signature over that digest.
-
The signer's EVM address is derived from that public key, the last 20 bytes of keccak256(public_key).
-
The derived EVM address matches the owner-address template variable baked into this LogicSig at compile time.
If all four hold, the program approves. The transaction executes.
If any of the checks fail, like a wrong signer, a tampered transaction, or a replayed signature, it rejects the transaction.
Replay protection comes from two places. The signature is bound to a specific transaction ID or group ID, which itself commits to the genesis hash and the first/last valid round, so the same signature can't be replayed on a different network or outside its validity window. And the EIP-712 domain is scoped to xChain Accounts, so a signature you give to some other EVM dApp can't be repurposed as an Algorand authorization.
What else can I do?
xChain Accounts is one example of what you can build using LogicSigs. The same LogicSig primitive can support other useful patterns:
-
Delegated authority: A standard account can sign a LogicSig program and delegate authority. Whoever holds it can submit transactions from the owner's account, but only ones the program approves, useful for things like recurring payments, where a utility company can collect a fixed amount on a schedule without ever holding the key.
-
Fee transactions: A LogicSig can let specific transactions go through without the user paying fees. This is a clean way to sponsor a user's first interaction with an app or even hide that you’re using blockchain.
-
Other signature schemes: The AVM also has native opcodes for secp256r1 and Ed25519. Developers can use these to build accounts authorized by passkeys, WebAuthn credentials, or hardware security module keys, the same xChain pattern, different source.
Build with it
xChain Accounts is a reference implementation1 developers can use to understand the model and build their own account experiences on top of it.
- The code: algorandfoundation/xchain-accounts LogicSig contract, the signing SDK, and use-wallet integration.
- The docs: the Smart Signature documentation on the Algorand developer portal
- Product context: the xChain Accounts announcement explains the product side. What's live, which wallets are supported, and how to try it.
xChain Accounts currently supports a limited set of compatible wallets and integrations, which may expand or change over time. Features, APIs, implementation details, and compatibility are subject to change as the technology evolves. Developers are responsible for independently evaluating, testing, and auditing their integrations before deploying to production environments.
1 THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Disclaimer: The content provided in this blog is for informational purposes only. The information is provided by the Algorand Foundation and while we strive to keep the information up-to-date and correct, we make no representations or warranties of any kind, express or implied, about the completeness, accuracy, reliability, suitability, or availability with respect to the blog or the information, products, services, or related graphics contained in the blog for any purpose. The content of this blog is not intended to be legal, financial, or investment advice nor is it an endorsement, guarantee, or investment recommendation. You should not take any action before conducting your own research or consulting with a qualified professional. Any reliance you place on such information is therefore strictly at your own risk. All companies are independent entities solely responsible for their operations, marketing, and compliance with applicable laws and regulations. In no event will Algorand Foundation nor any affiliates be liable for any loss or damage including without limitation, indirect, or consequential loss or damage, or any loss or damage whatsoever arising from loss of data or profits arising out of, or in connection with, the use of this blog. Through this blog, you may be able to link to other websites which are not under the control of the Algorand Foundation. We have no control over the nature, content, and availability of those sites. The inclusion of any links does not imply a recommendation nor endorse the views expressed therein.