---
# System prepended metadata

title: Intmax <-> Lightning Network

---

# Intmax <-> Lightning Network  

### Why this integration is interesting? 

- **Low cost** No need to pay evm gas fees for each transfer. Batching in a block offers lower cost transfers between intmax and LN. 
- **no Mininimum tx amount** It allows users to receive 1 sat without having to open a channel on LN. Addressing the tradional contstraint of channel capacity in the Lightning Network. 

###  Design Objectives

- **Native EVM L2 payment:** Intmax to Intmax payments should work as normal on the EVM rollup with native BTC (rBTC, cBTC..etc). 
- **Aggregation** Intmax to lightning and vice versa should benefit from aggregation to avoid paying EVM tx fees evert tx and to achieve scalability of LN.  
- **Single UX for transfers** both ways. i.e we do not want users to have to withdraw to EVM first then do another action on LN or intmax. 

### Actors 
- **Intmax node**: Anyone can run a node including intermediary. The node simply aggregates and permissionlessly submits blocks to EVM intmax contracts.  
- **Intermediary**: A market maker that has liquidity in Lightning Network and Intmax liquidity contract.  
- **Payer**: user on either LN or Intmax 
- **Recipient**: user on either LN or Intmax


### LN -> Intmax 
- **Recipient** : Intmax user  
- **payer**: Lightning N user  

```mermaid 
sequenceDiagram  
participant Payer (LN)
participant Intermediary
participant Recipient (Intmax)
participant Intmax node
Recipient (Intmax)-->>Intermediary: create H(s) & share LN payer details to check fees
Intermediary -->> Recipient (Intmax): LN invoice details 
Recipient (Intmax) -->> Payer (LN): share lightning invoice 
Payer (LN)->>Intermediary: HTLC payment with H(s) 

Intermediary->>Intmax node: Hash of tx (LN-tx with P to recpient)
Intermediary-->>Intmax node: case1 cancel tx 
Recipient (Intmax) -->> Intmax node: submit s to force spending from intermediary
 
```

1. **Recipient** creates a secret S and payment hash P that is produced by hash of secret H(S)
2. **Recipient** queries the **intermediary** off-chain, with payment hash P and an amount he wishes the receive, **intermediary** creates a bitcoin lightning invoice using payment hash P, with the amount specified and returns it to **Recipient**. 
3. **Recipient** sends lightning invoice to Payer 
4. **Intermediary** receives incoming lightning network payment from payer but cant spend because intermediary doesnt know secret S. 
5. **Intermediary** creates a tx on Intmax paying the funds to recipient after a time delay TIME_LIMIT (eg. 2mins). The time delay gives a chance to intermediary to cancel if they do not recive secret S from the recipient that allows them to spend the LN payment in step 4. 

##### successful payment
6. **Recipient** shares secret S with **intermediary** and no further action is taken by the **intermediary**. Once time delay is finished, the payment to intmax recipient is complete.
7. **Intermediary** uses the revealed _secret S_ to settle the lightning network payment.

##### Recipient goes offline
6. **Intermediary** waits just before TIME_LIMIT and submits a cancellation request to intmax node. 

##### Malicious intermediary 

6. **Recipient** shares the _secret S_ with intermediary, but intermediary still submits a cancellation tx. 
7. **Recipient** submits _secret S_ on EVM revealing it and forces the payment finally. 


#### LN-Intmax deposit block (aggregation)
The complete deposit block which aggregates all LN->intmax transfers occurs over 4 stages with onchain EVM transactions by the intmax node. 
1. Intmax Node commits root of  tree of txs from step 5 and shares open tree with all recipients. 
2. Intermediary shares cancellations with Intmax node and commits the cancellations dictionary onchain. 
3. Recipients have chance to respond to cancellations by submitting their secrets S onchain to enforce inclusion of their txs. 
4. Final root is calculated with all valid txs aftere removing the cancelled txs. (note:A zkp of correct transition from first root and cancellations may be needed in implementation). 


### Intmax -> LN 
- **Recipient** : Lightning Network user 
- **payer**: Intmax user  

```mermaid 
sequenceDiagram  
participant Payer (Intmax)
participant Intermediary
participant Recipient (LN)
participant Intmax node
Recipient (LN)-->>Payer (Intmax): use _secret S_ to create P & share  invoice 
Payer (Intmax) -->> Intmax node: ln tx with inputs (recipient address, P) 
Intermediary ->> Recipient (LN): HTLC payment with P revealing _secret S_ to intermediary
 
```

1. Recipient creates a regular bitcoin lightning invoice with fixed amount and sends it to the payer (this invoice contains the payment hash P)
2. Payer constructs a withdrawal tx on intmax with:
    - H(s) Hashlock 
    - Intermediary EVM address 

3. Intermediary observes withdrawal tx and proceeds to attempt payment of Lightning invoice 
##### Successful payment 
4. Recpient on LN reveals a secret S to intermediary in order to accept the payment of the lighting invoice.
5. Intermediary uses the knowledge of _secret S_ to obtain the funds from the HTLC on EVM and swap is finished.

##### Failed payment 
4. The payment was unsuccessful, so **recipient** did not reveal a secret S to the **intermediary**.
5. Intmax withdrawal was through a HTLC to the intermediary on EVM, so since its never claimed, funds go back to liquidity contract when timelock expires. 
##### Intermediary went offline 
4. Payer on Intmax waits until time lock is finished and the withdrawal tx is cancelled. 












