Release/chain v1.17.0 support to master #338
Conversation
WalkthroughThis PR extends exchange functionality with OpenNotionalCap support, introduces offset position capability, adds rate limiting to Peggy module, renames denom decimal queries, implements market ID prefixes, updates dependencies including Hyperlane integration, and refactors multiple message types and client APIs across the codebase. Changes
Sequence Diagram(s)sequenceDiagram
actor User
participant ChainClient
participant QueryService
participant Exchange
User->>ChainClient: FetchOpenInterest(ctx, marketId)
ChainClient->>QueryService: OpenInterest RPC
QueryService->>Exchange: Query open interest for market
Exchange-->>QueryService: OpenInterest {market_id, amount}
QueryService-->>ChainClient: QueryOpenInterestResponse
ChainClient-->>User: *exchangev2types.QueryOpenInterestResponse
sequenceDiagram
actor User
participant SDK
participant MsgOffsetPosition
participant ValidationLayer
User->>SDK: Send MsgOffsetPosition
SDK->>MsgOffsetPosition: Route() / Type()
MsgOffsetPosition->>ValidationLayer: ValidateBasic()
ValidationLayer->>ValidationLayer: Check sender, market_id, offsetting_subaccount_ids
alt Valid
ValidationLayer-->>SDK: nil (OK)
SDK->>SDK: GetSigners() / GetSignBytes()
SDK->>SDK: Broadcast transaction
else Invalid
ValidationLayer-->>SDK: error
SDK-->>User: validation error
end
sequenceDiagram
participant Market as Market Launch
participant Validation as ValidateBasic
participant OpenNotional as OpenNotionalCap Check
Market->>Validation: MsgInstantPerpetualMarketLaunch
Validation->>Validation: Validate ticker, fees, margins
Validation->>OpenNotional: ValidateOpenNotionalCap(*OpenNotionalCap)
alt Uncapped
OpenNotional-->>Validation: OK
else Capped
OpenNotional->>OpenNotional: Verify cap value > 0
OpenNotional-->>Validation: OK or error
end
Validation-->>Market: Success or error
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Areas requiring extra attention:
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
examples/chain/exchange/9_MsgBatchUpdateOrders/example.go (1)
91-135: Market orders should not specify a price.Market orders execute at the best available market price. Setting explicit
Pricevalues on lines 96 and 128 forspot_market_orderandderivative_market_orderis semantically incorrect and contradicts the intended behavior of market orders. This will mislead users copying this example.Apply this diff to remove price specifications from market orders:
spot_market_order := chainClient.CreateSpotOrderV2( defaultSubaccountID, &chainclient.SpotOrderData{ OrderType: int32(exchangev2types.OrderType_BUY), //BUY SELL Quantity: decimal.NewFromFloat(0.1), - Price: decimal.NewFromFloat(22), + Price: decimal.Zero, // Market orders execute at best available price FeeRecipient: senderAddress.String(), MarketId: smarketId, Cid: uuid.NewString(), }, )derivative_market_order := chainClient.CreateDerivativeOrderV2( defaultSubaccountID, &chainclient.DerivativeOrderData{ OrderType: int32(exchangev2types.OrderType_BUY), //BUY SELL Quantity: decimal.NewFromFloat(0.01), - Price: decimal.RequireFromString("33000"), + Price: decimal.Zero, // Market orders execute at best available price Leverage: decimal.RequireFromString("2"), FeeRecipient: senderAddress.String(), MarketId: dmarketId, IsReduceOnly: false, Cid: uuid.NewString(), }, )
🧹 Nitpick comments (5)
examples/chain/exchange/9_MsgBatchUpdateOrders/example.go (1)
79-145: Use idiomatic Go naming conventions.Variable names use snake_case (
spot_order,derivative_order,spot_market_order,derivative_market_order) instead of Go's idiomatic camelCase. Since this is an example file, it should demonstrate best practices.Consider renaming:
spot_order→spotOrderspot_market_order→spotMarketOrderderivative_order→derivativeOrderderivative_market_order→derivativeMarketOrderexamples/chain/exchange/query/66_OpenInterest/example.go (1)
63-66: Improve error handling consistency.The error handling prints the error but continues execution, attempting to marshal a potentially nil response. Consider adding an early return after the error print for consistency:
res, err := chainClient.FetchOpenInterest(ctx, marketId) if err != nil { fmt.Println(err) + return }chain/exchange/types/v2/msgs.go (2)
2135-2142: Duplicate market orders check: add basic validity guard for marketId (and nil orders)ensureNoDuplicateMarketOrders is good. Add cheap guards to fail fast on invalid market IDs or nil entries.
Apply:
func ensureNoDuplicateMarketOrders(sender sdk.AccAddress, orders []*DerivativeOrder) error { seen := make(map[string]struct{}) - for _, order := range orders { + for _, order := range orders { + if order == nil { + return errors.Wrap(types.ErrInvalidBatchMsgUpdate, "nil market order") + } + if !types.IsHexHash(order.MarketId) { + return errors.Wrap(types.ErrMarketInvalid, order.MarketId) + } // Normalize the subaccount ID (converts both full subaccount ID and subaccount index to full subaccount ID) normalizedSubaccountID, err := types.GetSubaccountIDOrDeriveFromNonce(sender, order.OrderInfo.SubaccountId) if err != nil { return errors.Wrap(types.ErrBadSubaccountID, order.OrderInfo.SubaccountId) }Also applies to: 2707-2725
215-223: ValidateOpenNotionalCap symbol resolves correctly; HasOpenNotionalCapUpdate simplification is valid
- ValidateOpenNotionalCap is correctly defined in chain/exchange/types/v2/params.go:328 and called unqualified at msgs.go lines 251, 707, 787, and 866.
- HasOpenNotionalCapUpdate (lines 339–349) can be simplified from the verbose switch statement to
return msg.NewOpenNotionalCap.GetCapped() != nil || msg.NewOpenNotionalCap.GetUncapped() != nilfor consistency with other Has*Update methods in the same file, which all use direct return patterns.Also applies to: 250–254, 707–710, 787–790, 866–869 (validation contexts for OpenNotionalCap).
proto/injective/exchange/v2/query.proto (1)
485-490: OpenInterest RPC: consider path param for consistency and cacheabilityCurrent GET path omits market_id in the URL; most market queries embed it. Suggest adding path param for consistency and better CDN caching keys.
- rpc OpenInterest(QueryOpenInterestRequest) - returns (QueryOpenInterestResponse) { - option (google.api.http).get = "/injective/exchange/v2/open_interest"; - } + rpc OpenInterest(QueryOpenInterestRequest) + returns (QueryOpenInterestResponse) { + option (google.api.http).get = + "/injective/exchange/v2/open_interest/{market_id}"; + }No wire incompatibility on gRPC; only HTTP-gateway route changes. Verify downstream clients before changing.
Also applies to: 1656-1671
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (55)
chain/exchange/types/exchange.pb.gois excluded by!**/*.pb.gochain/exchange/types/query.pb.gois excluded by!**/*.pb.gochain/exchange/types/tx.pb.gois excluded by!**/*.pb.gochain/exchange/types/v2/events.pb.gois excluded by!**/*.pb.gochain/exchange/types/v2/exchange.pb.gois excluded by!**/*.pb.gochain/exchange/types/v2/genesis.pb.gois excluded by!**/*.pb.gochain/exchange/types/v2/market.pb.gois excluded by!**/*.pb.gochain/exchange/types/v2/proposal.pb.gois excluded by!**/*.pb.gochain/exchange/types/v2/query.pb.gois excluded by!**/*.pb.gochain/exchange/types/v2/tx.pb.gois excluded by!**/*.pb.gochain/peggy/types/events.pb.gois excluded by!**/*.pb.gochain/peggy/types/genesis.pb.gois excluded by!**/*.pb.gochain/peggy/types/msgs.pb.gois excluded by!**/*.pb.gochain/peggy/types/rate_limit.pb.gois excluded by!**/*.pb.gochain/permissions/types/genesis.pb.gois excluded by!**/*.pb.gochain/permissions/types/params.pb.gois excluded by!**/*.pb.gochain/permissions/types/permissions.pb.gois excluded by!**/*.pb.gochain/permissions/types/query.pb.gois excluded by!**/*.pb.gochain/permissions/types/tx.pb.gois excluded by!**/*.pb.gochain/stream/types/v2/query.pb.gois excluded by!**/*.pb.gochain/tokenfactory/types/genesis.pb.gois excluded by!**/*.pb.gochain/tokenfactory/types/params.pb.gois excluded by!**/*.pb.gochain/tokenfactory/types/query.pb.gois excluded by!**/*.pb.gochain/tokenfactory/types/tx.pb.gois excluded by!**/*.pb.gochain/txfees/osmosis/types/query.pb.gois excluded by!**/*.pb.gochain/txfees/types/query.pb.gois excluded by!**/*.pb.goexchange/accounts_rpc/pb/goadesign_goagen_injective_accounts_rpc.pb.gois excluded by!**/*.pb.goexchange/accounts_rpc/pb/goadesign_goagen_injective_accounts_rpc_grpc.pb.gois excluded by!**/*.pb.goexchange/auction_rpc/pb/goadesign_goagen_injective_auction_rpc.pb.gois excluded by!**/*.pb.goexchange/auction_rpc/pb/goadesign_goagen_injective_auction_rpc_grpc.pb.gois excluded by!**/*.pb.goexchange/campaign_rpc/pb/goadesign_goagen_injective_campaign_rpc.pb.gois excluded by!**/*.pb.goexchange/campaign_rpc/pb/goadesign_goagen_injective_campaign_rpc_grpc.pb.gois excluded by!**/*.pb.goexchange/derivative_exchange_rpc/pb/goadesign_goagen_injective_derivative_exchange_rpc.pb.gois excluded by!**/*.pb.goexchange/derivative_exchange_rpc/pb/goadesign_goagen_injective_derivative_exchange_rpc_grpc.pb.gois excluded by!**/*.pb.goexchange/event_provider_api/pb/goadesign_goagen_event_provider_api.pb.gois excluded by!**/*.pb.goexchange/event_provider_api/pb/goadesign_goagen_event_provider_api_grpc.pb.gois excluded by!**/*.pb.goexchange/exchange_rpc/pb/goadesign_goagen_injective_exchange_rpc.pb.gois excluded by!**/*.pb.goexchange/exchange_rpc/pb/goadesign_goagen_injective_exchange_rpc_grpc.pb.gois excluded by!**/*.pb.goexchange/explorer_rpc/pb/goadesign_goagen_injective_explorer_rpc.pb.gois excluded by!**/*.pb.goexchange/explorer_rpc/pb/goadesign_goagen_injective_explorer_rpc_grpc.pb.gois excluded by!**/*.pb.goexchange/health_rpc/pb/goadesign_goagen_health.pb.gois excluded by!**/*.pb.goexchange/health_rpc/pb/goadesign_goagen_health_grpc.pb.gois excluded by!**/*.pb.goexchange/insurance_rpc/pb/goadesign_goagen_injective_insurance_rpc.pb.gois excluded by!**/*.pb.goexchange/insurance_rpc/pb/goadesign_goagen_injective_insurance_rpc_grpc.pb.gois excluded by!**/*.pb.goexchange/meta_rpc/pb/goadesign_goagen_injective_meta_rpc.pb.gois excluded by!**/*.pb.goexchange/meta_rpc/pb/goadesign_goagen_injective_meta_rpc_grpc.pb.gois excluded by!**/*.pb.goexchange/oracle_rpc/pb/goadesign_goagen_injective_oracle_rpc.pb.gois excluded by!**/*.pb.goexchange/oracle_rpc/pb/goadesign_goagen_injective_oracle_rpc_grpc.pb.gois excluded by!**/*.pb.goexchange/portfolio_rpc/pb/goadesign_goagen_injective_portfolio_rpc.pb.gois excluded by!**/*.pb.goexchange/portfolio_rpc/pb/goadesign_goagen_injective_portfolio_rpc_grpc.pb.gois excluded by!**/*.pb.goexchange/spot_exchange_rpc/pb/goadesign_goagen_injective_spot_exchange_rpc.pb.gois excluded by!**/*.pb.goexchange/spot_exchange_rpc/pb/goadesign_goagen_injective_spot_exchange_rpc_grpc.pb.gois excluded by!**/*.pb.goexchange/trading_rpc/pb/goadesign_goagen_injective_trading_rpc.pb.gois excluded by!**/*.pb.goexchange/trading_rpc/pb/goadesign_goagen_injective_trading_rpc_grpc.pb.gois excluded by!**/*.pb.gogo.sumis excluded by!**/*.sum
📒 Files selected for processing (61)
Makefile(2 hunks)chain/evm/precompiles/bank/fixed_supply_bank_erc20.abigen.go(1 hunks)chain/evm/precompiles/bank/i_bank_module.abigen.go(1 hunks)chain/evm/precompiles/bank/mint_burn_bank_erc20.abigen.go(1 hunks)chain/evm/precompiles/staking/i_staking_module.abigen.go(1 hunks)chain/evm/types/errors.go(3 hunks)chain/exchange/types/codec.go(2 hunks)chain/exchange/types/errors.go(3 hunks)chain/exchange/types/expected_keepers.go(0 hunks)chain/exchange/types/key.go(1 hunks)chain/exchange/types/market.go(4 hunks)chain/exchange/types/market_admin.go(1 hunks)chain/exchange/types/msgs.go(4 hunks)chain/exchange/types/params.go(3 hunks)chain/exchange/types/v2/codec.go(4 hunks)chain/exchange/types/v2/events.go(2 hunks)chain/exchange/types/v2/market.go(2 hunks)chain/exchange/types/v2/msgs.go(14 hunks)chain/exchange/types/v2/params.go(5 hunks)chain/exchange/types/v2/position.go(1 hunks)chain/exchange/types/v2/proposal.go(19 hunks)chain/peggy/types/codec.go(2 hunks)chain/peggy/types/key.go(2 hunks)client/chain/chain_test_support.go(2 hunks)client/chain/chain_v2.go(4 hunks)client/chain/context.go(2 hunks)client/chain/markets_assistant.go(1 hunks)client/chain/markets_assistant_test.go(2 hunks)client/chain/markets_assistant_test_support.go(2 hunks)client/exchange/exchange_test_support.go(0 hunks)examples/chain/12_ChainStream/example.go(1 hunks)examples/chain/exchange/13_MsgInstantBinaryOptionsMarketLaunch/example.go(1 hunks)examples/chain/exchange/25_MsgUpdateDerivativeMarket/example.go(1 hunks)examples/chain/exchange/30_MsgOffsetPosition/example.go(1 hunks)examples/chain/exchange/4_MsgInstantPerpetualMarketLaunch/example.go(1 hunks)examples/chain/exchange/5_MsgInstantExpiryFuturesMarketLaunch/example.go(1 hunks)examples/chain/exchange/9_MsgBatchUpdateOrders/example.go(2 hunks)examples/chain/exchange/query/66_OpenInterest/example.go(1 hunks)examples/chain/exchange/query/8_AuctionExchangeTransferDenomDecimal/example.go(1 hunks)examples/chain/exchange/query/9_AuctionExchangeTransferDenomDecimals/example.go(1 hunks)examples/explorer/1_GetTxByHash/example.go(1 hunks)go.mod(6 hunks)injective_data/chain_messages_list.json(3 hunks)proto/injective/exchange/v1beta1/exchange.proto(2 hunks)proto/injective/exchange/v1beta1/query.proto(1 hunks)proto/injective/exchange/v1beta1/tx.proto(2 hunks)proto/injective/exchange/v2/events.proto(2 hunks)proto/injective/exchange/v2/exchange.proto(2 hunks)proto/injective/exchange/v2/genesis.proto(1 hunks)proto/injective/exchange/v2/market.proto(4 hunks)proto/injective/exchange/v2/proposal.proto(7 hunks)proto/injective/exchange/v2/query.proto(9 hunks)proto/injective/exchange/v2/tx.proto(9 hunks)proto/injective/peggy/v1/events.proto(1 hunks)proto/injective/peggy/v1/genesis.proto(2 hunks)proto/injective/peggy/v1/msgs.proto(5 hunks)proto/injective/peggy/v1/rate_limit.proto(1 hunks)proto/injective/permissions/v1beta1/genesis.proto(1 hunks)proto/injective/permissions/v1beta1/params.proto(1 hunks)proto/injective/permissions/v1beta1/permissions.proto(3 hunks)proto/injective/permissions/v1beta1/query.proto(2 hunks)
💤 Files with no reviewable changes (2)
- chain/exchange/types/expected_keepers.go
- client/exchange/exchange_test_support.go
🧰 Additional context used
🧬 Code graph analysis (26)
examples/chain/12_ChainStream/example.go (1)
chain/stream/types/v2/query.pb.go (6)
OrderFailuresFilter(1778-1781)OrderFailuresFilter(1785-1785)OrderFailuresFilter(1786-1788)ConditionalOrderTriggerFailuresFilter(1823-1828)ConditionalOrderTriggerFailuresFilter(1832-1832)ConditionalOrderTriggerFailuresFilter(1833-1835)
examples/chain/exchange/30_MsgOffsetPosition/example.go (6)
client/common/network.go (1)
LoadNetwork(53-202)client/chain/keys.go (1)
InitCosmosKeyring(28-164)client/chain/context.go (1)
NewClientContext(95-140)client/chain/chain_v2.go (1)
NewChainClientV2(362-506)chain/exchange/types/v2/msgs.go (2)
MsgOffsetPosition(1861-1863)MsgOffsetPosition(1865-1867)chain/exchange/types/v2/tx.pb.go (3)
MsgOffsetPosition(2727-2732)MsgOffsetPosition(2736-2736)MsgOffsetPosition(2737-2739)
client/chain/markets_assistant.go (2)
client/chain/chain.go (1)
ChainClient(74-332)client/chain/chain_v2.go (1)
ChainClientV2(54-311)
examples/chain/exchange/25_MsgUpdateDerivativeMarket/example.go (1)
chain/exchange/types/v2/market.pb.go (9)
OpenNotionalCap(63-68)OpenNotionalCap(72-72)OpenNotionalCap(73-75)OpenNotionalCap(141-146)OpenNotionalCap_Capped(112-114)OpenNotionalCap_Capped(117-117)OpenNotionalCapCapped(184-186)OpenNotionalCapCapped(190-190)OpenNotionalCapCapped(191-193)
chain/exchange/types/v2/params.go (2)
chain/exchange/types/v2/market.pb.go (4)
OpenNotionalCap(63-68)OpenNotionalCap(72-72)OpenNotionalCap(73-75)OpenNotionalCap(141-146)chain/exchange/types/exchange.pb.go (4)
OpenNotionalCap(232-237)OpenNotionalCap(241-241)OpenNotionalCap(242-244)OpenNotionalCap(310-315)
chain/peggy/types/codec.go (2)
chain/peggy/types/msgs.pb.go (9)
MsgCreateRateLimit(1587-1603)MsgCreateRateLimit(1607-1607)MsgCreateRateLimit(1608-1610)MsgUpdateRateLimit(1709-1720)MsgUpdateRateLimit(1724-1724)MsgUpdateRateLimit(1725-1727)MsgRemoveRateLimit(1819-1824)MsgRemoveRateLimit(1828-1828)MsgRemoveRateLimit(1829-1831)chain/peggy/types/rate_limit.pb.go (3)
RateLimit(27-43)RateLimit(47-47)RateLimit(48-50)
examples/chain/exchange/query/66_OpenInterest/example.go (6)
client/common/network.go (1)
LoadNetwork(53-202)client/chain/keys.go (1)
InitCosmosKeyring(28-164)client/chain/context.go (1)
NewClientContext(95-140)client/chain/chain_v2.go (1)
NewChainClientV2(362-506)client/common/options.go (1)
OptionGasPrices(36-47)client/constants.go (1)
DefaultGasPriceWithDenom(6-6)
examples/explorer/1_GetTxByHash/example.go (1)
client/common/network.go (1)
LoadNetwork(53-202)
examples/chain/exchange/5_MsgInstantExpiryFuturesMarketLaunch/example.go (2)
chain/exchange/types/v2/market.pb.go (6)
OpenNotionalCap(63-68)OpenNotionalCap(72-72)OpenNotionalCap(73-75)OpenNotionalCap(141-146)OpenNotionalCap_Uncapped(109-111)OpenNotionalCap_Uncapped(116-116)chain/exchange/types/exchange.pb.go (6)
OpenNotionalCap(232-237)OpenNotionalCap(241-241)OpenNotionalCap(242-244)OpenNotionalCap(310-315)OpenNotionalCap_Uncapped(278-280)OpenNotionalCap_Uncapped(285-285)
examples/chain/exchange/9_MsgBatchUpdateOrders/example.go (3)
client/chain/chain.go (2)
SpotOrderData(1637-1645)DerivativeOrderData(1625-1635)chain/exchange/types/exchange.pb.go (9)
OrderType(97-97)OrderType(145-147)OrderType_BUY(101-101)SpotOrder(1413-1422)SpotOrder(1426-1426)SpotOrder(1427-1429)DerivativeOrder(1611-1622)DerivativeOrder(1626-1626)DerivativeOrder(1627-1629)chain/exchange/types/v2/tx.pb.go (3)
MsgBatchUpdateOrders(1722-1752)MsgBatchUpdateOrders(1756-1756)MsgBatchUpdateOrders(1757-1759)
chain/exchange/types/codec.go (3)
chain/exchange/types/msgs.go (4)
MsgInstantPerpetualMarketLaunch(593-593)MsgInstantPerpetualMarketLaunch(596-596)MsgInstantExpiryFuturesMarketLaunch(739-739)MsgInstantExpiryFuturesMarketLaunch(742-744)chain/exchange/types/tx.pb.go (6)
MsgInstantPerpetualMarketLaunch(755-790)MsgInstantPerpetualMarketLaunch(794-794)MsgInstantPerpetualMarketLaunch(795-797)MsgInstantExpiryFuturesMarketLaunch(982-1019)MsgInstantExpiryFuturesMarketLaunch(1023-1023)MsgInstantExpiryFuturesMarketLaunch(1024-1026)chain/exchange/types/v2/tx.pb.go (6)
MsgInstantPerpetualMarketLaunch(753-793)MsgInstantPerpetualMarketLaunch(797-797)MsgInstantPerpetualMarketLaunch(798-800)MsgInstantExpiryFuturesMarketLaunch(986-1027)MsgInstantExpiryFuturesMarketLaunch(1031-1031)MsgInstantExpiryFuturesMarketLaunch(1032-1034)
examples/chain/exchange/13_MsgInstantBinaryOptionsMarketLaunch/example.go (1)
chain/exchange/types/v2/market.pb.go (6)
OpenNotionalCap(63-68)OpenNotionalCap(72-72)OpenNotionalCap(73-75)OpenNotionalCap(141-146)OpenNotionalCap_Uncapped(109-111)OpenNotionalCap_Uncapped(116-116)
client/chain/chain_v2.go (2)
chain/exchange/types/v2/query.pb.go (21)
QueryAuctionExchangeTransferDenomDecimalResponse(937-939)QueryAuctionExchangeTransferDenomDecimalResponse(947-947)QueryAuctionExchangeTransferDenomDecimalResponse(948-950)QueryAuctionExchangeTransferDenomDecimalsResponse(1038-1040)QueryAuctionExchangeTransferDenomDecimalsResponse(1048-1048)QueryAuctionExchangeTransferDenomDecimalsResponse(1049-1051)QueryOpenInterestResponse(7567-7569)QueryOpenInterestResponse(7573-7573)QueryOpenInterestResponse(7574-7576)QueryAuctionExchangeTransferDenomDecimalRequest(887-889)QueryAuctionExchangeTransferDenomDecimalRequest(897-897)QueryAuctionExchangeTransferDenomDecimalRequest(898-900)QueryAuctionExchangeTransferDenomDecimalsRequest(987-990)QueryAuctionExchangeTransferDenomDecimalsRequest(998-998)QueryAuctionExchangeTransferDenomDecimalsRequest(999-1001)QueryOpenInterestRequest(7522-7525)QueryOpenInterestRequest(7529-7529)QueryOpenInterestRequest(7530-7532)OpenInterest(7475-7480)OpenInterest(7484-7484)OpenInterest(7485-7487)client/common/api_request_assistant.go (1)
ExecuteCall(13-37)
chain/exchange/types/msgs.go (8)
chain/exchange/types/tx.pb.go (6)
MsgInstantPerpetualMarketLaunch(755-790)MsgInstantPerpetualMarketLaunch(794-794)MsgInstantPerpetualMarketLaunch(795-797)MsgInstantExpiryFuturesMarketLaunch(982-1019)MsgInstantExpiryFuturesMarketLaunch(1023-1023)MsgInstantExpiryFuturesMarketLaunch(1024-1026)chain/exchange/types/v2/tx.pb.go (6)
MsgInstantPerpetualMarketLaunch(753-793)MsgInstantPerpetualMarketLaunch(797-797)MsgInstantPerpetualMarketLaunch(798-800)MsgInstantExpiryFuturesMarketLaunch(986-1027)MsgInstantExpiryFuturesMarketLaunch(1031-1031)MsgInstantExpiryFuturesMarketLaunch(1032-1034)chain/exchange/types/v2/msgs.go (3)
RouterKey(18-18)TypeMsgInstantPerpetualMarketLaunch(95-95)TypeMsgInstantExpiryFuturesMarketLaunch(96-96)chain/exchange/types/errors.go (8)
ErrInvalidTicker(19-19)ErrInvalidQuoteDenom(21-21)ErrFeeRatesRelation(52-52)ErrMarginsRelation(53-53)ErrInvalidPriceTickSize(42-42)ErrInvalidQuantityTickSize(43-43)ErrInvalidNotional(108-108)ErrInvalidExpiry(23-23)chain/exchange/types/params.go (6)
MaxTickerLength(38-38)ValidateMakerFee(300-319)ValidateFee(280-298)ValidateMarginRatio(446-463)ValidateTickSize(369-427)ValidateMinNotional(429-444)chain/exchange/types/v2/proposal.go (1)
NewOracleParams(743-755)chain/exchange/types/proposal.go (1)
NewOracleParams(659-671)chain/exchange/types/codec.go (1)
ModuleCdc(187-187)
chain/exchange/types/v2/codec.go (4)
chain/exchange/types/v2/msgs.go (2)
MsgOffsetPosition(1861-1863)MsgOffsetPosition(1865-1867)chain/exchange/types/v2/tx.pb.go (3)
MsgOffsetPosition(2727-2732)MsgOffsetPosition(2736-2736)MsgOffsetPosition(2737-2739)chain/exchange/types/v2/proposal.go (2)
UpdateAuctionExchangeTransferDenomDecimalsProposal(715-715)UpdateAuctionExchangeTransferDenomDecimalsProposal(718-720)chain/exchange/types/v2/proposal.pb.go (3)
UpdateAuctionExchangeTransferDenomDecimalsProposal(672-676)UpdateAuctionExchangeTransferDenomDecimalsProposal(684-684)UpdateAuctionExchangeTransferDenomDecimalsProposal(685-687)
examples/chain/exchange/4_MsgInstantPerpetualMarketLaunch/example.go (2)
chain/exchange/types/v2/market.pb.go (6)
OpenNotionalCap(63-68)OpenNotionalCap(72-72)OpenNotionalCap(73-75)OpenNotionalCap(141-146)OpenNotionalCap_Uncapped(109-111)OpenNotionalCap_Uncapped(116-116)chain/exchange/types/exchange.pb.go (6)
OpenNotionalCap(232-237)OpenNotionalCap(241-241)OpenNotionalCap(242-244)OpenNotionalCap(310-315)OpenNotionalCap_Uncapped(278-280)OpenNotionalCap_Uncapped(285-285)
chain/exchange/types/v2/msgs.go (4)
chain/exchange/types/v2/tx.pb.go (3)
MsgOffsetPosition(2727-2732)MsgOffsetPosition(2736-2736)MsgOffsetPosition(2737-2739)chain/exchange/types/errors.go (6)
ErrInvalidOpenNotionalCap(119-119)ErrInvalidAddress(91-91)ErrMarketInvalid(13-13)ErrBadSubaccountID(18-18)ErrOffsettingSubaccountIDsEmpty(118-118)ErrInvalidBatchMsgUpdate(66-66)chain/exchange/types/common_utils.go (4)
IsHexHash(110-120)IsValidSubaccountID(90-98)HasDuplicates(311-320)GetSubaccountIDOrDeriveFromNonce(203-213)chain/exchange/types/v2/codec.go (1)
ModuleCdc(24-24)
chain/exchange/types/v2/events.go (1)
chain/exchange/types/v2/events.pb.go (9)
EventOrderFail(1698-1703)EventOrderFail(1707-1707)EventOrderFail(1708-1710)EventTriggerConditionalMarketOrderFailed(2393-2400)EventTriggerConditionalMarketOrderFailed(2406-2406)EventTriggerConditionalMarketOrderFailed(2407-2409)EventTriggerConditionalLimitOrderFailed(2472-2479)EventTriggerConditionalLimitOrderFailed(2485-2485)EventTriggerConditionalLimitOrderFailed(2486-2488)
chain/exchange/types/v2/market.go (1)
chain/exchange/types/v2/market.pb.go (10)
DerivativeMarket(479-531)DerivativeMarket(535-535)DerivativeMarket(536-538)OpenNotionalCap(63-68)OpenNotionalCap(72-72)OpenNotionalCap(73-75)OpenNotionalCap(141-146)BinaryOptionsMarket(395-443)BinaryOptionsMarket(447-447)BinaryOptionsMarket(448-450)
chain/exchange/types/market.go (2)
chain/oracle/types/oracle.pb.go (2)
OracleType(32-32)OracleType(86-88)chain/peggy/types/ethereum.go (1)
NewPeggyDenomFromString(113-127)
client/chain/chain_test_support.go (1)
chain/exchange/types/v2/query.pb.go (9)
QueryAuctionExchangeTransferDenomDecimalResponse(937-939)QueryAuctionExchangeTransferDenomDecimalResponse(947-947)QueryAuctionExchangeTransferDenomDecimalResponse(948-950)QueryAuctionExchangeTransferDenomDecimalsResponse(1038-1040)QueryAuctionExchangeTransferDenomDecimalsResponse(1048-1048)QueryAuctionExchangeTransferDenomDecimalsResponse(1049-1051)QueryOpenInterestResponse(7567-7569)QueryOpenInterestResponse(7573-7573)QueryOpenInterestResponse(7574-7576)
client/chain/markets_assistant_test.go (1)
client/chain/markets_assistant.go (2)
NewMarketsAssistantWithAllTokens(58-64)NewHumanReadableMarketsAssistantWithAllTokens(66-72)
client/chain/markets_assistant_test_support.go (2)
chain/exchange/types/v2/market.pb.go (6)
OpenNotionalCap(63-68)OpenNotionalCap(72-72)OpenNotionalCap(73-75)OpenNotionalCap(141-146)OpenNotionalCap_Uncapped(109-111)OpenNotionalCap_Uncapped(116-116)chain/exchange/types/exchange.pb.go (6)
OpenNotionalCap(232-237)OpenNotionalCap(241-241)OpenNotionalCap(242-244)OpenNotionalCap(310-315)OpenNotionalCap_Uncapped(278-280)OpenNotionalCap_Uncapped(285-285)
chain/exchange/types/v2/position.go (2)
chain/exchange/types/v2/exchange.pb.go (3)
Position(607-618)Position(622-622)Position(623-625)chain/exchange/types/v2/market.pb.go (3)
PerpetualMarketFunding(952-961)PerpetualMarketFunding(965-965)PerpetualMarketFunding(966-968)
chain/exchange/types/errors.go (1)
chain/exchange/types/key.go (1)
ModuleName(17-17)
chain/exchange/types/v2/proposal.go (6)
chain/exchange/types/v2/market.pb.go (4)
OpenNotionalCap(63-68)OpenNotionalCap(72-72)OpenNotionalCap(73-75)OpenNotionalCap(141-146)chain/exchange/types/v2/params.go (1)
ValidateOpenNotionalCap(328-353)chain/exchange/types/errors.go (1)
ErrInvalidOpenNotionalCap(119-119)chain/exchange/types/v2/proposal.pb.go (3)
UpdateAuctionExchangeTransferDenomDecimalsProposal(672-676)UpdateAuctionExchangeTransferDenomDecimalsProposal(684-684)UpdateAuctionExchangeTransferDenomDecimalsProposal(685-687)chain/exchange/types/v2/exchange.pb.go (3)
DenomDecimals(1910-1915)DenomDecimals(1919-1919)DenomDecimals(1920-1922)chain/exchange/types/v2/msgs.go (1)
RouterKey(18-18)
🪛 Buf (1.59.0)
proto/injective/peggy/v1/rate_limit.proto
6-6: import "gogoproto/gogo.proto": file does not exist
(COMPILE)
🪛 OSV Scanner (2.2.4)
go.mod
[HIGH] 90-90: github.com/consensys/gnark-crypto 0.18.0: Unchecked memory allocation during vector deserialization in github.com/consensys/gnark-crypto
(GO-2025-4087)
[HIGH] 90-90: github.com/consensys/gnark-crypto 0.18.0: gnark-crypto allows unchecked memory allocation during vector deserialization
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: lint
- GitHub Check: run-tests
🔇 Additional comments (69)
examples/explorer/1_GetTxByHash/example.go (1)
13-13: Bug fix: Corrected invalid node parameter for mainnet.The previous code would have panicked at runtime because
LoadNetworkonly accepts"lb"as a valid node for mainnet, not"sentry". This change correctly uses the valid node parameter.proto/injective/permissions/v1beta1/params.proto (1)
15-16: Documentation improvement approved.The added comment clearly explains the purpose of the
wasm_hook_query_max_gasfield. This documentation-only change improves clarity without any functional impact.proto/injective/permissions/v1beta1/permissions.proto (1)
11-127: Documentation enhancements throughout message definitions.All fields across multiple message types now have inline comments explaining their purpose. The comments follow a consistent pattern and are appropriately descriptive for generated code documentation.
proto/injective/permissions/v1beta1/genesis.proto (1)
12-17: Documentation clarifications for GenesisState fields.Comments have been added to clarify the purpose of each field in the GenesisState message. This documentation-only change improves the clarity of the genesis initialization structure.
proto/injective/permissions/v1beta1/query.proto (1)
126-281: Comprehensive query API documentation improvements.All request and response message types now include inline field comments explaining their purpose. This systematic documentation enhancement follows a consistent pattern throughout the file and significantly improves the clarity of the query API, beneficial for code generation (gRPC gateway, OpenAPI, etc.).
examples/chain/12_ChainStream/example.go (1)
78-84: LGTM! Filters correctly demonstrate new v1.17.0 capabilities.The new filters are properly initialized and follow established patterns in this example:
OrderFailuresFilterdemonstrates wildcard usage (consistent withBankBalancesFilter)ConditionalOrderTriggerFailuresFilterdemonstrates targeted filtering (consistent withDerivativeOrdersFilterandPositionsFilter)Both filter structures match their protobuf definitions and correctly reference variables defined earlier in the file.
client/chain/context.go (2)
189-192: LGTM! Hyperlane interface registration follows the correct pattern.The interface registrations for Hyperlane modules are correctly implemented and follow the same pattern as existing Cosmos SDK and IBC module registrations. The ordering (core → warp → post_dispatch → interchain_security) logically groups related modules together.
11-14: No issues found. The Hyperlane dependency is properly configured and legitimately sourced.The verification confirms:
- The official repository is github.com/bcp-innovations/hyperlane-cosmos, and the codebase correctly uses the InjectiveLabs variant (v1.0.1-inj) via a go.mod replace directive.
- The version is properly pinned in go.mod rather than floating, addressing the version security concern.
- The file already contains numerous InjectiveLabs imports, confirming this is an Injective chain client where the Hyperlane Cosmos integration is contextually appropriate as part of the chain upgrade.
- No critical security advisories were found for this dependency.
chain/evm/precompiles/bank/i_bank_module.abigen.go (1)
1-2: LGTM! Auto-generated file.This is an auto-generated Go binding file. The ABI string has been reformatted with updated JSON field ordering (explicit
internalTypefields), but the contract interface remains unchanged.Also applies to: 34-34
chain/exchange/types/market_admin.go (1)
4-14: LGTM! Permission flag addition looks correct.The new
OpenNotionalCapPermpermission is correctly added to the bitwise flag series, andMaxPermis properly updated to include it in the OR combination.chain/evm/precompiles/staking/i_staking_module.abigen.go (1)
1-2: LGTM! Auto-generated file.This is an auto-generated Go binding file. The ABI string has been updated with revised JSON formatting (explicit
internalTypefields), but the Go API surface remains unchanged.Also applies to: 40-40
chain/peggy/types/key.go (1)
120-121: LGTM! Key prefix additions are consistent.The new key prefixes follow the existing sequential numbering pattern (0x1e, 0x1f) and the
GetMintAmountERC20Keyhelper function correctly follows the established pattern for key construction with proper buffer pre-allocation.Also applies to: 306-312
chain/exchange/types/key.go (1)
71-71: LGTM! Prefix constant addition is correct.The new
DerivativeMarketOpenInterestPrefixfollows the sequential numbering pattern (0x35) and is properly documented.chain/evm/types/errors.go (1)
10-10: LGTM! Revert reason encoding implementation is correct.The
RevertSelectorcorrectly computes the standard Solidity error selector forError(string), andRevertReasonBytesproperly ABI-encodes revert reasons by combining the selector with packed string data.Also applies to: 115-118, 299-313
proto/injective/peggy/v1/events.proto (1)
186-197: LGTM! Proto definitions are well-structured.The
JailReasonenum andEventValidatorJailedmessage are properly defined following proto3 conventions. The structure mirrors the existingEventValidatorSlashmessage appropriately.chain/evm/precompiles/bank/fixed_supply_bank_erc20.abigen.go (1)
1-2: LGTM! Auto-generated file.This is an auto-generated Go binding file. The ABI and deployment bytecode (Bin) have been updated to reflect the reformatted contract ABI with explicit
internalTypefields.Also applies to: 34-35
Makefile (2)
4-4: LGTM: Dependency versions updated for chain v1.17.0.The version bumps for both injective-indexer (v1.17.16) and injective-core (v1.17.0) align with the PR's objective to support chain upgrade v1.17.0.
Also applies to: 7-7
168-177: LGTM: Enhanced message extraction coverage.The updated extraction logic now includes both
tx.pb.goandmsgs.pb.gofiles, providing more comprehensive message name coverage. The added output reporting improves visibility into extraction results.chain/exchange/types/errors.go (2)
33-102: LGTM: Error message standardization.The error messages have been standardized with consistent lowercase formatting and improved phrasing. This enhances maintainability without affecting functionality.
117-119: LGTM: New error types for offset position and OpenNotionalCap features.The three new error declarations align with the PR's introduction of offset position capability and OpenNotionalCap support. Error codes are sequential and messages are clear.
examples/chain/exchange/13_MsgInstantBinaryOptionsMarketLaunch/example.go (1)
86-88: LGTM: OpenNotionalCap field properly initialized.The example correctly demonstrates the new OpenNotionalCap field with the Uncapped variant, consistent with the broader OpenNotionalCap feature rollout across market launch messages.
examples/chain/exchange/5_MsgInstantExpiryFuturesMarketLaunch/example.go (1)
87-89: LGTM: OpenNotionalCap field properly initialized.The example correctly demonstrates the new OpenNotionalCap field with the Uncapped variant for expiry futures market launch, maintaining consistency with other market launch message examples.
examples/chain/exchange/query/9_AuctionExchangeTransferDenomDecimals/example.go (1)
63-63: LGTM: Updated to use renamed API.The example correctly uses the renamed
FetchAuctionExchangeTransferDenomDecimalsAPI, which provides a more descriptive name for the denom decimal query functionality.proto/injective/peggy/v1/genesis.proto (1)
10-10: LGTM: Genesis state extended with rate limiting.The addition of the
rate_limitsfield to the GenesisState message properly integrates the new rate limiting functionality into the Peggy module's genesis state, with the appropriate import and sequential field numbering.Also applies to: 32-32
proto/injective/exchange/v1beta1/query.proto (1)
408-408: LGTM: Documentation comment corrected.The comment now accurately reflects that the RPC retrieves all binary options markets (plural), matching the RPC name and behavior.
examples/chain/exchange/query/8_AuctionExchangeTransferDenomDecimal/example.go (1)
63-63: LGTM: Updated to use renamed API.The example correctly uses the renamed
FetchAuctionExchangeTransferDenomDecimalAPI (singular version), consistent with the broader denom decimal query rename across the codebase.examples/chain/exchange/25_MsgUpdateDerivativeMarket/example.go (1)
81-87: LGTM!The
OpenNotionalCapinitialization with theCappedvariant is correctly structured, properly nesting theOpenNotionalCapCappedstruct and setting the value.chain/exchange/types/v2/market.go (2)
188-190: LGTM!The getter method is correctly implemented and follows the established pattern in the file.
293-295: LGTM!The getter method is correctly implemented and follows the established pattern in the file.
proto/injective/exchange/v2/events.proto (2)
296-306: LGTM!The addition of the
cidfield is backward compatible and follows the existing field numbering sequence.
308-318: LGTM!The addition of the
cidfield is backward compatible and follows the existing field numbering sequence.proto/injective/exchange/v1beta1/exchange.proto (2)
19-38: LGTM!The
OpenNotionalCapmessage structure is well-designed, using aoneoffield to represent the uncapped vs. capped variants. The amino annotations are correctly specified for Cosmos SDK compatibility.
306-307: LGTM!The addition of the
open_notional_capfield toDerivativeMarketfollows the existing field numbering sequence and is correctly marked as non-nullable.proto/injective/exchange/v2/genesis.proto (1)
118-121: Inconsistency detected between v1beta1 and v2 exchange genesis protos.The field rename to
auction_exchange_transfer_denom_decimalswas applied in v2 genesis proto, butproto/injective/exchange/v1beta1/genesis.protostill retains the old field namedenom_decimals(line 116). While the v2-specific generated code and business logic appear correctly updated, this creates a proto-level inconsistency between versions that requires clarification:
- Is v1beta1 intentionally unchanged, or should it also be updated?
- Does this impact version compatibility or genesis state migration?
No direct field access violations were found in business logic code—the field is only referenced through protobuf serialization in generated code.
client/chain/markets_assistant_test.go (2)
193-193: LGTM! Constructor signature correctly updated.The test correctly reflects the updated
NewMarketsAssistantWithAllTokenssignature, which no longer requires an exchange client parameter.
377-377: LGTM! V2 constructor signature correctly updated.The test correctly reflects the updated
NewHumanReadableMarketsAssistantWithAllTokenssignature, consistent with the removal of exchange client dependency.proto/injective/peggy/v1/rate_limit.proto (1)
1-50: LGTM! Well-structured rate limit proto definitions.The new
RateLimitandBridgeTransfermessages are properly defined with appropriate field types and gogoproto annotations. The use ofcosmossdk.io/math.LegacyDecandcosmossdk.io/math.Intwithnullable=falsefollows Cosmos SDK best practices.Note: The static analysis warning about missing
gogoproto/gogo.protois a false positive - this is a standard import in Cosmos SDK projects.client/chain/chain_test_support.go (2)
386-392: LGTM! Mock methods correctly renamed.The mock implementations correctly reflect the renamed query methods
FetchAuctionExchangeTransferDenomDecimalandFetchAuctionExchangeTransferDenomDecimals, with appropriate return type updates.
651-653: LGTM! New open interest query method added.The
FetchOpenInterestmock method is properly implemented following the established pattern for mock query methods.proto/injective/exchange/v1beta1/tx.proto (2)
399-467: Verify: Are RPC definitions missing for MsgInstantPerpetualMarketLaunch?The new
MsgInstantPerpetualMarketLaunchmessage definition looks well-structured with all necessary fields for launching a perpetual market. However, I don't see a corresponding RPC definition in theservice Msgblock (lines 16-163).If this message is intended to be used as a transaction, it needs an RPC entry like:
rpc InstantPerpetualMarketLaunch(MsgInstantPerpetualMarketLaunch) returns (MsgInstantPerpetualMarketLaunchResponse);Please confirm whether this is intentional or if the RPC definition should be added.
534-603: Verify: Are RPC definitions missing for MsgInstantExpiryFuturesMarketLaunch?Similar to
MsgInstantPerpetualMarketLaunch, this message definition appears complete but lacks a corresponding RPC in theservice Msgblock.If this message is intended to be used as a transaction, an RPC definition should be added:
rpc InstantExpiryFuturesMarketLaunch(MsgInstantExpiryFuturesMarketLaunch) returns (MsgInstantExpiryFuturesMarketLaunchResponse);Please confirm whether this is intentional or if the RPC definition should be added.
chain/exchange/types/v2/codec.go (3)
58-58: LGTM! MsgOffsetPosition correctly registered.The new
MsgOffsetPositionmessage type is properly registered in the legacy Amino codec, consistent with other message registrations.
79-83: LGTM! Proposal type rename applied consistently.The rename from
UpdateDenomDecimalsProposaltoUpdateAuctionExchangeTransferDenomDecimalsProposalis correctly applied in both the legacy Amino codec registration (lines 79-83) and the governance content interface registration (line 172). The multi-line formatting improves readability.Also applies to: 172-172
135-135: LGTM! MsgOffsetPosition registered in interface registry.The message is correctly added to the sdk.Msg interface registry, enabling proper type resolution for the new offset position functionality.
chain/exchange/types/msgs.go (4)
40-41: LGTM! New message types correctly declared.The interface assertions for
MsgInstantPerpetualMarketLaunchandMsgInstantExpiryFuturesMarketLaunchensure compile-time verification that these types implement thesdk.Msginterface.
377-377: LGTM! Simplified trigger price validation.The updated condition
(m.TriggerPrice == nil || m.TriggerPrice.LTE(math.LegacyZeroDec()))is clearer and more intuitive than the previous logic, properly validating that conditional orders have valid trigger prices.
592-659: LGTM! Complete sdk.Msg implementation for MsgInstantPerpetualMarketLaunch.The implementation includes all required sdk.Msg methods with comprehensive validation:
- Sender address validation
- Ticker length checks (lines 606-608)
- Quote denom validation (lines 609-611)
- Oracle params validation (lines 612-615)
- Fee rates validation with proper relationship checks (lines 616-630)
- Margin ratios validation with proper relationship checks (lines 622-633)
- Tick sizes and min notional validation (lines 634-642)
The validation logic is thorough and follows established patterns from similar message types.
738-811: LGTM! Complete sdk.Msg implementation for MsgInstantExpiryFuturesMarketLaunch.The implementation mirrors the perpetual market launch with appropriate additions:
- All standard validations present
- Expiry timestamp validation (lines 765-767)
- Proper fee and margin ratio relationship checks
The validation is comprehensive and consistent with the perpetual market launch message.
proto/injective/peggy/v1/msgs.proto (3)
81-90: LGTM! Rate limit RPCs properly defined.The three new RPCs (
CreateRateLimit,UpdateRateLimit,RemoveRateLimit) follow the established patterns in the service definition and provide complete CRUD operations for rate limit management.
160-169: Note: Breaking change - field renamed from eth_address to eth_dest.The field rename from
eth_addresstoeth_destat line 163 improves clarity by explicitly indicating this is a destination address. The updated comments also better describe the field's purpose.This is a breaking change for clients using this message. Ensure this is documented in release notes and migration guides.
366-439: LGTM! Comprehensive rate limit message definitions.The new rate limit messages are well-structured:
MsgCreateRateLimitincludes all necessary fields for establishing rate limits (token details, USD limits, mint limits, sliding window)MsgUpdateRateLimitallows updating key parameters (price ID, USD limit, window)MsgRemoveRateLimitprovides cleanup capability- All messages properly use the
authorityfield for governance control- Field types use appropriate Cosmos SDK math types with correct annotations
The implementation follows Cosmos SDK best practices for governance-controlled operations.
proto/injective/exchange/v2/query.proto (2)
84-90: DenomDecimal(s) → AuctionExchangeTransferDenomDecimal(s) — rename looks consistentRPC names, messages, and HTTP paths aligned. No issues spotted.
Also applies to: 94-99, 594-613
699-701: Orderbook seq added — coherent across spot/derivative and full variantsAdding seq at field 3 is non-breaking and helpful. LGTM.
Also applies to: 885-887, 1551-1552, 1563-1564
client/chain/chain_v2.go (2)
222-223: Client wiring verified ✓The FetchOpenInterest method is correctly wired:
- Interface definition (line 222) matches implementation (lines 2006-2011)
- Proto-generated OpenInterest method is properly exposed in the queryClient (line 8321 in query.pb.go)
- QueryOpenInterestRequest/QueryOpenInterestResponse types are correctly imported and used
- Implementation pattern is consistent with other query methods
164-166: Based on the search results, I can now generate the rewritten review comment.The search output confirms:
- No old Fetch method names remain: The ripgrep search found only proto definitions and generated code related to
DenomDecimal/DenomDecimals(the underlying gRPC service methods)- No references to old wrapper methods: There are no remnants of old Fetch method names like
FetchDenomDecimalorFetchDenomDecimals- Proto service methods unchanged: The underlying
DenomDecimal/DenomDecimalsgRPC service methods in protos are correctly unchanged (these are backend services, not client wrappers)- Client wiring verified: References in
client/chain/chain.go(lines 1805, 1814) use the proto service methods, which remain stable
Rename complete — no remaining usages of old wrapper method names detected
Verification confirms:
- No old Fetch method names remain in codebase
- Proto service methods (
DenomDecimal/DenomDecimals) correctly unchanged- Client wiring to gRPC methods stable
- No breakage risk
proto/injective/exchange/v2/tx.proto (5)
142-143: LGTM! New offset position RPC properly defined.The new RPC method follows established patterns and is properly documented.
314-316: LGTM! OpenNotionalCap field additions are consistent.The new
open_notional_capfield has been properly added to derivative market messages with appropriate field tags and non-nullable constraints. The naming convention (usingnew_prefix in update messages) is consistent with other fields.Also applies to: 537-539, 604-606, 684-686
898-906: LGTM! Market order support properly added to batch operations.The new fields for creating market orders in batch operations follow the established pattern for limit orders and use appropriate field tags and nullability constraints.
926-934: LGTM! Response fields properly mirror the request additions.The market order response tracking fields follow the established pattern for limit orders, with proper field numbering and consistent naming conventions for hashes, created CIDs, and failed CIDs.
1150-1163: No action required—comprehensive validation already implemented.The
ValidateBasic()function inchain/exchange/types/v2/msgs.go(lines 1869–1903) already addresses all validation concerns:
- Empty array: Validated at line 1886–1888
- Invalid subaccount ID format: Validated at line 1890–1893 via
IsValidSubaccountID()- Self-offsetting: Prevented at line 1895–1897
- Duplicate IDs: Checked at line 1900–1902
The implementation is comprehensive and correct.
proto/injective/exchange/v2/proposal.proto (3)
251-252: LGTM! OpenNotionalCap field additions follow proper design patterns.The
open_notional_capfield has been appropriately added to market proposals with correct nullability constraints:
- Launch proposals: Non-nullable (required) - ensures new markets have this cap defined
- Update proposals: Nullable (optional) - allows selective updates without requiring this field
Field numbering is sequential and consistent within each message.
Also applies to: 310-311, 389-390, 477-478, 573-574
118-119: Review comment is misleading about the nature of the change.This is not a field rename within v2—it's part of the v2 API redesign. The field
denom_decimals_update_proposal(with typeUpdateDenomDecimalsProposal) exists in v1/v1beta1 proto definitions. The v2 API introduces a new message structure withauction_exchange_transfer_denom_decimals_update_proposal(with typeUpdateAuctionExchangeTransferDenomDecimalsProposal) at tag 11.While this is a breaking change for API consumers migrating from v1 to v2, it's an expected consequence of a major API version bump—not an accidental rename. The field tag reuse across versions is acceptable. If this PR is introducing v2 as a new API version, the breaking changes are intentional and properly scoped.
Likely an incorrect or invalid review comment.
501-503: No action required—proposal type changes are properly versioned and compatible.The proto file changes affect only the v2 API (
proto/injective/exchange/v2/). The v1beta1 proposal typeUpdateDenomDecimalsProposalremains unchanged and continues to work; the new typeUpdateAuctionExchangeTransferDenomDecimalsProposalis a separate v2 addition with its own codec registration (exchange/v2/UpdateAuctionExchangeTransferDenomDecimalsProposal). Both are properly registered in their respective codec files with distinct amino names, so existing v1beta1 governance workflows are unaffected.injective_data/chain_messages_list.json (2)
39-40: LGTM! Exchange message types properly registered.The new exchange message types are correctly added with proper namespacing:
MsgInstantExpiryFuturesMarketLaunchandMsgInstantPerpetualMarketLaunchin v1beta1MsgOffsetPositionin v2These align with the proto definitions reviewed earlier.
Also applies to: 95-95
135-151: v2 Peggy messages are not present in the file.Verification confirms all 17 v1 Peggy message types have corresponding proto definitions in
proto/injective/peggy/v1/msgs.proto, including the rate limiting messages (MsgCreateRateLimit,MsgUpdateRateLimit,MsgRemoveRateLimit). However, the file contains only v1 entries — no v2 Peggy messages were found ininjective_data/chain_messages_list.json, and no v2 proto definitions exist in the repository. The original review requests verification that v2 versions are "properly added," but they are not present. Clarify whether v2 support is needed and should be included.chain/exchange/types/v2/proposal.go (4)
20-36: LGTM! Proposal constants properly updated with V2 suffix.The proposal type constants have been consistently updated with "V2" suffixes to distinguish them from v1beta1 proposals. The rename from
ProposalUpdateDenomDecimalstoProposalUpdateAuctionExchangeTransferDenomDecimalsaligns with the proto definition changes and provides clearer naming.Also applies to: 48-48
689-730: LGTM! Proposal type rename properly implemented.The rename from
UpdateDenomDecimalsProposaltoUpdateAuctionExchangeTransferDenomDecimalsProposalhas been completely and correctly applied across:
- Constructor function
- Type assertion
- All interface method implementations (GetTitle, GetDescription, ProposalRoute, ProposalType, ValidateBasic)
The validation logic remains unchanged, which is appropriate for a naming refactor.
458-499: LGTM! OpenNotionalCap properly integrated into DerivativeMarketParamUpdateProposal.The
OpenNotionalCapfield has been correctly added to the proposal with:
- Constructor parameter and initialization
- Proper nil-check in ValidateBasic (since it's optional for updates)
- Validation using
ValidateOpenNotionalCapfunction from params.go- Appropriate error wrapping with
types.ErrInvalidOpenNotionalCapBased on learnings
Also applies to: 524-592
817-919: LGTM! OpenNotionalCap consistently integrated across all market proposals.The
OpenNotionalCapfield has been properly added to:
- PerpetualMarketLaunchProposal (required, validated)
- ExpiryFuturesMarketLaunchProposal (required, validated)
- BinaryOptionsMarketLaunchProposal (validated)
- BinaryOptionsMarketParamUpdateProposal (optional, validated when provided)
All implementations use consistent validation via
ValidateOpenNotionalCapand proper error wrapping. The distinction between required (launch) and optional (update) is correctly enforced.Based on learnings
Also applies to: 921-1027, 1656-1658, 1663-1833
| _ sdk.Msg = &MsgIncreasePositionMargin{} | ||
| _ sdk.Msg = &MsgDecreasePositionMargin{} | ||
| _ sdk.Msg = &MsgLiquidatePosition{} | ||
| _ sdk.Msg = &MsgOffsetPosition{} |
There was a problem hiding this comment.
MsgOffsetPosition added — normalize hex and use hex-aware duplicate checks
Validation looks solid. Two gaps:
- Case-insensitive hex: equality uses raw strings; “0xABC..” vs “0xabc..” can bypass self-check.
- Duplicates: uses plain HasDuplicates; hex casing can hide dupes.
Recommend normalizing via common.HexToHash and using types.HasDuplicatesHexHash.
Apply this diff inside ValidateBasic:
@@
- if len(msg.OffsettingSubaccountIds) == 0 {
+ if len(msg.OffsettingSubaccountIds) == 0 {
return errors.Wrap(types.ErrOffsettingSubaccountIDsEmpty, "at least one offsetting subaccount ID must be provided")
}
- for _, subaccountID := range msg.OffsettingSubaccountIds {
+ orig := common.HexToHash(msg.SubaccountId)
+ for _, subaccountID := range msg.OffsettingSubaccountIds {
if _, ok := types.IsValidSubaccountID(subaccountID); !ok {
return errors.Wrap(types.ErrBadSubaccountID, subaccountID)
}
- if subaccountID == msg.SubaccountId {
+ if common.HexToHash(subaccountID) == orig {
return errors.Wrap(types.ErrBadSubaccountID, "offsetting subaccount ID cannot be the same as the original subaccount ID")
}
}
- if types.HasDuplicates(msg.OffsettingSubaccountIds) {
+ if types.HasDuplicatesHexHash(msg.OffsettingSubaccountIds) {
return errors.Wrap(types.ErrBadSubaccountID, "message contains duplicate offsetting subaccount IDs")
}Also applies to: 92-92, 1861-1916
🤖 Prompt for AI Agents
In chain/exchange/types/v2/msgs.go around lines 38 (and also apply same change
at lines 92 and 1861-1916), MsgOffsetPosition ValidateBasic currently compares
raw hex strings and uses plain HasDuplicates which is case-sensitive; normalize
hex strings by converting address/hex fields to canonical form using
common.HexToHash (or equivalent hex-normalizer) before equality checks and
replace types.HasDuplicates with types.HasDuplicatesHexHash (or the hex-aware
duplicate checker) so duplicate detection and self-checks become
case-insensitive and consistent. Ensure you normalize each hex field once at the
start of ValidateBasic, use the normalized values for comparisons and for the
duplicate-checking helper, and update any variable names/comments accordingly.
| OpenNotionalCap: exchangev2types.OpenNotionalCap{ | ||
| Cap: &exchangev2types.OpenNotionalCap_Uncapped{}, | ||
| }, |
There was a problem hiding this comment.
Verify the OpenNotionalCap initialization pattern.
Similar to the example files, this initialization may need to populate the inner Uncapped field:
OpenNotionalCap: exchangev2types.OpenNotionalCap{
- Cap: &exchangev2types.OpenNotionalCap_Uncapped{},
+ Cap: &exchangev2types.OpenNotionalCap_Uncapped{
+ Uncapped: &exchangev2types.OpenNotionalCapUncapped{},
+ },
},📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| OpenNotionalCap: exchangev2types.OpenNotionalCap{ | |
| Cap: &exchangev2types.OpenNotionalCap_Uncapped{}, | |
| }, | |
| OpenNotionalCap: exchangev2types.OpenNotionalCap{ | |
| Cap: &exchangev2types.OpenNotionalCap_Uncapped{ | |
| Uncapped: &exchangev2types.OpenNotionalCapUncapped{}, | |
| }, | |
| }, |
🤖 Prompt for AI Agents
In client/chain/markets_assistant_test_support.go around lines 190–192, the
OpenNotionalCap is set to an OpenNotionalCap_Uncapped value but the inner
Uncapped field is not initialized; change the initialization so Cap points to an
OpenNotionalCap_Uncapped that has its Uncapped field populated with a new
Uncapped struct instance (i.e., construct the OpenNotionalCap_Uncapped wrapper
and set its Uncapped member to a freshly allocated Uncapped value).
| OpenNotionalCap: exchangev2types.OpenNotionalCap{ | ||
| Cap: &exchangev2types.OpenNotionalCap_Uncapped{}, | ||
| }, |
There was a problem hiding this comment.
Verify the OpenNotionalCap initialization pattern.
Similar to the example files, this initialization may need to populate the inner Uncapped field:
OpenNotionalCap: exchangev2types.OpenNotionalCap{
- Cap: &exchangev2types.OpenNotionalCap_Uncapped{},
+ Cap: &exchangev2types.OpenNotionalCap_Uncapped{
+ Uncapped: &exchangev2types.OpenNotionalCapUncapped{},
+ },
},📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| OpenNotionalCap: exchangev2types.OpenNotionalCap{ | |
| Cap: &exchangev2types.OpenNotionalCap_Uncapped{}, | |
| }, | |
| OpenNotionalCap: exchangev2types.OpenNotionalCap{ | |
| Cap: &exchangev2types.OpenNotionalCap_Uncapped{ | |
| Uncapped: &exchangev2types.OpenNotionalCapUncapped{}, | |
| }, | |
| }, |
🤖 Prompt for AI Agents
In client/chain/markets_assistant_test_support.go around lines 219 to 221, the
OpenNotionalCap construction uses the oneof variant directly but does not
populate the inner Uncapped field; change the initialization to construct the
OpenNotionalCap message and set its Uncapped field to a new
OpenNotionalCap_Uncapped instance (i.e., assign the Uncapped field on the parent
struct instead of only referencing the variant type) so the protobuf oneof is
populated correctly.
| OpenNotionalCap: exchangev2types.OpenNotionalCap{ | ||
| Cap: &exchangev2types.OpenNotionalCap_Uncapped{}, | ||
| }, |
There was a problem hiding this comment.
🧩 Analysis chain
Verify the OpenNotionalCap initialization pattern.
The initialization appears to set Cap: &OpenNotionalCap_Uncapped{} without populating the inner Uncapped field. Based on the proto definition, the correct pattern should be:
OpenNotionalCap: exchangev2types.OpenNotionalCap{
- Cap: &exchangev2types.OpenNotionalCap_Uncapped{},
+ Cap: &exchangev2types.OpenNotionalCap_Uncapped{
+ Uncapped: &exchangev2types.OpenNotionalCapUncapped{},
+ },
},This ensures the oneof wrapper correctly references the inner message, even though OpenNotionalCapUncapped has no fields.
Run the following script to check how OpenNotionalCap_Uncapped is initialized elsewhere in the codebase:
🏁 Script executed:
#!/bin/bash
# Search for OpenNotionalCap_Uncapped initialization patterns
rg -A2 'OpenNotionalCap_Uncapped\{' --type=goLength of output: 1613
---
🏁 Script executed:
```shell
#!/bin/bash
# Find proto definitions for OpenNotionalCap
fd -e proto -type f | xargs rg -l 'OpenNotionalCap' | head -5
Length of output: 432
🏁 Script executed:
#!/bin/bash
# Search for the proto definition structure
rg -A5 'message OpenNotionalCap\b' --type=protoLength of output: 29
🏁 Script executed:
#!/bin/bash
# Check for OpenNotionalCapUncapped message definition
rg -A3 'message OpenNotionalCapUncapped' --type=protoLength of output: 29
🏁 Script executed:
#!/bin/bash
# Search for how OpenNotionalCap_Uncapped is used in actual code (not just initialization)
rg -B3 -A3 'OpenNotionalCap_Uncapped' --type=go | grep -A3 -B3 'GetCap\|\.Cap\s*=' | head -20Length of output: 1171
🏁 Script executed:
#!/bin/bash
# Check if there are any marshal/unmarshal tests that show the pattern
rg -B2 -A2 'OpenNotionalCap_Uncapped' client/chain/markets_assistant_test_support.goLength of output: 283
---
🏁 Script executed:
```shell
#!/bin/bash
# Read the proto definition for OpenNotionalCap
cat proto/injective/exchange/v2/market.proto | grep -A15 'message OpenNotionalCap'
Length of output: 821
🏁 Script executed:
#!/bin/bash
# Read the proto definition for OpenNotionalCapUncapped
cat proto/injective/exchange/v2/market.proto | grep -A5 'message OpenNotionalCapUncapped'Length of output: 212
🏁 Script executed:
#!/bin/bash
# Check if the example code actually compiles/is used in tests
rg -l 'OpenNotionalCap_Uncapped' --type=go | xargs grep -l '_test.go' | head -3Length of output: 0
🏁 Script executed:
#!/bin/bash
# Look at the generated Go code structure for OpenNotionalCap_Uncapped
rg -A10 'type OpenNotionalCap_Uncapped struct' chain/exchange/types/v2/market.pb.goLength of output: 478
---
🏁 Script executed:
```shell
#!/bin/bash
# Search for tests that use or validate OpenNotionalCap
rg -l 'OpenNotionalCap' --type=go | xargs grep -l 'test\|Test\|_test.go' | head -5
Length of output: 315
🏁 Script executed:
#!/bin/bash
# Check if there's any marshaling/serialization of OpenNotionalCap in tests
rg -B3 -A3 'Marshal.*OpenNotionalCap|OpenNotionalCap.*Marshal' --type=go | head -30Length of output: 2021
🏁 Script executed:
#!/bin/bash
# Search for how OpenNotionalCap_Capped is initialized to compare patterns
rg -A2 'OpenNotionalCap_Capped\{' --type=go | head -20Length of output: 707
---
🏁 Script executed:
```shell
#!/bin/bash
# List all files with the incorrect Uncapped pattern that need fixing
rg 'Cap: &exchangev2types.OpenNotionalCap_Uncapped\{\}' --type=go -l
Length of output: 262
Fix OpenNotionalCap_Uncapped initialization across all affected files.
The review comment correctly identifies an initialization pattern issue. The OpenNotionalCap_Uncapped wrapper struct should initialize its inner Uncapped field with &exchangev2types.OpenNotionalCapUncapped{}, consistent with how OpenNotionalCap_Capped properly initializes its inner Capped field.
Four files require this fix:
- examples/chain/exchange/4_MsgInstantPerpetualMarketLaunch/example.go
- examples/chain/exchange/5_MsgInstantExpiryFuturesMarketLaunch/example.go
- examples/chain/exchange/13_MsgInstantBinaryOptionsMarketLaunch/example.go
- client/chain/markets_assistant_test_support.go
Update each instance from Cap: &exchangev2types.OpenNotionalCap_Uncapped{} to Cap: &exchangev2types.OpenNotionalCap_Uncapped{Uncapped: &exchangev2types.OpenNotionalCapUncapped{}}.
🤖 Prompt for AI Agents
In examples/chain/exchange/4_MsgInstantPerpetualMarketLaunch/example.go (around
lines 86–88) and the other affected files
(examples/chain/exchange/5_MsgInstantExpiryFuturesMarketLaunch/example.go,
examples/chain/exchange/13_MsgInstantBinaryOptionsMarketLaunch/example.go,
client/chain/markets_assistant_test_support.go), the OpenNotionalCap_Uncapped
wrapper is created without initializing its inner Uncapped field; update each
occurrence from Cap: &exchangev2types.OpenNotionalCap_Uncapped{} to Cap:
&exchangev2types.OpenNotionalCap_Uncapped{Uncapped:
&exchangev2types.OpenNotionalCapUncapped{}} so the nested Uncapped struct is
properly instantiated.
| github.com/cometbft/cometbft/api v1.0.0 // indirect | ||
| github.com/consensys/bavard v0.1.30 // indirect | ||
| github.com/consensys/gnark-crypto v0.17.0 // indirect | ||
| github.com/consensys/gnark-crypto v0.18.0 // indirect |
There was a problem hiding this comment.
Blocker: gnark-crypto v0.18.0 carries a HIGH-severity advisory
The newly introduced github.com/consensys/gnark-crypto v0.18.0 release is flagged by GO-2025-4087 / GHSA-fj2x-735w-74vq for unchecked memory allocation during vector deserialization. Please bump to the patched upstream version (or revert to a known-safe revision) before shipping, otherwise we inherit that vulnerability. Based on static analysis hints
🧰 Tools
🪛 OSV Scanner (2.2.4)
[HIGH] 90-90: github.com/consensys/gnark-crypto 0.18.0: Unchecked memory allocation during vector deserialization in github.com/consensys/gnark-crypto
(GO-2025-4087)
[HIGH] 90-90: github.com/consensys/gnark-crypto 0.18.0: gnark-crypto allows unchecked memory allocation during vector deserialization
🤖 Prompt for AI Agents
In go.mod around line 90, the dependency github.com/consensys/gnark-crypto
v0.18.0 is flagged by a HIGH-severity advisory; update the module to a patched
release (or revert to a known-safe commit) by changing the version in go.mod to
the fixed upstream tag, run go get
github.com/consensys/gnark-crypto@<patched-version> (or replace with the safe
pseudo-version/commit), then run go mod tidy (and vendor/update go.sum if
applicable) and run the test suite/CI to verify no regressions.
masterbranchSummary by CodeRabbit
New Features
Improvements