Skip to content

Conversation

@yeager-eren
Copy link
Collaborator

@yeager-eren yeager-eren commented Jan 6, 2026

Summary

َUsing preconditions from server and make checking the trustline a separate step.

In the first implementation we were checking a user needs a trustline or not in client. there are some cases for the determining the trustline should be open first are hard, e.g. bridge a token into xrpl and a non-native token. we handed over this to server, now each transaction has a preconditions field which tell us to run the actual transaction what we need to first do. so here we are using this new approach.

Another change is make the check of trustline a separate step to break the process into smaller steps and in future we can integrate stellar more easily and also evm approvals.

Fixes RF-2294

Part of #1096
Blocked by rango-exchange/rango-types#57

How did you test this change?

you can test in #1096

do some transactions as followed:

  • xrpl native token to whatever in xrpl
  • whatever xrpl token to xrpl native token
  • bridge

Checklist:

  • I have performed a self-review of my code
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation
  • I have added tests that prove my fix is effective or that my feature works
  • Implemented a user interface (UI) change, referencing our Figma design to ensure pixel-perfect precision.


const hasAlreadyProceededToSign =
typeof swap.hasAlreadyProceededToSign === 'boolean';
const hasAlreadyProceededToSign = !!swap.hasAlreadyProceededToSign;
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is important change. if hasAlreadyProceededToSign was false, the old check was changing it to true at the end.

setTransactionDataByHash(hash, { response });
}
const { schedule, next } = actions;
updateStorageOnSuccessfulSign(actions, { hash, response }, data);
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the problem here was handleSuccessfulSign always schedule CHECK_TRANSACTION_STATUS as next step but in check trustline the next step is EXECUTE_XRPL_TRANASCTION.

@yeager-eren yeager-eren force-pushed the chore/rf-add-check-trust-line-using-preconidtions branch from e9a6a08 to df4988c Compare January 6, 2026 13:00
} else {
schedule(SwapActionTypes.EXECUTE_TRANSACTION);
}
schedule(SwapActionTypes.SCHEDULE_NEXT_STEP);
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

important change. ensure doesn't affect the non-xrpl flow.

@yeager-eren yeager-eren mentioned this pull request Jan 6, 2026
5 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants