[1IP-79] Trading Terminal, Limit Orders, and Solana Integration for the Alternative Modular Interface of 1inch

[Anonymous580]

Simple Summary:

Hello everyone! This is the team behind the alternative 1inch interface. We’re back with a new initiative: building on top of the existing interface, we aim to develop a full-featured trading terminal with limit order support, enhanced swap flow UX, and Solana integration.
We are requesting 12 months and $288,000 in funding to complete this work.

Abstract:

Our goal is not just to add new features, but to take a major step forward in the development of the alternative 1inch interface. We plan to implement:

• support for limit orders,
• a user-friendly trading terminal with charts, order books, and trade history,
• an improved swap flow where all actions (approve, permit, wrap) are unified into a single clear sequence,
• Solana integration,
• interface deployment on IPFS with ENS access,
• phishing protection and technical documentation.

We believe these improvements will make the interface even more user-friendly, secure, and in demand — both for users and developers.

Motivation:

From the beginning, our goal has been to build the best Web3 interface — focusing on simplicity, openness, speed, and independence. Currently, the interface supports Fusion and Fusion+ swaps, and this alone has made us competitive. But traders need more than just fast swaps — they need tools: orders, charts, history, control. And we want to give them that.

We also want to highlight an issue we’ve encountered: in the past six months, we’ve discovered over five phishing sites using our code. This is alarming. We’ve already taken a major step by implementing the DevPortal Proxy, which not only optimizes requests but also helps detect unauthorized copies of the interface and analyze suspicious activity. It’s not just a proxy server — it’s a full-fledged monitoring and anti-phishing system.

To improve stability and manageability, the proxy infrastructure was migrated to Kubernetes. This gives us flexibility in deployment and scaling, and allows us to relocate proxy services to any region quickly. This approach significantly increases the system’s reliability and resilience against external threats.

Additionally, as our team grew, we realized the importance of comprehensive documentation — not only for ourselves, but also for future auditors who need to understand the project architecture. As part of this grant, we aim to document key parts of the codebase.

Specification:

We currently have over 50 tasks queued for improving code, architecture, and security. For this proposal, we will focus on the following areas:

• Implementing a limit order module based on 1inch DevPortal and onchain sources.

• Developing a trading terminal:

  • integrating price charts (currently researching the optimal solution),
  • displaying order books,
  • trade history and user order history.

• Building a complete activity history in the Account View section.

• Sending and receiving funds directly in the interface.

• Updating the swap UX — combining all steps into a clear, visual flow.

• Extending the embeddable widget system (currently a basic swap widget is implemented; we want to expand this and deliver the full trading terminal as a widget).

• Adding support for the Solana network — tokens, routing, compatibility.

