Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extensify UniswapX scaffold-eth branch #167

Open
moltam89 opened this issue Dec 6, 2024 · 0 comments
Open

Extensify UniswapX scaffold-eth branch #167

moltam89 opened this issue Dec 6, 2024 · 0 comments

Comments

@moltam89
Copy link

moltam89 commented Dec 6, 2024

Hey guys,

I'm working on a UniswapX demo and already have a working scaffold-eth/UniswapX branch, but I cannot create an extension from it.

In order to show how to fill UniswapX intents, I'm doing some weird stuff. Using live data is not really feasible for a demo like this because professional fillers can easily beat my naive filling strategy—using UniswapV3 as a liquidity source—so I set up a local Arbitrum fork on a specific block number.
Also, I need to modify block timestamps because UniswapX intents currently use the block timestamps to calculate the required amounts (Dutch auction).

Here are the parts I ran into problems while creating an extension:

  1. hardhat.config.ts
    I'd need to change the hardhat network, as seen here.
hardhat: {
  allowBlocksWithSameTimestamp: true,
  forking: {
    url: `https://arb-mainnet.alchemyapi.io/v2/${providerApiKey}`,
    blockNumber: STRART_BLOCK_NUMBER,
    enabled: process.env.MAINNET_FORKING_ENABLED === "true",
  },
  chainId: CHAIN_ID_ARBITRUM,
},

Currently the hardhat.config.ts.template.mjs template doesn't support this.

  • Would it be a good solution if I added template support for the Hardhat network? I'm not sure if it’s the right approach to change pieces one by one; someone might need to change something else in the future.
  • Maybe a more general solution could be to merge settings, similarly to merge-package-json.ts. According to ChatGPT, we could use deepmerge so that we have a default HardhatUserConfig and merge it with the settings from the extension. However, backward compatibility might be an issue with this approach.
  1. scaffold.config.ts
    This is what I'd need to achieve.
import { localForkArbitrum } from "./app/uniswapx/_helpers/constants";

const scaffoldConfig = {
  ...
  targetNetworks: [localForkArbitrum],
  pollingInterval: 2000,
  onlyLocalBurnerWallet: false,
  ...
} as const satisfies ScaffoldConfig;

I use a customized Arbitrum network, which points to the locally running node. I'd also like to modify pollingInterval and onlyLocalBurnerWallet. Similarly to hardhat.config.ts, I'm not sure what would be the best approach.

  1. wagmiConfig.tsx
    This is how I tricked wagmi to use the locally running Arbitrum network:
export const wagmiConfig = createConfig({
  chains: enabledChains,
  connectors: wagmiConnectors,
  ssr: true,
  client({ chain }) {
    const alchemyHttpUrl = chain.id == arbitrum.id ? "http://127.0.0.1:8545" : getAlchemyHttpUrl(chain.id);

We don't have template files for wagmiConfig.

  1. FaucetButton.tsx
    I had to make some changes, my FaucetButton.tsx shows the faucet on my local Arbitrum network (not just on Hardhat). Additionally, I use a different method to send ETH that preserves the block timestamps, since UniswapX intents calculate the required amounts based on the block timestamp.

Repositories:

  • UniswapX-extension-base, this is the same as my scaffold-eth/UniswapX branch. It can be cloned into this the current create-eth repo, so we can use yarn create-extension UniswapX-extension-base to list the changes which needed to be done manually.
  • UniswapX-extension, this is what yarn create-extension UniswapX-extension-base results in, I also created the files to handle the package.json and Header.tsx changes.

Thanks for the help,
Tam

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant