To run the application, user will first need to deploy the gatewayImpl contract themselves as owner, then deploy contracts with gateway address.

In short, you need to execute the deployment script for the gatewayImpl(so you are the "auth" user), then with your deployed gatewayImpl address as constructor arguement, deploy all contract you want to intereact with (and optionally verify them), and update the backend and frontend const file with your contract address and multisig address.

For detail of deployment, refer to readMe in the Defi folder.

Then the user need the set up the backend. This involving connecting to database, run the migration file, and finally start the spring-boot server(s). You will need to modify the properties file, and possibly modify CROS config.

For detail of how to run the backend, refer to the backend readMe

Lastly, you can run the frontend and access our feature.

The XRP Ledger (XRPL) offers a fast, low-cost, and dependable platform for value transfer. Components like decentralized exchange (DEX), Automated Market Maker(AMM) and a native USD stablecoin provides a solid foundation for exchange and payment operations.

However, a significant challenge remains for XRPL users: efficiently and securely accessing USD beyond simple swaps and direct sales. While the XRPL provides a basic AMM for direct swaps and a USD stablecoin, the lack of advanced programmability, specifically robust smart contract capabilities, greatly limits options for users who are trying to convert their XRP to USD by advanced means, such as via collateralized lending or derivatives.

Users are forced to resort to manual bridging to other blockchains. This process is slow, expensive, cumbersome, and carries a substantial risk of bridge exploits and slippage. This results in an inefficient process that acts as a major barrier to users who need a reliable way to liquify their XRP holdings. These practices of obtaining USD from XRPL are thus expensive and inefficient, therefore costing users, who are in need of cost-effective alternatives to fulfill their financial needs.

The current fragmented landscape also presents another major challenge, as users must navigate various exchanges, bridges, and dApps to execute their financial activities. This fragmented approach leads to a poor user experience, requiring a great amount of user effort, and limited the sophisticated financial instruments to the users. There is a clear need for a unified platform to streamline this process and provide access to more sophisticated financial strategies for users to leverage their XRP to obtain USD.

The introduction of the XRPL EVM Sidechain, along with the integrated Axelar General Message Passing (GMP) technology, offers a chance to address this need. The EVM sidechain provides the necessary smart contract programmability for sophisticated financial applications, and Axelar GMP eliminates the need for manual bridging, making cross-chain transactions secure and seamless. This is a golden opportunity to deliver a cost-effective and comprehensive solution for users to leverage their XRP for USD. Our platform directly aims to tackle this issue, thus providing users a reliable, secure and efficient way to unlock the potential of their XRP holdings, while mitigating the risks of manual bridging.

Our solution is an all-in-one platform, that allows users to seamlessly engage with sophisticated financial instruments to leverage their XRP to obtain USD . This platform leverages the combined power of the XRPL, the XRPL EVM Sidechain, and Axelar GMP, all in a unified interface that allows users to convert their XRP to USD via multiple advanced methods including but not limited to collateralized lending, sale via the AMM, or investment in derivatives. This is done with great user convenience as all the functions are provided in a single place, and completely abstract away the complexity of bridging, and allows users to focus on the benefits without technical worries.

At the core of our platform are Axelar-executable smart contracts on the EVM Sidechain. These contracts enable a suite of powerful financial functionalities, available through a single, user-friendly interface on the XRPL network. Our platform monitors both the XRPL and EVM chain states via a backend to provide timely and correct data for the user. The platform offers the following core features:

• Pool-Based Lending (Pledge): Users can deposit XRP as collateral to borrow USD with flexible duration and a fixed interest rate and collateral ratio. This provides a simple and reliable method to obtain USD against their XRP holdings.
• Peer-to-Peer (P2P) Lending: Connecting lenders and borrowers directly, this feature enables negotiation of customized terms, including loan duration, collateralization ratios, interest rates, and liquidation thresholds, offering more control and flexibility to the user.
• Options Trading: Users can issue, buy, sell, and exercise call and put options based on XRP's price. This is a tool for users to manage their loan risks and participate in derivative trading.
• XRPL's Native AMM: In addition to these advanced functions, our platform integrates the XRPL's native AMM, allowing a simple method for users to swap between XRP and USD. Users can also deposit and withdraw funds from the AMM pool to earn trading fees and access immediate liquidity.

These diverse features are designed to give users a flexible approach to convert their XRP to USD based on their different needs and preferences. The user always interacts with the XRPL frontend, while our backend, along with GMP, handles all the complex cross-chain interactions, and abstract away the complexity of manual bridging. Users are never exposed to the complexity of EVM sidechain, while maintaining transparency, as all transactions are stored and easily accessible for verification. Our backend monitors and stores chain states to provide a fast and reliable service. The system is trust-free due to the security and trust of Axelar's GMP.

Our platform offers more than just simple swaps, but also allows users to better leverage the value of their XRP, and is designed to be the first and only stop for any XRPL users who need USD. By unifying all of the financial tools in a single platform, we not only eliminate the fragmentation that is currently being experienced by the users, but also unlock the full potential of XRPL and its new EVM sidechain.

There are four major components in our project. They are frontend, backend, smart contracts and Axelar Network Mock.

fig 1: Four components of the project

The Frontend serves as the user interface, providing views and handling user actions. The Backend listens for contracts’ events, mirrors and stores the chain’s state off chain. The PoolLending, P2PLending, OptionTrading contracts handle the logic and transactions. The Axelar Network is a special component and resides in both the “backend” and “Defi” directory in the source code of our project. The backend portion serves the role of “Axelar Network” and the smart contract portion serves as gateway.

fig 2: High level interaction between components

fig 3: Details of how frontend interacts with contracts on EVM chain

When the frontend interacts with contracts on EVM, it does so via General Message Pass call(GMP). It first sends a GMP call (a special type of transaction with fixed format of memos) to the multiSig address on the XRPL chain. The Axelar network mock in the backend will monitor for incoming GMP calls, and ask the gateway to approve it.

Users then need to send the payload to our backend, who will “kindly” inform the Axelar network to execute the contract call provided the payload matches the payload hash provided earlier. Then, Deployed AxelarExecutable Contracts will depend on gateway to validate the input, mint the token transfer, and handle the business logic.

fig 4: Details of how contract interacts with frontend

Contract can interact with the user via two means: emit events and transfer token.

When contracts emit events, it will be monitored, processed by the backend to provide user with up to date contract information while relieving computing, storing heavy tasks from the frontend.

The contract can also transfer the token it processed by making a call to the gateway. When approved, gateway will emit a TokenSent event, which will be processed by the Axelar network and processed accordingly.

This section details the technical architecture and implementation of our backend system, which is built using Java with the Spring Boot framework. This backend serves as the central hub for managing data, interacting with the XRPL and EVM sidechain, and providing APIs for the frontend.

The backend follows a layered, microservice architecture.

fig 5: Micro-service architecture of backend

Each component(p2p lending, option, pool lending) can run independently and be deployed, scaled, and updated without affecting the others, with a clearly defined responsibility.

Although currently, for the sanity of the developer, we have written them in the same backend server, each component could be scaled horizontally based on demand independently.

fig 6: Layered architecture of each service

Inside each service, it follows a layered architecture:

Controller Layer: Exposes RESTful APIs for the frontend to interact with the platform. These controllers handle incoming requests, validate data, and return appropriate responses. Key controllers include GmpInfoController, OptionController, P2pController, and PledgeController.

Service Layer: Contains the core business logic of the application. This layer orchestrates the data flow between controllers and repositories and implements the application’s specific financial logic. For example, the P2pBorrowingRequestService, P2pLendingRequestService, and P2pLoanService manage P2P lending functionalities.

Repository Layer: Interacts with the database using Spring Data JPA repositories. This layer handles database queries, data persistence, and entity management. Examples include GmpInfoRepository, OptionRepository, P2pBorrowingRequestRepository, and PoolLendingBorrowerRepository. Each entity has its corresponding repository.

Entity Layer: Represents the database tables as Java objects, using JPA annotations to map tables, columns, and relationships. This layer includes entities like GmpInfo, Option, P2pBorrowingRequest, PoolLendingBorrower, and more. These entities are designed to store the current application state.

Event Listener Layer: Asynchronously listens to smart contract events on EVM Sidechain. Upon detecting specific events (such as OptionIssued, LoanCreated), it triggers the relevant data update in our database to reflect the on-chain state.

fig 7： Option trading schema

fig 8: P2P lending schema

fig 9: Pool lending schema

• Language: Java 11
• Framework: Spring Boot
• Database: PostgreSQL
• ORM: Spring Data JPA with Hibernate
• Web Server: Embedded Tomcat (provided by Spring Boot)
• Web3j: For interacting with the EVM sidechain
• Xrpl4j: For interacting with the XRPL
• Axelar GMP: Utilized through custom smart contracts and backend logic
• Build Tool: Maven

This section describes the technical implementation of our frontend application. It is built using React, leveraging various libraries and tools to create a user-friendly and interactive experience.

fig 10: Frontend architecture

The frontend is structured as a single-page application (SPA), following a component-based architecture:

Components: The UI is broken down into reusable components, organized by feature or functionality. These include presentational components (e.g., PriceInfo, PieInfo, InputCard), layout components (e.g., WebsiteNavbar, InitLoader), and business-logic-heavy components (e.g., P2pDashboard, PledgePage).

Pages: Represents individual views or routes in the application. Examples include Home, Wallet, PoolPage, P2pPage, SwapPage, and FuturePage.

Hooks: Custom hooks (usePriceState, useConnectedWallet, useP2pLendingState,usePoolLendingState) are used to encapsulate business logic, manage state, and facilitate interaction with the backend API. They can be thought of as service classes in the backend.

API Layer: The /api/backend and /api/contract directories contain modules to interact with the backend API and smart contracts on EVM.

State Management: Recoil manages the application state, enabling efficient data sharing and updates across components.

• Build Tool: Vite
• Library: React
• State Management: Recoil
• Routing: React Router
• UI Library: Material UI (MUI)
• Charting: Recharts
• HTTP Client: Axios
• Styling: CSS Modules & MUI Styling
• Language: Typescript
• Chain activities: Xrpl

This section outlines the technical details of the smart contracts developed for our platform, focusing on their architecture, functionality, and interactions within the XRPL EVM Sidechain. We will use Solidity as the smart contract language.

The core of our smart contract implementation revolves around several key components:

Common: To leverage Axelar's General Message Passing (GMP) to enable cross-chain communication and token transfers. We utilize abstract contracts AxelarExecutable.sol and AxelarExecutableWithToken.sol to establish a base. The XRPFIATBinancePriceOracle.sol contract is responsible for fetching and storing the current prices of XRP against various fiat currencies from Binance.

MyAxelarGatewayImpl.sol: The gateway contract itself

OptionTrading.sol: Handles the issuance, trading, and exercise of call and put options.

XrpLendingP2P.sol: Implements peer-to-peer lending functionalities including loan requests, offers, repayments, and liquidations.

XrpLendingPool.sol: implements pool based lending functionalities including lending, borrowing, and reward calculation.

MyAxelarGatewayImp:https://explorer.xrplevm.org/address/0x31126a0BCf78cF10c8dC4381BF8A48a710df5978

XrpLendingP2PV5:https://explorer.xrplevm.org/address/0x9bB6D34405F7014979694242F4373fe83d038827

XrpLendingPoolV5:https://explorer.xrplevm.org/address/0x73f58074490bA15216B5eE88f6Be96FbD729e6A6

OptionTrading:https://explorer.xrplevm.org/address/0x82189dEeeC0310fd147f2423093f4B1F8F95BFc8

This contract acts as a gateway for cross-chain communication and token transfers using the Axelar network. It manages the approval and execution of contract calls and token transfers.

Methods:

