Merge branch 'master' into 5-update-flyover-rskj-config-doc

Luisfc68 · web-flow · commit 9b52a745f096 · 2026-02-24T23:30:57.000+01:00
diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md
@@ -0,0 +1,3 @@
+When performing a code review, apply the checks in the prompts/review-code.prompt.md file.
+
+When performing a code review, focus on readability and avoid nested ternary operators.
diff --git a/.github/prompts/review-code.prompt.md b/.github/prompts/review-code.prompt.md
@@ -0,0 +1,59 @@
+---
+agent: 'agent'
+description: 'Perform a comprehensive code review'
+---
+
+## Role
+
+You're a senior software engineer conducting a thorough code review. Provide constructive, actionable feedback.
+
+## Review Areas
+
+Analyze the selected code for:
+
+1. **Security Issues**
+   - Input validation and sanitization
+   - Data exposure risks
+   - Injection vulnerabilities
+   - OWASP Top 10 risks
+
+2. **Performance & Efficiency**
+   - Algorithm complexity
+   - Memory usage patterns
+   - Database query optimization
+   - Unnecessary computations
+
+3. **Code Quality**
+   - Readability and maintainability
+   - Proper naming conventions
+   - Function/class size and responsibility
+   - Code duplication
+
+4. **Architecture & Design**
+   - Design pattern usage
+   - Separation of concerns
+   - Dependency management
+   - Error handling strategy
+
+5. **Testing & Documentation**
+   - Test coverage and quality
+   - Documentation completeness
+   - Comment clarity and necessity
+
+## Output Format
+
+Provide feedback as:
+
+**🔴 Critical Issues** - Must fix before merge
+**🟡 Suggestions** - Improvements to consider
+**✅ Good Practices** - What's done well
+
+For each issue:
+- Specific line references
+- Clear explanation of the problem
+- Suggested solution with code example
+- Rationale for the change
+
+Focus on: ${input:focus:Any specific areas to emphasize in the review?}
+
+Be constructive and educational in your feedback.
diff --git a/.github/workflows/devPortal-update.yml b/.github/workflows/devPortal-update.yml
@@ -16,21 +16,29 @@ jobs:
       - name: Checkout Code
         uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
 
-      # Step 1: Clone the Devportal Repository
+      # Step 1: Generate GitHub App Token
+      - name: Generate GitHub App Token
+        id: generate_token
+        uses: actions/create-github-app-token@31c86eb3b33c9b601a1f60f98dcbfd1d70f379b4 # v1.10.3
+        with:
+          app-id: ${{ secrets.GH_APP_ID }}
+          private-key: ${{ secrets.GH_APP_PRIVATE_KEY }}
+          owner: rsksmart
+          repositories: devportal
+
+      # Step 2: Clone the Devportal Repository
       - name: Clone Devportal Repository
-        env:
-          GITHUB_TOKEN: ${{ secrets.DEVPORTAL_DOCS_UPDATE_TOKEN }}
         run: |
           TIMESTAMP=$(date +'%Y%m%d-%H%M%S')
           BRANCH_NAME="update-from-lps-${TIMESTAMP}"
           echo "BRANCH_NAME=${BRANCH_NAME}" >> $GITHUB_ENV
 
-          git clone https://github.com/rsksmart/devportal.git
+          git clone https://x-access-token:${{ steps.generate_token.outputs.token }}@github.com/rsksmart/devportal.git
           cd devportal
           git checkout -b ${BRANCH_NAME} || git checkout ${BRANCH_NAME}
           cd ..
 
-      # Step 2: Transform Each File and Copy to Devportal Repository
+      # Step 3: Transform Each File and Copy to Devportal Repository
       - name: Transform Files for Devportal
         run: |
           set -e
@@ -232,27 +240,23 @@ jobs:
           rm ${TEMP_FILE}
           cp ${TRANSFORMED_FILE} ${BASE_DST}/trusted-accounts.md
 
