Scoped authorization

Authorize Seer Tian (天) — Yin Yang

This grants a bounded, revocable Altana session key, not access to your wallet. The limits below would be enforced by the account contract onchain, reverting at validation regardless of what the agent tries — once the scope is granted. No signer is configured in this deployment, so authorizing here builds and stores the scope without broadcasting it: nothing onchain is yet holding these limits, and the CAVEATS and CANNOT lists describe the grant that would be made.

Scope-build modeNo onchain transaction will be sent.

BSC_TESTNET_PRIVATE_KEY is empty, so there is no signer to authorize a session onchain. Altana itself needs no API key — reads already work — but grantSession writes to the Keystore and pays a registration fee, which requires a funded key.

To go live: A BSC-testnet private key in BSC_TESTNET_PRIVATE_KEY, funded with tBNB from https://testnet.bnbchain.org/faucet-smart

What still happens for real when you authorize: the exact SessionPermissions object below is constructed and stored, and the live Altana Keystore is queried. What does not happen: no transaction is broadcast, so there is no transaction hash, no onchain session key and no explorer link — none would be real.

You will get a record id for the stored scope. It names a row in this application’s database — the thing you can revoke, re-read and cite here — and it is not an onchain session key.

Keystore contract 0x6572…7E0a ↗ confirmed live on BNB Smart Chain mainnet just now — 8,756 bytes of bytecode. Reads against it need no credentials at all.

AGENT AUTHORIZATION — SEER TIAN (天) — YIN YANG

CAN

✓
Read approved market data
Onchain reads are free and need no permission at all — the agent can quote prices and read balances without any grant from you.
✓
Interact with PancakeSwap V3 Position Manager
Adjust a concentrated-liquidity position’s range. Restricted to: decreaseLiquidity((uint256,uint128,uint256,uint256,uint256)), increaseLiquidity((uint256,uint256,uint256,uint256,uint256,uint256)), collect((uint256,address,uint128,uint128)). Contract 0x46A15B0b27311cedF172AB29E4f4766fbE7F4364.
✓
Interact with PancakeSwap V2 Router
Swap tokens along an approved path. Restricted to: swapExactTokensForTokens(uint256,uint256,address[],address,uint256), getAmountsOut(uint256,address[]). Contract 0x10ED43C718714eb63d5aA57B78B54704E256024E.
✓
Interact with USDT (BSC-USD)
Approve a spender to move the agent’s USDT — intended for the PancakeSwap router in this preset, but the spender is chosen by the agent at call time, not by this scope. Restricted to: approve(address,uint256). Contract 0x55d398326f99059fF775485246999027B3197955.
✓
Interact with WBNB
Approve a spender to move the agent’s WBNB for a swap. Wrapping BNB is not in scope — only approve() is allowed — and the spender is chosen by the agent, not by this scope. Restricted to: approve(address,uint256). Contract 0xbb4CdB9CBd36B01bD1cBaEBF2De08d9173bc095c.

LIMITS

·
Maximum spend: 50 USDT per day
Encoded as exactly 50000000000000000000 raw units (18 decimals) — that conversion is done here and is what would be committed. Once the scope is granted, the account contract holds the cap and a transaction that would exceed it reverts at validation. Before then the number below is a request, not a bound.
·
Chain: BNB Smart Chain mainnet (chain 56)
Every contract above is a BNB Smart Chain mainnet deployment, so the session is bound to chain 56. A grant on any other chain would allowlist addresses that hold no code there.
·
Session duration: 30 minutes
Would expire 2026-09-02T06:42:59.248Z. Expiry needs no transaction — a granted key simply stops validating once it passes.
·
Revocable at any time
A granted session is revoked by a single transaction on BNB Smart Chain mainnet, effective immediately and monotonic — a revoked key can never be reactivated. A scope that was built but never broadcast has no onchain authority to withdraw, so revoking it clears the stored record and sends nothing.

CAVEATS