• constructor(address authModule_): Initializes the contract, setting the authModule address.
• sendToken(string destinationChain, string destinationAddress, string symbol, uint256 amount): Burns (or locks) a specified amount of tokens from the sender's balance and emits a TokenSent event.
• isContractCallApproved(bytes32 commandId, string sourceChain, string sourceAddress, address contractAddress, bytes32 payloadHash): Checks if a contract call has been approved by the gateway.
• isContractCallAndMintApproved(bytes32 commandId, string sourceChain, string sourceAddress, address contractAddress, bytes32 payloadHash, string symbol, uint256 amount): Checks if a contract call with a token transfer has been approved.
• validateContractCall(bytes32 commandId, string sourceChain, string sourceAddress, bytes32 payloadHash): Validates a contract call, marking it as executed and emits a ContractCallExecuted event if valid.
• validateContractCallAndMint(bytes32 commandId, string sourceChain, string sourceAddress, bytes32 payloadHash, string symbol, uint256 amount): Validates a contract call with a token transfer, marks it as executed and mints tokens to the msg.sender if valid.
• isCommandExecuted(bytes32 commandId): Checks if a command has been executed based on its command ID.
• execute(bytes input): Executes a batch of commands (approving contract calls or calls with mint) signed by the Axelar network. Emits an Executed event if successful.
• approveContractCall(bytes params, bytes32 commandId): Approves a contract call and emit a ContractCallApproved event. (Called by this contract itself)
• approveContractCallWithMint(bytes params, bytes32 commandId): Approves a contract call with a token transfer and emit a ContractCallApprovedWithMint event. (Called by this contract itself)
• _mintToken(string symbol, address account, uint256 amount): Mocks the minting of specified token to an account.
• _burnTokenFrom(address sender, string symbol, uint256 amount): Mocks the burning of tokens from a sender's balance.

Events:

• TokenSent(address sender, string destinationChain, string destinationAddress, string symbol, uint256 amount): Emitted when tokens are sent to another chain.
• ContractCallExecuted(bytes32 commandId): Emitted when a contract call is successfully executed (validated).
• Executed(bytes32 commandId): Emitted when a command is successfully executed.
• ContractCallApproved(bytes32 commandId, string sourceChain, string sourceAddress, address contractAddress, bytes32 payloadHash, bytes32 sourceTxHash, uint256 sourceEventIndex): Emitted when a contract call is approved.
• ContractCallApprovedWithMint(bytes32 commandId, string sourceChain, string sourceAddress, address contractAddress, bytes32 payloadHash, string symbol, uint256 amount, bytes32 sourceTxHash, uint256 sourceEventIndex): Emitted when a contract call with token transfer is approved.

This contract manages the trading of options using a decentralized order book, including issuing, exercising, buying, and selling options.

Methods:

