Activity

1. carlotestor

   added

   bug

   on Oct 16, 2026
2. carlotestor commented on Oct 16, 2026

   

   carlotestor

   on Oct 16, 2026

   Collaborator

   More actions

   Thanks for the detailed report and the verbose log. It points at the cause. Your verbose output shows the wallet login succeeded: 200, {"funding_account_address": …}. The error comes from the client side, and it is specific to the Rust port (the code you posted is Rust, even though the issue form says JavaScript).

   GRVT returns the session in the response headers (Set-Cookie and X-Grvt-Account-Id), and grvt.handleErrors reads them from there. On current master, the Rust build loses them in two places:

   1. Response headers are never passed in. In rust/ccxt-common/src/exchange.rs fetch_typed, DerivedExchange::handle_errors(...) is called with Value::Null in the response-headers slot. resp.headers() is never read before resp.text(). So safe_string2(headers, "Set-Cookie", …) is always null.
   2. The values would not be kept anyway. In the generated rust/ccxt-base/src/exchanges/grvt.rs (around lines 4663–4672), handle_errors takes &self and writes AuthAccountId / AuthCookieValue into self.options.clone(). That is a copy, so the write is discarded, and the next check sees null and panics with exactly your message.

   The JS/Python/PHP builds pass the real response headers, so this path should work there. To unblock yourself now, use one of those languages with the same credentials.

   One thing to check on your side: privateKey must be the wallet's private key (hex, 0x…), not its address. The issue says you put your L1 address in that slot. If so, the login is signed by a different, derived address, so it won't be your registered wallet even once the Rust issue is fixed.

   The Rust fix needs to (a) capture the response headers in fetch_typed and pass them to handle_errors, and (b) give the Rust grvt sign-in path a way to keep the cookie and account id (mutable options state). That is a change to the Rust runtime and transpiler, not a one-line exchange fix, so I've labelled this as a bug for the maintainers.
3. ErwinSchweiz12 commented on Oct 16, 2026

   

   ErwinSchweiz12

   on Oct 16, 2026

   Author

   More actions

   Yes, sorry. I meant to say my L1 private key not L1 address. I did supply my L1 private key and it did not work.
4. carlosmiei

   self-assigned this

   on Oct 20, 2026
5. carlosmiei commented on Oct 20, 2026

   

   carlosmiei

   on Oct 20, 2026

   Collaborator

   More actions

   @ErwinSchweiz12 We will take a look and get back to you. thanks for reporting it
6. carlosmiei commented on Oct 20, 2026

   

   carlosmiei

   on Oct 20, 2026

   Collaborator

   More actions

   @ErwinSchweiz12 Will be fixed here #30941

   npm run cli.rs -- grvt fetchBalance          
   
   > ccxt@4.5.88 cli.rs
   > ./build/utils/cargo-runner.sh run --manifest-path examples/rust/Cargo.toml --features ws,all-venues --bin cli -- grvt fetchBalance
   
       Finished `dev` profile [unoptimized] target(s) in 0.09s
        Running `examples/rust/target/debug/cli grvt fetchBalance`
   exchange: grvt
   method:   fetchBalance (fetch_balance)
   credentials: privateKey
   
   
   result: {
     info: {
       event_time: '1792501990412829764',
       sub_account_id: '978620473301664',
       margin_type: 'SIMPLE_CROSS_MARGIN',
       settle_currency: 'USDT',
       unrealized_pnl: '0.0',
       total_equity: '0.0',
       initial_margin: '0.0',
       maintenance_margin: '0.0',
       available_balance: '0.0',
       spot_balances: [],
       positions: [],
       settle_index_price: '0.998634994',
       derisk_margin: '0.0',
       derisk_to_maintenance_margin_ratio: '1.0',
       total_cross_equity: '0.0',
       cross_unrealized_pnl: '0.0',
       sub_account_mode: 'SINGLE_ASSET_MODE',
       margin_balance: '0.0',
       algo_trading_enabled: false