Skip to content

Latest commit

 

History

History
96 lines (77 loc) · 5.14 KB

README.MD

File metadata and controls

96 lines (77 loc) · 5.14 KB
Raw

This is the mono repo for gastly

Description

As web3 users navigate the diverse ecosystems across many chains, we will inevitably accumulate an abundance of disparate wallets, with many different tokens.

The goal of building Gastly is to unify all these wallets & tokens in a task that is ubiquitous across every chain: paying for gas.

Gastly is the glue that enables any of your wallets pay for a transaction, using any token, regardless of the chain.

Definitions

  • Root Pool
    • The pool on a home chain (currently Polygon) in which all other branch chains send their gas payments to
  • Branch Pool
    • The pool on a chain other than the main chain that the user sends their gas token to.
  • Safe
    • Smart contract wallet
  • 1Balance
    • Paymaster for the Safe wallet
  • xERC20
    • A bridgable LP token minted to liquidity providers

Features

Native Asset Pools

Root and Branch Pools do not rely on a lock and mint mechanism. They instead are liquidity pools that providers directly depost the native token (USDC on Polygon mainnet, goerli Eth on goerli) into. The accounting is done using virtual crediting that is sent through Wormhole

Dynamic Balancing Pools

Diagram At the heart of Gastly is a hub-and-spoke pool model. When a user pays with Branch Pool tokens, intuitively, the tokens should be sent to the Root Pool. However, this would be costly for users if their tokens were always bridged over.

Instead, it relies on internal accounting to determine how much can be bridged. Tokens are kept on their respective chain, and rebalancers are incentivizes through rebalancing fees.

BranchPool
LP: 100
assets: 100
last known balance of Root: 100
Bridgable bandwidth of BranchPool (b): 100

RootPool
LP: 100
assets: 100
last known balance of Branch: 100
Bridgable bandwidth of RootPool (b): 100

==Transfer 50==
BranchPool
LP: 100
assets: 100 + 50 = 150
last known balance of Root: 100 + 50 = 150
Bridgable bandwidth of BranchPool (b): 100 - 50 = 50

RootPool
LP: 100
assets: 100 - 50 = 50
last known balance of Branch: 100 - 50 = 50
Bridgable bandwidth of RootPool (b): 100+ 500 = 150

In the above scenario, 50 tokens are bridged from Branch to Root. This reduces the bandwidth to 50, which mean only 50 more tokens can be bridged. In the Root, the bandwidth has increased to 150, this means up to 150 can be bridged over to Branch. Also to note, that the bandwidth has diverged from the currently liquidity (LP). We can incentivize users to 1) deposit more LP to bring it closer to the bandwidth 1:1, or 2) bridge to Branch

Account Abstraction

Gastly uses Safe Accounts with 1Balance to pay for transactions. 1Balance receives tokens from the Root Pool.

Bridgable LP token

LP tokens are xERC20 tokens that can be bridged over. Utilizing Connext, LPs to reclaim their collateral on different chains. This helps the protocol by aiding in rebalancing of the pools, but also gives LP freedom on where they want their liquidity. A model to incentivize rebalancing is being developed.

Dynamic Fee

Fees are charged based on a [utilization curve] of the Root Pool. Utilization is calculatd as

Utilization Rate = balanceUsed / gasToken.balanceOf(rootPool)

where balanceUsed is adjusted everytime stable coins are deposited in 1Balance.

As utilization rate approaches 1 (or, 100%), it means that liquidity on the root pool is being depleted, and branch pool liquidity is increasing. High utilization means users pay higher fees, which also incentivizes liquidity to be 1) rebalanced from the branch pools, and 2) deposited directly into the root pool.

Known issues

  • Incase crosschain fails, there is no withdraw deposit function
  • Gas overages does not get refunded
  • No LP fee curve

Addresses

To verify XERC20

forge verify-contract  --verifier-url  https://api-testnet.polygonscan.com/api 0xA34488C6C27542cdCDD381D41eb359755B232dc5 lib/xERC20/solidity/contracts/XERC20.sol:XERC20 --chain 80001 --constructor-args 000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000000000a0000000000000000000000000c10fa06d401c05bce65b55efb1ef2158e55ff1d7000000000000000000000000000000000000000000000000000000000000000e676173746c792d6c702d676574680000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007676c706745746800000000000000000000000000000000000000000000000000 --watch