• constructor(address gateway_): Initializes the contract with a gateway address and some initial parameters
• _getExpiryTimestamp(uint256 expiryWeeks): returns the expiry timestamp of a given expiry week.
• _isOptionExpired(uint256 expiryWeeks): returns if a given option is expired.
• _execute(bytes32 commandId, string sourceChain, string sourceAddress, bytes calldata payload): Handles cross-chain calls that are not with token transfer.
• _executeWithToken(bytes32 commandId, string sourceChain, string sourceAddress, bytes calldata payload, string calldata tokenSymbol, uint256 amount): Handles cross-chain calls with token transfer.
• sellCallOption(string posterAddress, uint256 strikePrice, uint256 expiryWeeks, uint256 price, uint256 amount): Places a sell order for call options.
• sellPutOption(string posterAddress, uint256 strikePrice, uint256 expiryWeeks, uint256 price, uint256 amount): Places a sell order for put options.
• buyCallOption(string buyerAddress, string symbol, uint256 transferedAmount, uint256 strikePrice, uint256 expiryWeeks, uint256 price, uint256 amount): Places a buy order for call options.
• buyPutOption(string buyerAddress, string symbol, uint256 transferedAmount, uint256 strikePrice, uint256 expiryWeeks, uint256 price, uint256 amount): Places a buy order for put options.
• cancelSellCallOptionOrder(string posterAddress, uint256 orderId): Cancels a sell order for call options.
• cancelSellPutOptionOrder(string posterAddress, uint256 orderId): Cancels a sell order for put options.
• cancelBuyCallOptionOrder(string buyerAddress, uint256 orderId): Cancels a buy order for call options.
• cancelBuyPutOptionOrder(string buyerAddress, uint256 orderId): Cancels a buy order for put options.
• issueCallOption(string sourceAddress, string tokenSymbol, uint256 xrp_transfered, uint256 strikePrice, uint256 expiryWeeks): Issues new call options.
• issuePutOption(string sourceAddress, string tokenSymbol, uint256 usd_collateral, uint256 strikePrice, uint256 expiryWeeks): Issues new put options.
• exerciseCallOption(string sourceChain, string sourceAddress, string tokenSymbol, uint256 usd_transfered, uint256 strikePrice, uint256 expiryWeeks): Exercises call options.
• exercisePutOption(string sourceChain, string sourceAddress, string tokenSymbol, uint256 xrp_transfered, uint256 strikePrice, uint256 expiryWeeks): Exercises put options.
• withdrawCallOptionCollateral(string sourceChain, string sourceAddress, uint256 strikePrice, uint256 expiryWeeks): Withdraws collateral from expired call options.
• withdrawPutOptionCollateral(string sourceChain, string sourceAddress, uint256 strikePrice, uint256 expiryWeeks): Withdraws collateral from expired put options.
• _createOrder(string posterAddress, uint256 strikePrice, uint256 expiryWeeks, uint256 price, uint256 amount, int orderType): Creates a new order and returns its ID.
• _addOrderToChain(uint256 newId, mapping(uint256 => mapping(uint256 => uint256)) storage listHeadMap, bool increasing): Adds a new order to the order chain.
• _removeFromSortedList(OrderInfo storage order, mapping(uint256 => mapping(uint256 => uint256)) storage listHeadMap): Removes a order from the order chain.
• _matchOrders(uint256 strikePrice, uint256 expiryWeeks, mapping(uint256 => mapping(uint256 => uint256)) storage sellOrderChainHead, mapping(uint256 => mapping(uint256 => uint256)) storage buyOrderChainHead): Matches orders in the order book.
• _matchCallOptionOrders(uint256 strikePrice, uint256 expiryWeeks): Matches buy and sell orders for call options.
• _matchPutOptionOrders(uint256 strikePrice, uint256 expiryWeeks): Matches buy and sell orders for put options.
• _handleWithdrawal(string sourceChain, string sourceAddress, uint256 amountOwned, uint256 totalIssued, uint256 totalExercised, uint256 strikePrice): Handle withdraw logics based on the number of options that are exercised.
• init(): Initializes some of the internal constants and storage variables.

Events:

• OptionIssued(string sourceAddress, uint256 strikePrice, uint256 expiryWeeks, uint256 amount, bool isCall): Emitted when new options are issued.
• OptionExercised(string sourceAddress, uint256 strikePrice, uint256 expiryWeeks, uint256 amount, bool isCall): Emitted when options are exercised.
• OptionOrderPlaced(uint256 orderId, string posterAddress, uint256 strikePrice, uint256 expiryWeeks, uint256 price, uint256 amount, int orderType): Emitted when a new order is placed.
• OptionOrderCancelled(uint256 orderId, string posterAddress, uint256 strikePrice, uint256 expiryWeeks, uint256 amount, int orderType): Emitted when an order is cancelled.
• OptionTradeExecuted(string buyerAddress, string sellerAddress, uint256 optionId, uint256 strikePrice, uint256 expiryWeeks, uint256 price, uint256 amount, uint256 buyOrderId, uint256 sellOrderId): Emitted when an option trade is executed.
• OptionCollateralWithdrawn(string sourceAddress, uint256 strikePrice, uint256 expiryWeeks, uint256 amount, bool isCall): Emitted when collateral is withdrawn after expiry.

This contract implements a peer-to-peer lending platform on the Axelar network, allowing users to create and fulfill lending/borrowing requests using XRP as collateral.

Methods:

