Wallet authentication required
Only currently active owners of the AVKAT Safe may use this interface. Sign a short-lived login challenge; every protected action rechecks ownership on Katana.
Safe assets and ranges
Live loop and lending metrics (KAT units)
Refresh overview to load.
Configured Charm / ERC-4626 reserves
No vault readings yet.
Token balances are directly read from the Safe; range metadata is read from RangeManager. Guardian book already includes its configured vault and position equity in net TVL; displayed free token balances are not an additional total.
Indicative portfolio valuation breakdown
Refresh to calculate a USD estimate for discovered, spot-priced holdings, including staked Sushi V3 NFTs, configured vaults and loop debt. Not certified total Safe TVL; any undiscovered asset or inaccessible price leaves the total incomplete.
No USD valuation run.
Guardian observations
Select an observation.
Wind-up allocation bands
Thresholds are offsetBps above the on-chain start premium, NOT absolute KAT/avKAT discount percentages. The active effective values are read from Guardian first.
Guardian wind-down bands
The deployed Guardian defines exactly three configurable dewindBands: maximum loss threshold in basis points and percent of eligible budget to unwind. This is distinct from the LoopLPManager on-chain getTiers schedule, whose Safe-only on-chain setter cannot be called by the existing executor.
On-chain LP tiers appear in Overview metrics.
On-chain LoopLPManager tiers — Safe owner action
Edit the deployed on-chain allocation ladder. Discount thresholds must decrease while cumulative allocations increase. Percentages use up to two decimal places. The actual setter validates its parameter limits before preview. Saving prepares a normal Safe transaction using the live owner signature threshold. Guardian wind-up and wind-down settings above remain unchanged.
No on-chain tier reading loaded.
Position dashboard
Registered positions and current NFT custody, staking and liquidity are displayed in Overview. RangeManager changes and Guardian rebalance eligibility belong to Bot actions in your requested interface. On-chain configuration setters are available under Safe owner and use the live Safe signature threshold.
Guardian operations
Bot control requests require your single Safe-owner wallet login signature, even when the Safe requires multiple confirmations for owner transactions. The Guardian retains its preapproved, restricted executor permissions.
No operation submitted.
Compound supported staked registered range
Guardian v2 can compound other registered staked Sushi V3 ranges using eligible Safe-held token0 and token1 above the configured idle reserves; unsupported ranges are rejected by on-chain simulation. Existing stable range remains supported. Save the request ID for reconciliation.
Bot KAT → USDC swap (existing authorized route)
UNSAFE LEGACY ENDPOINT DISABLED. Guardian supports this route with minOut=0, which is inadequate for controlled financial execution. Use the protected general approved-route bot swap below instead.
No swap requested.
General approved-route bot swap
Available after deploying Guardian Worker v2. Requires an installed, enabled SafeSwapModule and an owner-approved directed route. A positive minimum output is mandatory. This is an executor action authenticated by ONE current Safe owner, independent of Safe threshold.
No request yet.
Other executor actions
With Guardian v2, the existing compound queue supports eligible Safe-held pool tokens for other registered staked NFTs, subject to simulation and custody checks. Charm/ERC-4626 compounding of Safe-held assets is a Safe-owner transaction available under Safe Owner Actions. The registered NFT compounding queue remains a bot action.
Vault holdings — read only
View configured vault balances and integration capability status. For Charm ERC-4626 deposits/compounding, use the Safe Owner Actions tab; signing follows the live Safe threshold.
No vault data loaded.
Bot Worker rebalance eligibility (one-owner session)
Guardian runtime policy can be edited with ONE active-owner session. This is distinct from the on-chain RangeManager active and trigger setters.
Independent range waiting periods
Set a range ID and optional waiting seconds. 0 means immediate when the RangeManager condition is true; blank removes the override and restores legacy immediate/global dwell. Timer resets if conditions stop qualifying or observations lose continuity. Requires supplied Guardian Worker v2 to be deployed first.
No custom waiting configuration loaded.
RangeManager configuration — Safe owner action
Configure existing registered positions through normal Safe transactions using the current owner signature threshold. Guardian waiting and condition-recheck settings are preserved. Enter a RangeManager range ID, not an NFT ID. Read back the exact executed configuration after signing.
Range shape
Center/one-sided specs may be zero; their sum must span at least one tick spacing. Fixed specs are absolute, ordered tick bounds aligned to the pool spacing.
Idle absorption
No configuration request.
Verify completed position or allocation configuration
The preview saves the exact requested configuration. After the Safe transaction executes, verify its exact SafeTx hash and receipt-block on-chain values. Current state is shown separately. Any mismatch remains unverified.
No configuration verification yet.
Move liquidity between existing NFT positions — Safe owner action
Move a chosen percentage of liquidity from one currently registered, staked Sushi V3 NFT to another existing registered, staked NFT using RangeManager.move(). One ordinary Safe MultiSend transaction; the live Safe owner signature threshold applies. Existing activation flags are restored.
No migration inspected.
Safe balance transfers
Approved swap paths
This updates RangeManager's on-chain token address path, not the Guardian's runtime config. Use verified route/pool configuration for actual bot swaps.
Approved router pool (single hop)
Approve or revoke executor swap route
After creating a route above, approve its CURRENT hash separately through a normal multisig Safe transaction. The SafeSwapModule rejects changed or unapproved routes. This does not change the bot executor.
Create and fund SushiSwap V3 position
Available proven path: register an EMPTY range against a real pool, configure it, then move existing range liquidity into it. Arbitrary loose-balance mint is not established by supplied evidence.
This owner action registers an empty range; the separate guided creation workflow below atomically configures and funds a NEW NFT. Moving between two ALREADY-EXISTING NFT positions belongs in Bot Actions.
Guided position exit → swap → transfer
Step 1 executes a Safe-approved position withdrawal to the Safe. Wait for confirmation and refresh Safe balances before Step 2; a newly withdrawn amount cannot safely be assumed before execution. Step 2 atomically swaps the exact entered token amount and transfers the guaranteed minimum output to your recipient. Any additional swap output remains in the Safe. All actions use ordinary Safe owner signatures and respect its current threshold.
After the withdrawal is confirmed and the Safe balance is refreshed, choose an approved swap route and exact input. Source tokens must already be in the Safe.
No quote yet.
For tokens without an approved route, use the send-only action; the Safe must already hold the tokens. Safe Transaction Builder preview and multisig confirmation remain mandatory.
Additional Safe-only controls
Owner actions use ordinary Safe calls. Charm/ERC-4626 withdrawals, redemptions and transfers are owner actions. Deposits/compounding are BOT actions and remain blocked without an authorized module. Automatic registration of a directly minted NFT from idle Safe tokens remains unsupported by the verified RangeManager interface: the proven automatic registered creation path is the existing registered-range migration. The separate on-chain LoopLPManager tier setter is available as an explicit Safe owner action; the Guardian wind-up and wind-down bot policy setters are supported.
Create a new auto-balancing NFT from an existing position
Atomic Safe owner NEW-POSITION workflow: register new range → configure → move an exact percentage of an existing staked NFT → mint/stake/register automatically through RangeManager. Partial moves retain the remaining source position. No idle-token NFT mint and no new module.
Select an existing source range.
No destination verification yet.
Current free Safe balances in the destination token pair are captured as reserve floors. An inactive source is only activated temporarily and returned to its prior state. The new destination ends active, subject to Guardian monitoring, configured waiting and route eligibility.
Withdraw staked or directly held Sushi V3 NFT
Uses regular Safe calls. For Safe-beneficial staked NFTs, it unstakes, decreases and collects liquidity, and attempts restaking on partial withdrawals; full withdrawal leaves the range inactive. Only live simulation-approved sequences can be sent. Minimums are human token units; zero has no slippage protection.
Specifying a recipient sends the entire collected token0/token1 balance, including accrued fees, to that wallet. Slippage minimums are enforced by decreaseLiquidity.
Transfer Safe-owned NFT
Transfers NFT custody, not liquidity. If NFT is staked for the Safe, the Safe atomically unstakes and transfers it, deactivating any registered range. Existing range registration is not deleted; registered positions are atomically deactivated before transfer.
Finalize NFT withdrawal or transfer — verify live state
After the owner Safe transaction is mined, check actual on-chain NFT custody, remaining liquidity/owed fees and RangeManager active status. RangeManager has NO verified unregister function; linked historical registrations are retained INACTIVE. Full withdrawals leave the empty NFT in the Safe; NFT transfers leave it in the recipient wallet. A successful transaction receipt alone does not establish these postconditions.
No final-state verification yet.
Stake a directly Safe-held NFT
For a new NFT after mint confirmation, enter its actual ID from the transaction receipt. The Safe approves and stakes it through the existing Sushi staker. This does not automatically register it with RangeManager.
Charm / ERC-4626 vault management
Configured Charm vaults expose ERC-4626. Deposits (compounding Safe-held vault underlying), withdrawals, redemptions and transfers are ordinary Safe-owner transactions, requiring the current Safe threshold. Standard deposit() has no enforced minimum-share field; any minShares below is a preview-only check.
Choose a vault to see available shares and assets.
Redeem Charm / ERC-4626 shares
Standard redeem(shares,recipient,Safe) for the selected vault; collect the underlying into Safe or send directly to an external wallet.
Swap Safe-held tokens via an existing approved route
Atomic Safe owner approve → swapExactInput → reset approval. Uses only the router's live approved route, and sends output back to Safe. This does not create a new bot permission.
Advanced Safe owner transaction
For operations whose interface is not in the package. This authorizes a normal Safe CALL to a target you specify and does not involve a bot/module executor. Calldata is required for contract methods; a Safe address alone does not define arbitrary destination contract methods.
Paste Safe transaction JSON
Paste a single {to, value, data}, an array of CALLs, or a Safe Transaction Builder export (encoded data or supported simple contractMethod inputs). Value is in WEI. Batches are atomic. Imported operation=1 delegatecalls are rejected; the dApp generates its own vetted MultiSend. No private keys or imported signatures accepted.
Atomic custom Safe batch
Add up to eight CALL steps. Each is executed in order inside a single Safe MultiSend transaction. No delegatecall or module invocation is permitted in the batch steps.
Safe multisig approvals
If Safe threshold exceeds 1, a proposing owner signs the exact EIP-712 SafeTx; other active Safe owners sign the same hash. Once the live threshold is reached, any connected owner can execute. A changed Safe nonce invalidates pending proposals. Bot controls remain gated by one owner login signature and the existing Guardian permissions.
No proposal selected.
Owner operations history
No events loaded.