-      # Step 3: Commit and Push Changes to Devportal Repository
+      # Step 4: Commit and Push Changes to Devportal Repository
       - name: Commit and Push Changes
-        env:
-          GITHUB_TOKEN: ${{ secrets.DEVPORTAL_DOCS_UPDATE_TOKEN }}
         run: |
           cd devportal
           git config user.name "github-actions[bot]"
           git config user.email "github-actions[bot]@users.noreply.github.com"
           git add docs/02-developers/06-integrate/02-flyover/
           git commit -m "Automated update from Liquidity Provider Server repository"
-          git remote set-url origin https://x-access-token:${GITHUB_TOKEN}@github.com/rsksmart/devportal.git
+          git remote set-url origin https://x-access-token:${{ steps.generate_token.outputs.token }}@github.com/rsksmart/devportal.git
           git push -f origin ${BRANCH_NAME}
 
-      # Step 4: Create a Pull Request in the Devportal Repository
+      # Step 5: Create a Pull Request in the Devportal Repository
       - name: Create Pull Request
-        env:
-          GITHUB_TOKEN: ${{ secrets.DEVPORTAL_DOCS_UPDATE_TOKEN }}
         run: |
           cd devportal
           curl -L -X POST -H "Accept: application/vnd.github+json" \
-          -H "Authorization: Bearer ${{ secrets.DEVPORTAL_DOCS_UPDATE_TOKEN }}" \
+          -H "Authorization: Bearer ${{ steps.generate_token.outputs.token }}" \
           -H "X-GitHub-Api-Version: 2022-11-28" \
           https://api.github.com/repos/rsksmart/devportal/pulls \
           -d "{\"title\":\"Liquidity-provider-server automated update of documentation ${BRANCH_NAME}\",\"body\":\"This PR updates the Devportal documentation with the latest changes from the Liquidity Provider Server repository.\",\"head\":\"${BRANCH_NAME}\",\"base\":\"main\"}"
diff --git a/README.md b/README.md
@@ -191,6 +191,9 @@ The service is configured in `docker-compose/monitoring/src/config.ts` and suppo
 
 The service can be configured to monitor other addresses by modifying the `MONITORED_ADDRESSES` array in `docker-compose/monitoring/src/config.ts`.
 
+## Additional clarifications
+- The liquidity provider server is designed to run with an exclusive wallet. Horizontal scaling requires a separate wallet per instance. This codebase assumes a non-shared wallet.
+
 ## More Information
 
 If you're looking forward to integrate with Flyover Protocol then you can check the [Flyover SDK repository](https://github.com/rsksmart/flyover-sdk/blob/main/README.md).
diff --git a/SECURITY.md b/SECURITY.md
@@ -1,37 +1,25 @@
-# Liquidity Provider Server Security Process
+# RootstockLabs's Security Process
 
 We are committed to conduct our security process in a professional and civil manner. Public shaming, under-reporting or misrepresentation of vulnerabilities will not be tolerated.
 
 ## Responsible Disclosure
 
