Skip to main content
KuruTradingWallet is EIP-7702 logic used by a secondary EOA. The EOA signs actions; a relayer submits them; AccountCore checks the EOA’s live root-wide permission over the target account.

​
Domains and identity

Use SDK typed-data builders rather than hand-maintaining type hashes. Wallet v2 uses fresh storage and chain-local state. Old wallet signatures and storage are not migrated into this model.

​
Immediate actions

The header binds the actual target account ID, market, root authorization epoch, millisecond nonce, deadline, and correlation ID. Read getAccountAuthorizationEpoch({ accountId }) before signing. Allocate nonces durably per delegated EOA and chain; see Signer Lifecycle. SDK intent helpers include signBatchIntent and signReplaceBySlotIntent. For additional actions, use prepareCancelOrdersByIdIntent, prepareCancelAllIntent, or prepareFokSwapIntent, then signPreparedWalletIntent and buildWalletActionRequest. Verify market precision, notional constraints, permissions, and live order bindings before signing. Cancel-by-ID accepts 1–62 unique live order IDs and reverts the complete action on a stale or invalid target. Cancel-all operates on the target account’s live orders in that market at execution time, including orders placed after signing. It does not cancel triggers, TWAP schedules, or passive positions. Despite its name, the wallet FOK swap is a base-quantity marketable limit order, not the OrderBook exact-input swap. Dust rules still apply. Reconcile actual packed fills.

​
Triggers

Automated triggers, including TP/SL, are not implemented as a live feature and remain work in progress. Contract-level storage and execution rules below do not imply that a condition-monitoring keeper is deployed.
Trigger creation authenticates the signature once. Firing checks keeper authority, live trading permission, unchanged root epoch, expiry, verified market, and applicable order bindings. The creation signature is not recovered again at firing. The opt-in Relay FOK trigger creation route only stores the signed instruction and condition hash. It does not monitor the condition or register a keeper; retain the condition bytes for your own integration. getTrigger contains execution state. The creation nonce, deadline, and condition commitment are available from calldata/events rather than retained as getter fields. Any future automated execution would require an offchain keeper to evaluate the condition; the Relay storage route does not supply one.

​
TWAP

Automated TWAP slice execution is not implemented and remains work in progress. A stored schedule does not execute trades on its own.
A signed schedule binds total quantity, limit price, future start, interval, and slice count. Quantity must divide into equal slices. Each interval permits its corresponding FOK slice. No catch-up or rollover occurs; a reverted attempt may be retried in the same interval. Creating a schedule reserves no funds. The opt-in Relay TWAP creation route only stores the schedule; it does not run slices. Its finalization route records expired/skipped/finished state without executing trades or transferring funds. Contract capabilities and a stored schedule do not imply a deployed scheduler.

​
Signed data

emitSignedData publishes opaque, public bytes authenticated by the delegated wallet, such as a display label. Its sequential signedDataNonce is separate from trading, trigger, and TWAP nonces. This event neither grants permissions nor proves current account access. The contract reference contains the precise execution rules. The Relay guide identifies the available transport methods; contract support alone does not imply a hosted endpoint.