• Deploying the interface on IPFS with ENS (we’ve already secured the 1inch-community.eth name, test version available at https://1inch-community.eth.limo).

• Automating publishing and updates via CI/CD to IPFS.

• Further improving the phishing protection system.

• Preparing architectural and technical documentation.

• Direct integration of hardware wallets (Ledger and Trezor — technical research is underway).

Below I would like to demonstrate an early draft of the trading terminal:

Rationale:

We’ve come a long way — from a basic swap interface (1IP-50) to a modular solution with Fusion+ support and phishing protection (1IP-66). Everything we do is open, transparent, and flexible. Now it’s time to expand the functionality and provide traders with advanced tools. This will enable integration into DApps, wallets, and trading platforms. We aim not just to catch up — but to lead.

We also highly value community input in this project’s development. If you have suggestions, ideas, or comments — we would love to hear them in the forum thread. Your feedback helps guide us in the right direction and make the interface better for everyone.

Considerations:

Security:

• All interaction with 1inch Dev Portal occurs only through https and an authorized proxy, which ensures a secure channel.
• The proxy infrastructure is protected using WAF, CORS, and a monitoring system.
• The architecture is built on Kubernetes, ensuring rapid response to threats and scalability.

Infrastructure and Distribution:

• Production deployment on IPFS with ENS.
• Automatic CI/CD publishing for new builds.
• Phishing monitoring system.

Documentation and Support:

• Code documentation for better internal understanding and external auditing.
• Continued modularization and embeddability improvements.

Budget and Team:

• Total budget: $288,000 for 12 months.

• If approved, 288,000 USDC will be transferred to the Operations Multi-Sig (0x45e84e10e8E85c583C002A40007D10629EF80fAF) and then paid out to 0x568D3086f5377e59BF2Ef77bd1051486b581b214 as follows:

  • An initial payment of 24,000 USDC as an advance.
  • The remaining 264,000 USDC to be streamed over the next 11 months.

Team:

• Lead developer — author of 1IP-50 and 1IP-66,
• Frontend developer with 10+ years of experience,
• UI/UX designer who has been helping us deliver the best user experience,
• QA engineer and former QA core team member at 1inch with deep DeFi testing experience.

Funding will cover:

• Developer services, including:

  • Solana integration and system modernization,
  • Infrastructure maintenance and extension (CI/CD, proxy, servers),
  • Documentation preparation, publication, and maintenance.

• QA services:

  • Swap and limit order flow testing,
  • Widget system testing,
  • Desktop app testing.

• Design services:

  • UI/UX improvements and architecture updates,
  • Design for the limit order interface,
  • UI/UX enhancements for Solana support.

• Security, testing, and update releases.

• Domain costs.

• Other services required for monitoring and security.

• A small reserve for future team expansion.

1IP-66 Work Report:

Here we would like to share the results of the work completed under 1IP-66.

Fully Completed:

• Fusion+ functionality implemented, including related refactoring for cross-chain flow.
• Private proxy server-based phishing protection system deployed.
• Account View implemented.
• CI/CD modernization completed — automatic publishing of all project libraries to GitHub Packages.
• Major infrastructure upgrade: proxy wrapped in Kubernetes for flexibility and scalability, with global load balancing for improved performance.

Not Fully Completed:

• Permit2: the frontend implementation is done, but due to issues on the 1inch DevPortal side, it’s temporarily disabled. We’ve reported the issue to the 1inch team and are waiting for a fix. As soon as it’s resolved, we’ll re-enable, test, and release Permit2 functionality.
• We weren’t able to fully implement automatic code signing for the macOS desktop app, due to communication issues with Apple support. We’re currently resolving this, and will resume once we gain the necessary developer rights.
• Initial load performance: to protect users from phishing, we implemented an interface verification system, which increased initial load time. This is a temporary issue — we plan to fix it soon by introducing bypass mechanisms without compromising user safety.

Project GitHub repository: link
Project GitHub Paging staging link

[crushingstance33]

[Arana_Digital]

Thank you for your follow up proposal. This proposal is a significant step up in terms of costs relative to both 1IP-50 & 66. There is a case for expending a baseline level of capital for an open-source 1inch front-end, however, we fail to see the merits of including every feature that the canonical FE has in the open-source FE. Redundant feature introductions simply add more costs without necessarily providing tangible value back to the protocol growth or DAO sustainability. In our opinion, the entire purpose of an alternative FE is to provide a backup venue for users to rely on in case unexpected issues transpire with the canonical FE. It’s doubtful the alternative FE will ever act as a substitute.

Correspondingly, the most important variable here is the analysis of existing and historical usage of the alternative FE since its introduction via 1IP-50. If anyone has access to alternative vs canonical FE usage, we would very much appreciate that information. In the event that a considerable number of users do indeed use the alternative FE, we will be more inclined to vote in favor of this proposal. However, presently, we neither have the data nor are convinced that enough users access this FE. To that end, we reserve the position that an alternative front-end is a baseline product that requires basic sustenance without excessive feature additions.

[Anonymous580]

Hello! Let me clarify our goals and position regarding the current proposal.
The goal of this project is not to compete with the main 1inch interface, but to create the best true decentralized app solution on the market. We aim to rely not only on what already exists in the 1inch interface but also to adopt the best practices and ideas available across the industry. In the long term, this project aspires to become the primary interface for 1inch.
We are currently researching the implementation of a WebTorrent-based distribution system. This will allow us to create a truly decentralized exchange application and a resilient p2p network of users that does not depend on any external infrastructure or providers.
In the near future, we also plan to implement a simplified distribution system using IPFS + ENS. This can be delivered relatively quickly and already provides the ability to access the application in a decentralized way. However, the WebTorrent-based approach is extremely promising and could benefit the entire ecosystem.
Regarding the budget — yes, we fully acknowledge that the costs have increased, along with the size of our development team. The first two proposals were implemented by a single developer. We are now joined by an additional developer and a QA engineer. This will allow us to improve the overall quality and stability of the product and speed up the development process. I would also like to emphasize that we are not requesting the full amount upfront — funds will be streamed over the course of a year, and in the event of any issues, the DAO can stop the stream at any time. We believe this is the most transparent and secure model for the DAO.
As for usage — we recognize that the number of users is currently much lower than that of the main 1inch interface, but it is not zero. We would be genuinely grateful if major community participants could help spread the word about our interface via their social media channels.

[Anonymous580]

Regarding your statement that a trading terminal might be excessive for an alternative interface — I want to emphasize once again that our goal is to deliver the best solution. I firmly believe that if we as a community can provide users with the best experience on the market, it will demonstrate the DAO’s strength — not only in managing financial decisions but also in attracting contributors capable of building technically ambitious, long-term projects from scratch — within the ecosystem of the 1inch DAO.
Thank you for your attention.

[Anonymous580]

We have taken your feedback regarding the budget into account and were able to reassess certain expenses, reducing the requested amount to $288,000.

[Arana_Digital]

Appreciate you taking the feedback into consideration, Denis.

Would you happen to have more clear numbers around the alt FE’s usage since it went live? Without publicizing this FE through a concerted marketing effort, it likely won’t pick up usage. And if marketing occurs on two fronts, it would simply confuse users.

“In the long term, this project aspires to become the primary interface for 1inch.” —> What’s the basis for this claim? Is the 1inch team also aligned with this vision, or is the vision for this to be an entirely community-led project? If the answer is the latter, there should also be a means by which visibility is addressed. And with the canonical FE existing, which has marketing spend around it, the alt FE would in practice be a competitive venue. Therefore, we still hold the opinion that a community-based FE should be sustained but remain rudimentary in its feature set—until it becomes necessary to add onto the FE. For now, a baseline maintenance + security assurance request would seem more apt.

Happy to hear what other delegates also have to say.

[FranklinDAO_Penn_Blo]

This feels like funding a solution in search of a problem. $288K for a competitive interface with unclear adoption seems hard to justify. The goal should remain keeping this as backup infrastructure to the main FE rather than gunning to “become the primary interface for 1inch.”

We’re supportive of the minimum needed to develop and maintain an interface that’s secure with basic functionality to act as an alternative. We’re not for increasing the scope by adding features with uncertain demand.

If there’s measurable and substantial organic usage, and these users are pushing for a more robust feature-set, then we can reconsider expanding the scope using the lean-approach. But right now we don’t have usage data to justify a full trading terminal and advanced features. The DAO shouldn’t fund feature parity with the main interface just because we can. We should incrementally fund what users actually need based on demonstrated demand/feedback.

[Anonymous580]

We have heard your position and respect it. However, we still believe that implementing limit orders, Solana network support, and a trading terminal will be beneficial for users, even as part of a fallback interface. In addition, we have outlined a number of technical improvements aimed at increasing the stability of the application.

At this point, I believe we can take a snapshot and proceed with the vote. If the community votes against the proposal by majority, I will revise the task plan and budgets, reduce them, and submit a new proposal requesting funding to support the application’s infrastructure.