• constructor(address gateway_, address priceOracle_): Initializes the contract, setting the gateway and price oracle addresses.
• setPriceOracle(uint256 newPrice): Updates the price of XRP in USD by the oracle. (Only oracle updater can call)
• _execute(bytes32 commandId, string sourceChain, string sourceAddress, bytes calldata payload): Handles cross-chain calls that are not with token transfer.
• _executeWithToken(bytes32 commandId, string sourceChain, string sourceAddress, bytes calldata payload, string calldata tokenSymbol, uint256 amount): Handles cross-chain calls with token transfer.
• createLendingRequest(string sourceChain, string sourceAddress, string tokenSymbol, uint256 amountToLendUSD, uint256 minCollateralRatio, uint256 liquidationThreshold, uint256 desiredInterestRate, uint256 paymentDuration, uint256 minimalPartialFill): Creates a new lending request.
• createBorrowingRequest(string sourceChain, string sourceAddress, string tokenSymbol, uint256 collateralAmountXRP, uint256 amountToBorrowUSD, uint256 maxCollateralRatio, uint256 liquidationThreshold, uint256 desiredInterestRate, uint256 paymentDuration, uint256 minimalPartialFill): Creates a new borrowing request.
• acceptLendingRequest(string sourceChain, string sourceAddress, string tokenSymbol, uint256 collateralAmountXRP, uint256 requestId, uint256 borrowAmountUSD): Accepts a lending request by sending USD to the borrower.
• acceptBorrowingRequest(string sourceChain, string sourceAddress, string tokenSymbol, uint256 amountToLendUSD, uint256 requestId, uint256 collateralAmountXRP): Accepts a borrowing request and send USD to the borrower.
• cancelLendingRequest(string sourceChain, string sourceAddress, uint256 requestId): Cancels a lending request.
• cancelBorrowingRequest(string sourceChain, string sourceAddress, uint256 requestId): Cancels a borrowing request.
• mustCancelLendingRequest(uint256 requestId): Cancel a lending request without refund the collateral.
• mustCancelBorrowingRequest(uint256 requestId): Cancel a borrowing request without refund the collateral.
• repayLoan(string sourceChain, string sourceAddress, string tokenSymbol, uint256 repayAmountUSD, uint256 loanId): Repays a loan.
• liquidateLoan(uint256 loanId, string caller): Liquidates a loan if the borrower defaults.
• calculateInterest(uint256 amountBorrowedUSD, uint256 desiredInterestRate): Calculates the interest amount.
• calculateCollateralAt(uint256 amountBorrowedUSD, uint256 collateralRatio): Calculates the required collateral amount for a given loan amount.
• calculatePayableAmount(uint256 amountBorrowedUSD, uint256 desiredInterestRate): Calculates the amount payable (principle + interest).
• updatePrice(): Updates the current XRP price from the price oracle.
• getLoanDetails(uint256 loanId): Returns details about a specific loan.
• getUserLoans(string user): Returns an array of loan IDs associated with a user.
• getLendingRequest(uint256 requestId): Returns details about a specific lending request.
• getBorrowingRequest(uint256 requestId): Returns details about a specific borrowing request.
• getUserLendingRequests(string user): Returns an array of lending request IDs associated with a user.
• getUserBorrowingRequests(string user): Returns an array of borrowing request IDs associated with a user.
• getCurrentPrice(): Returns the current price of XRP.
• _removeLoanFromUser(string borrower, uint256 loanId): removes a loanId from a user's loan array.

Events:

• LoanEvent(string eventName, uint256 amount1, uint256 loanId, string lender, string borrower, uint256 amountBorrowedUSD, uint256 amountPayableToLender, uint256 amountPayableToPlatform, uint256 amountPaidUSD, uint256 collateralAmountXRP, uint256 repayBy, uint256 liquidationThreshold, bool isLiquidated): Emitted when a loan related action occurs, such as lending, borrowing, repayment or liquidation.
• PriceUpdated(uint256 newPrice): Emitted when the XRP price is updated from the oracle.
• LendingRequestEvent(string eventName, uint256 requestId, string lender, uint256 amountToLendUSD, uint256 amountLendedUSD, uint256 minCollateralRatio, uint256 liquidationThreshold, uint256 desiredInterestRate, uint256 paymentDuration, uint256 minimalPartialFill, bool canceled, bool autoCanceled): Emitted when a lending request related action occurs, such as creating, canceling a lending request.
• BorrowingRequestEvent(string eventName, uint256 requestId, string borrower, uint256 amountToBorrowUSD, uint256 amountBorrowedUSD, uint256 initialCollateralAmountXRP, uint256 existingCollateralAmountXRP, uint256 maxCollateralRatio, uint256 liquidationThreshold, uint256 desiredInterestRate, uint256 paymentDuration, uint256 minimalPartialFill, bool canceled, bool autoCanceled): Emitted when a borrowing request related action occurs, such as creating, canceling a borrowing request.

