[1IP-50] 1inch alternative swap interface

2.1 General Proposals
1

Simple Summary

It is proposed to create an alternative open-source version of the 1inch swap interface.

Abstract

The alternative exchange interface will implement the same functions as the main 1inch exchange interface, but being an open source product, which allows each community member to make changes and put forward suggestions for improving the product

Motivation

Creation of an alternative version of the interface in the development of which every community member can participate

Specification

The main technical task at the moment is to implement an interface that allows creating Fusion Swap Order and Limit Order based on token prices from open onchain or subgraph sources, such as Uniswap v2, v3, SushiSwap, PancakeSwap, and others.
For the technical implementation, Angular 17 (the current version at this moment) will be used, utilizing the new signal approach in this framework. The viem library will be used for onchain interaction.
Also, it is necessary to create a desktop version of the swap interface. For this purpose, an Electron wrapper (or similar technologies) and a distribution system through GitHub Releases will be used.

Rationale
For the implementation of the application, I chose from the three most popular solutions for web applications at the moment: React.js, Angular, and Vue.js. The main criteria for selection were:

  • Developers’ experience working with these solutions.
  • Flexibility of the solutions.
  • The completeness of features ‘out of the box’.
  • Support for TypeScript.

Based on these criteria, I settled on Angular as this framework is my main tool. Currently, the Angular development team greatly facilitates the process of working with the framework, making it more flexible and adaptable. This framework provides a full range of solutions for implementing complete web applications, and importantly, TypeScript is native to Angular.

Viem was chosen as the most modern and lightweight implementation of the onchain middleware. It is well-suited for tree shaking and has very strict TypeScript support.

Considerations

Although the main goal of the application is to fully transition to an onchain work system and to move away from various APIs, at this stage, we cannot completely abandon the use of external APIs. The only essential API, without which the application cannot function, is the API for sending fusion orders. To interact with this API, the 1inch Dev Portal will be used. Since the 1inch Dev Portal requires authorization and its security policies do not allow working with the API through web applications, setting up and maintaining a proxy is required. In turn, a completely open and unprotected proxy will become a kind of backdoor for anyone who wants to use it. This implies the need for setting up CORS policies and various security measures such as a Web Application Firewall.

Costs

Lead Developer: The team leader’s responsibilities include creating the basic framework of the application, establishing and maintaining contribution rules for the community, writing application code, writing unit tests.
Cost for 12 months: $72000

**Part-time UI/UX Designer: **The designer’s responsibilities include developing a design that differs from the main 1inch design and creating a unique style for the application
Cost for 12 months: $1000

Total: $73000

Receiving Address
For funding the project, the following address is proposed: 0x568D3086f5377e59BF2Ef77bd1051486b581b214.

GitHub repository: https://github.com/1inch-community/interface

3 Likes
2

That’s a great proposal that community members can contribute to the protocol experience directly.
If these updates are implemented, or right now, are there any ways to keep the contributors motivated to submit the proposals for fixing the user experience of 1inch frontends so far?

3

Hello, currently there is no specialized page for collecting user feedback. I think that at the initial stages, GitHub Issues will be sufficient.

4

I am trying to understand the motivation and abstraction behind it.

You want to provide an open source solution but with the same functionality. I just don’t see the benefits. You could make the current version open source and let the community participating.

What is the reason for this main goal:

main goal of the application is to fully transition to an onchain work system and to move away from various APIs
If it has valid points why not bringing the focus in the current dapp to improve it in this direction?

You mention here a price for some parts of an application development but it contains a way more than this. Community projects need a well defined testing strategy and a lot of effort to hold it.

How many devs would work on it to bring the quality you need for a sensitive application like this.

How do you want to attract people in the community to participate (for free)?
What is here the business model behind it for them?

In my opinion, this proposal needs a way more preparation with more details and more considerations in different directions.

1 Like
5

Thank you Denis, for the shout out! I always knew, there must have been a person brave enough to purpose this!

For the sake of all 1inch contributors,
I want to officialy sentence myself to be obliged to take on this burden, and dedicate my entire life to the good of open source 1inch project, powered by the most modern of all times framework: Vue.js … and no part-time designers needed … … .
I’m faithfully willing to give this favour to 1inch, only for: 250k, a case of beer and a helicopter.
So, gentlemen, could you please be so greatful to send your helicopters at: 0x610732Aa2ca548b3e4F19e8dc715572F3CF8D18A to sponsor my faithful idea.

All the best, and always at your service,
Yurii Rohovtsov

6

This proposal has passed the temperature-check vote and has been posted to Snapshot: [1IP-50] 1inch alternative swap interface

1 Like
7

Hi, I’d like to answer a few of your questions.

You could make the current version open source and let the community participating.
I think that it is not in my competence to decide whether the current version of the product will be open source

Main goal of the application is to fully transition to an onchain work system and to move away from various APIs
Moving away from centralized APIs will allow the creation of a more distributed and resilient system, and will also be able to provide the same swap functionality as the main application without putting a heavy load on the 1inch devportal servers.

If it has valid points why not bringing the focus in the current dapp to improve it in this direction?
I cannot answer this question since I do not influence the development processes of the main application

Community projects need a well defined testing strategy and a lot of effort to hold it.
I completely agree with you, testing is an extremely important aspect for any application. But at the moment, I plan to limit myself to unit tests. Furthermore, if someone from the community wants to participate in the project as a QA engineer, I would be very happy to receive such help.

How many devs would work on it to bring the quality you need for a sensitive application like this.
At the moment, I am the only developer, but I hope that in the future, other developers from the 1inch community will join me.
I also believe that open sourcing the code will allow everyone to follow the development process and contribute to it.

