Ekubo Adds Shadow Accounts for Liquidity Providers

Ekubo’s Starknet mainnet create-position page now displays a Public/Private selector alongside its token-pair, fee and price-range controls. The default page displays ETH and USDC. Using Shadow Accounts requires a wallet that supports the shadow-specific STRK20 methods, according to the developer guide.

The integration follows StarkWare’s Oct. 13 launch of Shadow Accounts. The technical change is a lasting owner for a DeFi position: the existing helper-contract approach completes an operation and returns its proceeds within one transaction, while a shadow account can retain balances and positions across transactions, according to the starknet.js guide.

Under the documented design, funds move from a shielded balance to the shadow address, which makes ordinary calls to the application’s contracts. Proceeds can return to the privacy pool. The shadow account has no signing keys; only the ShadowAccountAnonymizer contract can execute calls through it.

Privacy Has Limits

Amounts and timing remain observable. The developer example linked from STRK20’s launch guide warns that those observations, along with infrastructure-level information, can create correlations. A separate address is not a guarantee of anonymity.

Audit coverage for the end-to-end Ekubo integration remains unconfirmed. The published OpenZeppelin report dated May 29 covers privacy-pool code at a specified commit; its listed scope does not include the ShadowAccountAnonymizer or Ekubo’s interface.

STRK20 also retains a disclosure mechanism. Its viewing-key documentation says a user’s private viewing key is encrypted to an auditor’s public key and stored onchain at registration. An auditor acting under lawful process can recover that key and decrypt the user’s history. The viewing key provides read access, not authority to move funds.