Skip to content

Commit

Permalink
add docs for router pay
Browse files Browse the repository at this point in the history
  • Loading branch information
abhisom2912 committed Nov 14, 2024
1 parent bfb821b commit 5f4844b
Show file tree
Hide file tree
Showing 9 changed files with 295 additions and 0 deletions.
73 changes: 73 additions & 0 deletions docs/router-pay/README.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,73 @@
---
title: Introduction
sidebar_position: 1
canonicalUrl: https://docs.routerprotocol.com/develop
---

import {
HomepageCard as Card,
HomepageSection as Section,
} from '../../src/components/HomepageComponents';

import {
IDEIcon,
TerminalIcon,
RelayerIcon,
Contribute,
Guide,
NitroIcon
} from '../../src/icons';

# Introduction

Router Pay introduces the Instruction Specific Address (ISA) mechanism, which enables wallet-less interactions with decentralized applications (DApps). By generating dynamic, single-use addresses, users can initiate transactions by transferring assets directly, without wallet connections or approvals. The ISA mechanism supports both single-chain and cross-chain interactions, enhancing user security and convenience while bringing a familiar Web 2.0 experience to Web 3.0 applications, including use cases like POS machines for merchant payments.

# Motivation

Currently, DApp interactions in Web 3.0 often require wallet connections and approvals, introducing additional steps that disrupt usability and pose security risks. This complex flow has hindered DeFi adoption, as Web 3.0 interfaces don’t match the ease and familiarity of Web 2.0 experiences, especially compared to centralized exchanges.

Router Pay (referred to as ISA as well) addresses these issues by offering a user journey that mirrors the simplicity of Web 2.0 actions. With Router Pay, users can complete interactions by simply scanning a QR code and sending payment. This approach enables a seamless, recognizable process, supporting a Web 2.0-like user experience in a Web 3.0 setting. By bridging the usability gap between centralized and decentralized applications, Router Pay opens the door for greater mainstream adoption of DeFi.


<Section title="Integrating Router Pay" id="web-sdks" hasSubSections >

<Section>
<Card
title="Add ISA to your dApp"
description="Integrate Router Pay and provide a no sign-up UX to users"
to="/router-pay/integrate-router-pay/dapp-integration"
icon={<IDEIcon />}
/>
<Card
title="Nitro integration via Router Pay"
description="Integrate Router Nitro with no sign-up flow for users"
to="/router-pay/integrate-router-pay/router-nitro"
icon={<NitroIcon />}
/>
</Section>

</Section>

<Section title="Learn about Router Pay" id="web-sdks" hasSubSections >
<Section>
<Card
title="User Journey with Router Pay"
description="Learn about the advanced user journey with Router Pay"
to="/router-pay/user-journey"
icon={<RelayerIcon />}
/>
<Card
title="Technical Specifications"
description="How does Router Pay work technically"
to="/router-pay/technical-specifications"
icon={<TerminalIcon />}
/>
<Card
title="Benefits"
description="Benefits of Router Pay"
to="/router-pay/benefits"
icon={<Contribute />}
/>
</Section>

</Section>
12 changes: 12 additions & 0 deletions docs/router-pay/benefits.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,12 @@
---
title: Benefits
sidebar_position: 3
description: Benefits of Router Pay to the Ecosystem
---

1. **Web 2.0-Like Convenience:** Users interact simply by scanning a QR code and making a payment, aligning with familiar Web 2.0 actions, which eases adoption by removing the complex setup steps traditionally required in Web 3.0.
2. **No Wallet Connection:** Simplifies UX by eliminating wallet connection, approval, and injection steps.
3. **Improved Integration with Centralized Exchanges:** Enables DApp interactions directly from centralized exchanges.
4. **Security Enhancements:** Minimizes phishing risks by removing the need for wallet approvals.
5. **Broad Browser Compatibility:** Compatible with any browser, as no wallet extensions are required.
6. **Merchant Payment Support:** Paves the way for real-world use cases, such as POS machines for merchant payments.
Binary file added docs/router-pay/img/router-pay-workflow.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
33 changes: 33 additions & 0 deletions docs/router-pay/integrate-router-pay/README.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,33 @@
---
title: Integrating Router Pay
sidebar_position: 1
---

import {
HomepageCard as Card,
HomepageSection as Section,
} from '../../../src/components/HomepageComponents';

import {
IDEIcon,
NitroIcon
} from '../../../src/icons';

Router Pay provides the capability to generate a ISA for any dApp which wants to provide a no sign-up experience to its users.

## Integration