-For all security related issues, Liquidity Provider Server has two main points of contact. Reach us at `security@rootstocklabs.com` or refer to our [Bug Bounty Program](https://www.rootstocklabs.com/bug-bounty-program). **Do not open up a GitHub issue if the bug is a security vulnerability**
+For all security related issues, RootstockLabs has two main points of contact. Reach us at <security@rootstocklabs.com> or refer to our [Bug Bounty Program](https://www.rootstocklabs.com/bug-bounty-program/). **Do not open up a GitHub issue if the bug is a security vulnerability**
 
 **Ensure the bug was not already reported** by searching on GitHub under [Issues](https://github.com/rsksmart/liquidity-provider-server/issues).
 
-## Vulnerability Handling
+## Disclosure Policy
 
-### Response Time
+- Follow Immunefi's [disclosure guidelines](https://immunefi.com/responsible-publication/).
+- Public disclosure of a vulnerability makes it ineligible for a bounty.
 
-RootstockLabs will make a best effort to meet the following response times for reported vulnerabilities:
-
-* Time to first response (from report submit) - 5 business days
-* Time to triage (from report submit) - 7 business days
-* Time to bounty (from triage) - 15 business days
-
-We'll try to keep you informed about our progress throughout the process.
-
-### Disclouse Policy
-
-* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).
-* Public disclosure of a vulnerability makes it ineligible for a bounty. If the user reports the vulnerability to other security teams (e.g. Ethereum or ETC) but reports to RootstockLabs with considerable delay, then RootstockLabs may reduce or cancel the bounty.
-
-For more information check RootstockLabs bounty program policy at [HackerOne](https://hackerone.com/rootstocklabs)
+For more information, check RootstockLabs bounty program policy at [Immunefi](https://immunefi.com/bug-bounty/rootstocklabs/information)
 
 ## Public Keys
 
 ### Security
 
-```
+```gpg
 -----BEGIN PGP PUBLIC KEY BLOCK-----
 Version: GnuPG v2
 
@@ -140,4 +128,4 @@ v0FjOkVKB3PSHj1q4fogldX0Yb55tUa3rX0Rb8QEKInQj8FFPd44XHclv9PTv0OL
 IfHtYt8huvu34FA85HR8wAOPiqvyJ7Oj
 =r7Yf
 -----END PGP PUBLIC KEY BLOCK-----
-```
+```
diff --git a/docs/DESIGN.md b/docs/DESIGN.md
@@ -1,14 +1,8 @@
 # Flyover Protocol Design
 
-The Flyover system allows a user to transfer BTC from Bitcoin to RSK and vice versa in a fast way, where a third party
-takes the risk to advance the payment for the user. Flyover also provides the new feature to transfer BTC from Bitcoin
-directly to a smart contract in RSK.
-
-The outstanding feature of the Flyover system is that it accomplishes the above without giving any third party custody
-of the transferred funds. This is an outstanding security guarantee to the user. The system comprises one or more
-liquidity providers (LPs) that store their BTC in RSK and Bitcoin. The first version of the Flyover protocol supports only the
-peg-in process (BTC to RBTC). Later versions will also support the peg-out process (RBTC to BTC).
+The Flyover system allows a user to transfer BTC from Bitcoin to Rootstock and vice versa in a fast way, where a third party takes the risk to advance the payment for the user. Flyover also provides the new feature to transfer BTC from Bitcoin directly to a smart contract in Rootstock.
 
+The outstanding feature of the Flyover system is that it accomplishes the above without giving any third party custody of the transferred funds. This is an outstanding security guarantee to the user. The system comprises one or more liquidity providers (LPs) that store their BTC in Rootstock and Bitcoin. The first version of the Flyover protocol supports only the peg-in process (BTC to RBTC). Later versions will also support the peg-out process (RBTC to BTC).
 
 ## Workflow
 
@@ -18,21 +12,21 @@ to isOperational could be performed at a different time:
 ![Flyover Sequence Diagram](https://raw.githubusercontent.com/rsksmart/liquidity-provider-server/refs/heads/master/docs/diagrams/flyover-sd.png)
 
 
-The following diagrams show the interactions between Liquidity Provider, Liquidity Bridge Contract and RSK Bridge Contract in three different scenarios:
+The following diagrams show the interactions between Liquidity Provider, Liquidity Bridge Contract and Rootstock Bridge Contract in three different scenarios:
 1. Basic fast bridge workflow (happy path)
 2. Unsuccessful call on behalf of a user
 3. Liquidity Provider fails to deliver funds to LBC
 
 ![Flyover Sequence Diagram](https://raw.githubusercontent.com/rsksmart/liquidity-provider-server/master/docs/diagrams/flyover-ad-basic.png)
 
-_Figure 1 - Basic fast bridge workflow. Note that step (3) `registerPegin` can be called by the LP or any other entity._
+* Figure 1 - Basic fast bridge workflow. Note that step (3) `registerPegin` can be called by the LP or any other entity._
 
 
 ![Flyover Sequence Diagram](https://raw.githubusercontent.com/rsksmart/liquidity-provider-server/master/docs/diagrams/flyover-ad-unsuccessful-call.png)
 
-_Figure 2 - Fast bridge interactions when the call on behalf of the user is unsuccessful. The LP keeps the call fee and the rest is refunded to the refund RSK address._
+* Figure 2 - Fast bridge interactions when the call on behalf of the user is unsuccessful. The LP keeps the call fee and the rest is refunded to the refund RSK address._
 
 
 ![Flyover Sequence Diagram](https://raw.githubusercontent.com/rsksmart/liquidity-provider-server/master/docs/diagrams/flyover-ad-no-call.png)
 
-_Figure 3 - Fast bridge interactions when the LP fails to call the LBC on behalf of the user. The LBC slashes the LP's collateral and refunds the user on the refund RSK address._
+* Figure 3 - Fast bridge interactions when the LP fails to call the LBC on behalf of the user. The LBC slashes the LP's collateral and refunds the user on the refund RSK address._
diff --git a/docs/Operating-LP.md b/docs/Operating-LP.md
@@ -1,16 +1,18 @@
-A Liquidity Provider (LP) contributes funds in Rootstock (RBTC) and Bitcoin (BTC) to a liquidity pool. In exchange for providing this liquidity and facilitating trades between the two assets, LPs earn rewards (fees) generated from trading activity. 
+A Liquidity Provider (LP) contributes funds in Rootstock (rBTC) and Bitcoin (BTC) to a liquidity pool. In exchange for providing this liquidity and facilitating trades between the two assets, LPs earn rewards (fees) generated from trading activity. 
 
-> LPs can be individuals, institutions, exchanges, or aggregators. See [glossary](/developers/integrate/flyover/glossary/) section for explanation of terms.
+> LPs can be individuals, institutions, exchanges, or aggregators. See the [glossary](/developers/integrate/flyover/glossary/) for term definitions.
 
-This section outlines the key features and functionalities that Liquidity Providers (LPs) should be familiar with to effectively operate their Liquidity Provider Servers (LPS). The information provided encompasses both technical and operational aspects, making it a valuable resource for both LPs and those responsible for deploying the LPS environment.
+The Flyover protocol is trust-minimized, this means user funds go to the PowPeg federation (peg-in) or the Liquidity Bridge Contract (peg-out), never to the Liquidity Provider. LPs supply liquidity and are repaid by the protocol; they do not hold custody of user funds. This design matters for institutional LPs and their users.
+
+This section outlines the key features and operations that Liquidity Providers (LPs) need to run their Liquidity Provider Servers (LPS) effectively. The information provided encompasses both technical and operational aspects, making it a valuable resource for both LPs and those responsible for deploying the LPS environment.
 
 ## Requirements
 * See minimum security requirements
 * Configure environments
     - LPS Wallet
     - LPS environment
 * Liquidity
-    - The minimum required is the collateral amount (regardless of the amount of liquidity), which currently is 0.06 RBTC that needs to be paid during transaction registration. See [how to get RBTC](https://rootstock.io/rbtc/).
+    - The minimum required is the collateral amount (regardless of the amount of liquidity), which currently is 0.06 rBTC that needs to be paid during transaction registration. See [how to get rBTC](https://rootstock.io/rbtc/).
 
 ### Main Dependencies
 The liquidity provider server has the following dependencies:
@@ -57,4 +59,4 @@ See the [minimum security requirements](https://github.com/rsksmart/liquidity-pr
 - [Liquidity Provider Server](https://github.com/rsksmart/liquidity-provider-server?tab=readme-ov-file)
 - [Liquidity Bridge Contract](https://github.com/rsksmart/liquidity-bridge-contract)
 - [Flyover LBC Mainnet Contract Address](https://explorer.rootstock.io/address/0xaa9caf1e3967600578727f975f283446a3da6612)
-- [Flyover LBC Testnet Contract Address](https://explorer.testnet.rootstock.io/address/0xc2a630c053d12d63d32b025082f6ba268db18300)
+- [Flyover LBC Testnet Contract Address](https://explorer.testnet.rootstock.io/address/0xc2a630c053d12d63d32b025082f6ba268db18300)
diff --git a/docs/Trusted-Accounts.md b/docs/Trusted-Accounts.md
@@ -1,13 +1,11 @@
 # Liquidity Provider Trusted Accounts
 
-## 🧠 Summary
+## Summary
 The **Liquidity Provider Trusted Accounts** feature extends the existing **Liquidity Provider Server (LPS)** and **FlyoverSDK** to allow Liquidity Providers (LPs) to configure a set of trusted Rootstock accounts that can bypass certain validation checks — such as the **reCAPTCHA** verification — during **PegIn** or **PegOut** operations.
 
 This functionality is part of the **Flyover Protocol**, aimed at enabling automated integrations for partners and liquidity providers who operate frequently.
 
----
-
-## 🏗 Architecture and Design
+## Architecture and Design
 
 ### Components
 This feature adds functionality to two existing components:
@@ -18,9 +16,7 @@ This feature adds functionality to two existing components:
 - Backward compatible with existing FlyoverSDK versions `>= v1.7.0` and LPS versions `>= v2.3.0`.
 - The account paying for the operation doesn’t need to be the same as the whitelisted account, but a valid signature of the quote hash from the trusted account must be provided.
 
----
-
-## ⚙️ Setup and Configuration
+## Setup and Configuration
 
 ### Environment Requirements
 - **FlyoverSDK:** `>= v1.70`
@@ -30,9 +26,7 @@ This feature adds functionality to two existing components:
 - The LP must configure authorized trusted accounts in their **LPS instance**.
 - No additional `.env` variables or feature flags are required.
 
----
-
-## 🔌 API / Interface Details
+## API / Interface Details
 
 ### FlyoverSDK Methods
 
@@ -53,9 +47,7 @@ Both error types are raised as **`FlyoverError`** instances:
 | Invalid Signature | The provided signature does not match a whitelisted account. |
 | Locking Cap Exceeded | The account exceeded its assigned BTC/RBTC locking cap. |
 
----
-
-## 🧭 Integration Guide
+## Integration Guide
 
 To integrate this feature:
 
@@ -75,9 +67,7 @@ Trust is based solely on account whitelisting and signature verification.
 - Primary integration via **FlyoverSDK**
 - No direct API calls required
 
----
-
-## 🧪 Testing
+## Testing
 
 ### Local Testing Setup
 - Deploy a **local LPS instance**.
@@ -91,15 +81,12 @@ Example tests and automation demos can be found in:
 ### Notes
 Follow the documentation in the above repository for commands and setup steps.
 
----
-
 ## 🧾 Changelog
 | Component | Version | Release Link |
 |------------|----------|---------------|
 | FlyoverSDK | v1.7.0 | [GitHub Release](https://github.com/rsksmart/flyover-sdk/releases/tag/v1.7.0) |
 | LPS | v2.3.0 | [GitHub Release](https://github.com/rsksmart/liquidity-provider-server/releases/tag/v2.3.0) |
 
----
 
 ## 📦 Related Resources
 - **Flyover SDK (npm):** [@rsksmart/flyover-sdk](https://www.npmjs.com/package/@rsksmart/flyover-sdk)

Original file line number	Diff line number	Diff line change
`@@ -0,0 +1,3 @@`
	`1`	`+When performing a code review, apply the checks in the prompts/review-code.prompt.md file.`
	`2`	`+`
	`3`	`+When performing a code review, focus on readability and avoid nested ternary operators.`