Under the hood of xChain Accounts: meet Smart Signature Accounts

May 25, 2026

Written by: Joseph Cecala & Camilo Molano

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:

1. The signed digest is the EIP-712 digest of this specific Algorand transaction ID or group ID.

2. ecdsa_pk_recover recovers the secp256k1 public key that produced the signature over that digest.

3. The signer's EVM address is derived from that public key, the last 20 bytes of keccak256(public_key).

4. 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.