[GuardianUI] LTIPP Application Draft

SECTION 1: APPLICANT INFORMATION

Provide personal or organizational details, including applicant name, contact information, and any associated organization. This information ensures proper identification and communication throughout the grant process.

Applicant Name: Lienid

Project Name: GuardianUI

Project Description: GuardianUI is an end-to-end testing and frontend security monitoring platform for web3 apps. We offer a suite of products designed to improve frontend security, including our open source testing framework - GuardianTest.

Team Members and Roles:
Lienid is a full-stack engineer at OlympusDAO

Jem is a full-stack engineer at Bond Protocol and previously contributed to OlympusDAO

Ivelin Ivanov is an experienced open source software contributor and technology entrepreneur with an emphasis in AI and machine learning.

Lipman is a BD contributor to Balancer and has contributed to several web3 projects DAOs.

Project Links: [Enter Any Relevant Project Links (website, demo, github, twitter, etc.)]

Website: https://www.guardianui.com/

Docs: ​​GuardianUI Overview - GuardianUI

Discord: GuardianUI

Github: GuardianUI · GitHub

Twitter: https://twitter.com/guardian_ui

Contact Information

Point of Contact (note: this should be an individual’s name, not the name of the protocol): Lienid

Point of Contact’s TG handle: @Lienid_11

Twitter: https://twitter.com/0xLienid

Email: 0xlienid@gmail.com

Do you acknowledge that your team will be subject to a KYC requirement?: Yes

SECTION 2a: Team and Product Information

Our team has worked closely together since Q4 2021 in different capacities - originally as members of OlympusDAO’s Engineering Working Group. We co-founded GuardianUI in the late summer of 2022.

Lienid was a full-stack and smart contract engineer at OlympusDAO until recently

Jem was a full-stack engineer at OlympusDAO until recently and is a current core contributor at Bond Protocol

Lipman ran business development and new ventures at one of the largest ecommerce companies in the U.S. In addition, he co-founded SporosDAO and has advised multiple web3 projects.

Our open source web3 end-to-end testing framework (GuardianTest), which enables defi developers to create user simulations and ensure their UI is creating the correct smart contract interactions, has 26 stars on Github. It extends the popular Playwright testing framework so developers can easily:

  • Engage with local deployments, staging deployments, OR live production
  • Perform tests on EVM compatible chains
  • Pin tests to any block
  • Interact with a site using a wallet
  • Mock ERC20 balances and allowances
  • Validate target contract addresses from app interactions
  • Perform any other actions or validation Playwright offers (e.g. standard user flows are working, copy and layout appear correctly, etc.)

In summer 2023, we brought on Bond Protocol as a paying client for our frontend security monitoring (see: case study), which integrates tests written with GuardianTest with our Frontend Security Monitoring platform to check and verify whether a dapp’s live UI is working appropriately for users (e.g. transactions point to the correct contracts and approvals give the correct addresses access to user funds).

GuardianUI’s Frontend Security Monitoring solution provides real-time vulnerability and performance-issue detection for a dapp’s frontend:

  • Simulate user interactions for web3 flows (e.g. making sure a transaction points to the correct contract).
  • Perform simulations as frequently as every 5 minutes.
  • Get notified immediately via email and/or discord when there’s an issue.

We were in the process of bringing on other clients, however, we decided to pause the business during the bear market due to defi protocols tightening their budgets and the co-founders self-funding the business.

Our frontend security monitoring product was recognized as a leader in Threat Intelligence and Security Testing Tools in the Coinbase Ventures Web3 Security Stack report.

We will use this grant to monitor the top 10 most critical smart contract interactions for the UIs of the top 10 defi protocols on Arbitrum. This will provide immediate value to those protocols and Arbitrum by helping keep real users safe, and act as a “trial period” to encourage these 10 protocols (and hopefully others) to monitor more than these 10 smart contract interactions.

What novelty or innovation does your product bring to Arbitrum?

We are one of the only open source e2e testing frameworks in web3 and extend an already popular web2 framework (Playwright) to make it possible. We are the only protocol using end-to-end tests to simulate user interactions against live dapps to detect frontend attacks.

Is your project composable with other projects on Arbitrum? If so, please explain:

Yes. Our monitoring solution works for all defi protocols on arbitrum.

Do you have any comparable protocols within the Arbitrum ecosystem or other blockchains?

Synpress is another open source testing framework that can be used in pre-deployment workflows. However, they do not provide ongoing continuous monitoring for threat detection of live dApps like GuardianUI.

How do you measure and think about retention internally? (metrics, target KPIs)

Our business is more akin to a traditional SaaS company, so we think about retention as both customer retention (e.g. the % of paying customers who continue to pay month-over-month), and dollar retention (e.g. the absolute revenue $s we earn month-over-month across our customer base).

Relevant usage metrics

Because we are a security tool, the metrics listed in chart 5 are not as relevant.

Do you agree to remove team-controlled wallets from all milestone metrics AND exclude team-controlled wallets from any incentives included in your plan: Yes

Did you utilize a grants consultant or other third party not named as a grantee to draft this proposal? If so, please disclose the details of that arrangement here, including conflicts of interest (Note: this does NOT disqualify an applicant): NO

SECTION 2b: PROTOCOL DETAILS

Is the protocol native to Arbitrum?: NO. Our testing framework is compatible with ethereum, arbitrum, polygon, avalanche, and optimism.

On what other networks is the protocol deployed?: ethereum, arbitrum, polygon, avalanche, and optimism

What date did you deploy on Arbitrum mainnet?: June 2023 is when we first made our open source testing framework available.

Do you have a native token?: No and no plans

Past Incentivization: What liquidity mining/incentive programs, if any, have you previously run? Please share results and dashboards, as applicable?

We have not previously run any incentive programs.

Current Incentivization: How are you currently incentivizing your protocol?

We are not currently incentivizing our project other than free trials since in the context of a self-funded security product it doesn’t really make sense without an external grant.

Have you received a grant from the DAO, Foundation, or any Arbitrum ecosystem related program?

NO

Protocol Performance: [Detail the past performance of the protocol and relevance, including any key metrics or achievements, dashboards, etc.]

N/A

Protocol Roadmap: [Describe relevant roadmap details for your protocol or relevant products to your grant application. Include tangible milestones over the next 12 months.]

N/A

Audit History & Security Vendors: [Provide historic audits and audit results. Do you have a bug bounty program? Please provide details around your security implementation including any advisors and vendors.]

We have no audits or bug bounties given that we are not a traditional protocol.

Security Incidents: [Has your protocol ever been exploited? If so, please describe what, when and how for ALL incidents as well as the remedies to solve and mitigate for future incidents]

None.

SECTION 3: GRANT INFORMATION

Requested Grant Size: 20,000 ARB

The grant would cover the following:

  • Identification of 10 ARB defi protocols to be monitored by GuardianUI
  • Identification of 10 most critical interactions between each protocol’s UI and its smart contracts.
  • Writing end-to-end tests for each of the 10 interactions for each protocols (e.g. 100 e2e tests total)
  • Maintaining each of the 100 tests and updating as necessary (e.g. creating a new test if a protocol makes a UI change and breaks one of their e2e tests as a result)
  • Continuously monitoring each interaction every 15 minutes for one year
  • Configuring workspaces for each protocol in GuardianUI app
  • Sending unlimited email and discord alerts to the protocol and/or arbitrum

Grant Matching: None

Grant Breakdown: [Please provide a high-level overview of the budget breakdown and planned use of funds]

  • Test writing: 5k ARB (~$100/test)
  • Monitoring and alerts: 15k ARB

Funding Address: 0xE375fCE09AEe94891E4E2D0158a72B11D8B0e94a

