# Vectis - Neutron GrantDAO Prop

### 1. Are interchain accounts, interchain queries and the high pos security from ICS useful to your project?

Interchain queries, specifically that provided by Neutron ICQ relayers / infrastructure, is particularly interesting for Vectis. One of the unique features of Vectis is permissioned execution plugins, which means a controller of a Vectis account can permission another contract / account to call itself. Let’s say a user would like to track the update on a different chain, using the KV-queries feature, and do certain action depending on that value periodically, this can be done simply on Neutron with a fair economic model.

Important to note the difference of a plugin to automation directly via our friends at Cron.cat. We have worked together to create [cronkitty](https://github.com/nymlab/vectis-plugins/tree/main/contracts/cronkitty) which wraps around the Cron.cat contract. A plugin allows users to 1) have info.sender be their account / identity for the target applications and 2) keep the funds in the accounts until it needs to be sent. In the case of Neutron, the Vectis plugin will store the actual logic of the KV-queries callback whist only register for the ICQ module to call the plugin upon receiving updates.

Vectis is designed to be interchain by design. Interchain account abstraction are created via the _IBC-Tunnel_ directly for a Vectis Proxy allows to streamline user experience when using ICAs and ICQ. A core assumption when using this _IBC-TUNNEL_ is that it is permission-ed, i.e. connections are only allowed for approved connection-id and port-id. With this assumption, it is important the the chains allowed to be connected has high pos security.

### 2. What’s your cross-chain vision? Do you intend to leverage Neutron’s infrastructure to realize it?

One of the reasons we are interested in Neutron is the alignment with the Vectis multichain by design nature. As mentioned above, we want to deploy _IBC-TUNNEL_ to support all enhanced ICA usability features. One of the problems with IBC enabled smart contracts is that existing relayers might not register to relay such channel. Whilst we are exploring some self-relaying solutions with our frontend clients, we expect to be relaying majority of the packets. Therefore economically, the fee_refunder module makes sense to us for all types of IBC calls.

### 3. What types of protocols do you think would benefit most from integrating with your project? What types of protocols would your project benefit the most from integrating with?

Vectis enhances users experience with all dApps, with the browser extension (easily added to web-applications via cosmos-kit) and mobile application (soon). The Plugin system is also extremely powerful as it allows for extensibility to tailor user experience to different protocols through permission-ed transactions, automation and pre-transaction checks / workflow.

### 4. Does your project have a view on MEV and/or orderflow? Would your project benefit from mev/orderflow solutions? From automated CRON-like execution via EndBlockers?

The project at this moment does not have detailed strategy to help users with orderflow. On top of the automation mentioned above, Vectis is going to be progressively decentralised, i.e. Vectis aims to be governed by a DAO and the CRON module will be extremely helpful.

### 5. What are your funding needs? What will you use the funds for? Are you more interested in liquidity (fund operational expenses) or incentives alignements (get upside from a project you intend to build upon)? What is your team’s size and composition?

We are interested in both but in the short term we are looking mainly for funding for an security audit for the V1 of our contracts and browser extension which we expect to be in the range of 70-100k. We envisioned this to be paid as a crowdfund effort by all networks we would like to deploy on. This will be in the range of 25-40k USD per network. This will also help prioritise our deployment. Note: prior to this crowdfunding initiative, we have received grants from Juno and TGrade. We are currently deployed on the Juno Testnet and Malaga.

Vectis is a crucial part of Nymlab’s [solution](https://nymlab.notion.site/Introduction-to-Nymlab-f7fa9025874c475880a51a67ea8dc31c) to bring mainstream adoption to decentralised infrastructure and Self Sovereign Identity. We are a total team of 7 where 4 are focused on Vectis, of which 3 are developers working on the clients, smart contracts and infrastructure. The other project that Nymlab works on is [Gayadeed](https://www.gayadeed.it/en/), a legally binding digital signature platform. Both these projects will be combined to bring the user friendly, self-custodian and secure solution for mainstream users to adopt web3 technologies.

### 6. How do you evaluate success? What do you see as the main challenges to your success?
We evaluate a successful deployment onto a chain by the number of users and the IBC tx they can make with their Vectis accounts. In our view, this captures the Vectis value, enhanced user experience; this might be from the new plugins developed by the community or the frictionless ICA Vectis provides.