How do you want to attract people in the community to participate (for free)?
I believe that attracting people to work for free is unfair and very bad; any labor should be compensated.

You’ve asked very useful questions that have made me think even more deeply about the development of the project. Thank you and best wishes!

8

After reviewing the [1IP-50] proposal for creating an alternative swap interface. Although we think generally open-souring is a good idea,we have decided to vote against this initiative based on several critical concerns:

Lack of Detailed Development Plan and Timeline:

The proposal lacks a comprehensive development plan, including detailed timelines, testing strategies, and maintenance frameworks. The allocation of $73,000 for 12 months raises questions about the efficient use of funds - particularly, we would like to see a clear breakdown of expected man-hours, specific tasks, and milestones . A detailed plan is crucial for ensuring accountability, effective resource use, and the initiatives’s long-term success. The absence of such details suggests a risk of misallocation of DAO resources, which could be better utilized in areas with a more transparent and structured approach.

Redundancy and Efficiency Concerns:

The proposal suggests developing an alternative interface that replicates the functionality of our current swap interface, which raises concerns about redundancy. There appears to be an opportunity to improve and sourcing our existing interface rather than building a new one from scratch. This approach would likely result in more efficient use of resources, avoiding unnecessary duplication of efforts and focusing on strengthening and expanding the capabilities of our existing stack.

9

Work Description for DAO

I would like to summarize the current grant and outline, step by step, what has been accomplished and the challenges encountered during the development. If you wish to see what has been done, you can visit this link, where all updates related to the project are published. Please note that this version may be unstable, so use it at your own risk.

1. Technology Analysis and Selection

At the beginning of the development, the 1inch team proposed the idea of creating a modular interface that could be embedded into any applications. I liked this idea, but it required additional technical analysis. A thorough analysis of existing technologies and frameworks for interface development was conducted. Initially, Angular was planned to be used as the main framework, but during the technical analysis, it was identified that Angular is a heavyweight solution that could negatively impact the performance of pages with embedded modules. After discussing with the 1inch team and evaluating the performance requirements, a decision was made to switch to Lit.

Lit was chosen for its lightweight nature and support for native web components, which significantly reduced the system load, minimized bundle sizes, and accelerated the operation of embedded modules. This solution proved to be more efficient for creating modular and easily integrable solutions.

2. Development of Modular Architecture

The main focus of the interface development was on creating a modular architecture, which allowed for a flexible and easily adaptable system. The modular design enabled the integration of various components, such as the swap form and other elements, into any applications and platforms without the need for significant changes to the existing infrastructure.

This architecture was implemented using Lit and a build system based on esbuild, which significantly accelerated the development process and optimized the build of components for further use.

3. Creation of Integration Layer

To ensure the universality of module integration, a special integration layer was developed. This layer allows embedding the swap form or any other module into the desired location of the host application, regardless of which framework or library the application uses (React, Angular, Vue, etc.).

This integration layer ensures compatibility with various web environments and simplifies the process of connecting modules to existing interfaces. Examples and documentation for using this technology have been made available on the project’s GitHub so that developers can quickly integrate these solutions into their platforms.

4. Implementation of Swap Functionality

A user-friendly interface was created to enable users to quickly swap tokens using the 1inch protocol. Special attention was given to UX/UI to ensure an intuitive and fast process for end-users.

This functionality was tested on various devices and platforms to ensure its stability and performance.

5. Performance Optimization

During development, a data storage system using IndexedDB was implemented. This solution minimized the number of network requests and ensured fast interface performance, even on devices with limited resources.

In addition, various code and algorithm optimizations were made to prevent lags and ensure smooth application operation. The use of IndexedDB proved to be a key solution for improving stability and performance on portable devices.

6. Development of Desktop Interface Version

A desktop version of the interface was also developed using the Electron framework. This version supports builds for all major operating systems, including Windows, MacOS, and Linux (AppImage). The desktop version provides the same capabilities as the web version.

This approach allowed the project to reach a wider audience and provide convenient access to the interface’s functionality, regardless of the platform.

7. CI/CD Setup for Automatic Publishing and Updates

To increase development efficiency, a CI/CD system was configured to automate the process of building and publishing new interface versions. The desktop version is published through GitHub Releases, allowing the application to be automatically updated for users.

An automatic publication of the latest version of the web interface on GitHub Pages was also set up so that users could easily view the latest changes and improvements to the project.

8. Ensuring Security and Stability

One of the most significant challenges was the need to use an Nginx proxy to encapsulate keys from the 1inch Dev Portal. Proxy servers were deployed on DigitalOcean in India to optimize response times for users in Asia and Europe. However, the use of a proxy server revealed its limitations in terms of scalability and stability.

A plan was developed to improve the infrastructure, including optimizing server locations and increasing their performance to ensure stable handling of requests even under high load.

9. Problems and Challenges

The project encountered a number of challenges:

  • Proxy server performance issues: The server sometimes fails to handle a large number of requests, which affects response times and interface stability.
  • Challenges with obtaining signatures for the desktop version: When planning the grant, it was not considered that a proper signature is required for signing the desktop application code. The lack of a signature currently prevents automatic updates on some versions of the desktop application.
  • Need for additional collaboration with the 1inch team: Expanding the functionality required close collaboration with the 1inch team to enhance the capabilities of the Dev Portal and API.

Despite these challenges, solutions were found to improve the quality of the application’s performance.

Conclusion

The development of an alternative interface for 1inch with a modular architecture, swap support, and an integration layer demonstrated significant achievements in improving performance and user experience. Continuous work on optimization, issue resolution, and integration enhancements has allowed the proposal of one of the best solutions on the market for crypto asset exchanges.