This contract implements a lending pool on Axelar, where users can contribute USD, borrow by providing XRP as collateral, and earn rewards based on pool performance.

Methods:

• constructor(address gateway_, address priceOracle_, uint256 dailyInterestFactorE18_): Initializes the contract with a gateway, a price oracle, and the daily interest factor.
• setPriceOracle(address _priceOracle): Sets the price oracle address. (Only owner can call)
• _execute(bytes32 commandId, string sourceChain, string sourceAddress, bytes calldata payload): Handles cross-chain calls that are not with token transfer.
• _executeWithToken(bytes32 commandId, string sourceChain, string sourceAddress, bytes calldata payload, string calldata tokenSymbol, uint256 amount): Handles cross-chain calls with token transfer.
• contribute(string sourceChain, string sourceAddress, string tokenSymbol, uint256 lendingAmount): Allows users to contribute USD to the pool.
• withdraw(string sourceChain, string sourceAddress, uint256 withdrawAmount): Allows users to withdraw USD from the pool.
• claimReward(string sourceChain, string sourceAddress): Allows users to claim accumulated rewards.
• borrow(string sourceChain, string sourceAddress, string tokenSymbol, uint256 xrpAmount, uint256 borrowAmountUSD): Allows users to borrow USD from the pool, with XRP as collateral.
• repayLoan(string sourceChain, string sourceAddress, string tokenSymbol, uint256 repayAmountUSD): Allows users to repay their loans.
• liquidateLoan(string sourceChain, string sourceAddress, string tokenSymbol, uint256 _repayAmountUSD): Allow anyone to liquidate loans that breach the liquidation threshold.
• updateRewardClaimable(ContributorInfo storage user): Updates pending reward amount for a user.
• updateAmountPayable(BorrowerInfo storage borrower): Updates the current owed amount (principle + interest).
• distributeRewards(): Distributes rewards to pool contributors.
• updatePrice(): Updates the current price of XRP in USD.
• getBorrowerInfo(string _user): Returns information about a borrower.
• getContributorInfo(string _user): Returns information about a contributor.

Events:

• BorrowerEvent(string eventName, uint256 amount1, string borrower, uint256 borrowAmountUSD, uint256 amountPayableUSD, uint256 collateralAmountXRP, uint256 lastPayableUpdateTime, uint256 repaidUSD): Emitted when a borrowing related event occurs (borrowing, repaying or liquidation).
• ContributorEvent(string eventName, uint256 amount1, string user, uint256 contributionBalance, uint256 rewardDebt, uint256 confirmedRewards): Emitted when a contributor related event occurs (contribute, withdraw or claim reward).
• PoolRewardEvent(uint256 rewardDistributed, uint256 accRewardPerShareE18, uint256 equity, uint256 retainedEarning): Emitted when rewards are distributed to contributors.

Our platform's API leverages blockchain technology in several crucial ways, both on the XRPL network and the EVM sidechain. This interconnected approach allows us to provide secure, transparent, and efficient financial services. Here’s a breakdown of how we utilize blockchain:

Transaction Immutability: All financial activities on our platform, such as loan requests, accepting of loan, repayment, options trading, and AMM swaps are recorded as transactions on the XRPL, or the EVM side chain. Once recorded, these transactions cannot be altered or deleted, ensuring a transparent and auditable history of all activities.

Smart Contracts for Automation: The core logic of our lending platform and options trading is encoded in smart contracts deployed on the XRPL EVM sidechain. These smart contracts automatically execute the terms of the agreement, such as loan disbursal, repayments, and option exercises, removing the need for intermediaries and ensuring fair and reliable execution.

Decentralized Security: By operating on a decentralized blockchain, we mitigate the risks associated with a single point of failure. The network is secured by a global network of nodes, making the system resistant to tampering or censorship. The integration with Axelar GMP further enhances security by allowing our contract on EVM chain to use the proven security model of Axelar network to conduct cross-chain messaging, all done via our API.
Trust Without Intermediaries: Users can engage in financial activities on our platform without trusting a central authority. The blockchain provides a shared and verifiable record of all activities, building confidence and trust among all participants of the platform. The use of GMP will also allow users to have a trust free operation, and access transaction details on the explorer.

Data Availability: All blockchain data, including our financial transactions, smart contract state and details, are publicly available on block explorers, ensuring full transparency. This allows users to monitor our operation and verify their transactions. Our backend API will also store a copy of all states on our server to provide user with a faster experience. However, all data will be available on block explorer, and users can cross-validate data between our backend and the block explorer.

Secure Cross-Chain Communication: Axelar GMP: Instead of requiring users to manually bridge assets, which is a complex and error-prone process, our platform uses Axelar's General Message Passing (GMP) technology. This system allows our contracts on the EVM sidechain to be called directly from the XRPL.

API Interaction with Front-End: The frontend fetch the latest XRP price data by directly communicating with the AMM on the XRP mainnet. Meanwhile, the frontend application interacts with our API, which presents a simplified view of the blockchain.

Read through news, documentation and code sample to design feature for the app

Add javascript scripts and deploy dummy contracts as proof of concepts to the tech stack used

Deploy the contract, set up backend, frontend and Axaler network mock, integrate the component together

Improve the security and edge cases of the contract.

Improve error handling in the backend.

Improve consumer support in frontend.

Deploy on cloud and submit as a Defi app to the EVM sidechain explorer

Pending ripple’s infrastructure and ecosystem for EVM side chain.

The competitive landscape can be broken down into a few categories:

Native AMM/DEX: These are the most immediate competitors for the basic XRP-USD swap functionality. They are built into the XRPL and offer a baseline level of trading capability. We have incorporate them in our website, but user only seeking simple swap may be fairly well diverted away.

Weaknesses: Limited functionality (no lending, options), not user-friendly for complex operations, no cross-chain feature.

This category includes any existing manual bridging mechanisms and custom solutions that enable transferring XRP or other XRPL tokens to other chains.

Weaknesses: Cumbersome, risky, not user-friendly, not scalable, not designed for cross-chain dApps.

There might be some very early-stage projects experimenting with DeFi concepts on the XRPL.

Weaknesses: Likely limited functionality, limited user base, less focused, usually lack cross-chain capability.

This category includes established DeFi protocols that provide lending, options, and similar services on other blockchains.

Weaknesses: Generally higher transaction costs, slower speeds compared to XRPL, lack direct integration with XRPL, limited user base within the XRP community.

XRPL-Native Focus: Unlike DeFi platforms on other chains, ours is built specifically for XRPL users and benefits from XRPL's speed, low fees, and direct access to its AMM, as well as an existing pool of users. We will leverage the official USD stablecoin that is on the XRPL.

Simplified Cross-Chain Interaction: Axelar's GMP hides the complexity of bridging away from the end users, and the users only need to stay on the XRPL frontend, making our platform extremely user-friendly, which solves a key pain point for existing users.

Unified Platform: Our all-in-one solution provides a seamless experience for users looking to convert XRP into USD, including AMM, lending (both pool-based and P2P), and derivatives trading. This eliminates the need to switch between different platforms, saving time and effort.

Advanced Functionality: Our platform offers more sophisticated financial instruments, such as collateralized lending and options trading, not available on native XRPL solutions.

First Mover Advantage: We are positioned as an early mover in leveraging the new XRPL EVM sidechain and Axelar GMP for building a comprehensive DeFi platform, specifically for users of the XRPL ecosystem.