These standalone apps currently work with Leather only. Xverse can't be used yet — not a preference, a safety limit. Here is exactly why, and what would change it.
Two capabilities are non-negotiable for this tooling, because they are what keep your funds safe when you sign:
connect() so the wallet connects to the network you intend. Without it, a wallet can silently default to mainnet when its active account differs from the one you are connecting — a dangerous mismatch when real STX is involved.stake, unstake, stake-update, register-self, claim-rewards, fee/admin, and the contract deploy — is sent in deny mode with explicit post-conditions on stx_callContract / stx_deployContract. Post-conditions are declared by the app, shown by the wallet, and enforced by the protocol; they are the primary defense against a buggy or malicious contract moving more than intended.Per the official @stacks/connect compatibility table:
No post-conditions on contract calls or deploys. Xverse-like wallets are listed as supporting stx_callContract / stx_deployContract with "hex-encoded Clarity values & post-conditions only, no support for postConditions." That means the safety limits above cannot be enforced when signing through Xverse. We will not sign these calls without post-conditions, so we block Xverse rather than quietly drop your protection.
Connect itself is unreliable for us. Xverse does not implement stx_getAddresses natively (it relies on wallet_connect); the connect library maps around this, but in our testing Xverse failed to connect on both mainnet and the testnet, so it never even reaches the signing step.
SIP-030 defines stx_callContract and stx_deployContract with postConditions and postConditionMode parameters, and a standard address/connection path. To be fully usable by apps like these, Xverse would need to:
1. Honor postConditions and postConditionMode (including deny mode with explicit conditions) on stx_callContract and stx_deployContract, as the standard specifies.
2. Support the standard connect path — implement stx_getAddresses (or make the wallet_connect mapping reliable) and accept the network parameter on connect.
Once those land, enabling Xverse here is a small change on our side.
Leather and Xverse are the two most-used Stacks wallets. When one implements only part of SIP-030 — especially post-conditions, which are the main protection for user funds — every builder faces the same bad choice: drop safety to reach both wallets, or support only one and lose half the users. A single, fully-implemented standard is precisely what lets one app run safely in every wallet. That is the whole point of SIP-030, and it only works if wallets implement all of it.
For now, connect with Leather to use these apps. ← Back to the apps