Add optional recipient field for intent outputs

[Asem-Abdelhady]

Linear: https://linear.app/lifi-linear/issue/V2-116/add-recipient-field-on-lintentorg

Summary

• Adds an optional recipient field to global store (state.svelte.ts)
• Surfaces a Recipient address input in the IssueIntent screen (accepts any EVM address, validates on-the-fly)
• Threads outputRecipient through intentFactory.ts to toCoreCreateIntentOptions for both compact and escrow paths

Notes

• Stacked on asem/V2-109/accommodate-intent.ts-solana-changes
• Field is optional — leaving it blank uses the default recipient behaviour from the intent library

Test plan

• Open IssueIntent screen, verify Recipient input appears under the Verifier controls
• Enter an invalid string — confirm the field turns red (error state)
• Enter a valid EVM address — confirm error state clears
• Submit an intent with a custom recipient and verify the order's output recipient reflects the input address

Expected output

Screen.Recording.2026-04-07.at.1.15.16.PM.mov

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 986510fe-5e1d-46a0-9077-05be63d26ad5

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feature/v2-116-add-recipient-field-on-lintentorg

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[reednaa]

Closes: V2-116

[lifi-qa-agent]

🔍 QA Review — V2-116

🔗 Linear Ticket · Pull Request #41

⚠️ Note: No write access to lifinance/lintent — formal GitHub review actions (CHANGES_REQUESTED / APPROVE) are blocked. All findings posted as plain comments.

⚠️ Stacked PR: This PR is stacked on asem/V2-109/accommodate-intent.ts-solana-changes (lintent PR #39, ticket V2-109). It cannot be merged before V2-109 is merged. The V2-109 review has identified a High issue (.claude/settings.local.json committed) that must also be resolved before this stack lands.

🧠 What this ticket does

Adds an optional Recipient address field to the lintent.org intent issuance UI. The field accepts any EVM address and, when populated, threads outputRecipient through intentFactory.ts → toCoreCreateIntentOptions() → the @lifi/intent library. When left blank, intent output defaults to the connected wallet address.

Verdict: Needs Work — 1 Medium (no test verifying outputRecipient threads through to the submitted order's outputs), 1 Low (duplicate helper). Test plan item "Submit an intent with a custom recipient" is unchecked.

---

📋 Ticket Summary

Add Recipient field on lintent.org

Acceptance Criteria:

1. Field on lintent.org where an address can be entered and the target tokens are rerouted to this address — ✅ Met: IssueIntent.svelte adds a "Recipient" text input, validated via resolveRecipient(), bound to store.recipient, passed as outputRecipient in both compact and escrow paths in intentFactory.ts.

Testing Notes:

• Works for same-chain — ⚠️ Unit tests cover address validation only; full intent submission with custom recipient unverified
• Works for multi-chain — ⚠️ Unverified

---

🏷️ PR Naming — ❌ Fail

Add optional recipient field for intent outputs — missing ticket prefix and type prefix. Expected: [V2-116] feat: Add optional recipient field for intent outputs

---

✅ Ticket Coverage — Medium

AC item is met — field is present and wired up correctly through the intent options (both compact and escrow paths). However, the test plan confirms E2E intent submission with a non-default recipient is unverified. The threading path (store.recipient → resolveRecipient → outputRecipient → toCoreCreateIntentOptions) is covered only for the address validation helper in isolation, not for the final order output shape.

---

⚠️ Issues Found (2)

#	Severity	Type	Issue / File
1	🟠 Medium	Test gap	No test verifying outputRecipient threads through to the submitted order's outputs — tests/unit/recipientField.test.ts
2	🟢 Low	Code	resolveRecipient duplicates resolveExclusiveFor in IssueIntent.svelte

🟠 [Medium] No test verifying outputRecipient threads through to order outputs — tests/unit/recipientField.test.ts

The existing recipientField.test.ts covers resolveRecipient() in isolation (address validation helper). The test plan's final item — "Submit an intent with a custom recipient and verify the order's output recipient reflects the input address" — is unchecked. No test verifies the full path: store.recipient set → resolveRecipient() produces address → intentOptions.outputRecipient populated → toCoreCreateIntentOptions() passes it through → the created order's output contains the custom recipient.

Add to tests/unit/recipientField.test.ts or tests/unit/intentFactory.test.ts (new):

• toCoreCreateIntentOptions() with outputRecipient: "0xABCD..." → CreateIntentOptions.outputRecipient equals "0xABCD..."
• toCoreCreateIntentOptions() without outputRecipient → CreateIntentOptions.outputRecipient is undefined (default behaviour preserved)

🟢 [Low] resolveRecipient in IssueIntent.svelte duplicates resolveExclusiveFor

Both helpers are identical one-liners:

const resolveExclusiveFor = (value: string): `0x${string}` | undefined =>
  isAddress(value, { strict: false }) ? value : undefined;

const resolveRecipient = (value: string): `0x${string}` | undefined =>
  isAddress(value, { strict: false }) ? value : undefined;

Extract to a shared utility (e.g. $lib/utils/address.ts → resolveAddress()) to avoid drift if validation logic changes.

---

🧪 Test Coverage

Layer	Score	Files reviewed
Unit	Partial	tests/unit/recipientField.test.ts
Integration	N/A	UI library
E2e	None	Manual test plan — final item unchecked

Unit gaps:

• [Medium] Full intent-factory threading test for outputRecipient (see issue Overhaul UI to have better logic flow and separation #1 above)

---

🔗 Downstream Impact

No blocking relations. Stacked on V2-109 (lintent PR #39) — V2-109 must land first.

---

QA Agent (lifi-qa-agent[bot]) — 2026-05-06