[C-795] update api docs for v1.18.0 chain upgrade#184
Merged
Conversation
…or the websocket API.
📝 WalkthroughWalkthroughThis PR updates documentation and versioning across the Injective ecosystem. Changes include version bumps for SDK and chain components, expanded API schemas with new fields (ForcePaused status, ChainlinkDataStreams oracle type, cumulative funding entries), API signature updates for oracle filtering, error code additions/modifications, permissions module field renames, and new WebSocket endpoint documentation. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~28 minutes This PR spans diverse file types and modules with heterogeneous changes: version bumps (trivial), documentation updates with new field/enum additions (moderate complexity), extensive JSON schema files (repetitive, lower density), API signature changes (requires careful review), and error code reorganization (straightforward data updates). The mix of documentation, schemas, and minor API changes with consistent patterns reduces individual cognitive load, but the breadth and number of files (80+) demands comprehensive coverage. Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
Pull request overview
This pull request updates the API documentation to reflect changes in Injective chain version v1.18.0 and the corresponding indexer version. The main additions include comprehensive Chainlink Data Streams oracle support, EVM hook functionality for the permissions module, market force-pause capabilities, and a new WebSocket API for real-time event streaming.
Changes:
- Added WebSocket API documentation providing a JSON-RPC 2.0 interface over the existing Chain Stream gRPC service
- Updated oracle module to support Chainlink Data Streams with new parameters, types, and error codes
- Extended permissions module with EVM contract hooks alongside existing CosmWasm hooks
- Enhanced exchange module with market force-pause functionality and minimal protocol fee controls
- Added comprehensive RFQ (Request for Quote) API definitions for the indexer
- Deprecated Band oracle with appropriate error messaging
- Updated SDK versions (Python v1.13.0, Go v1.60.0) and all dependency versions
Reviewed changes
Copilot reviewed 90 out of 90 changed files in this pull request and generated 6 comments.
Show a summary per file
| File | Description |
|---|---|
| source/includes/_websocket.md | New WebSocket API documentation with subscribe/unsubscribe patterns and JSON-RPC 2.0 examples |
| source/index.html.md | Added websocket page to documentation index |
| Makefile | Updated all version numbers for v1.18.0 dependencies and SDKs |
| source/includes/_changelog.md | Added changelog entry for v1.18.0 release |
| source/json_tables/injective/oracle/* | Added Chainlink Data Streams types and updated oracle parameters |
| source/json_tables/injective/permissions/* | Renamed contract_hook to wasm_hook, added evm_hook support |
| source/json_tables/injective/exchange/v2/* | Added force pause info, minimal protocol fee flags, and new execution types |
| source/json_tables/indexer/injective_rfqrpc/* | Added complete RFQ API type definitions for market maker functionality |
| source/json_tables/errors/* | Updated error codes for oracle, exchange, permissions, peggy, and erc20 modules; removed deprecated bandoracle module |
| source/includes/_permissions.md | Updated documentation to reflect wasm_hook/evm_hook changes |
| source/includes/_derivatives.md | Added ForcePausedInfo and updated market status codes |
| source/includes/_spot.md | Added has_disabled_minimal_protocol_fee field and ForcePaused market status |
| source/includes/_binaryoptions.md | Added force pause support and updated oracle types |
| source/includes/_oraclerpc.md | Added OracleListRequest parameters for pagination |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Comment on lines
+1
to
+6
| [ | ||
| { | ||
| "Parameter": "price_states", | ||
| "Type": "ChainlinkDataStreamsPriceState array", | ||
| "Description": "" | ||
| } |
There was a problem hiding this comment.
The Description field is empty for all parameters in this new API response type. Consider adding descriptive text for each parameter to help API consumers understand what each field represents, especially for price_states which is an array of ChainlinkDataStreamsPriceState.
Comment on lines
+7
to
21
| { | ||
| "Parameter": "chainlink_verifier_proxy_contract", | ||
| "Type": "string", | ||
| "Description": "" | ||
| }, | ||
| { | ||
| "Parameter": "accept_unverified_chainlink_data_streams_reports", | ||
| "Type": "bool", | ||
| "Description": "" | ||
| }, | ||
| { | ||
| "Parameter": "chainlink_data_streams_verification_gas_limit", | ||
| "Type": "uint64", | ||
| "Description": "" | ||
| } |
There was a problem hiding this comment.
All new Chainlink-related parameters have empty Description fields. These parameters control important Chainlink Data Streams functionality and should have descriptions explaining their purpose. For example, chainlink_verifier_proxy_contract should describe the EVM contract address, accept_unverified_chainlink_data_streams_reports should explain when unverified reports are accepted, and chainlink_data_streams_verification_gas_limit should describe the gas limit for verification operations.
Comment on lines
+1
to
+22
| [ | ||
| { | ||
| "Parameter": "feed_id", | ||
| "Type": "byte array", | ||
| "Description": "" | ||
| }, | ||
| { | ||
| "Parameter": "full_report", | ||
| "Type": "byte array", | ||
| "Description": "" | ||
| }, | ||
| { | ||
| "Parameter": "valid_from_timestamp", | ||
| "Type": "uint64", | ||
| "Description": "" | ||
| }, | ||
| { | ||
| "Parameter": "observations_timestamp", | ||
| "Type": "uint64", | ||
| "Description": "" | ||
| } | ||
| ] |
There was a problem hiding this comment.
All parameters in this new ChainlinkReport type have empty Description fields. Consider adding descriptions for feed_id (the Chainlink feed identifier), full_report (the complete report data), valid_from_timestamp (when the report becomes valid), and observations_timestamp (when observations were made).
Comment on lines
+1
to
+27
| [ | ||
| { | ||
| "Parameter": "feed_id", | ||
| "Type": "string", | ||
| "Description": "" | ||
| }, | ||
| { | ||
| "Parameter": "report_price", | ||
| "Type": "cosmossdk_io_math.Int", | ||
| "Description": "" | ||
| }, | ||
| { | ||
| "Parameter": "valid_from_timestamp", | ||
| "Type": "uint64", | ||
| "Description": "" | ||
| }, | ||
| { | ||
| "Parameter": "observations_timestamp", | ||
| "Type": "uint64", | ||
| "Description": "" | ||
| }, | ||
| { | ||
| "Parameter": "price_state", | ||
| "Type": "PriceState", | ||
| "Description": "" | ||
| } | ||
| ] |
There was a problem hiding this comment.
All parameters in ChainlinkDataStreamsPriceState have empty Description fields. These fields represent important oracle price state information and should have descriptions explaining their purpose (e.g., feed_id for the data stream identifier, report_price for the reported price value, timestamps for validity and observation times, and price_state for the aggregated price state).
Comment on lines
+1
to
+12
| [ | ||
| { | ||
| "Parameter": "reason", | ||
| "Type": "ForcePausedReason", | ||
| "Description": "" | ||
| }, | ||
| { | ||
| "Parameter": "mark_price_at_pausing", | ||
| "Type": "cosmossdk_io_math.LegacyDec", | ||
| "Description": "" | ||
| } | ||
| ] |
There was a problem hiding this comment.
Both parameters in ForcePausedInfo have empty Description fields. Consider adding descriptions for reason (why the market was force paused) and mark_price_at_pausing (the market's mark price at the time of pausing).
Comment on lines
+7
to
+11
| { | ||
| "Parameter": "market", | ||
| "Type": "RFQSettlementMarketActionType", | ||
| "Description": "Market order action" | ||
| } |
There was a problem hiding this comment.
The RFQSettlementUnfilledActionType references a type "RFQSettlementMarketActionType" that does not appear to be defined in any JSON file in the injective_rfqrpc directory. This will likely cause issues when generating documentation or for API consumers trying to understand the structure. Either add the missing RFQSettlementMarketActionType.json file or update the type reference if it's incorrect.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 16
🧹 Nitpick comments (25)
source/json_tables/indexer/injective_rfqrpc/StreamQuoteRequest.json (1)
3-6: Clarify address format and constraints.Consider specifying the expected address format (e.g., bech32 prefix), whether the list can be empty, and any max length/limits for the array to avoid ambiguity for API consumers.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@source/json_tables/indexer/injective_rfqrpc/StreamQuoteRequest.json` around lines 3 - 6, Update the StreamQuoteRequest.json entry for the "addresses" parameter to explicitly define expected format and constraints: clarify that "addresses" is an array of strings (bech32 or other prefix — specify which), whether empty arrays are allowed (e.g., "minItems": 1 or "minItems": 0), maximum items (e.g., "maxItems": 100), any per-item length or regex pattern (e.g., bech32 regex) and uniqueness requirement (e.g., "uniqueItems": true), and include an example address or array to illustrate; update the "Description" to mention the required address format and limits and add JSON Schema-like keys ("items", "pattern"/"format", "minItems", "maxItems", "uniqueItems", "example") so API consumers know exactly what to send.source/json_tables/indexer/injective_auction_rpc/AuctionAccountStatusResponse.json (1)
1-6: Document possiblestatusvalues.If
statusis an enum or has a fixed set of values, please list them (or link to the enum) to make the response actionable for clients.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@source/json_tables/indexer/injective_auction_rpc/AuctionAccountStatusResponse.json` around lines 1 - 6, The JSON schema for AuctionAccountStatusResponse is missing the allowed values for the "status" field; update AuctionAccountStatusResponse.json to document the exact enum (or set of fixed strings) for "status" (e.g., "allowed", "blocked", "pending", etc., use the real enum names from your codebase) or add a link/reference to the canonical enum/type where it's defined so clients know the concrete possible values and their meanings.source/json_tables/indexer/injective_auction_rpc/AuctionAccountStatusRequest.json (1)
1-13: Clarify parameter constraints and address format.Consider tightening the descriptions to indicate any constraints (e.g., non-negative round) and the expected address format to reduce ambiguity for API consumers.
✏️ Possible doc-only tweak
- "Description": "The auction round number", + "Description": "Auction round number (non-negative).", ... - "Description": "Address of account", + "Description": "Account address (specify expected chain address format/encoding).",🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@source/json_tables/indexer/injective_auction_rpc/AuctionAccountStatusRequest.json` around lines 1 - 13, Update the "round" and "address" parameter Descriptions in AuctionAccountStatusRequest.json to specify constraints and expected formats: change "round" to indicate it must be a non-negative int64 (e.g., "non-negative auction round number, 0-based"), and change "address" to state the exact address encoding expected by the API (e.g., "address of account, hex-encoded 20-byte (0x...) or bech32, depending on backend") — replace the generic descriptions for the "round" and "address" entries to include these constraints so consumers know valid values and formats.source/json_tables/indexer/injective_auction_rpc/AuctionContract.json (1)
52-55: Clarify the scope/timing ofis_bid_placed.The description could be read as “ever” vs “current round” or “current auction lifecycle.” Please specify the scope to avoid misinterpretation.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@source/json_tables/indexer/injective_auction_rpc/AuctionContract.json` around lines 52 - 55, Update the "Description" for the Parameter "is_bid_placed" in AuctionContract.json to explicitly state its scope/timing (e.g., whether it indicates a bid placed ever, during the current auction lifecycle, or within the current round). Replace the ambiguous text "Whether any bid has been placed in the auction." with a clear phrase such as "Whether any bid has been placed during the current auction lifecycle (since auction start)" or "Whether any bid has been placed in the current bidding round" depending on the intended semantics of is_bid_placed used by the auction logic.source/json_tables/indexer/injective_megavault_rpc/User.json (1)
17-26: Minor description inconsistency.The descriptions reference "vault" creation/update, but this schema is for the
Usertype. If the user entity is indeed associated with a vault (user's vault position), consider clarifying the descriptions to reflect this relationship, e.g., "Block height when the user's vault position was created."Also, the description style is inconsistent:
created_atuses "CreatedAt timestamp" whilecreated_heightuses "Block height when...". Consider aligning with the existingupdated_at/updated_heightstyle for consistency.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@source/json_tables/indexer/injective_megavault_rpc/User.json` around lines 17 - 26, Update the descriptions for the User schema fields to consistently reference the user’s vault position and align phrasing with the updated_* fields: change the "created_height" description to something like "Block height when the user's vault position was created." and change the "created_at" description to match style (e.g. "Created timestamp in UNIX millis for the user's vault position."). Ensure you update the entries for the Parameters "created_height" and "created_at" in User.json and mirror the same style used by "updated_height"/"updated_at".source/json_tables/injective/oracle/ChainlinkDataStreamsPriceState.json (1)
1-27: Consider adding descriptions for better API documentation.All
Descriptionfields are empty. Adding brief descriptions would improve the documentation value for developers integrating with this API (e.g., explaining whatfeed_idrepresents, the unit/precision ofreport_price, the semantics ofvalid_from_timestampvsobservations_timestamp).🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@source/json_tables/injective/oracle/ChainlinkDataStreamsPriceState.json` around lines 1 - 27, Add concise Description values for each parameter in ChainlinkDataStreamsPriceState.json: explain "feed_id" (e.g., unique identifier for the data feed), "report_price" (units/precision and that it's a cosmossdk_io_math.Int representing the reported price), "valid_from_timestamp" (when the price becomes valid), "observations_timestamp" (time of the underlying observation), and "price_state" (briefly describe the PriceState enum/structure semantics); update the Description fields next to the Parameter names so API docs clearly convey intent and units for feed_id, report_price, valid_from_timestamp, observations_timestamp, and price_state.source/json_tables/injective/exchange/v2/ForcePausedInfo.json (1)
1-12: Consider adding descriptions for better API documentation.Similar to other new schema files, the
Descriptionfields are empty. Brief descriptions would help API consumers understand the purpose ofreasonandmark_price_at_pausing.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@source/json_tables/injective/exchange/v2/ForcePausedInfo.json` around lines 1 - 12, Add concise Description strings for the schema fields so API docs are informative: update the "reason" entry (Type: ForcePausedReason) to describe what triggers the force pause (e.g., enum explaining pause causes), and update "mark_price_at_pausing" (Type: cosmossdk_io_math.LegacyDec) to describe that it records the mark price when the pause was enacted and its units/precision; ensure both descriptions are short, clear sentences suitable for generated docs.source/includes/_websocket.md (1)
10-12: Add language specifier to fenced code block.The code block showing the WebSocket URL path lacks a language specifier, which triggers the MD040 linting warning. Consider adding a language like
textorplaintext.📝 Suggested fix
->``` +>```text ws://<node-address>:<port>/injstream-ws</details> <details> <summary>🤖 Prompt for AI Agents</summary>Verify each finding against the current code and only fix it if needed.
In
@source/includes/_websocket.mdaround lines 10 - 12, Add a language specifier
to the fenced code block containing the WebSocket URL
"ws://:/injstream-ws" (e.g., changetotext oraround that exact string to include the chosen language specifier.source/json_tables/indexer/injective_archiver_rpc/AccountStatsRequest.json (1)
7-13: Consider documenting valid period formats.The
periodparameter description mentions filtering but doesn't specify the expected format or valid values (e.g., "7d", "30d", "1y", or specific format strings). Documenting accepted values would help API consumers use this parameter correctly.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@source/json_tables/indexer/injective_archiver_rpc/AccountStatsRequest.json` around lines 7 - 13, Update the "period" parameter description in AccountStatsRequest.json to list the accepted formats and examples so clients know what to send; for example indicate that "period" accepts relative duration strings like "7d", "30d", "1y" (days/weeks/months/years) and/or ISO 8601 date ranges (e.g., "2025-01-01/2025-01-31") if supported, and clarify whether single values are inclusive/exclusive and default behavior. Ensure the revised Description text next to "Parameter": "period" explicitly states the allowed formats, example values, and any defaults or validation rules.source/json_tables/injective/oracle/ChainlinkReport.json (1)
1-21: Consider filling in parameter descriptions for clarity.Empty descriptions make the rendered docs hard to use; even short, one-line explanations would help.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@source/json_tables/injective/oracle/ChainlinkReport.json` around lines 1 - 21, Add concise one-line descriptions for each parameter in the ChainlinkReport JSON entry so the rendered docs are clear: provide a short purpose for "feed_id" (e.g., identifier of the data feed), "full_report" (e.g., serialized report payload or signer observations), "valid_from_timestamp" (e.g., epoch time from which the report is valid), and "observations_timestamp" (e.g., epoch time when observations were recorded); update the "Description" fields for feed_id, full_report, valid_from_timestamp, and observations_timestamp accordingly in the ChainlinkReport JSON.source/json_tables/indexer/injective_rfqrpc/CreateRFQRequestType.json (1)
1-62: Clarify if this schema represents a client request or a data type definition.This schema includes server-assigned fields like
rfq_id,status,created_at,updated_at,transaction_time, andheight, which are typically not provided by clients during creation. If this is intended as a full data type definition (rather than a client-facing create request), the namingCreateRFQRequestTypemay be misleading. Consider either:
- Renaming to reflect it's a data transfer object (e.g.,
RFQType), or- Removing server-assigned fields if this is meant to be a client request schema
The schema is also missing
request_addresscompared toRFQRequestType.json, which is expected if the address is derived from authentication context.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@source/json_tables/indexer/injective_rfqrpc/CreateRFQRequestType.json` around lines 1 - 62, The schema in CreateRFQRequestType.json currently mixes client-supplied and server-assigned fields (rfq_id, status, created_at, updated_at, transaction_time, height), which is misleading for a "Create" request; either rename the type to RFQType/DT O to represent the full data model or remove the server-assigned fields so the create request only includes client-provided fields (market_id, direction, margin, quantity, worst_price, expiry and any auth-derived request_address). Also ensure request_address is either added (if clients supply it) or explicitly omitted/derived from auth to match RFQRequestType.json expectations. Make the change in CreateRFQRequestType.json and update any references to CreateRFQRequestType to the new name if you rename it.source/includes/_derivatives.md (3)
1425-1428: Consider a clearer deprecation callout forexpiration_twap_start_price_cumulative.The deprecation note is very long inside a table cell; it’s hard to scan. Suggest moving the explanation to a dedicated “Deprecated” note beneath the table and keep the cell concise (e.g., “Deprecated; see note below”).
Also applies to: 1778-1781, 3133-3136
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@source/includes/_derivatives.md` around lines 1425 - 1428, Shorten the long deprecation text inside the table cell for expiration_twap_start_price_cumulative to a concise marker like "Deprecated; see note below", and add a separate "Deprecated" note immediately beneath the table that explains the full rationale and lists the replacement fields expiration_twap_start_base_cumulative_price and expiration_twap_start_quote_cumulative_price; apply the same change to the other occurrences of expiration_twap_start_price_cumulative noted in the comment so each table cell is concise and the full explanation lives in a single, well-formatted note below the respective tables.
4125-4127: Add a short note explaining string-basedDecimalliterals.Since multiple examples now use
Decimal("..."), consider a one-line note near the first snippet explaining that string literals avoid float precision issues. It’ll help readers copy the pattern consistently.Also applies to: 4433-4435, 5041-5044, 5064-5067, 5529-5534, 6627-6630, 6760-6763
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@source/includes/_derivatives.md` around lines 4125 - 4127, Add a one-line explanatory note near the first code snippet that uses Decimal("...") (the snippet containing price=Decimal("50000"), quantity=Decimal("0.1"), margin=Decimal("5000")) stating that Decimal should be constructed from string literals to avoid float precision issues and to encourage copying the pattern; then apply the same single-line note to the other places in the document that use Decimal("...") so they consistently document using string-based Decimal literals.
1456-1461: Add field descriptions forForcePausedInfofields.Both
reasonandmark_price_at_pausingare blank in the table, which makes the new ForcePaused docs hard to interpret. Please add short descriptions (e.g., why paused, and whether mark price is in human-readable units).Also applies to: 1809-1814
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@source/includes/_derivatives.md` around lines 1456 - 1461, Update the ForcePausedInfo field docs in the JSON source for ForcePausedInfo (the JSON used by the JSON_TO_HTML_TABLE generator) to include short descriptions: set "reason" to a brief note like "Reason the market was force-paused (enum ForcePausedReason, e.g., emergency, maintenance)." and set "mark_price_at_pausing" to something like "Mark price at the time of pausing as a human-readable decimal (cosmossdk_io_math.LegacyDec) representing the asset price." Ensure these descriptions are added to the ForcePausedInfo.json entries for the reason and mark_price_at_pausing fields so the generated table shows them.source/json_tables/injective/oracle/Params.json (1)
6-21: LGTM!The new Chainlink Data Streams configuration parameters are properly structured with appropriate types. The empty descriptions are consistent with the existing
pyth_contractentry in this file.Optional: Consider adding descriptions for better documentation.
While empty descriptions are consistent with the existing pattern in this file, adding brief descriptions would improve the API documentation quality for these new Chainlink parameters.
📝 Suggested descriptions
{ "Parameter": "chainlink_verifier_proxy_contract", "Type": "string", - "Description": "" + "Description": "Contract address for Chainlink verifier proxy" }, { "Parameter": "accept_unverified_chainlink_data_streams_reports", "Type": "bool", - "Description": "" + "Description": "Whether to accept unverified Chainlink data streams reports" }, { "Parameter": "chainlink_data_streams_verification_gas_limit", "Type": "uint64", - "Description": "" + "Description": "Gas limit for Chainlink data streams verification" }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@source/json_tables/injective/oracle/Params.json` around lines 6 - 21, Add brief human-readable descriptions for the new Chainlink Data Streams parameters to improve documentation: update the JSON entries for "chainlink_verifier_proxy_contract", "accept_unverified_chainlink_data_streams_reports", and "chainlink_data_streams_verification_gas_limit" by populating their "Description" fields with short explanatory text describing the purpose and expected values (e.g., that the first is the verifier proxy contract address, the second toggles acceptance of unverified reports, and the third sets the gas limit used during verification).source/json_tables/errors/permissions_errors.json (1)
53-85: Standardize hook terminology and ERC20 casing.Line 55 uses “contract hook” while Lines 65/80 use “wasm/evm hook.” If “contract hook” is the umbrella term, consider aligning the other descriptions or adding a clarifying phrase. Also, Line 85 should use “ERC20” for consistency.
📘 Suggested wording tweaks
- "description": "invalid erc20 denom" + "description": "invalid ERC20 denom"🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@source/json_tables/errors/permissions_errors.json` around lines 53 - 85, Update the "description" fields to use consistent hook terminology and ERC20 casing: change the entry with error_code 12 to a clear umbrella term like "contract hook query error", change error_code 14 to "contract hook (wasm) error" and error_code 17 to "contract hook (evm) error" so all hook types use the same "contract hook" phrasing, and change error_code 18's description to use "ERC20" capitalized (e.g., "invalid ERC20 denom"); locate these by the unique error_code values (12, 14, 17, 18) in the permissions module and update their description strings accordingly.source/json_tables/indexer/injective_rfqrpc/StreamRequestRequest.json (1)
1-7: Consider documenting non-empty constraints formarket_ids.If the server expects at least one market ID, add a short note in the description to avoid ambiguous usage.
📝 Example clarification
- "Description": "Filter by market IDs", + "Description": "Filter by market IDs (at least one required)",🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@source/json_tables/indexer/injective_rfqrpc/StreamRequestRequest.json` around lines 1 - 7, Update the "market_ids" parameter documentation in StreamRequestRequest.json to state the non-empty constraint and expected behavior when empty; specifically, change the "Description" for "market_ids" to include a short note such as "Filter by market IDs (must contain at least one ID)" and, if applicable, mention server response on empty input (e.g., rejected/400 or treated as no-filter). Keep the parameter name "market_ids" and the file StreamRequestRequest.json as the target for this edit.source/json_tables/indexer/injective_rfqrpc/StreamError.json (1)
1-7: Consider adding an error message field.The
StreamErrortype only includes an errorcode. For better debugging and user experience, consider adding amessagefield for human-readable error descriptions.💡 Optional enhancement
[ { "Parameter": "code", "Type": "string", "Description": "Error code" + }, + { + "Parameter": "message", + "Type": "string", + "Description": "Human-readable error message" } ]🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@source/json_tables/indexer/injective_rfqrpc/StreamError.json` around lines 1 - 7, The StreamError JSON schema currently only defines a "code" string; add a new "message" string property to the StreamError type (e.g., "message": "Human-readable error description") so clients receive a readable error explanation; update any validators, constructors or code paths that create StreamError objects to populate the new message field and ensure schema consumers (parsers/serializers) accept the additional property.source/includes/_permissions.md (1)
3464-3469: Consider adding EvmHook to the Go MsgUpdateNamespace sample (or note it’s optional).
Python sample includes evm_hook; the Go sample only shows WasmHook, which may look inconsistent.Also applies to: 3593-3597
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@source/includes/_permissions.md` around lines 3464 - 3469, Update the Go sample for MsgUpdateNamespace to either include the EvmHook field or explicitly document it as optional; locate the MsgUpdateNamespace construction (fields like wasm_hook="...", role_permissions, role_managers, policy_statuses, policy_manager_capabilities) and add evm_hook="" (or an example value) to mirror the Python sample, or add a short comment in the Go snippet stating that EvmHook is optional so the examples are consistent.source/json_tables/injective/exchange/v2/SpotMarketParamUpdateProposal.json (1)
71-75: Call out DisableMinimalProtocolFeeUpdate semantics in the description.
The name reads like a bool, but the type is a structured update. A short hint will prevent confusion.💡 Suggested description tweak
- "Description": "has_disabled_minimal_protocol_fee defines whether the minimal protocol fee is disabled for the market" + "Description": "has_disabled_minimal_protocol_fee defines whether the minimal protocol fee is disabled for the market (see DisableMinimalProtocolFeeUpdate for accepted values)"🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@source/json_tables/injective/exchange/v2/SpotMarketParamUpdateProposal.json` around lines 71 - 75, The description for the "has_disabled_minimal_protocol_fee" parameter is ambiguous because the Type is a structured update "DisableMinimalProtocolFeeUpdate" rather than a simple bool; update the Description in SpotMarketParamUpdateProposal to explicitly state that DisableMinimalProtocolFeeUpdate is a structured patch (e.g., contains fields to enable/disable or set metadata) and not just a boolean flag, briefly listing the semantic effect (what fields/actions the update supports) so readers know to inspect DisableMinimalProtocolFeeUpdate for details.source/json_tables/indexer/injective_rfqrpc/MakerStreamResponse.json (1)
1-21: Clarify which payload field is set for each message_type.
Without a “oneof” note, it’s unclear which of request/quote_ack/error is expected per message.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@source/json_tables/indexer/injective_rfqrpc/MakerStreamResponse.json` around lines 1 - 21, The schema currently lists message_type and payload fields (request, quote_ack, error) but doesn't state which payload is present for each message_type; update the JSON docs for MakerStreamResponse to include a "oneof" mapping that explicitly ties message_type values to the corresponding payload fields (e.g., message_type 'request' -> request (RFQRequestType); 'quote_ack' -> quote_ack (StreamAck); 'error' -> error (StreamError); 'pong' -> no payload), and adjust the Description text for message_type and each payload field to note that only the indicated field is populated for that message_type.source/json_tables/indexer/injective_rfqrpc/RFQSettlementType.json (1)
53-71: Specify timestamp units (e.g., seconds vs nanoseconds).
Clarifying units for transaction_time / event_time / created_at / updated_at prevents client-side misinterpretation.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@source/json_tables/indexer/injective_rfqrpc/RFQSettlementType.json` around lines 53 - 71, Update the timestamp field descriptions to explicitly state their units (e.g., seconds since epoch, milliseconds, or nanoseconds) for transaction_time, event_time, created_at, and updated_at in RFQSettlementType.json; modify each "Description" value to include the unit (for example "Transaction time timestamp in seconds since Unix epoch") and, if your system uses a specific precision, also note that precision (e.g., "nanoseconds") so clients can unambiguously parse the values.source/json_tables/injective/permissions/Params.json (1)
3-10: Clarify enforced_restrictions_contracts wording to avoid a double‑negative.
“will not bypass” can be read as either exempt or restricted. Consider “cannot bypass” for unambiguous intent.💡 Suggested wording tweak
- "Description": "EVM addresses of contracts that will not bypass module-to-module transfers" + "Description": "EVM addresses of contracts that cannot bypass module-to-module transfers"🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@source/json_tables/injective/permissions/Params.json` around lines 3 - 10, Update the Description for the Parameter "enforced_restrictions_contracts" to remove the double-negative ambiguity by replacing "will not bypass module-to-module transfers" with a clearer phrase such as "cannot bypass module-to-module transfers" so the intent is unambiguous; locate the entry for the "enforced_restrictions_contracts" Parameter in Params.json and edit its Description accordingly (ensure punctuation and capitalization remain consistent with other entries).source/json_tables/injective/permissions/MsgUpdateNamespace.json (1)
15-18: Align hook descriptions with the “cosmwasm” wording used elsewhere.
Keeps terminology consistent across Namespace/MsgUpdateNamespace docs.💡 Suggested wording tweak
- "Description": "address of wasm smart contract to apply code-based restrictions", + "Description": "address of cosmwasm contract to apply code-based restrictions", ... - "Description": "address of EVM smart contract to apply code-based restrictions", + "Description": "address of EVM smart contract to apply code-based restrictions",Also applies to: 44-48
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@source/json_tables/injective/permissions/MsgUpdateNamespace.json` around lines 15 - 18, Update the Description for the "wasm_hook" parameter (Type: MsgUpdateNamespace_SetContractHook) in MsgUpdateNamespace to use the same "cosmwasm" wording as elsewhere: replace "address of wasm smart contract to apply code-based restrictions" with "address of cosmwasm smart contract to apply code-based restrictions"; apply the same exact change to the other occurrence (the second block at lines ~44-48) so both descriptions are consistent.source/includes/_errors.md (1)
248-248: Consider using formal language in error descriptions.The description "can't charge denom creation fee" uses informal contraction. For consistency with other error messages in the codebase, consider using "cannot charge denom creation fee" instead.
📝 Suggested improvement
-<tr ><td class="module-name-td td_text">erc20</td><td class="error-code-td td_num">12</td><td class="description-td td_text">can't charge denom creation fee</td></tr></tbody></table> +<tr ><td class="module-name-td td_text">erc20</td><td class="error-code-td td_num">12</td><td class="description-td td_text">cannot charge denom creation fee</td></tr></tbody></table>🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@source/includes/_errors.md` at line 248, Update the error description for module "erc20" with error code 12 to use formal wording; replace the informal "can't charge denom creation fee" with "cannot charge denom creation fee" in the error definitions (look for the table row containing module-name "erc20" and error-code "12" in the error registry or source/includes/_errors.md and update the description text).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@Makefile`:
- Around line 2-24: The Makefile sets INJECTIVE_CORE_VERSION and INDEXER_VERSION
but those tags couldn't be verified; check the INJECTIVE_CORE_REPO and
INDEXER_REPO for the presence of tags INJECTIVE_CORE_VERSION (v1.18.0) and
INDEXER_VERSION (v1.18.3), correct the repository URLs if they point to the
wrong remotes, or update the version constants (INJECTIVE_CORE_VERSION /
INDEXER_VERSION) to valid tags found in their repos, and then re-run tag
verification before merging.
In `@source/includes/_binaryoptions.md`:
- Around line 197-199: Update the BinaryOptionsMarkets response examples to
include the newly documented fields so the examples match the schema: add
open_notional_cap (either a representative OpenNotionalCap object or null),
has_disabled_minimal_protocol_fee (e.g., false), and force_paused_info (e.g.,
null) in each example block for BinaryOptionsMarkets; ensure the field names
exactly match open_notional_cap, has_disabled_minimal_protocol_fee, and
force_paused_info and mirror the types described in the docs so examples at the
original location and the repeated block around lines 262-275 stay consistent.
In `@source/includes/_changelog.md`:
- Around line 3-7: The changelog header "## 2026-02-19" may be incorrect if the
release isn't scheduled for that exact date; update the heading to the correct
release date or replace it with "## Unreleased" to avoid confusion, and ensure
the block that lists chain v1.18.0 changes, websocket docs, and SDK versions
remains under the updated heading (look for the heading string "## 2026-02-19"
to locate and change it).
In `@source/includes/_oraclerpc.md`:
- Around line 74-77: The table currently marks symbol, oracle_type, per_page,
and token as Required: Yes but the Go example shows token passed as an empty
string and per_page as 0, implying pagination params are optional; update the
docs to mark per_page and token as Optional (keep symbol and oracle_type as
Required) and add a brief note near the Go example clarifying that passing
token="" or per_page=0 disables pagination/defaults to server behavior so users
aren’t confused. Reference the parameter names per_page and token and the
existing Go example that passes ""/0 when making the change.
- Around line 82-87: Remove the stray Coin schema block from the OracleList
endpoint docs: locate the auto-generated Coin JSON_TO_HTML_TABLE block (the
section documenting the "Coin" schema) that appears inside the OracleList
documentation and delete that entire MARKDOWN-AUTO-DOCS block so
OracleListRequest and OracleListResponse no longer show an unused Coin schema;
leave the Coin schema in place elsewhere if it is referenced by other endpoint
fields.
- Around line 58-62: The examples for GetOracleList contradict the parameter
table: either mark token and per_page as optional in the docs or update the
examples to pass real required values; fix by updating the parameter table to
set token and per_page as Optional (not Required) or change the Go call to
exchangeClient.GetOracleList(ctx, symbol, oracleType, "your-token", 100) and the
Python example to include token and per_page parameters so they match the
documented required fields; reference the GetOracleList invocation and the
parameters symbol, oracle_type (oracleType), token and per_page when making the
change.
In `@source/includes/_permissions.md`:
- Around line 2854-2855: Update the PermissionsModuleState response example to
replace the old field name wasm_hook_query_max_gas with contract_hook_max_gas so
it matches the updated Params schema; locate the PermissionsModuleState example
in source/includes/_permissions.md and change the response JSON/YAML example key
and any corresponding descriptive text to use contract_hook_max_gas (keeping the
same uint64 value and description "Max amount of gas allowed for contract hook
queries") and ensure enforced_restrictions_contracts remains as the string array
example.
In `@source/includes/_spot.md`:
- Around line 314-315: Update the JSON response examples for SpotMarkets,
SpotMarket, and FullSpotMarkets to include the new boolean field
has_disabled_minimal_protocol_fee (e.g., "has_disabled_minimal_protocol_fee":
false) so the example payloads match the schema table; ensure the field is added
to every example object that represents a market and kept consistent with
quote_decimals and other market fields.
In
`@source/json_tables/indexer/injective_megavault_rpc/OperationStatusLogEntry.json`:
- Around line 3-6: Update the "Description" for the "status" parameter in
OperationStatusLogEntry.json to use neutral wording (remove the word
"subscription") so it applies to both subscriptions and redemptions; modify the
entry where "Parameter": "status" (and its "Type": "string") to a generic phrase
such as "Current status of the operation at this log entry" to replace the
subscription-specific description.
In `@source/json_tables/indexer/injective_oracle_rpc/OracleListRequest.json`:
- Around line 15-25: Update the OracleListRequest JSON so that the pagination
fields are optional: change the "Required": "Yes" entry for both "per_page" and
"token" to "No" (or remove the Required field) and ensure their Description
notes that token defaults to an empty string for first-page requests and
per_page is optional with a sensible default; modify the entries for the
"Parameter": "per_page" and "Parameter": "token" objects accordingly so SDKs and
docs align.
In
`@source/json_tables/indexer/injective_rfqrpc/MakerStreamStreamingRequest.json`:
- Around line 1-13: The "quote" parameter is currently marked as "Required: No"
which is ambiguous; update the documentation for the "quote" parameter
(Parameter: "quote") to state that it is required when "message_type" equals
'quote' (e.g., change the Required field to "Conditional" or update the
Description to "Required when message_type == 'quote'") so clients know to
include quote only for message_type 'quote'.
In `@source/json_tables/indexer/injective_rfqrpc/TakerStreamResponse.json`:
- Around line 1-21: The current JSON schema lists fields message_type, quote,
request_ack, and error but doesn't state which fields are present for each
message_type; update the documentation for TakerStreamResponse to explicitly map
message_type values ('quote', 'request_ack', 'error', 'pong') to which payload
field is populated (e.g., when message_type == 'quote' include RFQQuoteType in
quote; when message_type == 'request_ack' include StreamAck in request_ack; when
message_type == 'error' include StreamError in error; 'pong' has no payload),
and add a note that non-matching fields will be omitted or null so clients know
which fields to expect.
In
`@source/json_tables/indexer/injective_rfqrpc/TakerStreamStreamingRequest.json`:
- Around line 1-13: Update the JSON schema docs so the "request" field (Type:
CreateRFQRequestType) is marked as conditionally required when "message_type"
equals 'request' — modify the "Required" value for "request" to indicate "Yes
when message_type == 'request' (otherwise No)" and update the Description to
state "RFQ request to create; required when message_type is 'request'." Ensure
you reference the "message_type" and "request" entries so readers clearly see
the conditional requirement.
In `@source/json_tables/injective/exchange/v2/ExpiryFuturesMarketInfo.json`:
- Around line 18-20: The Description for the parameter
expiration_twap_start_price_cumulative is a long single sentence; split the
deprecation note into a second sentence (or insert a line break after
"Deprecated:") and rephrase for clarity—e.g., keep the first sentence describing
what the field defines and then start a new sentence "Deprecated: For correctly
calculating the expiration price using TWAP, keep separate cumulative prices for
the base and quote assets; use expiration_twap_start_base_cumulative_price and
expiration_twap_start_quote_cumulative_price instead." Update the Description
string accordingly in the JSON entry for expiration_twap_start_price_cumulative.
In `@source/json_tables/injective/exchange/v2/Params.json`:
- Around line 172-176: Update the Description for the parameter
enforced_restrictions_contracts to fix the typo "erc20: denoms" — replace the
misplaced colon and normalize casing (e.g., use "ERC-20 denoms" or "erc20
denoms") so the description reads clearly that these are market-denominated
ERC-20 denoms the exchange listens to; modify the Description string in
Params.json accordingly.
In
`@source/json_tables/injective/oracle/QueryChainlinkDataStreamsPriceStatesResponse.json`:
- Around line 1-6: The response schema's "price_states" field is missing a
description; update the "price_states" entry in
QueryChainlinkDataStreamsPriceStatesResponse.json to include a concise
description such as: "Array of ChainlinkDataStreamsPriceState objects
representing the current/latest price state for each data stream/feed (includes
price, timestamp, and related metadata)"; ensure the description is added to the
"Description" property for the "price_states" parameter so consumers understand
the contents and purpose of the array.
---
Duplicate comments:
In `@source/includes/_derivativesrpc.md`:
- Around line 3088-3090: Update the mirrored parameters in the derivatives RPC
table to ensure consistency: verify the three parameter entries funding_sum,
cumulative_funding_entry, and effective_cumulative_funding_entry are present
with type "string" and their descriptions match the original source ("Net
funding fees since position opened", "Cumulative funding entry of the position",
"Effective cumulative funding entry of the position"); correct any typos or
mismatched wording so the mirrored table exactly matches the original table
entries.
- Around line 2769-2771: There are duplicated/mirrored table rows for the
parameters funding_sum, cumulative_funding_entry, and
effective_cumulative_funding_entry; remove the duplicate block so each parameter
appears only once (or if mirroring is intentional, replace the duplicate with a
clear "mirrored" note), and ensure the remaining entries for funding_sum,
cumulative_funding_entry, and effective_cumulative_funding_entry retain the
exact description text ("Net funding fees since position opened", "Cumulative
funding entry of the position", "Effective cumulative funding entry of the
position") to keep docs consistent.
In `@source/includes/_permissions.md`:
- Around line 3625-3630: The descriptions for wasm_hook and evm_hook are
inconsistent with the wording used in MsgUpdateNamespace.json; update the
description text for the parameters named wasm_hook and evm_hook (type
MsgUpdateNamespace_SetContractHook) so they match the same phrasing used in
MsgUpdateNamespace.json (use the exact same sentence structure and terminology
for "smart contract" and "apply code-based restrictions"), ensuring both entries
use identical wording and punctuation as the MsgUpdateNamespace.json reference.
---
Nitpick comments:
In `@source/includes/_derivatives.md`:
- Around line 1425-1428: Shorten the long deprecation text inside the table cell
for expiration_twap_start_price_cumulative to a concise marker like "Deprecated;
see note below", and add a separate "Deprecated" note immediately beneath the
table that explains the full rationale and lists the replacement fields
expiration_twap_start_base_cumulative_price and
expiration_twap_start_quote_cumulative_price; apply the same change to the other
occurrences of expiration_twap_start_price_cumulative noted in the comment so
each table cell is concise and the full explanation lives in a single,
well-formatted note below the respective tables.
- Around line 4125-4127: Add a one-line explanatory note near the first code
snippet that uses Decimal("...") (the snippet containing price=Decimal("50000"),
quantity=Decimal("0.1"), margin=Decimal("5000")) stating that Decimal should be
constructed from string literals to avoid float precision issues and to
encourage copying the pattern; then apply the same single-line note to the other
places in the document that use Decimal("...") so they consistently document
using string-based Decimal literals.
- Around line 1456-1461: Update the ForcePausedInfo field docs in the JSON
source for ForcePausedInfo (the JSON used by the JSON_TO_HTML_TABLE generator)
to include short descriptions: set "reason" to a brief note like "Reason the
market was force-paused (enum ForcePausedReason, e.g., emergency, maintenance)."
and set "mark_price_at_pausing" to something like "Mark price at the time of
pausing as a human-readable decimal (cosmossdk_io_math.LegacyDec) representing
the asset price." Ensure these descriptions are added to the
ForcePausedInfo.json entries for the reason and mark_price_at_pausing fields so
the generated table shows them.
In `@source/includes/_errors.md`:
- Line 248: Update the error description for module "erc20" with error code 12
to use formal wording; replace the informal "can't charge denom creation fee"
with "cannot charge denom creation fee" in the error definitions (look for the
table row containing module-name "erc20" and error-code "12" in the error
registry or source/includes/_errors.md and update the description text).
In `@source/includes/_permissions.md`:
- Around line 3464-3469: Update the Go sample for MsgUpdateNamespace to either
include the EvmHook field or explicitly document it as optional; locate the
MsgUpdateNamespace construction (fields like wasm_hook="...", role_permissions,
role_managers, policy_statuses, policy_manager_capabilities) and add evm_hook=""
(or an example value) to mirror the Python sample, or add a short comment in the
Go snippet stating that EvmHook is optional so the examples are consistent.
In `@source/includes/_websocket.md`:
- Around line 10-12: Add a language specifier to the fenced code block
containing the WebSocket URL "ws://<node-address>:<port>/injstream-ws" (e.g.,
change ``` to ```text or ```plaintext) so the Markdown linter MD040 is
satisfied; update the fenced block around that exact string to include the
chosen language specifier.
In `@source/json_tables/errors/permissions_errors.json`:
- Around line 53-85: Update the "description" fields to use consistent hook
terminology and ERC20 casing: change the entry with error_code 12 to a clear
umbrella term like "contract hook query error", change error_code 14 to
"contract hook (wasm) error" and error_code 17 to "contract hook (evm) error" so
all hook types use the same "contract hook" phrasing, and change error_code 18's
description to use "ERC20" capitalized (e.g., "invalid ERC20 denom"); locate
these by the unique error_code values (12, 14, 17, 18) in the permissions module
and update their description strings accordingly.
In `@source/json_tables/indexer/injective_archiver_rpc/AccountStatsRequest.json`:
- Around line 7-13: Update the "period" parameter description in
AccountStatsRequest.json to list the accepted formats and examples so clients
know what to send; for example indicate that "period" accepts relative duration
strings like "7d", "30d", "1y" (days/weeks/months/years) and/or ISO 8601 date
ranges (e.g., "2025-01-01/2025-01-31") if supported, and clarify whether single
values are inclusive/exclusive and default behavior. Ensure the revised
Description text next to "Parameter": "period" explicitly states the allowed
formats, example values, and any defaults or validation rules.
In
`@source/json_tables/indexer/injective_auction_rpc/AuctionAccountStatusRequest.json`:
- Around line 1-13: Update the "round" and "address" parameter Descriptions in
AuctionAccountStatusRequest.json to specify constraints and expected formats:
change "round" to indicate it must be a non-negative int64 (e.g., "non-negative
auction round number, 0-based"), and change "address" to state the exact address
encoding expected by the API (e.g., "address of account, hex-encoded 20-byte
(0x...) or bech32, depending on backend") — replace the generic descriptions for
the "round" and "address" entries to include these constraints so consumers know
valid values and formats.
In
`@source/json_tables/indexer/injective_auction_rpc/AuctionAccountStatusResponse.json`:
- Around line 1-6: The JSON schema for AuctionAccountStatusResponse is missing
the allowed values for the "status" field; update
AuctionAccountStatusResponse.json to document the exact enum (or set of fixed
strings) for "status" (e.g., "allowed", "blocked", "pending", etc., use the real
enum names from your codebase) or add a link/reference to the canonical
enum/type where it's defined so clients know the concrete possible values and
their meanings.
In `@source/json_tables/indexer/injective_auction_rpc/AuctionContract.json`:
- Around line 52-55: Update the "Description" for the Parameter "is_bid_placed"
in AuctionContract.json to explicitly state its scope/timing (e.g., whether it
indicates a bid placed ever, during the current auction lifecycle, or within the
current round). Replace the ambiguous text "Whether any bid has been placed in
the auction." with a clear phrase such as "Whether any bid has been placed
during the current auction lifecycle (since auction start)" or "Whether any bid
has been placed in the current bidding round" depending on the intended
semantics of is_bid_placed used by the auction logic.
In `@source/json_tables/indexer/injective_megavault_rpc/User.json`:
- Around line 17-26: Update the descriptions for the User schema fields to
consistently reference the user’s vault position and align phrasing with the
updated_* fields: change the "created_height" description to something like
"Block height when the user's vault position was created." and change the
"created_at" description to match style (e.g. "Created timestamp in UNIX millis
for the user's vault position."). Ensure you update the entries for the
Parameters "created_height" and "created_at" in User.json and mirror the same
style used by "updated_height"/"updated_at".
In `@source/json_tables/indexer/injective_rfqrpc/CreateRFQRequestType.json`:
- Around line 1-62: The schema in CreateRFQRequestType.json currently mixes
client-supplied and server-assigned fields (rfq_id, status, created_at,
updated_at, transaction_time, height), which is misleading for a "Create"
request; either rename the type to RFQType/DT O to represent the full data model
or remove the server-assigned fields so the create request only includes
client-provided fields (market_id, direction, margin, quantity, worst_price,
expiry and any auth-derived request_address). Also ensure request_address is
either added (if clients supply it) or explicitly omitted/derived from auth to
match RFQRequestType.json expectations. Make the change in
CreateRFQRequestType.json and update any references to CreateRFQRequestType to
the new name if you rename it.
In `@source/json_tables/indexer/injective_rfqrpc/MakerStreamResponse.json`:
- Around line 1-21: The schema currently lists message_type and payload fields
(request, quote_ack, error) but doesn't state which payload is present for each
message_type; update the JSON docs for MakerStreamResponse to include a "oneof"
mapping that explicitly ties message_type values to the corresponding payload
fields (e.g., message_type 'request' -> request (RFQRequestType); 'quote_ack' ->
quote_ack (StreamAck); 'error' -> error (StreamError); 'pong' -> no payload),
and adjust the Description text for message_type and each payload field to note
that only the indicated field is populated for that message_type.
In `@source/json_tables/indexer/injective_rfqrpc/RFQSettlementType.json`:
- Around line 53-71: Update the timestamp field descriptions to explicitly state
their units (e.g., seconds since epoch, milliseconds, or nanoseconds) for
transaction_time, event_time, created_at, and updated_at in
RFQSettlementType.json; modify each "Description" value to include the unit (for
example "Transaction time timestamp in seconds since Unix epoch") and, if your
system uses a specific precision, also note that precision (e.g., "nanoseconds")
so clients can unambiguously parse the values.
In `@source/json_tables/indexer/injective_rfqrpc/StreamError.json`:
- Around line 1-7: The StreamError JSON schema currently only defines a "code"
string; add a new "message" string property to the StreamError type (e.g.,
"message": "Human-readable error description") so clients receive a readable
error explanation; update any validators, constructors or code paths that create
StreamError objects to populate the new message field and ensure schema
consumers (parsers/serializers) accept the additional property.
In `@source/json_tables/indexer/injective_rfqrpc/StreamQuoteRequest.json`:
- Around line 3-6: Update the StreamQuoteRequest.json entry for the "addresses"
parameter to explicitly define expected format and constraints: clarify that
"addresses" is an array of strings (bech32 or other prefix — specify which),
whether empty arrays are allowed (e.g., "minItems": 1 or "minItems": 0), maximum
items (e.g., "maxItems": 100), any per-item length or regex pattern (e.g.,
bech32 regex) and uniqueness requirement (e.g., "uniqueItems": true), and
include an example address or array to illustrate; update the "Description" to
mention the required address format and limits and add JSON Schema-like keys
("items", "pattern"/"format", "minItems", "maxItems", "uniqueItems", "example")
so API consumers know exactly what to send.
In `@source/json_tables/indexer/injective_rfqrpc/StreamRequestRequest.json`:
- Around line 1-7: Update the "market_ids" parameter documentation in
StreamRequestRequest.json to state the non-empty constraint and expected
behavior when empty; specifically, change the "Description" for "market_ids" to
include a short note such as "Filter by market IDs (must contain at least one
ID)" and, if applicable, mention server response on empty input (e.g.,
rejected/400 or treated as no-filter). Keep the parameter name "market_ids" and
the file StreamRequestRequest.json as the target for this edit.
In `@source/json_tables/injective/exchange/v2/ForcePausedInfo.json`:
- Around line 1-12: Add concise Description strings for the schema fields so API
docs are informative: update the "reason" entry (Type: ForcePausedReason) to
describe what triggers the force pause (e.g., enum explaining pause causes), and
update "mark_price_at_pausing" (Type: cosmossdk_io_math.LegacyDec) to describe
that it records the mark price when the pause was enacted and its
units/precision; ensure both descriptions are short, clear sentences suitable
for generated docs.
In `@source/json_tables/injective/exchange/v2/SpotMarketParamUpdateProposal.json`:
- Around line 71-75: The description for the "has_disabled_minimal_protocol_fee"
parameter is ambiguous because the Type is a structured update
"DisableMinimalProtocolFeeUpdate" rather than a simple bool; update the
Description in SpotMarketParamUpdateProposal to explicitly state that
DisableMinimalProtocolFeeUpdate is a structured patch (e.g., contains fields to
enable/disable or set metadata) and not just a boolean flag, briefly listing the
semantic effect (what fields/actions the update supports) so readers know to
inspect DisableMinimalProtocolFeeUpdate for details.
In `@source/json_tables/injective/oracle/ChainlinkDataStreamsPriceState.json`:
- Around line 1-27: Add concise Description values for each parameter in
ChainlinkDataStreamsPriceState.json: explain "feed_id" (e.g., unique identifier
for the data feed), "report_price" (units/precision and that it's a
cosmossdk_io_math.Int representing the reported price), "valid_from_timestamp"
(when the price becomes valid), "observations_timestamp" (time of the underlying
observation), and "price_state" (briefly describe the PriceState enum/structure
semantics); update the Description fields next to the Parameter names so API
docs clearly convey intent and units for feed_id, report_price,
valid_from_timestamp, observations_timestamp, and price_state.
In `@source/json_tables/injective/oracle/ChainlinkReport.json`:
- Around line 1-21: Add concise one-line descriptions for each parameter in the
ChainlinkReport JSON entry so the rendered docs are clear: provide a short
purpose for "feed_id" (e.g., identifier of the data feed), "full_report" (e.g.,
serialized report payload or signer observations), "valid_from_timestamp" (e.g.,
epoch time from which the report is valid), and "observations_timestamp" (e.g.,
epoch time when observations were recorded); update the "Description" fields for
feed_id, full_report, valid_from_timestamp, and observations_timestamp
accordingly in the ChainlinkReport JSON.
In `@source/json_tables/injective/oracle/Params.json`:
- Around line 6-21: Add brief human-readable descriptions for the new Chainlink
Data Streams parameters to improve documentation: update the JSON entries for
"chainlink_verifier_proxy_contract",
"accept_unverified_chainlink_data_streams_reports", and
"chainlink_data_streams_verification_gas_limit" by populating their
"Description" fields with short explanatory text describing the purpose and
expected values (e.g., that the first is the verifier proxy contract address,
the second toggles acceptance of unverified reports, and the third sets the gas
limit used during verification).
In `@source/json_tables/injective/permissions/MsgUpdateNamespace.json`:
- Around line 15-18: Update the Description for the "wasm_hook" parameter (Type:
MsgUpdateNamespace_SetContractHook) in MsgUpdateNamespace to use the same
"cosmwasm" wording as elsewhere: replace "address of wasm smart contract to
apply code-based restrictions" with "address of cosmwasm smart contract to apply
code-based restrictions"; apply the same exact change to the other occurrence
(the second block at lines ~44-48) so both descriptions are consistent.
In `@source/json_tables/injective/permissions/Params.json`:
- Around line 3-10: Update the Description for the Parameter
"enforced_restrictions_contracts" to remove the double-negative ambiguity by
replacing "will not bypass module-to-module transfers" with a clearer phrase
such as "cannot bypass module-to-module transfers" so the intent is unambiguous;
locate the entry for the "enforced_restrictions_contracts" Parameter in
Params.json and edit its Description accordingly (ensure punctuation and
capitalization remain consistent with other entries).
Comment on lines
+2
to
24
| COSMOS_SDK_VERSION := v0.50.14-inj.4 | ||
| COSMOS_SDK_REPO := https://github.com/InjectiveLabs/cosmos-sdk.git | ||
|
|
||
| INJECTIVE_CORE_VERSION := v1.17.0 | ||
| INJECTIVE_CORE_VERSION := v1.18.0 | ||
| INJECTIVE_CORE_REPO := https://github.com/InjectiveLabs/injective-core.git | ||
|
|
||
| INDEXER_VERSION := v1.17.16 | ||
| INDEXER_VERSION := v1.18.3 | ||
| INDEXER_REPO := https://github.com/InjectiveLabs/injective-indexer.git | ||
|
|
||
| IBC_GO_VERSION := v8.7.0-inj.3 | ||
| IBC_GO_REPO := https://github.com/InjectiveLabs/ibc-go.git | ||
|
|
||
| COMETBFT_VERSION := v1.0.1-inj.4 | ||
| COMETBFT_VERSION := v1.0.1-inj.6 | ||
| COMETBFT_REPO := https://github.com/InjectiveLabs/cometbft.git | ||
|
|
||
| WASMD_VERSION := v0.53.3-inj.2 | ||
| WASMD_REPO := https://github.com/InjectiveLabs/wasmd.git | ||
|
|
||
| PYTHON_SDK_VERSION := v1.12.0 | ||
| PYTHON_SDK_VERSION := v1.13.0 | ||
| PYTHON_SDK_REPO := https://github.com/InjectiveLabs/sdk-python.git | ||
|
|
||
| GO_SDK_VERSION := v1.59.0 | ||
| GO_SDK_VERSION := v1.60.0 | ||
| GO_SDK_REPO := https://github.com/InjectiveLabs/sdk-go.git |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify all version tags exist in InjectiveLabs repositories
declare -A repos=(
["COSMOS_SDK"]="https://github.com/InjectiveLabs/cosmos-sdk.git:v0.50.14-inj.4"
["INJECTIVE_CORE"]="https://github.com/InjectiveLabs/injective-core.git:v1.18.0"
["INDEXER"]="https://github.com/InjectiveLabs/injective-indexer.git:v1.18.3"
["IBC_GO"]="https://github.com/InjectiveLabs/ibc-go.git:v8.7.0-inj.3"
["COMETBFT"]="https://github.com/InjectiveLabs/cometbft.git:v1.0.1-inj.6"
["WASMD"]="https://github.com/InjectiveLabs/wasmd.git:v0.53.3-inj.2"
["PYTHON_SDK"]="https://github.com/InjectiveLabs/sdk-python.git:v1.13.0"
["GO_SDK"]="https://github.com/InjectiveLabs/sdk-go.git:v1.60.0"
)
echo "=== Verifying Version Tags ==="
all_found=true
for component in "${!repos[@]}"; do
IFS=':' read -r repo_url tag <<< "${repos[$component]}"
echo -n "Checking $component $tag... "
if git ls-remote --tags "$repo_url" | grep -q "refs/tags/$tag\$"; then
echo "✓ FOUND"
else
echo "✗ NOT FOUND"
all_found=false
fi
done
echo ""
if [ "$all_found" = true ]; then
echo "All version tags verified successfully."
else
echo "WARNING: Some version tags were not found."
fiRepository: InjectiveLabs/api-exchange-docs
Length of output: 2291
🏁 Script executed:
#!/bin/bash
# Verify all version tags exist using corrected syntax
echo "=== Verifying Version Tags ==="
# COSMOS_SDK
echo -n "Checking COSMOS_SDK v0.50.14-inj.4... "
git ls-remote --tags https://github.com/InjectiveLabs/cosmos-sdk.git 2>/dev/null | grep -q "refs/tags/v0.50.14-inj.4$" && echo "✓ FOUND" || echo "✗ NOT FOUND"
# INJECTIVE_CORE
echo -n "Checking INJECTIVE_CORE v1.18.0... "
git ls-remote --tags https://github.com/InjectiveLabs/injective-core.git 2>/dev/null | grep -q "refs/tags/v1.18.0$" && echo "✓ FOUND" || echo "✗ NOT FOUND"
# INDEXER
echo -n "Checking INDEXER v1.18.3... "
git ls-remote --tags https://github.com/InjectiveLabs/injective-indexer.git 2>/dev/null | grep -q "refs/tags/v1.18.3$" && echo "✓ FOUND" || echo "✗ NOT FOUND"
# IBC_GO
echo -n "Checking IBC_GO v8.7.0-inj.3... "
git ls-remote --tags https://github.com/InjectiveLabs/ibc-go.git 2>/dev/null | grep -q "refs/tags/v8.7.0-inj.3$" && echo "✓ FOUND" || echo "✗ NOT FOUND"
# COMETBFT
echo -n "Checking COMETBFT v1.0.1-inj.6... "
git ls-remote --tags https://github.com/InjectiveLabs/cometbft.git 2>/dev/null | grep -q "refs/tags/v1.0.1-inj.6$" && echo "✓ FOUND" || echo "✗ NOT FOUND"
# WASMD
echo -n "Checking WASMD v0.53.3-inj.2... "
git ls-remote --tags https://github.com/InjectiveLabs/wasmd.git 2>/dev/null | grep -q "refs/tags/v0.53.3-inj.2$" && echo "✓ FOUND" || echo "✗ NOT FOUND"
# PYTHON_SDK
echo -n "Checking PYTHON_SDK v1.13.0... "
git ls-remote --tags https://github.com/InjectiveLabs/sdk-python.git 2>/dev/null | grep -q "refs/tags/v1.13.0$" && echo "✓ FOUND" || echo "✗ NOT FOUND"
# GO_SDK
echo -n "Checking GO_SDK v1.60.0... "
git ls-remote --tags https://github.com/InjectiveLabs/sdk-go.git 2>/dev/null | grep -q "refs/tags/v1.60.0$" && echo "✓ FOUND" || echo "✗ NOT FOUND"Repository: InjectiveLabs/api-exchange-docs
Length of output: 434
🏁 Script executed:
#!/bin/bash
# Check available versions in the repositories with missing tags
echo "=== Available versions in INJECTIVE_CORE ==="
git ls-remote --tags https://github.com/InjectiveLabs/injective-core.git 2>/dev/null | grep -o 'refs/tags/v[^/]*$' | sed 's|refs/tags/||' | sort -V | tail -20
echo ""
echo "=== Available versions in INDEXER ==="
git ls-remote --tags https://github.com/InjectiveLabs/injective-indexer.git 2>/dev/null | grep -o 'refs/tags/v[^/]*$' | sed 's|refs/tags/||' | sort -V | tail -20Repository: InjectiveLabs/api-exchange-docs
Length of output: 158
🏁 Script executed:
#!/bin/bash
echo "=== Raw tags from INJECTIVE_CORE (first 30 lines) ==="
git ls-remote --tags https://github.com/InjectiveLabs/injective-core.git 2>/dev/null | head -30
echo ""
echo "=== Raw tags from INDEXER (first 30 lines) ==="
git ls-remote --tags https://github.com/InjectiveLabs/injective-indexer.git 2>/dev/null | head -30Repository: InjectiveLabs/api-exchange-docs
Length of output: 176
🏁 Script executed:
#!/bin/bash
echo "=== Testing INJECTIVE_CORE repository accessibility ==="
curl -s -I https://github.com/InjectiveLabs/injective-core.git 2>&1 | head -5
echo ""
echo "=== Checking INJECTIVE_CORE with ls-remote (verbose) ==="
git ls-remote https://github.com/InjectiveLabs/injective-core.git 2>&1 | head -20
echo ""
echo "=== Testing INDEXER repository accessibility ==="
curl -s -I https://github.com/InjectiveLabs/injective-indexer.git 2>&1 | head -5
echo ""
echo "=== Checking INDEXER with ls-remote (verbose) ==="
git ls-remote https://github.com/InjectiveLabs/injective-indexer.git 2>&1 | head -20
echo ""
echo "=== Testing other known working repo (IBC_GO) ==="
git ls-remote --tags https://github.com/InjectiveLabs/ibc-go.git 2>&1 | head -5Repository: InjectiveLabs/api-exchange-docs
Length of output: 1269
Critical: Two primary repository versions cannot be verified.
The INJECTIVE_CORE (v1.18.0) and INDEXER (v1.18.3) repositories are not accessible, preventing verification that these version tags exist. These are the core components for the v1.18.0 upgrade.
Six other version tags (COSMOS_SDK v0.50.14-inj.4, IBC_GO v8.7.0-inj.3, COMETBFT v1.0.1-inj.6, WASMD v0.53.3-inj.2, PYTHON_SDK v1.13.0, GO_SDK v1.60.0) were verified as present in their repositories.
Before merging, confirm that INJECTIVE_CORE v1.18.0 and INDEXER v1.18.3 tags exist in their respective repositories and that the repository URLs are correct.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@Makefile` around lines 2 - 24, The Makefile sets INJECTIVE_CORE_VERSION and
INDEXER_VERSION but those tags couldn't be verified; check the
INJECTIVE_CORE_REPO and INDEXER_REPO for the presence of tags
INJECTIVE_CORE_VERSION (v1.18.0) and INDEXER_VERSION (v1.18.3), correct the
repository URLs if they point to the wrong remotes, or update the version
constants (INJECTIVE_CORE_VERSION / INDEXER_VERSION) to valid tags found in
their repos, and then re-run tag verification before merging.
Comment on lines
+197
to
+199
| <tr ><td class="parameter-td td_text">open_notional_cap</td><td class="type-td td_text">OpenNotionalCap</td><td class="description-td td_text">open_notional_cap defines the maximum open notional for the market</td></tr> | ||
| <tr ><td class="parameter-td td_text">has_disabled_minimal_protocol_fee</td><td class="type-td td_text">bool</td><td class="description-td td_text">has_disabled_minimal_protocol_fee indicates whether the minimal protocol fee is disabled for the market</td></tr> | ||
| <tr ><td class="parameter-td td_text">force_paused_info</td><td class="type-td td_text">ForcePausedInfo</td><td class="description-td td_text">force_paused_info defines additional info for force paused markets, only set when status == ForcePaused</td></tr></tbody></table> |
There was a problem hiding this comment.
Sync BinaryOptions response examples with new fields.
open_notional_cap, has_disabled_minimal_protocol_fee, and force_paused_info are now documented, but the BinaryOptionsMarkets response example still omits them. Please add them (e.g., has_disabled_minimal_protocol_fee: false, force_paused_info: null) so examples match the schema.
Also applies to: 262-275
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@source/includes/_binaryoptions.md` around lines 197 - 199, Update the
BinaryOptionsMarkets response examples to include the newly documented fields so
the examples match the schema: add open_notional_cap (either a representative
OpenNotionalCap object or null), has_disabled_minimal_protocol_fee (e.g.,
false), and force_paused_info (e.g., null) in each example block for
BinaryOptionsMarkets; ensure the field names exactly match open_notional_cap,
has_disabled_minimal_protocol_fee, and force_paused_info and mirror the types
described in the docs so examples at the original location and the repeated
block around lines 262-275 stay consistent.
Comment on lines
+3
to
+7
| ## 2026-02-19 | ||
| - Updated all messages to reflect the changes included in the chain version v1.18.0, and the Indexer for that chain version | ||
| - Added documentation for the new websocket for exchange module events available on the chain nodes | ||
| - Python SDK v1.13.0 | ||
| - Go SDK v1.60.0 |
There was a problem hiding this comment.
Confirm the release date for the new changelog entry.
The heading is 2026-02-19 (tomorrow, Feb 19, 2026). If the release isn’t scheduled for that exact date, consider using the actual date or an “Unreleased” heading to prevent confusion.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@source/includes/_changelog.md` around lines 3 - 7, The changelog header "##
2026-02-19" may be incorrect if the release isn't scheduled for that exact date;
update the heading to the correct release date or replace it with "##
Unreleased" to avoid confusion, and ensure the block that lists chain v1.18.0
changes, websocket docs, and SDK versions remains under the updated heading
(look for the heading string "## 2026-02-19" to locate and change it).
Comment on lines
+58
to
+62
| symbol := "PYTH/USDT" | ||
| oracleType := "pricefeed" | ||
|
|
||
| ctx := context.Background() | ||
| res, err := exchangeClient.GetOracleList(ctx) | ||
| res, err := exchangeClient.GetOracleList(ctx, symbol, oracleType, "", 0) |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Description: Search for GetOracleList and fetch_oracle_list usage patterns to verify parameter requirements
# Check Go usage
echo "=== Go GetOracleList usage ==="
rg -A 2 'GetOracleList\(' --type go
# Check Python usage
echo -e "\n=== Python fetch_oracle_list usage ==="
rg -A 2 'fetch_oracle_list\(' --type pyRepository: InjectiveLabs/api-exchange-docs
Length of output: 460
🏁 Script executed:
#!/bin/bash
# Get repository structure
echo "=== Repository file structure ==="
git ls-files | head -30
echo -e "\n=== Total files ==="
git ls-files | wc -l
# Search for GetOracleList without type filters
echo -e "\n=== All GetOracleList references ==="
rg 'GetOracleList' -i
# Search for fetch_oracle_list without type filters
echo -e "\n=== All fetch_oracle_list references ==="
rg 'fetch_oracle_list' -iRepository: InjectiveLabs/api-exchange-docs
Length of output: 978
🏁 Script executed:
#!/bin/bash
# Read the markdown file to see the full context and parameter documentation
echo "=== Reading _oraclerpc.md (lines 40-90) ==="
sed -n '40,90p' source/includes/_oraclerpc.mdRepository: InjectiveLabs/api-exchange-docs
Length of output: 2611
Resolve inconsistency between parameter requirements and example usage.
The parameter documentation marks all fields as "Required" (symbol, oracle_type, per_page, token), but the provided examples contradict this:
- Go example passes empty string
""for token and0for per_page - Python example omits token and per_page entirely, only passing symbol and oracle_type
Either the parameters should be marked as optional in the table, or the examples need to pass actual required values. This inconsistency will confuse developers about which parameters are truly mandatory.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@source/includes/_oraclerpc.md` around lines 58 - 62, The examples for
GetOracleList contradict the parameter table: either mark token and per_page as
optional in the docs or update the examples to pass real required values; fix by
updating the parameter table to set token and per_page as Optional (not
Required) or change the Go call to exchangeClient.GetOracleList(ctx, symbol,
oracleType, "your-token", 100) and the Python example to include token and
per_page parameters so they match the documented required fields; reference the
GetOracleList invocation and the parameters symbol, oracle_type (oracleType),
token and per_page when making the change.
Comment on lines
+74
to
+77
| <table class="JSON-TO-HTML-TABLE"><thead><tr><th class="parameter-th">Parameter</th><th class="type-th">Type</th><th class="description-th">Description</th><th class="required-th">Required</th></tr></thead><tbody ><tr ><td class="parameter-td td_text">symbol</td><td class="type-td td_text">string</td><td class="description-td td_text">Filter by oracle symbol</td><td class="required-td td_text">Yes</td></tr> | ||
| <tr ><td class="parameter-td td_text">oracle_type</td><td class="type-td td_text">string</td><td class="description-td td_text">Filter by oracle type</td><td class="required-td td_text">Yes</td></tr> | ||
| <tr ><td class="parameter-td td_text">per_page</td><td class="type-td td_text">int32</td><td class="description-td td_text">Number of results per page</td><td class="required-td td_text">Yes</td></tr> | ||
| <tr ><td class="parameter-td td_text">token</td><td class="type-td td_text">string</td><td class="description-td td_text">Pagination token from previous response</td><td class="required-td td_text">Yes</td></tr></tbody></table> |
There was a problem hiding this comment.
Clarify optional vs required parameters.
All four parameters are marked as "Required: Yes", but the Go example (line 62) passes empty string for token and 0 for per_page, suggesting these pagination parameters are actually optional. Consider marking per_page and token as optional to avoid confusing users who want to fetch all results without pagination.
📋 Suggested documentation fix
-<tr ><td class="parameter-td td_text">per_page</td><td class="type-td td_text">int32</td><td class="description-td td_text">Number of results per page</td><td class="required-td td_text">Yes</td></tr>
-<tr ><td class="parameter-td td_text">token</td><td class="type-td td_text">string</td><td class="description-td td_text">Pagination token from previous response</td><td class="required-td td_text">Yes</td></tr>
+<tr ><td class="parameter-td td_text">per_page</td><td class="type-td td_text">int32</td><td class="description-td td_text">Number of results per page (optional, 0 for all)</td><td class="required-td td_text">No</td></tr>
+<tr ><td class="parameter-td td_text">token</td><td class="type-td td_text">string</td><td class="description-td td_text">Pagination token from previous response (optional)</td><td class="required-td td_text">No</td></tr>📝 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.
Suggested change
| <table class="JSON-TO-HTML-TABLE"><thead><tr><th class="parameter-th">Parameter</th><th class="type-th">Type</th><th class="description-th">Description</th><th class="required-th">Required</th></tr></thead><tbody ><tr ><td class="parameter-td td_text">symbol</td><td class="type-td td_text">string</td><td class="description-td td_text">Filter by oracle symbol</td><td class="required-td td_text">Yes</td></tr> | |
| <tr ><td class="parameter-td td_text">oracle_type</td><td class="type-td td_text">string</td><td class="description-td td_text">Filter by oracle type</td><td class="required-td td_text">Yes</td></tr> | |
| <tr ><td class="parameter-td td_text">per_page</td><td class="type-td td_text">int32</td><td class="description-td td_text">Number of results per page</td><td class="required-td td_text">Yes</td></tr> | |
| <tr ><td class="parameter-td td_text">token</td><td class="type-td td_text">string</td><td class="description-td td_text">Pagination token from previous response</td><td class="required-td td_text">Yes</td></tr></tbody></table> | |
| <table class="JSON-TO-HTML-TABLE"><thead><tr><th class="parameter-th">Parameter</th><th class="type-th">Type</th><th class="description-th">Description</th><th class="required-th">Required</th></tr></thead><tbody ><tr ><td class="parameter-td td_text">symbol</td><td class="type-td td_text">string</td><td class="description-td td_text">Filter by oracle symbol</td><td class="required-td td_text">Yes</td></tr> | |
| <tr ><td class="parameter-td td_text">oracle_type</td><td class="type-td td_text">string</td><td class="description-td td_text">Filter by oracle type</td><td class="required-td td_text">Yes</td></tr> | |
| <tr ><td class="parameter-td td_text">per_page</td><td class="type-td td_text">int32</td><td class="description-td td_text">Number of results per page (optional, 0 for all)</td><td class="required-td td_text">No</td></tr> | |
| <tr ><td class="parameter-td td_text">token</td><td class="type-td td_text">string</td><td class="description-td td_text">Pagination token from previous response (optional)</td><td class="required-td td_text">No</td></tr></tbody></table> |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@source/includes/_oraclerpc.md` around lines 74 - 77, The table currently
marks symbol, oracle_type, per_page, and token as Required: Yes but the Go
example shows token passed as an empty string and per_page as 0, implying
pagination params are optional; update the docs to mark per_page and token as
Optional (keep symbol and oracle_type as Required) and add a brief note near the
Go example clarifying that passing token="" or per_page=0 disables
pagination/defaults to server behavior so users aren’t confused. Reference the
parameter names per_page and token and the existing Go example that passes ""/0
when making the change.
Comment on lines
+1
to
+21
| [ | ||
| { | ||
| "Parameter": "message_type", | ||
| "Type": "string", | ||
| "Description": "Type: 'quote', 'request_ack', 'error', 'pong'" | ||
| }, | ||
| { | ||
| "Parameter": "quote", | ||
| "Type": "RFQQuoteType", | ||
| "Description": "Quote from market maker" | ||
| }, | ||
| { | ||
| "Parameter": "request_ack", | ||
| "Type": "StreamAck", | ||
| "Description": "Acknowledgment for request creation" | ||
| }, | ||
| { | ||
| "Parameter": "error", | ||
| "Type": "StreamError", | ||
| "Description": "Error message" | ||
| } |
There was a problem hiding this comment.
Document which fields appear for each message_type.
To avoid ambiguity for clients, clarify that quote, request_ack, and error are populated only for specific message_type values.
📝 Suggested doc tweaks
- "Description": "Quote from market maker"
+ "Description": "Quote from market maker (message_type = 'quote')"- "Description": "Acknowledgment for request creation"
+ "Description": "Acknowledgment for request creation (message_type = 'request_ack')"- "Description": "Error message"
+ "Description": "Error message (message_type = 'error')"📝 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.
Suggested change
| [ | |
| { | |
| "Parameter": "message_type", | |
| "Type": "string", | |
| "Description": "Type: 'quote', 'request_ack', 'error', 'pong'" | |
| }, | |
| { | |
| "Parameter": "quote", | |
| "Type": "RFQQuoteType", | |
| "Description": "Quote from market maker" | |
| }, | |
| { | |
| "Parameter": "request_ack", | |
| "Type": "StreamAck", | |
| "Description": "Acknowledgment for request creation" | |
| }, | |
| { | |
| "Parameter": "error", | |
| "Type": "StreamError", | |
| "Description": "Error message" | |
| } | |
| [ | |
| { | |
| "Parameter": "message_type", | |
| "Type": "string", | |
| "Description": "Type: 'quote', 'request_ack', 'error', 'pong'" | |
| }, | |
| { | |
| "Parameter": "quote", | |
| "Type": "RFQQuoteType", | |
| "Description": "Quote from market maker (message_type = 'quote')" | |
| }, | |
| { | |
| "Parameter": "request_ack", | |
| "Type": "StreamAck", | |
| "Description": "Acknowledgment for request creation (message_type = 'request_ack')" | |
| }, | |
| { | |
| "Parameter": "error", | |
| "Type": "StreamError", | |
| "Description": "Error message (message_type = 'error')" | |
| } | |
| ] |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@source/json_tables/indexer/injective_rfqrpc/TakerStreamResponse.json` around
lines 1 - 21, The current JSON schema lists fields message_type, quote,
request_ack, and error but doesn't state which fields are present for each
message_type; update the documentation for TakerStreamResponse to explicitly map
message_type values ('quote', 'request_ack', 'error', 'pong') to which payload
field is populated (e.g., when message_type == 'quote' include RFQQuoteType in
quote; when message_type == 'request_ack' include StreamAck in request_ack; when
message_type == 'error' include StreamError in error; 'pong' has no payload),
and add a note that non-matching fields will be omitted or null so clients know
which fields to expect.
Comment on lines
+1
to
+13
| [ | ||
| { | ||
| "Parameter": "message_type", | ||
| "Type": "string", | ||
| "Description": "Type: 'request', 'ping'", | ||
| "Required": "Yes" | ||
| }, | ||
| { | ||
| "Parameter": "request", | ||
| "Type": "CreateRFQRequestType", | ||
| "Description": "RFQ request to create", | ||
| "Required": "No" | ||
| } |
There was a problem hiding this comment.
Clarify conditional requirement for request.
Given Line 5’s message types, Line 9’s request should be documented as required when message_type is 'request' to avoid confusion.
📝 Suggested doc tweak
- "Description": "RFQ request to create",
+ "Description": "RFQ request to create (required when message_type is 'request')",📝 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.
Suggested change
| [ | |
| { | |
| "Parameter": "message_type", | |
| "Type": "string", | |
| "Description": "Type: 'request', 'ping'", | |
| "Required": "Yes" | |
| }, | |
| { | |
| "Parameter": "request", | |
| "Type": "CreateRFQRequestType", | |
| "Description": "RFQ request to create", | |
| "Required": "No" | |
| } | |
| [ | |
| { | |
| "Parameter": "message_type", | |
| "Type": "string", | |
| "Description": "Type: 'request', 'ping'", | |
| "Required": "Yes" | |
| }, | |
| { | |
| "Parameter": "request", | |
| "Type": "CreateRFQRequestType", | |
| "Description": "RFQ request to create (required when message_type is 'request')", | |
| "Required": "No" | |
| } |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@source/json_tables/indexer/injective_rfqrpc/TakerStreamStreamingRequest.json`
around lines 1 - 13, Update the JSON schema docs so the "request" field (Type:
CreateRFQRequestType) is marked as conditionally required when "message_type"
equals 'request' — modify the "Required" value for "request" to indicate "Yes
when message_type == 'request' (otherwise No)" and update the Description to
state "RFQ request to create; required when message_type is 'request'." Ensure
you reference the "message_type" and "request" entries so readers clearly see
the conditional requirement.
Comment on lines
18
to
+20
| "Parameter": "expiration_twap_start_price_cumulative", | ||
| "Type": "cosmossdk_io_math.LegacyDec", | ||
| "Description": "expiration_twap_start_price_cumulative defines the cumulative price for the start of the TWAP window (in human readable format)" | ||
| "Description": "expiration_twap_start_price_cumulative defines the cumulative price for the start of the TWAP window (in human readable format) Deprecated: For correctly calculating the expiration price using TWAP, we need to keep the cumulative price at the start of TWAP calculation separately for the base asset and the quote asset. Use expiration_twap_start_base_cumulative_price and expiration_twap_start_quote_cumulative_price instead." |
There was a problem hiding this comment.
Consider splitting the deprecation note into clearer sentences.
The description is now a very long single sentence; splitting into two sentences (or adding a line break after “Deprecated:”) will improve readability in generated docs.
📝 Suggested wording tweak
- "Description": "expiration_twap_start_price_cumulative defines the cumulative price for the start of the TWAP window (in human readable format) Deprecated: For correctly calculating the expiration price using TWAP, we need to keep the cumulative price at the start of TWAP calculation separately for the base asset and the quote asset. Use expiration_twap_start_base_cumulative_price and expiration_twap_start_quote_cumulative_price instead."
+ "Description": "expiration_twap_start_price_cumulative defines the cumulative price for the start of the TWAP window (in human readable format). Deprecated: For correctly calculating the expiration price using TWAP, keep the cumulative price at the start of TWAP separately for the base asset and the quote asset. Use expiration_twap_start_base_cumulative_price and expiration_twap_start_quote_cumulative_price instead."📝 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.
Suggested change
| "Parameter": "expiration_twap_start_price_cumulative", | |
| "Type": "cosmossdk_io_math.LegacyDec", | |
| "Description": "expiration_twap_start_price_cumulative defines the cumulative price for the start of the TWAP window (in human readable format)" | |
| "Description": "expiration_twap_start_price_cumulative defines the cumulative price for the start of the TWAP window (in human readable format) Deprecated: For correctly calculating the expiration price using TWAP, we need to keep the cumulative price at the start of TWAP calculation separately for the base asset and the quote asset. Use expiration_twap_start_base_cumulative_price and expiration_twap_start_quote_cumulative_price instead." | |
| "Parameter": "expiration_twap_start_price_cumulative", | |
| "Type": "cosmossdk_io_math.LegacyDec", | |
| "Description": "expiration_twap_start_price_cumulative defines the cumulative price for the start of the TWAP window (in human readable format). Deprecated: For correctly calculating the expiration price using TWAP, keep the cumulative price at the start of TWAP separately for the base asset and the quote asset. Use expiration_twap_start_base_cumulative_price and expiration_twap_start_quote_cumulative_price instead." |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@source/json_tables/injective/exchange/v2/ExpiryFuturesMarketInfo.json` around
lines 18 - 20, The Description for the parameter
expiration_twap_start_price_cumulative is a long single sentence; split the
deprecation note into a second sentence (or insert a line break after
"Deprecated:") and rephrase for clarity—e.g., keep the first sentence describing
what the field defines and then start a new sentence "Deprecated: For correctly
calculating the expiration price using TWAP, keep separate cumulative prices for
the base and quote assets; use expiration_twap_start_base_cumulative_price and
expiration_twap_start_quote_cumulative_price instead." Update the Description
string accordingly in the JSON entry for expiration_twap_start_price_cumulative.
Comment on lines
+172
to
176
| { | ||
| "Parameter": "enforced_restrictions_contracts", | ||
| "Type": "EnforcedRestrictionsContract array", | ||
| "Description": "Contracts that exchange will be listening to pause markets denominated in respective erc20: denoms, with their pause event signatures" | ||
| } |
There was a problem hiding this comment.
Minor typo in description.
The description contains "erc20: denoms" which appears to have a misplaced colon. Should this be "erc20 denoms" or "ERC-20 denoms"?
📝 Suggested fix
{
"Parameter": "enforced_restrictions_contracts",
"Type": "EnforcedRestrictionsContract array",
- "Description": "Contracts that exchange will be listening to pause markets denominated in respective erc20: denoms, with their pause event signatures"
+ "Description": "Contracts that exchange will be listening to pause markets denominated in respective ERC-20 denoms, with their pause event signatures"
}📝 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.
Suggested change
| { | |
| "Parameter": "enforced_restrictions_contracts", | |
| "Type": "EnforcedRestrictionsContract array", | |
| "Description": "Contracts that exchange will be listening to pause markets denominated in respective erc20: denoms, with their pause event signatures" | |
| } | |
| { | |
| "Parameter": "enforced_restrictions_contracts", | |
| "Type": "EnforcedRestrictionsContract array", | |
| "Description": "Contracts that exchange will be listening to pause markets denominated in respective ERC-20 denoms, with their pause event signatures" | |
| } |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@source/json_tables/injective/exchange/v2/Params.json` around lines 172 - 176,
Update the Description for the parameter enforced_restrictions_contracts to fix
the typo "erc20: denoms" — replace the misplaced colon and normalize casing
(e.g., use "ERC-20 denoms" or "erc20 denoms") so the description reads clearly
that these are market-denominated ERC-20 denoms the exchange listens to; modify
the Description string in Params.json accordingly.
Comment on lines
+1
to
+6
| [ | ||
| { | ||
| "Parameter": "price_states", | ||
| "Type": "ChainlinkDataStreamsPriceState array", | ||
| "Description": "" | ||
| } |
There was a problem hiding this comment.
Add a short description for price_states.
Line 5’s empty description leaves the response unclear.
📝 Suggested wording
- "Description": ""
+ "Description": "List of Chainlink data stream price states"📝 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.
Suggested change
| [ | |
| { | |
| "Parameter": "price_states", | |
| "Type": "ChainlinkDataStreamsPriceState array", | |
| "Description": "" | |
| } | |
| [ | |
| { | |
| "Parameter": "price_states", | |
| "Type": "ChainlinkDataStreamsPriceState array", | |
| "Description": "List of Chainlink data stream price states" | |
| } |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@source/json_tables/injective/oracle/QueryChainlinkDataStreamsPriceStatesResponse.json`
around lines 1 - 6, The response schema's "price_states" field is missing a
description; update the "price_states" entry in
QueryChainlinkDataStreamsPriceStatesResponse.json to include a concise
description such as: "Array of ChainlinkDataStreamsPriceState objects
representing the current/latest price state for each data stream/feed (includes
price, timestamp, and related metadata)"; ensure the description is added to the
"Description" property for the "price_states" parameter so consumers understand
the contents and purpose of the array.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary by CodeRabbit
Release Notes
New Features
Documentation
Chores