Merged
Conversation
🦋 Changeset detectedLatest commit: 314c654 The changes in this PR will be included in the next version bump. Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
📝 WalkthroughWalkthroughThe PR adds comprehensive schema updates to the SDK's API layer, introducing five new yield-specific endpoints ( Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~28 minutes 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 docstrings
🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
src/api/index.ts (1)
287-301:⚠️ Potential issue | 🟠 MajorChange
transactionIdparameter fromunknownback tostringtype.The
transactionIdparameter was changed tounknowntype forsubmitTransactionHash,submitTransaction, andgetTransaction, but this degrades type safety and is inconsistent with the codebase pattern. All other ID parameters in the API (yieldId,actionId,providerId) usestringtype. Problems withunknown:
- Loses compile-time type checking—callers can pass any value without errors
- When interpolated into URL templates,
unknowncoerces via.toString(), which may produce unexpected results for objects- Breaks type safety for SDK consumers who expect
stringparameters- REST API path parameters are always strings per HTTP standards;
stringis the correct typeChange these three functions to use
transactionId: stringinstead oftransactionId: unknown.Also applies to: 307-321, 327-335
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/api/index.ts` around lines 287 - 301, The transactionId parameter was wrongly typed as unknown; update submitTransactionHash (and the related functions submitTransaction and getTransaction) to use transactionId: string instead of unknown, updating their signatures and any internal uses that assume a string (e.g., URL template interpolation in customFetch call) so callers get proper compile-time type checking and URLs are built from strings.
🧹 Nitpick comments (15)
src/api/schemas/getBalancesArgumentsDto.ts (1)
6-11: Consider markingautoSweepDayOfMonthas integer in schema metadata.Line 11 uses
number, but this field is day-of-month semantics; adding integer-format metadata reduces ambiguity for generated docs/clients.Suggested doc/schema tweak
/** * Day of month when auto-sweep window starts (used by Solana auto-sweep balance actions) + * `@format` int32 * `@minimum` 1 * `@maximum` 31 */ autoSweepDayOfMonth?: number;🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/api/schemas/getBalancesArgumentsDto.ts` around lines 6 - 11, The autoSweepDayOfMonth field should be marked as an integer in the schema and validation metadata: update the autoSweepDayOfMonth definition to include integer/schema metadata (e.g. OpenAPI type/format: type: 'integer' or format: 'int32') and add an integer validator (e.g. IsInt) alongside the existing minimum/maximum constraints so generated docs/clients treat it as an integer rather than a generic number.src/api/schemas/yieldRiskExponentialDtoUrl.ts (1)
4-4: Narrow this URL type to avoid losing SDK type safety.Line 4 currently accepts any keyed object with
unknownvalues, which is very permissive for a URL-focused DTO. If the API contract permits, prefer a narrower type (for examplestringorRecord<string, string>).Proposed tightening
-export type YieldRiskExponentialDtoUrl = { [key: string]: unknown }; +export type YieldRiskExponentialDtoUrl = Record<string, string>;🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/api/schemas/yieldRiskExponentialDtoUrl.ts` at line 4, The exported type YieldRiskExponentialDtoUrl is overly permissive ({[key: string]: unknown}); tighten it to the real shape used by the API (for example change YieldRiskExponentialDtoUrl to Record<string, string> or string | Record<string, string> if the URL can be either a plain string or keyed params) to preserve SDK type safety; update any callers or deserialization logic that assume unknown values to handle the new narrower type (adjust parse/validation in functions that consume YieldRiskExponentialDtoUrl).src/api/schemas/balanceDto.ts (1)
48-53: Consider grouping share fields into one optional object in a future schema revision.Current shape is valid, but independent optional fields can yield partially-populated share metadata (
shareAmountwithoutshareToken, etc.), which is harder for consumers to reason about.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/api/schemas/balanceDto.ts` around lines 48 - 53, The three optional fields shareAmount, shareAmountRaw and shareToken should be consolidated into a single optional object (e.g., share?: { amount?: string; amountRaw?: string; token?: TokenDto }) to avoid partially-populated share metadata; update the schema definition that currently declares shareAmount, shareAmountRaw and shareToken to instead declare a single optional share object, adjust any references/serializers/deserializers that access shareAmount/shareAmountRaw/shareToken to use share.amount/share.amountRaw/share.token, and keep TokenDto as the nested type for the token field.src/api/schemas/actionsControllerGetActionsNetwork.ts (1)
5-105: Consider centralizing network literals to avoid cross-file drift.This catalog appears duplicated with other schema network maps. Reusing a shared source constant will reduce maintenance risk when networks are added/removed.
Refactor sketch
+import { ActionArgumentsDtoOutputTokenNetwork as SharedNetworks } from "./actionArgumentsDtoOutputTokenNetwork"; + // eslint-disable-next-line `@typescript-eslint/no-redeclare` -export const ActionsControllerGetActionsNetwork = { - ... -} as const; +export const ActionsControllerGetActionsNetwork = SharedNetworks;// Keep the existing derived union type: export type ActionsControllerGetActionsNetwork = (typeof ActionsControllerGetActionsNetwork)[keyof typeof ActionsControllerGetActionsNetwork];🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/api/schemas/actionsControllerGetActionsNetwork.ts` around lines 5 - 105, The ActionsControllerGetActionsNetwork object duplicates a network literal set that exists elsewhere; change it to reuse a single shared constant (e.g., export a central Networks/NetworkMap const) and import that constant into this file instead of re-declaring the literals; keep the existing derived union type pattern (export type ActionsControllerGetActionsNetwork = (typeof ActionsControllerGetActionsNetwork)[keyof typeof ActionsControllerGetActionsNetwork]) so consumers keep the same type, update any local references to the original object to use the imported constant, and ensure the central constant is kept as a readonly/const object to preserve type semantics.src/api/schemas/actionsControllerGetActionsStatusesItem.ts (1)
1-13: Avoid duplicating status literals across two schema files.Line 1 through Line 13 duplicates the same status set already defined in
actionsControllerGetActionsStatus.ts. Reusing that source avoids drift.♻️ Proposed refactor
+import type { ActionsControllerGetActionsStatus } from "./actionsControllerGetActionsStatus"; +import { ActionsControllerGetActionsStatus as ActionsStatusMap } from "./actionsControllerGetActionsStatus"; + -export type ActionsControllerGetActionsStatusesItem = - (typeof ActionsControllerGetActionsStatusesItem)[keyof typeof ActionsControllerGetActionsStatusesItem]; - -// eslint-disable-next-line `@typescript-eslint/no-redeclare` -export const ActionsControllerGetActionsStatusesItem = { - CANCELED: "CANCELED", - CREATED: "CREATED", - WAITING_FOR_NEXT: "WAITING_FOR_NEXT", - PROCESSING: "PROCESSING", - FAILED: "FAILED", - SUCCESS: "SUCCESS", - STALE: "STALE", -} as const; +export type ActionsControllerGetActionsStatusesItem = ActionsControllerGetActionsStatus; +export const ActionsControllerGetActionsStatusesItem = ActionsStatusMap;🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/api/schemas/actionsControllerGetActionsStatusesItem.ts` around lines 1 - 13, This file duplicates the status literal set defined elsewhere; replace the local definition of ActionsControllerGetActionsStatusesItem with a reuse of the existing export from actionsControllerGetActionsStatus.ts: import (or re-export) the original constant/type (the symbol exported from that file, e.g., ActionsControllerGetActionsStatus) and export it under the current name (ActionsControllerGetActionsStatusesItem) or directly re-export the original symbol so both callers share the same source of truth and avoid literal drift.src/api/schemas/actionsControllerGetActionsParams.ts (1)
26-30: Makestatusvsstatusesbehavior explicit.Line 26 and Line 30 currently allow both filters at once. Please either make them mutually exclusive in the type or document precedence clearly to avoid ambiguous requests.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/api/schemas/actionsControllerGetActionsParams.ts` around lines 26 - 30, The current ActionsControllerGetActionsParams type allows both status and statuses simultaneously, causing ambiguity; update the type or docs so only one is accepted: make ActionsControllerGetActionsParams enforce mutual exclusivity by turning the fields into a discriminated union (one branch with status?: ActionsControllerGetActionsStatus and no statuses, the other with statuses?: ActionsControllerGetActionsStatusesItem[] and no status) or, if you prefer preserving shape, add a clear JSDoc on the ActionsControllerGetActionsParams interface and implement runtime validation in the handler (e.g., validate in getActions controller) to reject requests that include both, referencing the status and statuses fields and the ActionsControllerGetActionsParams type to locate where to change.src/api/schemas/yieldRequirementsDto.ts (1)
3-5: Consider encoding thekycRequired/kycUrlrelationship in the type.At Line 3 and Line 5,
kycRequired: truecan still coexist with an undefinedkycUrl. If URL is mandatory when KYC is required, a discriminated union would make that explicit.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/api/schemas/yieldRequirementsDto.ts` around lines 3 - 5, The current type allows kycRequired: true with an undefined kycUrl; change the type that defines kycRequired and kycUrl into a discriminated union so that { kycRequired: true; kycUrl: string } is a separate variant from { kycRequired: false; kycUrl?: undefined } (or { kycRequired?: false; kycUrl?: string } as needed), update the type declaration that contains the kycRequired and kycUrl properties accordingly, and adjust any places that construct or consume this type to satisfy the new required kycUrl when kycRequired is true.src/api/schemas/curatorDtoName.ts (1)
1-5: Consider narrowing the type toRecord<string, string> | nullif curator name is localized text with string values.The type
{ [key: string]: unknown } | nullappears to be a localization map based on the field name and pattern. If all values are guaranteed to be strings (e.g., language code keys mapping to localized name strings), usingRecord<string, string> | nullwould provide stronger type safety for consumers. Alternatively, if not localized,string | nullwould be more direct.Note:
CuratorDtoDescriptionandCuratorDtoLogoURIfollow the same pattern; consider applying consistent typing improvements across all three fields.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/api/schemas/curatorDtoName.ts` around lines 1 - 5, CuratorDtoName is too permissive as { [key: string]: unknown } | null; if this field represents localized text where values are strings, change the exported type CuratorDtoName to Record<string, string> | null to provide stronger type safety; if it's a single non-localized name, use string | null instead; apply the same consistent narrowing to CuratorDtoDescription and CuratorDtoLogoURI type definitions (replace their { [key: string]: unknown } | null with the chosen narrower type) so consumers get accurate typings.src/api/schemas/validatorProviderDtoTvlUsd.ts (1)
1-5:tvlUsdtyping is too permissive for a core numeric field.
{ [key: string]: unknown } | nullmakes downstream handling brittle. If this value is scalar (or a stable object), model it explicitly to preserve type safety.Proposed tightening (example)
-export type ValidatorProviderDtoTvlUsd = { [key: string]: unknown } | null; +export type ValidatorProviderDtoTvlUsd = string | null;🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/api/schemas/validatorProviderDtoTvlUsd.ts` around lines 1 - 5, The ValidatorProviderDtoTvlUsd type is too permissive; replace the broad index signature with a concrete numeric type to preserve type safety — change ValidatorProviderDtoTvlUsd from "{ [key: string]: unknown } | null" to "number | null" (or "string | number | null" if the API sometimes returns strings) and update any call sites that currently assume an object to parse/validate the scalar (e.g., use Number()/parseFloat() or runtime validation) so consumers handle the numeric TVL value correctly.src/api/schemas/yieldsControllerGetYieldsNetwork.ts (1)
1-105: Consider centralizing network literals to prevent drift.This file and
src/api/schemas/transactionDtoNetwork.tscarry near-identical long network maps. A shared source-of-truth constant (re-exported where needed) would reduce divergence risk in future additions like Line 91.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/api/schemas/yieldsControllerGetYieldsNetwork.ts` around lines 1 - 105, The YieldsControllerGetYieldsNetwork constant duplicates network literals from transactionDtoNetwork; extract the shared network map into a single exported constant (e.g., NETWORKS or SupportedNetworks) and have YieldsControllerGetYieldsNetwork and transactionDtoNetwork.ts re-export or reference that constant (update usages of YieldsControllerGetYieldsNetwork and any type aliases that derive from it to point to the new shared symbol) so both files use the single source-of-truth and avoid drift.src/api/schemas/curatorDtoDescription.ts (1)
1-5: Consider tightening the description map type.If this field is known to be localized text, replacing
unknownwithstringvalues (e.g.,Record<string, string> | null) would improve SDK usability and type-safety.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/api/schemas/curatorDtoDescription.ts` around lines 1 - 5, The CuratorDtoDescription alias is too permissive using unknown values; tighten it by changing the type of CuratorDtoDescription to a string map (e.g., Record<string, string> | null) so localized text values are enforced. Update the exported type alias CuratorDtoDescription to use Record<string, string> | null and adjust any call sites or tests that currently rely on non-string values to ensure compatibility.src/api/schemas/yieldRiskCredoraDtoCurator.ts (1)
1-4: Clarify doc/type mismatch for curator field.Line 2 says “curator name” (scalar semantics), but Line 4 defines an arbitrary object. Please align either the comment or the type to avoid confusion for SDK consumers.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/api/schemas/yieldRiskCredoraDtoCurator.ts` around lines 1 - 4, The documentation comment and the type for YieldRiskCredoraDtoCurator disagree: the comment describes a scalar "curator name" while the type is a map {[key: string]: unknown}. Decide which is correct and make them consistent—if curator is a name change the type to string and update the comment to "Credora curator name (string)"; if curator is an object keep the mapped type but update the comment to "Credora curator object" and, if possible, replace {[key: string]: unknown} with a more specific interface or Record<string, unknown> named e.g., CredoraCurator to improve SDK clarity. Ensure you update the symbol YieldRiskCredoraDtoCurator and its comment together.src/api/schemas/yieldsControllerGetYieldTvlHistory429.ts (1)
1-6: Consider extracting a shared HTTP error schema to reduce duplication.This shape is repeated across multiple new
400/401/429files. A sharedHttpErrorDto(andRateLimitedErrorDtoextension withretryAfter) would lower maintenance cost and keep response typing consistent.Proposed refactor pattern
+// src/api/schemas/httpErrorDto.ts +export interface HttpErrorDto { + message?: string; + error?: string; + statusCode?: number; +} + +// src/api/schemas/rateLimitedErrorDto.ts +import type { HttpErrorDto } from "./httpErrorDto"; +export interface RateLimitedErrorDto extends HttpErrorDto { + retryAfter?: number; +}-export type YieldsControllerGetYieldTvlHistory429 = { - message?: string; - error?: string; - statusCode?: number; - retryAfter?: number; -}; +import type { RateLimitedErrorDto } from "./rateLimitedErrorDto"; +export type YieldsControllerGetYieldTvlHistory429 = RateLimitedErrorDto;🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/api/schemas/yieldsControllerGetYieldTvlHistory429.ts` around lines 1 - 6, Extract the repeated error shape into a shared HttpErrorDto and a RateLimitedErrorDto that extends it (adding retryAfter), then update the specific type YieldsControllerGetYieldTvlHistory429 to reuse these shared types (e.g., type YieldsControllerGetYieldTvlHistory429 = RateLimitedErrorDto) so you remove duplicated message/error/statusCode fields; add the new shared types in a common schema file and replace other similar 400/401/429 types to reference HttpErrorDto or RateLimitedErrorDto accordingly.src/api/schemas/yieldRiskDto.ts (1)
5-6: Consider specifying timestamp format in the type doc.To avoid parsing ambiguity for SDK consumers, document
updatedAtexplicitly as ISO-8601 (or backend canonical format).🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/api/schemas/yieldRiskDto.ts` around lines 5 - 6, Update the JSDoc for the updatedAt property in yieldRiskDto (updatedAt: string) to explicitly state the expected timestamp format (e.g., "ISO-8601 / RFC3339 string, UTC") and optionally include an example value; ensure the schema comment for updatedAt clearly documents the canonical backend format so SDK consumers know how to parse it.src/api/index.ts (1)
136-149: Consider using a more specific return type instead ofPaginatedResponseDto.The
getYieldRewardsfunction returns a genericPaginatedResponseDto, while all similar endpoints likegetBalanceHistoryandgetYieldsuse specific response types (YieldsControllerGetBalanceHistory200,YieldsControllerGetYields200). These specific types extendPaginatedResponseDtowith typed item arrays, providing better type safety for the paginated items. Adding aYieldsControllerGetYieldRewards200type following the existing pattern would preserve type information about the reward items.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/api/index.ts` around lines 136 - 149, Replace the generic PaginatedResponseDto return type in getYieldRewards with a specific typed response (e.g., YieldsControllerGetYieldRewards200) to preserve item typing: update the function signature and the customFetch generic to use YieldsControllerGetYieldRewards200 instead of PaginatedResponseDto, and add or import the new YieldsControllerGetYieldRewards200 type (matching the pattern used by getBalanceHistory/getYields) so the paginated items are strongly typed.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.changeset/silly-jokes-start.md:
- Around line 2-5: The changeset currently marks the SDK update as a patch but
this PR adds new endpoints and exported schema types, so update the changeset
entry that reads "@yieldxyz/sdk": patch to use minor instead (i.e., change
"patch" to "minor") so the release correctly reflects an additive API change.
In `@src/api/schemas/liquidityStateDtoUtilization.ts`:
- Around line 1-5: The JSDoc for LiquidityStateDtoUtilization says it should be
a decimal utilization rate but the type alias LiquidityStateDtoUtilization is
currently { [key: string]: unknown } | null; change the type to number | null
(or a branded/decimal type your codebase uses) so the type matches the
documented contract and update the JSDoc if you use a specific numeric format;
ensure any references to LiquidityStateDtoUtilization in validation/conversion
functions are adjusted to treat it as a numeric value rather than an object.
In `@src/api/schemas/rewardEventDto.ts`:
- Around line 14-15: Update the JSDoc for the amountRaw property in
rewardEventDto.ts to be chain-agnostic: replace the EVM-specific "wei" wording
with a neutral phrase like "smallest denomination (base units)" or "base units /
smallest denomination" so the comment now reads that amountRaw is the raw reward
amount in base units (smallest denomination) and does not reference EVM-specific
terminology; locate the amountRaw property in the RewardEvent DTO to apply this
change.
In `@src/api/schemas/tvlHistoryResponseDto.ts`:
- Around line 3-18: Add the missing payload array to the DTOs: update
TvlHistoryResponseDto to include a snapshots field of type TvlSnapshotDto[] (or
items: TvlSnapshotDto[] if you want to match BalancesResponseDto naming) so the
time-series data is returned with the metadata, and make the analogous change in
RewardRateHistoryResponseDto to include an array field (e.g., snapshots:
RewardRateSnapshotDto[] or items: RewardRateSnapshotDto[]) to mirror the
BalancesResponseDto pattern and ensure the API returns the history snapshots.
In `@src/api/schemas/yieldRiskExponentialDtoPoolScore.ts`:
- Around line 1-4: The exported type YieldRiskExponentialDtoPoolScore currently
allows any object but should represent a numeric score 1–5; change the
declaration of YieldRiskExponentialDtoPoolScore to a concrete numeric type
(preferably the literal union 1|2|3|4|5 or at minimum number with a JSDoc
comment) and adjust any callers/validators to accept that numeric type (or
perform runtime validation) so the public contract matches the comment and
prevents arbitrary objects from being passed.
---
Outside diff comments:
In `@src/api/index.ts`:
- Around line 287-301: The transactionId parameter was wrongly typed as unknown;
update submitTransactionHash (and the related functions submitTransaction and
getTransaction) to use transactionId: string instead of unknown, updating their
signatures and any internal uses that assume a string (e.g., URL template
interpolation in customFetch call) so callers get proper compile-time type
checking and URLs are built from strings.
---
Nitpick comments:
In `@src/api/index.ts`:
- Around line 136-149: Replace the generic PaginatedResponseDto return type in
getYieldRewards with a specific typed response (e.g.,
YieldsControllerGetYieldRewards200) to preserve item typing: update the function
signature and the customFetch generic to use YieldsControllerGetYieldRewards200
instead of PaginatedResponseDto, and add or import the new
YieldsControllerGetYieldRewards200 type (matching the pattern used by
getBalanceHistory/getYields) so the paginated items are strongly typed.
In `@src/api/schemas/actionsControllerGetActionsNetwork.ts`:
- Around line 5-105: The ActionsControllerGetActionsNetwork object duplicates a
network literal set that exists elsewhere; change it to reuse a single shared
constant (e.g., export a central Networks/NetworkMap const) and import that
constant into this file instead of re-declaring the literals; keep the existing
derived union type pattern (export type ActionsControllerGetActionsNetwork =
(typeof ActionsControllerGetActionsNetwork)[keyof typeof
ActionsControllerGetActionsNetwork]) so consumers keep the same type, update any
local references to the original object to use the imported constant, and ensure
the central constant is kept as a readonly/const object to preserve type
semantics.
In `@src/api/schemas/actionsControllerGetActionsParams.ts`:
- Around line 26-30: The current ActionsControllerGetActionsParams type allows
both status and statuses simultaneously, causing ambiguity; update the type or
docs so only one is accepted: make ActionsControllerGetActionsParams enforce
mutual exclusivity by turning the fields into a discriminated union (one branch
with status?: ActionsControllerGetActionsStatus and no statuses, the other with
statuses?: ActionsControllerGetActionsStatusesItem[] and no status) or, if you
prefer preserving shape, add a clear JSDoc on the
ActionsControllerGetActionsParams interface and implement runtime validation in
the handler (e.g., validate in getActions controller) to reject requests that
include both, referencing the status and statuses fields and the
ActionsControllerGetActionsParams type to locate where to change.
In `@src/api/schemas/actionsControllerGetActionsStatusesItem.ts`:
- Around line 1-13: This file duplicates the status literal set defined
elsewhere; replace the local definition of
ActionsControllerGetActionsStatusesItem with a reuse of the existing export from
actionsControllerGetActionsStatus.ts: import (or re-export) the original
constant/type (the symbol exported from that file, e.g.,
ActionsControllerGetActionsStatus) and export it under the current name
(ActionsControllerGetActionsStatusesItem) or directly re-export the original
symbol so both callers share the same source of truth and avoid literal drift.
In `@src/api/schemas/balanceDto.ts`:
- Around line 48-53: The three optional fields shareAmount, shareAmountRaw and
shareToken should be consolidated into a single optional object (e.g., share?: {
amount?: string; amountRaw?: string; token?: TokenDto }) to avoid
partially-populated share metadata; update the schema definition that currently
declares shareAmount, shareAmountRaw and shareToken to instead declare a single
optional share object, adjust any references/serializers/deserializers that
access shareAmount/shareAmountRaw/shareToken to use
share.amount/share.amountRaw/share.token, and keep TokenDto as the nested type
for the token field.
In `@src/api/schemas/curatorDtoDescription.ts`:
- Around line 1-5: The CuratorDtoDescription alias is too permissive using
unknown values; tighten it by changing the type of CuratorDtoDescription to a
string map (e.g., Record<string, string> | null) so localized text values are
enforced. Update the exported type alias CuratorDtoDescription to use
Record<string, string> | null and adjust any call sites or tests that currently
rely on non-string values to ensure compatibility.
In `@src/api/schemas/curatorDtoName.ts`:
- Around line 1-5: CuratorDtoName is too permissive as { [key: string]: unknown
} | null; if this field represents localized text where values are strings,
change the exported type CuratorDtoName to Record<string, string> | null to
provide stronger type safety; if it's a single non-localized name, use string |
null instead; apply the same consistent narrowing to CuratorDtoDescription and
CuratorDtoLogoURI type definitions (replace their { [key: string]: unknown } |
null with the chosen narrower type) so consumers get accurate typings.
In `@src/api/schemas/getBalancesArgumentsDto.ts`:
- Around line 6-11: The autoSweepDayOfMonth field should be marked as an integer
in the schema and validation metadata: update the autoSweepDayOfMonth definition
to include integer/schema metadata (e.g. OpenAPI type/format: type: 'integer' or
format: 'int32') and add an integer validator (e.g. IsInt) alongside the
existing minimum/maximum constraints so generated docs/clients treat it as an
integer rather than a generic number.
In `@src/api/schemas/validatorProviderDtoTvlUsd.ts`:
- Around line 1-5: The ValidatorProviderDtoTvlUsd type is too permissive;
replace the broad index signature with a concrete numeric type to preserve type
safety — change ValidatorProviderDtoTvlUsd from "{ [key: string]: unknown } |
null" to "number | null" (or "string | number | null" if the API sometimes
returns strings) and update any call sites that currently assume an object to
parse/validate the scalar (e.g., use Number()/parseFloat() or runtime
validation) so consumers handle the numeric TVL value correctly.
In `@src/api/schemas/yieldRequirementsDto.ts`:
- Around line 3-5: The current type allows kycRequired: true with an undefined
kycUrl; change the type that defines kycRequired and kycUrl into a discriminated
union so that { kycRequired: true; kycUrl: string } is a separate variant from {
kycRequired: false; kycUrl?: undefined } (or { kycRequired?: false; kycUrl?:
string } as needed), update the type declaration that contains the kycRequired
and kycUrl properties accordingly, and adjust any places that construct or
consume this type to satisfy the new required kycUrl when kycRequired is true.
In `@src/api/schemas/yieldRiskCredoraDtoCurator.ts`:
- Around line 1-4: The documentation comment and the type for
YieldRiskCredoraDtoCurator disagree: the comment describes a scalar "curator
name" while the type is a map {[key: string]: unknown}. Decide which is correct
and make them consistent—if curator is a name change the type to string and
update the comment to "Credora curator name (string)"; if curator is an object
keep the mapped type but update the comment to "Credora curator object" and, if
possible, replace {[key: string]: unknown} with a more specific interface or
Record<string, unknown> named e.g., CredoraCurator to improve SDK clarity.
Ensure you update the symbol YieldRiskCredoraDtoCurator and its comment
together.
In `@src/api/schemas/yieldRiskDto.ts`:
- Around line 5-6: Update the JSDoc for the updatedAt property in yieldRiskDto
(updatedAt: string) to explicitly state the expected timestamp format (e.g.,
"ISO-8601 / RFC3339 string, UTC") and optionally include an example value;
ensure the schema comment for updatedAt clearly documents the canonical backend
format so SDK consumers know how to parse it.
In `@src/api/schemas/yieldRiskExponentialDtoUrl.ts`:
- Line 4: The exported type YieldRiskExponentialDtoUrl is overly permissive
({[key: string]: unknown}); tighten it to the real shape used by the API (for
example change YieldRiskExponentialDtoUrl to Record<string, string> or string |
Record<string, string> if the URL can be either a plain string or keyed params)
to preserve SDK type safety; update any callers or deserialization logic that
assume unknown values to handle the new narrower type (adjust parse/validation
in functions that consume YieldRiskExponentialDtoUrl).
In `@src/api/schemas/yieldsControllerGetYieldsNetwork.ts`:
- Around line 1-105: The YieldsControllerGetYieldsNetwork constant duplicates
network literals from transactionDtoNetwork; extract the shared network map into
a single exported constant (e.g., NETWORKS or SupportedNetworks) and have
YieldsControllerGetYieldsNetwork and transactionDtoNetwork.ts re-export or
reference that constant (update usages of YieldsControllerGetYieldsNetwork and
any type aliases that derive from it to point to the new shared symbol) so both
files use the single source-of-truth and avoid drift.
In `@src/api/schemas/yieldsControllerGetYieldTvlHistory429.ts`:
- Around line 1-6: Extract the repeated error shape into a shared HttpErrorDto
and a RateLimitedErrorDto that extends it (adding retryAfter), then update the
specific type YieldsControllerGetYieldTvlHistory429 to reuse these shared types
(e.g., type YieldsControllerGetYieldTvlHistory429 = RateLimitedErrorDto) so you
remove duplicated message/error/statusCode fields; add the new shared types in a
common schema file and replace other similar 400/401/429 types to reference
HttpErrorDto or RateLimitedErrorDto accordingly.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: ce12d743-6e21-4538-a1ab-ec78c118c8a0
📒 Files selected for processing (116)
.changeset/silly-jokes-start.mdsrc/api/index.msw.tssrc/api/index.tssrc/api/schemas/actionArgumentsDto.tssrc/api/schemas/actionArgumentsDtoInputTokenNetwork.tssrc/api/schemas/actionArgumentsDtoOutputTokenNetwork.tssrc/api/schemas/actionDto.tssrc/api/schemas/actionDtoType.tssrc/api/schemas/actionsControllerGetActionsNetwork.tssrc/api/schemas/actionsControllerGetActionsParams.tssrc/api/schemas/actionsControllerGetActionsStatus.tssrc/api/schemas/actionsControllerGetActionsStatusesItem.tssrc/api/schemas/actionsControllerGetActionsType.tssrc/api/schemas/actionsQueryDto.tssrc/api/schemas/actionsQueryDtoNetwork.tssrc/api/schemas/actionsQueryDtoStatusesItem.tssrc/api/schemas/actionsQueryDtoType.tssrc/api/schemas/allocationDto.tssrc/api/schemas/allocationDtoNetwork.tssrc/api/schemas/allocationDtoRewardRate.tssrc/api/schemas/allocationRewardRateDto.tssrc/api/schemas/argumentFieldDtoName.tssrc/api/schemas/balanceDto.tssrc/api/schemas/balanceHistorySnapshotDto.tssrc/api/schemas/balancesRequestDto.tssrc/api/schemas/createManageActionDtoAction.tssrc/api/schemas/curatorDto.tssrc/api/schemas/curatorDtoDescription.tssrc/api/schemas/curatorDtoLogoURI.tssrc/api/schemas/curatorDtoName.tssrc/api/schemas/getBalancesArgumentsDto.tssrc/api/schemas/index.tssrc/api/schemas/liquidityStateDto.tssrc/api/schemas/liquidityStateDtoLiquidity.tssrc/api/schemas/liquidityStateDtoUtilization.tssrc/api/schemas/networkDtoId.tssrc/api/schemas/networks.tssrc/api/schemas/pendingActionDto.tssrc/api/schemas/pendingActionDtoType.tssrc/api/schemas/rewardDtoYieldSource.tssrc/api/schemas/rewardEventDto.tssrc/api/schemas/rewardRateHistoryResponseDto.tssrc/api/schemas/rewardRateHistoryResponseDtoInterval.tssrc/api/schemas/rewardRateSnapshotDto.tssrc/api/schemas/riskParameterDto.tssrc/api/schemas/riskParameterDtoAsset.tssrc/api/schemas/riskParameterDtoIntegrationId.tssrc/api/schemas/riskParameterDtoProtocol.tssrc/api/schemas/riskParameterDtoValue.tssrc/api/schemas/tokenDtoNetwork.tssrc/api/schemas/transactionDtoNetwork.tssrc/api/schemas/transactionDtoType.tssrc/api/schemas/tvlHistoryResponseDto.tssrc/api/schemas/tvlHistoryResponseDtoInterval.tssrc/api/schemas/tvlSnapshotDto.tssrc/api/schemas/validatorProviderDto.tssrc/api/schemas/validatorProviderDtoTvlUsd.tssrc/api/schemas/validatorProviderDtoType.tssrc/api/schemas/yieldBalancesDto.tssrc/api/schemas/yieldBalancesDtoRewardRate.tssrc/api/schemas/yieldDto.tssrc/api/schemas/yieldDtoNetwork.tssrc/api/schemas/yieldMechanicsDto.tssrc/api/schemas/yieldQueryDto.tssrc/api/schemas/yieldQueryDtoNetwork.tssrc/api/schemas/yieldQueryDtoSort.tssrc/api/schemas/yieldRequirementsDto.tssrc/api/schemas/yieldRiskCredoraDto.tssrc/api/schemas/yieldRiskCredoraDtoCurator.tssrc/api/schemas/yieldRiskCredoraDtoPsl.tssrc/api/schemas/yieldRiskCredoraDtoPublishDate.tssrc/api/schemas/yieldRiskCredoraDtoRating.tssrc/api/schemas/yieldRiskCredoraDtoScore.tssrc/api/schemas/yieldRiskDto.tssrc/api/schemas/yieldRiskExponentialDto.tssrc/api/schemas/yieldRiskExponentialDtoPoolRating.tssrc/api/schemas/yieldRiskExponentialDtoPoolScore.tssrc/api/schemas/yieldRiskExponentialDtoRatingDescription.tssrc/api/schemas/yieldRiskExponentialDtoUrl.tssrc/api/schemas/yieldStateDto.tssrc/api/schemas/yieldsControllerGetBalanceHistory200.tssrc/api/schemas/yieldsControllerGetBalanceHistory200AllOf.tssrc/api/schemas/yieldsControllerGetBalanceHistory400.tssrc/api/schemas/yieldsControllerGetBalanceHistory401.tssrc/api/schemas/yieldsControllerGetBalanceHistory429.tssrc/api/schemas/yieldsControllerGetBalanceHistory500.tssrc/api/schemas/yieldsControllerGetBalanceHistoryInterval.tssrc/api/schemas/yieldsControllerGetBalanceHistoryParams.tssrc/api/schemas/yieldsControllerGetBalanceHistorySort.tssrc/api/schemas/yieldsControllerGetYieldRewardRateHistory400.tssrc/api/schemas/yieldsControllerGetYieldRewardRateHistory401.tssrc/api/schemas/yieldsControllerGetYieldRewardRateHistory429.tssrc/api/schemas/yieldsControllerGetYieldRewardRateHistory500.tssrc/api/schemas/yieldsControllerGetYieldRewardRateHistoryInterval.tssrc/api/schemas/yieldsControllerGetYieldRewardRateHistoryParams.tssrc/api/schemas/yieldsControllerGetYieldRewardRateHistoryPeriod.tssrc/api/schemas/yieldsControllerGetYieldRewards400.tssrc/api/schemas/yieldsControllerGetYieldRewards401.tssrc/api/schemas/yieldsControllerGetYieldRewards429.tssrc/api/schemas/yieldsControllerGetYieldRewards500.tssrc/api/schemas/yieldsControllerGetYieldRewardsParams.tssrc/api/schemas/yieldsControllerGetYieldRewardsSort.tssrc/api/schemas/yieldsControllerGetYieldRisk400.tssrc/api/schemas/yieldsControllerGetYieldRisk401.tssrc/api/schemas/yieldsControllerGetYieldRisk429.tssrc/api/schemas/yieldsControllerGetYieldRisk500.tssrc/api/schemas/yieldsControllerGetYieldTvlHistory400.tssrc/api/schemas/yieldsControllerGetYieldTvlHistory401.tssrc/api/schemas/yieldsControllerGetYieldTvlHistory429.tssrc/api/schemas/yieldsControllerGetYieldTvlHistory500.tssrc/api/schemas/yieldsControllerGetYieldTvlHistoryInterval.tssrc/api/schemas/yieldsControllerGetYieldTvlHistoryParams.tssrc/api/schemas/yieldsControllerGetYieldTvlHistoryPeriod.tssrc/api/schemas/yieldsControllerGetYieldsNetwork.tssrc/api/schemas/yieldsControllerGetYieldsParams.tssrc/api/schemas/yieldsControllerGetYieldsSort.ts
Comment on lines
+2
to
+5
| "@yieldxyz/sdk": patch | ||
| --- | ||
|
|
||
| feat: update schemas |
There was a problem hiding this comment.
Use a minor changeset for additive SDK API surface.
Line 2 marks this as patch, but this PR introduces new endpoints and exported schema types. That’s an additive feature release and should be signaled as minor.
Proposed changeset update
---
-"@yieldxyz/sdk": patch
+"@yieldxyz/sdk": minor
---
feat: update schemas📝 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
| "@yieldxyz/sdk": patch | |
| --- | |
| feat: update schemas | |
| "@yieldxyz/sdk": minor | |
| --- | |
| feat: update schemas |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.changeset/silly-jokes-start.md around lines 2 - 5, The changeset currently
marks the SDK update as a patch but this PR adds new endpoints and exported
schema types, so update the changeset entry that reads "@yieldxyz/sdk": patch to
use minor instead (i.e., change "patch" to "minor") so the release correctly
reflects an additive API change.
Comment on lines
+1
to
+5
| /** | ||
| * Utilization rate as a decimal (e.g., 0.8 = 80%) | ||
| * @nullable | ||
| */ | ||
| export type LiquidityStateDtoUtilization = { [key: string]: unknown } | null; |
There was a problem hiding this comment.
Type definition conflicts with its own contract.
Line 2 documents a decimal utilization rate, but Line 5 types it as an arbitrary object or null. This is a schema correctness issue and will propagate incorrect typing to SDK consumers.
Proposed fix
/**
* Utilization rate as a decimal (e.g., 0.8 = 80%)
* `@nullable`
*/
-export type LiquidityStateDtoUtilization = { [key: string]: unknown } | null;
+export type LiquidityStateDtoUtilization = number | null;🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@src/api/schemas/liquidityStateDtoUtilization.ts` around lines 1 - 5, The
JSDoc for LiquidityStateDtoUtilization says it should be a decimal utilization
rate but the type alias LiquidityStateDtoUtilization is currently { [key:
string]: unknown } | null; change the type to number | null (or a
branded/decimal type your codebase uses) so the type matches the documented
contract and update the JSDoc if you use a specific numeric format; ensure any
references to LiquidityStateDtoUtilization in validation/conversion functions
are adjusted to treat it as a numeric value rather than an object.
Comment on lines
+14
to
+15
| /** Raw reward amount in base units (wei) */ | ||
| amountRaw: string; |
There was a problem hiding this comment.
Make amountRaw unit description chain-agnostic.
wei is EVM-specific and may mislead for non-EVM rewards. Use “smallest denomination/base units” wording instead.
Suggested diff
- /** Raw reward amount in base units (wei) */
+ /** Raw reward amount in the token's smallest denomination */
amountRaw: string;📝 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
| /** Raw reward amount in base units (wei) */ | |
| amountRaw: string; | |
| /** Raw reward amount in the token's smallest denomination */ | |
| amountRaw: string; |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@src/api/schemas/rewardEventDto.ts` around lines 14 - 15, Update the JSDoc for
the amountRaw property in rewardEventDto.ts to be chain-agnostic: replace the
EVM-specific "wei" wording with a neutral phrase like "smallest denomination
(base units)" or "base units / smallest denomination" so the comment now reads
that amountRaw is the raw reward amount in base units (smallest denomination)
and does not reference EVM-specific terminology; locate the amountRaw property
in the RewardEvent DTO to apply this change.
Comment on lines
+3
to
+18
| export interface TvlHistoryResponseDto { | ||
| /** Total number of items available */ | ||
| total: number; | ||
| /** Offset of the current page */ | ||
| offset: number; | ||
| /** Limit of the current page */ | ||
| limit: number; | ||
| /** Unique identifier of the yield */ | ||
| yieldId: string; | ||
| /** Sampling interval used for this response */ | ||
| interval: TvlHistoryResponseDtoInterval; | ||
| /** Start of the returned date range (ISO 8601) */ | ||
| from: string; | ||
| /** End of the returned date range (ISO 8601) */ | ||
| to: string; | ||
| } |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify whether TVL history payload data is modeled elsewhere and how the endpoint is typed.
# 1) List TVL-related schema files
fd -i 'tvl' src/api/schemas
# 2) Inspect history response DTO patterns for payload-bearing fields (e.g., data/items/snapshots)
rg -n -C3 'interface .*HistoryResponseDto|data:|items:|snapshots:' src/api/schemas
# 3) Inspect API wiring for /tvl/history return type usage
rg -n -C4 'getYieldTvlHistory|/tvl/history|customFetch<' src/api/index.tsRepository: stakekit/sdk
Length of output: 11516
🏁 Script executed:
# Read the complete tvlHistoryResponseDto file
cat -n src/api/schemas/tvlHistoryResponseDto.ts
# Read the tvlSnapshotDto file to see the data model
cat -n src/api/schemas/tvlSnapshotDto.ts
# Check rewardRateHistoryResponseDto for comparison (similar pattern)
cat -n src/api/schemas/rewardRateHistoryResponseDto.tsRepository: stakekit/sdk
Length of output: 1805
🏁 Script executed:
# Search for tests or usage of getYieldTvlHistory and TvlHistoryResponseDto
rg -n 'getYieldTvlHistory|TvlHistoryResponseDto' --type ts --type tsx -A 3 -B 1 | head -50
# Check if there are any comments or TODOs about missing fields
rg -n 'TODO|FIXME' src/api/schemas/tvlHistoryResponseDto.ts
# Look for balancesResponseDto pattern to compare with history response
cat -n src/api/schemas/balancesResponseDto.tsRepository: stakekit/sdk
Length of output: 469
🏁 Script executed:
# Look for test files related to TVL history
fd -e test.ts -e spec.ts -e test.tsx . | head -20
# Search for any TVL history usage in the codebase
rg 'getYieldTvlHistory' -A 5 -B 1
# Check if there are examples or integration files
fd -e example.ts -e example.tsx -e integration.ts .Repository: stakekit/sdk
Length of output: 784
🏁 Script executed:
# Check if there's any schema/OpenAPI definition file that might show the actual structure
fd -e openapi -e swagger -e schema.json . | head -10
# Look for any type generation configuration
fd -e codegen -e openapi.config -e schema .
# Check git history or comments in the DTO file for any hints
git log --oneline -n 10 src/api/schemas/tvlHistoryResponseDto.ts 2>/dev/null || echo "Git history not available"Repository: stakekit/sdk
Length of output: 84
Add missing data field to hold TVL history snapshots.
TvlHistoryResponseDto contains pagination and metadata fields but lacks a field for the actual history snapshots. The DTO should include a field like snapshots: TvlSnapshotDto[] to hold the time series data. Note that the same issue appears in RewardRateHistoryResponseDto—both should follow the pattern established by BalancesResponseDto, which correctly includes an items field for its payload data.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@src/api/schemas/tvlHistoryResponseDto.ts` around lines 3 - 18, Add the
missing payload array to the DTOs: update TvlHistoryResponseDto to include a
snapshots field of type TvlSnapshotDto[] (or items: TvlSnapshotDto[] if you want
to match BalancesResponseDto naming) so the time-series data is returned with
the metadata, and make the analogous change in RewardRateHistoryResponseDto to
include an array field (e.g., snapshots: RewardRateSnapshotDto[] or items:
RewardRateSnapshotDto[]) to mirror the BalancesResponseDto pattern and ensure
the API returns the history snapshots.
Comment on lines
+1
to
+4
| /** | ||
| * Exponential pool score (1-5) | ||
| */ | ||
| export type YieldRiskExponentialDtoPoolScore = { [key: string]: unknown }; |
There was a problem hiding this comment.
Type contradicts documented scalar score range (1–5).
The comment documents a numeric score, but the exported type allows an arbitrary object. This weakens the public contract and can cause incorrect consumer integrations.
Proposed fix
/**
* Exponential pool score (1-5)
*/
-export type YieldRiskExponentialDtoPoolScore = { [key: string]: unknown };
+export type YieldRiskExponentialDtoPoolScore = 1 | 2 | 3 | 4 | 5;📝 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
| /** | |
| * Exponential pool score (1-5) | |
| */ | |
| export type YieldRiskExponentialDtoPoolScore = { [key: string]: unknown }; | |
| /** | |
| * Exponential pool score (1-5) | |
| */ | |
| export type YieldRiskExponentialDtoPoolScore = 1 | 2 | 3 | 4 | 5; |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@src/api/schemas/yieldRiskExponentialDtoPoolScore.ts` around lines 1 - 4, The
exported type YieldRiskExponentialDtoPoolScore currently allows any object but
should represent a numeric score 1–5; change the declaration of
YieldRiskExponentialDtoPoolScore to a concrete numeric type (preferably the
literal union 1|2|3|4|5 or at minimum number with a JSDoc comment) and adjust
any callers/validators to accept that numeric type (or perform runtime
validation) so the public contract matches the comment and prevents arbitrary
objects from being passed.
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
2 participants
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
Improvements