Katana | Integrate Enso DeFi Shortcuts
Use Enso-style DeFi shortcuts to compose multi-step Katana actions while validating routes, approvals, slippage and transaction outputs.
Goal
Compose complex DeFi workflows into a smaller number of user actions without hiding route details or safety checks.
Before you begin
Confirm that your wallet is connected to Katana, that you have enough ETH for gas, and that token addresses or positions match the intended network. Review approvals before signing and avoid copying addresses from unverified sources.
Step-by-step workflow
Define the intended start and end assets.
Quote the route before building a transaction.
Inspect approvals and intermediate protocols.
Set slippage and minimum-output constraints.
Simulate or preview the route where possible.
Verify final balances after execution.
What changes onchain
The transaction updates a Katana smart-contract position rather than only changing the interface. Wallet prompts should therefore be checked for contract address, token amount, approvals and network before signing.
Risk and troubleshooting
Cross-chain, liquidity, smart-contract and configuration risks depend on the specific workflow. Always validate network, contract, token and expected output before signing.
- Wrong network or token address.
- Insufficient gas or token balance.
- Stale interface state after a transaction.
- Unexpected approval scope.
- Market, liquidity or exit conditions changing after entry.
Verification after completion
Check the transaction on Katana’s explorer, refresh balances from the chain and confirm that the expected position or token amount changed. For multi-step workflows, verify each transaction before continuing.
Frequently Asked Questions
What is the first safety check?
Verify the active Katana network and the exact contract or token address involved.
Should approvals be unlimited?
Use the smallest practical approval scope unless the application clearly requires a different pattern.
How do I verify completion?
Check the confirmed transaction and resulting onchain state, not only the interface message.
What if the UI disagrees with the explorer?
Treat onchain explorer/RPC state as authoritative and investigate caching or indexing lag in the interface.