✕
USDT (BSC-USD): the approved spender is not pinned
This grant allows approve() on USDT. The preset intends that approval for the PancakeSwap router, but the spender is an argument, and Altana's call permissions match a contract and a selector — never an argument. So the agent chooses who it approves, and an approved address can then move USDT out of the wallet up to the allowance it was given. Your spend cap still applies; the allowlist alone does not stop this.
✕
WBNB: the approved spender is not pinned
This grant allows approve() on WBNB. The preset intends that approval for the PancakeSwap router, but the spender is an argument, and Altana's call permissions match a contract and a selector — never an argument. So the agent chooses who it approves, and an approved address can then move WBNB out of the wallet up to the allowance it was given. Your spend cap still applies; the allowlist alone does not stop this.

CANNOT

✕
Access any other contract
Only the 4 contract(s) listed above are permitted. Once granted, a call to anything else reverts at validation in the account contract, not by our convention.
✕
Exceed 50 USDT per day
A granted session’s cap is a rolling window enforced by the account contract.
✕
Continue after expiry
After 2026-09-02T06:42:59.248Z a granted session key stops validating and cannot be renewed without a fresh grant from you.
✕
Grant itself more authority
Only the wallet admin key can grant sessions. A session key cannot sub-delegate or escalate its own permissions.

Why this scope

A rebalancer needs the position manager to move a range and the router plus token approvals to rebalance inventory. It does not need lending markets.

The exact permissions object that would be committed onchain

{
  "calls": [
    {
      "to": "0x46A15B0b27311cedF172AB29E4f4766fbE7F4364",
      "signature": "decreaseLiquidity((uint256,uint128,uint256,uint256,uint256))"
    },
    {
      "to": "0x46A15B0b27311cedF172AB29E4f4766fbE7F4364",
      "signature": "increaseLiquidity((uint256,uint256,uint256,uint256,uint256,uint256))"
    },
    {
      "to": "0x46A15B0b27311cedF172AB29E4f4766fbE7F4364",
      "signature": "collect((uint256,address,uint128,uint128))"
    },
    {
      "to": "0x10ED43C718714eb63d5aA57B78B54704E256024E",
      "signature": "swapExactTokensForTokens(uint256,uint256,address[],address,uint256)"
    },
    {
      "to": "0x10ED43C718714eb63d5aA57B78B54704E256024E",
      "signature": "getAmountsOut(uint256,address[])"
    },
    {
      "to": "0x55d398326f99059fF775485246999027B3197955",
      "signature": "approve(address,uint256)"
    },
    {
      "to": "0xbb4CdB9CBd36B01bD1cBaEBF2De08d9173bc095c",
      "signature": "approve(address,uint256)"
    }
  ],
  "spend": [
    {
      "limit": "50000000000000000000  // 50 USDT at 18 decimals",
      "period": "day",
      "token": "0x55d398326f99059fF775485246999027B3197955"
    }
  ],
  "expiry": 1788331379
}

Spend limits are raw token units. USDT and USDC use 18 decimals on BNB Chain, not 6 as on Ethereum — writing a 6-decimal figure here would set a cap a trillion times smaller than intended, so the conversion is done once, exactly, and shown above.

Set your limits

Maximum spend (USDT per day)Capped at 1000 USDT per day. The cap is enforced by the API, not just by this field.Session duration (minutes)Capped at 24 hours. A long-lived key is the thing scoped authorization exists to avoid.

Allowed contracts: 4
Network: BNB Smart Chain mainnet · 56

The button says “build scope” because that is all it can honestly do without a funded signer. It will not claim to have authorized anything.

Revocation is first-class

Every session created here appears on the agent’s Permissions tab, with a revoke action in this browser. Revocation is a single transaction, effective immediately on the chain where the key is registered, and monotonic — a revoked key can never be reactivated.

The session id is a secret, not an identifier: it is what authorises revocation. Public pages show only its first 12 characters, so the revoke control appears for whoever created the session — not for every visitor to the agent’s page.

Anyone can verify this session

Session authority lives in a public onchain registry. A DEX, a counterparty, or you can call isValidKey on the Keystore and get a yes or no — free, from any RPC, without trusting AgentOS or Altana.