Funding Address Characteristics: [Enter details on the status of the address; the eligible address must be a 2/3, 3/5 or similar setup multisig with unique signers and private keys securely stored (or an equivalent custody setup that is clearly stated). The multisig must be able to accept and interact with ERC-721s in order to accept the funding stream.

The address is a Moloch v3 style contract requiring 20% quorum and 60% approval with a 2 day voting period. It is controlled by $GUI token holders. $GUI is a non-transferrable ERC-20 representing ownership in GuardianUI, LLC.

  • Lipman - 37%
  • Lienid - 32%
  • Jem - 13%
  • Ivelin - 18%

Treasury Address: 0xE375fCE09AEe94891E4E2D0158a72B11D8B0e94a

Contract Address: N/A

SECTION 4: GRANT OBJECTIVES, EXECUTION AND MILESTONES

Objectives: The objective of this grant is to monitor the most critical smart contract <> frontend interactions for the most popular Arbitrum defi protocols and detect and mitigate hacks/threats to keep users safe.

Execution Strategy:

  • GuardianUI (GUI) will identify 10 ARB defi protocols to be monitored
  • GUI will identify the 10 most critical interactions between each protocol’s UI and its smart contracts. ‘Critical’ is defined as the interactions with the most volume.
  • GUI will write the end-to-end tests for each of the 10 interactions for each protocol (100 e2e tests total)
  • GUI will be responsible for maintaining each of the 100 tests and updating as necessary (e.g. creating a new test if a protocol makes a UI change and breaks one of their e2e tests as a result)
  • GUI will use its monitoring platform to continuously monitor each interaction every 15 minutes for 365 days.
  • GUI will create separate workspaces in the GUI app for each protocol
  • GUI will send unlimited email and discord alerts to the protocol and/or arbitrum team

What mechanisms within the incentive design will you implement to incentivize “stickiness” whether it be users, liquidity or some other targeted metric?

We’ll use the grant to subsidize the cost of these 10 interactions for each of the 10 protocols. However, many of these protocols will have more than 10 interactions between their frontend and smart contracts. Our goal is to use this grant to convert them into at least converting into paying customers after the grant ends. Ideally, they also increase their coverage during the grant and/or after the grant.

Specify the KPIs that will be used to measure success in achieving the grant objectives and designate a source of truth for governance to use to verify accuracy.

KPI #1 = write 100 end-to-end tests.

  • Source of truth = GuardianUI github. We will provide folders with each of the tests.

KPI #2 = monitor 100 end-to-end tests every 15 minutes

  • Source of truth = Monitoring Google Sheet. We will create and update a google sheet every month to include the following for each protocol.
    • Number of times each protocol was monitored (how many times their end-to-end tests ran)
    • % of times each end-to-end test passed
    • % of times each end-to-end test failed (a test can fail if it timed out or if something malicious happened

KPI #3 = Alerts sent within 5 minutes for “severe vulnerability” threats

  • Source of truth = Alerts Google Sheet. We will create and update a google sheet with data for reach protocol if a severe vulnerability is detected and we trigger an alert.
  • Severe vulnerability is defined as a threat GUI detects that includes a contract mismatch.

Grant Timeline and Milestones:

Milestone 1 (1 week): Identify 10 defi protocols and 10 frontend <> smart contract interactions for each to monitor (these have the most volume and thus user interactions and user risk)…

Milestone 2 (2-4 weeks,): GuardianUI writes 10 e2e tests for each of the protocols identified in Milestone 1. No effort or integration is required from the protocols to onboard and start using our monitoring platform.

Milestone 3 (2 week): GuardianUI configures the tests created in Milestone 2 to the GUI continuous monitoring platform and sets up a dedicated workspace for each protocol. Alerts are set up (email/discord) and can be sent to the protocol teams and/or team members at Arbitrum.

Milestone 4 (12 months): GuardianUI monitors each of the 10 protocols’ live frontends by running each test from Milestone 2 every 15 minutes. We would include unlimited service hours to help with test maintenance as needed.

How will receiving a grant enable you to foster growth or innovation within the Arbitrum ecosystem?

Web3 apps still depend on web2 infrastructure - which leaves dapps exposed to countless vulnerabilities and is impossible to constantly review manually.

GuardianUI continuously monitors dapp for issues that cause their frontend to create the wrong smart contract interactions (among other things).

Risk vectors include:

  • DNS poisoning attacks
  • Cloudflare attacks
  • BGP hijacking
  • Javascript injections
  • Malicious package injections
  • Malicious minifiers
  • Package name squatting
  • Compromised linters
  • Etc.

There are several examples of the types of frontend attacks our monitoring system would detect. In each of the examples below, bad actors were able to compromise vulnerabilities with a project’s frontend and steal money from users.

  • BadgerDAO (Cloudflare attack) - $120M in user funds stolen
  • Sushiswap’s Miso (Supply chain attack) - $3M in user funds stolen
  • Klayswap (BGP) - $2M in user funds stolen
  • Curve Finance (DNS) - $600k in user funds stolen
  • Ribbon Finance (DNS) - $500k in user funds stolen
  • Frax (DNS) - $300k in user funds stolen
  • Balancer (DNS) - $238k in user funds stolen
  • Kyber Network (Google Tag Manager) - $265k in user funds stolen
  • Celer Protocol (DNS) - $250k in user funds stolen
  • Black Wallet (DNS) - $400k in user funds stolen
  • Pancake Swap (DNS) - prompted users to enter seed phrase
  • Cream Finance (DNS) - prompted users to enter seed phrase

While there’s emphasis placed on smart contract security (audits, monitoring), ensuring a dapps frontend is creating the correct smart contract interactions is often overlooked. As a result, users are at risk and devs are flying blind as to whether their UI is performing as intended for users.

Receiving this grant means GuardianUI can monitor the most critical defi interactions on Arbitrum and alert the protocol’s team so they can address threats immediately to keep users safe.

Do you accept the funding of your grant streamed linearly for the duration of your grant proposal, and that the multisig holds the power to halt your stream? YES

SECTION 5: Data and Reporting

OpenBlock Labs has developed a comprehensive data and reporting checklist for tracking essential metrics across participating protocols. Teams must adhere to the specifications outlined in the provided link here: Onboarding Checklist from OBL . Along with this list, please answer the following:

Is your team prepared to comply with OBL’s data requirements for the entire life of the program and three months following and then handoff to the Arbitrum DAO? Are there any special requests/considerations that should be considered?

We are a security tooling company, so the OBL data requirement may not be the most applicable. We would recommend reporting on the metrics provided in the KPI section above.

Does your team agree to provide bi-weekly program updates on the Arbitrum Forum thread that reference your OBL dashboard? [Please describe your strategy and capabilities for data/reporting]

Yes. We will provide the information mentioned above at the mandatory frequency.

First Offense: *In the event that a project does not provide a bi-weekly update, they will be reminded by an involved party (council, advisor, or program manager). Upon this reminder, the project is given 72 hours to complete the requirement or their funding will be halted.

Second Offense: Discussion with an involved party (advisor, pm, council member) that will lead to understanding if funds should keep flowing or not.

Third Offense: Funding is halted permanently

Does your team agree to provide a final closeout report not later than two weeks from the ending date of your program? This report should include summaries of work completed, final cost structure, whether any funds were returned, and any lessons the grantee feels came out of this grant. Where applicable, be sure to include final estimates of acquisition costs of any users, developers, or assets onboarded to Arbitrum chains. (NOTE: No future grants from this program can be given until a closeout report is provided.)

Yes.

Does your team acknowledge that failure to comply with any of the above requests can result in the halting of the program’s funding stream?: YES

1 Like

Hello @guardianui,

Thank you for your application! Your advisor will be Castle Capital @Atomist.

Please join the LTIPP discord and ping your advisor in the general chat so they can create a new channel and start communicating with you.

@cliffton.eth hi we are withdrawing after receiving feedback and will pursue other grant channels. Thank you.