Key Features • Short Description • How To Use • Inspirations •
- Batch sell multiple tokens into USDC on same network
- E.g. Swap Cake, WMatic and Link for native USDC with
one click
- E.g. Swap Cake, WMatic and Link for native USDC with
- Aggregated transaction and Slippage Control
- Native USDC bridge from source chain to destination chain through CCTP
- Abstracted redeem USDC process thanks to WormHole Automatic relayers
- I.e. Utilise Wormhole to deliver USDC to user wallet after destination chain USDC arrival
- React Front end utilising Three.js
- 1RPC https endpoints for CCTPxWormhole supported chains - maximise privacy during wallet-wide off-ramping
- Quick withdrawal, Potential Gas Savings and Ability to optimise transfer for speed vs cost
- Specific Ubeswap integration for liquidity enhancement on Celo Chain - Forward thinking accommodation of potential Roll-up layer 2 conversion.
Utilising the Dzap sdks, we can identify all the tokens in a connect wallet (supports metamask, walletconnect, talisman etc). We then allow the user to dictate which tokens in their wallet to be converted to USDC and their slippage tolerance. Dzap sdk natively calls 1inch, uniswap and sushiswap, Event Horizon integrates Ubeswap to allow integration of Celo chain. Then they select which wallet address and destination chain to receive the USDC. We use the CCTP and wormhole integration together with 1RPC https endpoints for Ethereum and Avalanche C-chain for the moment.
To clone and run this application, you'll need Git and Node.js (which comes with npm) installed on your computer. From your command line:
# Clone this repository
$ git clone https://github.com/Podima2/Event-Horizon
# Go into the repository
$ cd Event-Horizon
# Install dependencies
$ npm install
# Run the app
$ npm start
Note DZap SDK is not connected to front end in current version. DZap swap, of multiple tokens should be fed into CCTPxWormhole swap mechanism. Additionally, Dzap sdks are not connected to CTTPxwormhole integration due to unknown network connection issues not regarding API connectivity in the nativeUSDC demo clone.
- Why is this necessary?
Off-ramping for diversified token holders is a time-consuming and potentially frustrating process in particular during moments of high volatility. Simplifying the process is critical for onboarding more users from more catered environments in web2.
- Why alter the circle/wormhole integration to remove the last swap from USDC to the destination chain native token?
We believe this actually allows for increased flexibility given native to USDC liquidity, therefore, should the user decide to continue swapping, they commence from a low-risk position. Additionally, by leveraging the ability to redeem USDC/USD 1-to-1, we are effectively creating a wallet-wide off-ramp mechanism.
- Why utilise 1RPC endpoints as opposed to other providers and why ethereum and avalanche C chain?
Other node providers such as Infura have been known to collect user information such as IP address, to maintain the ethos to right-of-privacy for Event Horizon users we believe they allign best with our values. With regards to ethereum and avalanche C chain specifically, these are two of the three networks supported by CCTP as of the present moment however we operate under the assumption that Native USDC will only continue to expand its interoperability and therefore the destination chains will become more diverse.
- Whats the roadmap going forward?
Utilise RFQ based crosschain DEX's in combination with xDEX's to provide enhanced support for trading pairs across chains. This would replace the dependency on the Dzap sdks. Furthermore, including support for Arbitrum, the other supported network by CCTP.
These examples contributed to the creation of this project:
GitHub @Podima2 · Twitter @The_Game_2030