Open
Conversation
Signed-off-by: georgi <georgi@li.finance>
Signed-off-by: georgi <georgi@li.finance>
Signed-off-by: georgi <georgi@li.finance>
glarov95
force-pushed
the
core-213-intermediary-fee-types
branch
from
d40b155 to
0ea7b4a
Compare
glarov95
changed the title
Signed-off-by: georgi <georgi@li.finance>
Signed-off-by: georgi <georgi@li.finance>
- Rename `FeeRecipientType` → `FeeSplitType` (consistent with the backend internal name and the CORE-252 PR description). - Add `'DISTRIBUTION'` to the union — emitted on the wire by CORE-252 partner-distribution recipients. - Align `FeeRecipient` field names with the wire shape the backend has been emitting since CORE-214: - `integration` → `name` - `feeType` → `type` (now optional, matching `feeSplit.recipients[].type`) Mirrors the consolidated CORE-213/214/252 shape in lifi-backend (`utils/helpers.ts:FeeRecipient`, `feeCollection.ts:118-124`, `statusService.evm.utils.ts:624`).
- Per-member JSDoc on FeeSplitType (FIXED / SHARED / DYNAMIC / INTERMEDIARY / DISTRIBUTION) so SDK consumers understand each value; recommend a default branch when narrowing since the union is expected to grow. - Document the polymorphic FeeRecipient.name (lifi / integrator id / intermediary id / wallet address depending on type) and the UX hazard of rendering it raw without type-aware formatting. - Document FeeRecipient.type? optionality so consumers null-check. - Spell out FeeCost.feeSplit aggregate semantics: integratorFee is the sum of every non-LiFi recipient (and includes intermediaryFee); intermediaryFee is absent when no intermediary participates. Warn against summing the legacy aggregates to derive the parent amount.
Earlier wording described `integratorFee` as the sum of every non-LiFi recipient (with `intermediaryFee` already included). The backend now emits disjoint slices end-to-end: `lifiFee`, `integratorFee` (integrator only), `intermediaryFee` (only when present). Distribution-recipient amounts surface only on `recipients[]` entries tagged `DISTRIBUTION`. Update the JSDoc to match. The three legacy aggregate fields plus distribution recipients sum to the parent `FeeCost.amount`.
Earlier wording implied the disjoint slices summed to the parent amount via `recipients[]` of `type: 'DISTRIBUTION'` entries on the same `feeSplit`. In practice partner-distribution recipients are emitted as separate `FeeCost` entries (one per receiver, name "Fee Forward") at quote/route estimation time, while at status time they may appear merged on the integrator's `FeeCost` for compactness. Update the JSDoc to scope the slice contract to a single `FeeCost` and note where distribution recipients live across estimate vs status.
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.
Which Linear task is linked to this PR?
Why was it implemented this way?
Explain the reasoning behind the implementation. Were there alternative approaches? Why was this solution chosen?
Visual showcase (Screenshots or Videos)
If applicable, attach screenshots, GIFs, or videos to showcase the functionality, UI changes, or bug fixes.
Checklist before requesting a review