<Section>
<Card
title="Add ISA to your dApp"
description="Integrate Router Pay and provide a no sign-up UX to users"
to="/router-pay/integrate-router-pay/dapp-integration"
icon={<IDEIcon />}
/>
<Card
title="Nitro integration via Router Pay"
description="Integrate Router Nitro with no sign-up flow for users"
to="/router-pay/integrate-router-pay/router-nitro"
icon={<NitroIcon />}
/>
</Section>
68 changes: 68 additions & 0 deletions docs/router-pay/integrate-router-pay/dapp-integration.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,68 @@
---
title: Integrating Router Pay into your dApp
sidebar_position: 2
---

Any dApp can integrate Router Pay to provide it's users a no sign-up UX. This can be easily done by integrating Router Pay APIs.
Integration of Router Pay is a 2 step process -
1. **Generation of deposit address:** API to generate a deposit address where user will send their funds to. Relayer will use the funds sent to this address to execute the transaction on behalf of the user.
2. **Check status:** API to check the status of the transaction.

## Generate Deposit Address
The below end point will generate the deposit address where the end user can send funds to. By default the expiry time for an address is 10 mins. Any amount sent to the address post 10 mins can be refunded back to the user in a trustless way.

**Endpoint:** `POST /generate-deposit-address` **Content-Type:** `application/json`

**Request Body**

| **Parameter** | **Type** | **Description** |
| --------------------- | -------------------------- | ------------------------ |
| contractAddressOnSrcChain | string | Contract address on selected chain which needs to be called for execution |
| calldata | string | Calldata for contract execution (hex) |
| fromTokenAddress | string | The token which user will be sending funds in |
| refundAddress | string | Address for potential refunds |
| chainId | string | Chain Id on which the user will be sending funds (should be the same where the contract has to be called) |
| amount | string | Amount to be used for executing the calldata |
| partnerId | number | OPTIONAL: Partner identification number |


**Sample Request**
```jsx
{
"contractAddressOnSrcChain": "0x1396f41d89b96eaf29a7ef9ee01ad36e452235ae",
"calldata": "0xddddd",
"fromTokenAddress": "0xAF82969ECF299c1f1Bb5e1D12dDAcc9027431160",
"refundAddress": "0xf79D7E74304AF49748A4d77d4B64eeEE84d131cf",
"chainId": "43113",
"amount": "100000000000000023001",
"partnerId": 12
}
```

## Check Status
The API will provide the status of the transaction for a particular deposit address.

**Endpoint:** ``GET /get-status-by-deposit-address``

**Query Parameters**

| **Parameter** | **Type** | **Description** |
| --------------------- | -------------------------- | ------------------------ |
| depositAddress | string | The deposit address to check the status for |
| chainId | number | Chain Id where deposit was made |
| limit | number | Number of transactions per page |
| page | number | Page number for pagination |

**Sample Request**
```jsx
GET /get-status-by-deposit-address?depositAddress=0x55E0213D2C0dFf7A42b6F2Bf05B636e2605eD990&chainId=56&limit=20&page=1
```
### Transaction Statuses
| **Status** | **Description** |
| --------------------- | -------------------------- | ------------------------ |
| PENDING | Waiting for funds to be deposited |
| SUCCESS | Funds deposited, relaying in progress |
| FAILED | Simulation failed or transaction receipt failed |
| NOT_FOUND | No funds sent before address expiration |
| REVERTED | Transaction reverted |
4 changes: 4 additions & 0 deletions docs/router-pay/integrate-router-pay/router-nitro.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,4 @@
---
title: Integrating Router Nitro with ISA capabilities
sidebar_position: 3
---
48 changes: 48 additions & 0 deletions docs/router-pay/technical-specifications.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,48 @@
---
title: Technical Specifications
sidebar_position: 2
description: Technical Specifications for Router Pay
---

## Dynamic Address Generation

* **Contract**: RouterRelay
* `addressForTokenDeposit`: Generates a dynamic, single-use deposit address for token deposits based on user-supplied data, which can also be displayed as a QR code for easy scanning.
* `sendTokenDeposit`: Deploys a DepositReceiver contract to handle the asset forwarding and initiate cross-chain transfers.

## Asset Transfer and Forwarding

* **Contract**: ReceiverImplementation
* **Purpose**: Receives assets and forwards them as per user-specified data. Handles transaction failures with a refund mechanism.
* **Core Components**:
* Data Structure: `GenericData`
* callTo: Target address for forward operation (e.g., another contract).
* approvalTo: Address for granting token approval if required.
* data: Encoded transaction data for interaction.
* srcToken: Address of the asset being transferred.
* refundAddress: Address for refunds in case of transaction failure.
* Native Asset Identifier: NATIVE_ASSETID to detect and handle native tokens (e.g., ETH).
* Key Function: `receiveAndSendToken`
* Verifies callTo and refundAddress are non-zero.
* Identifies asset type (native/ERC20) and retrieves the balance.
* Grants approval for ERC20 transfers if necessary and initiates a call to callTo with data.
* If the transaction fails, refunds the balance to refundAddress.
* Uses safeTransfer for ERC20 tokens, ensuring a secure refund process.

## Temporary Deposit Receiver Contract

* **Contract**: DepositReceiver
* **Purpose**: Acts as a transient address to hold the user’s tokens and call ReceiverImplementation using delegatecall.
* **Core Components**:
* Constructor:
* Executes delegatecall to ReceiverImplementation for asset handling.
* If delegatecall fails, reverts with the original error and refunds assets to refundAddress.
* Self-destructs after transaction completion to clear storage and prevent reuse.
* Fallback Function: Receives native tokens (e.g., ETH), allowing flexibility for handling WETH and similar assets.

## Deterministic Address Calculation

* `_depositAddress` Function in RouterRelay.
* Uses CREATE2 for predictable address generation based on salt and genericData.
* Allows the creation of identical addresses across chains, simplifying cross-chain deposits.

51 changes: 51 additions & 0 deletions docs/router-pay/user-journey.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,51 @@
---
title: User Journey with Router Pay
sidebar_position: 1
---

Router Pay simplifies the workflow for end users and reduces the risks of approvals and phishing websites from their dApp interaction journey. Below we have shown the difference in the journey for a user in the legacy dApps vs the ones which use Router Pay.
<center><figure><img src={require('./img/router-pay-workflow.png').default} alt="Router Pay Workflow" style={{width: "90%", marginBottom: 12}} /><figcaption>User Journey Pre and Post Router Pay</figcaption></figure></center>

## How does Router Pay work?

### Interaction Setup

* User begins by selecting a desired DApp interaction, such as a cross-chain transfer or interaction with a decentralized application.
* User inputs key parameters for the interaction, including:
* Target Address (callTo): Where the assets will be sent or utilized. This will be the dApp contract address.
* Approval Address (approvalTo): The address authorized to handle token transfers (if required).
* Encoded Data (data): Details about the transaction.
* Source Token (srcToken): The asset type for the interaction.
* Refund Address (refundAddress): Address to receive refunded assets if the interaction fails.
* Expiry Time: The maximum time allowed for the transaction to be completed.

### QR Code Generation

* RouterRelay Contract generates a unique deposit address using the provided parameters, and this address can be encoded as a QR code for easy user access.
* The User can simply scan the QR code, aligning with a familiar Web 2.0 experience.

### Asset Transfer

* User transfers assets (tokens or native assets) to the generated deposit address.
* DepositReceiver Contract is deployed at this address to hold the assets temporarily.

### Execution and Forwarding

* ReceiverImplementation.receiveAndSendToken is called via delegatecall by DepositReceiver, attempting to forward the assets to the specified callTo address.
* Conditional Solver Check:
* If assets are successfully forwarded to the specified address within the expiry time:
* The Solver validates the transaction parameters, including balance and expiry time.
* Upon successful validation, the Solver triggers the final transaction, completing the interaction on behalf of the user (e.g., cross-chain transfer).
* If conditions aren’t met or the expiry time is reached without adequate balance, assets are automatically refunded.

### Refund Mechanism (if applicable)

* If the transaction forwarding fails or the expiry time is reached without triggering, the following occurs:
* DepositReceiver sends the remaining balance to the refundAddress, ensuring user funds are secure.
* DepositReceiver then self-destructs to free resources, ensuring that temporary contract storage is cleared.

### Completion

* If successful, the transaction completes as intended, with assets transferred to the DApp or cross-chain destination.
* User receives confirmation of the transaction status and any relevant details about the final destination of their assets.

6 changes: 6 additions & 0 deletions docusaurus.config.js
Original file line number Diff line number Diff line change
Expand Up @@ -55,6 +55,7 @@ const SECTIONS = [
// defineSection('omnichain-framework'),
defineSection('tooling'),
defineSection('brand-assets'),
defineSection('router-pay'),
];

/** @type {import('@docusaurus/types').Config} */
Expand Down Expand Up @@ -186,6 +187,11 @@ const config = {
// className: 'new-badge',
// activeBaseRegex: '(.*ui-kit|.*web-core)',
},
{
label: 'Router Pay',
to: '/router-pay',
position: 'left',
},
{
label: 'Tooling',
to: '/tooling',
Expand Down

0 comments on commit 5f4844b

Please sign in to comment.