Integration Platform as a Protocol combines the best of both worlds

Grindery's Integration Platform as a Protocol (iPaaP) represents a significant evolution in the field of integration platforms. This innovative solution reimagines the traditional Integration Platform as a Service (IPaaS) model, integrating the advantages of both centralized and decentralized systems. By substituting the centralized execution environment with a network of nodes that are resistant to faults, attacks, and collusion, iPaaP provides a trustless infrastructure for the secure relay of arbitrary messages between blockchains.
This novel approach allows Grindery to address a broad spectrum of web3 and DeFi requirements while functioning within the parameters of a conventional iPaaS. Grindery's iPaaP equips developers with the tools to seamlessly implement a majority of on-chain, off-chain, and cross-chain native integrations via a single, user-friendly platform. This streamlined process facilitates the enhancement of user experiences, the reduction of adoption barriers, and the promotion of customer retention.
Furthermore, Grindery's iPaaP encourages a more democratic and inclusive web3 ecosystem by enabling developers to embed no-code integration apps. This feature empowers end users to become active contributors within the web3 ecosystem, providing them with the ability to construct their own integrations and automate processes. This user-centric approach not only fosters innovation but also enhances engagement, as users gain more control and flexibility over their integrations.
Grindery's iPaaP is not merely an incremental iPaaS improvements; it represents a paradigm shift in the integration landscape. It represents Grindery's commitment to democratizing access to web3 technologies, bridging the gap between disparate systems, and fostering a more transparent, efficient, and inclusive digital landscape.

Redefining Cross-Chain DeFi

As already discussed DeFi has been marred by high-profile hacks, largely due to the combination of immature technologies that introduce risks for specific protocols and decentralized applications (dApps). This amalgamation of protocols amplifies the risk, creating a precarious DeFi Lego or a DeFi house of cards, ready to collapse at the slightest disturbance.
A significant part of this vulnerability stems from the cross-chain bridges, which have been the weakest points in the whole ecosystem. These bridges, while facilitating data sharing, asset transfer, and contract access across blockchains, have also been the sites of major security breaches. To date, hackers have stolen approximately $2.53 billion from decentralized applications that enable cross-chain transactions, with bridge hacks accounting for more than 50% of the total value lost in DeFi.
To demonstrate the challenges of external integration, let's consider a notable example from 2022. During that year, DeFi protocols experienced losses of $403.2 million due to 41 distinct attacks targeting oracles. These incidents highlighted the vulnerabilities associated with relying on external integration.
Image without caption
The approach of creating a cross-chain patchwork of AMMs, bridges, cross-chain messaging systems, oracles, and automators has cast a dark shadow over DeFi. It has further created a terrible end-user experience, amplified the inherent low capital efficiency of AMMs and furthered liquidity fragmentation.
However, new cross-chain approaches for DeFi are emerging constantly. Some promising include the use of more optimistic, self-contained protocols, and the democratization of automated trading technologies.
Grindery is a staunch supporter of these innovative approaches and has built its iPaaP with these ideas in mind. iPaaP supports this trend and facilitates the creation of an entirely new generation of self-contained DeFi systems. These systems have the potential to surmount liquidity fragmentation, reduce systemic risks, and accelerate innovation within the vast array of chains, tokens, and protocols that comprise the long tail of the blockchain landscape. By doing so, Grindery is poised to make a significant contribution to a better, more secure, and more efficient DeFi ecosystem.

General Platform Architecture

Initially, Grindery Nexus will be introduced as a hosted service, following a similar approach to The Graph. However, it will gradually transition into a decentralized network comprising independent nodes.
Image without caption

A flexible language to compose workflows

Grindery Nexus is a comprehensive platform similar to Zapier, designed for Web3. It enables users and developers to create complex automations that connect smart contracts and off-chain systems. The available connectors determine the accessibility to Web2 APIs and Web3 chains. The system revolves around CDS, which describe interactions with specific systems and can be combined in various ways for flexible workflows. This language at the core of Grindery Nexus allows direct interaction with end users, benefiting Web3 dApp developers, end-users, connector developers, and blockchain APIs and nodes.

System Components

Grindery Nexus is composed of several independent components:
  • Orchestrator: The Orchestrator serves as the central component of the workflow engine. It manages a list of all workflows, signals triggers, dispatches workflow actions for execution and validation, and stores execution results in persistent storage (IPFS/Ceramic).
  • Beacon: Beacons are signaling services responsible for receiving events from Web2 apps and Web3 providers. They send WebSocket messages to the orchestrators to keep them informed.
  • Gateway: Gateways serve as interfaces for encapsulating Web2 services or Web3 blockchains into composable actions.

Workflow Lifecycle

The language and components described earlier enable the creation of complex workflows that follow this execution process:
  1. Users create a workflow, which is then saved in a database and ultimately stored in a persistent storage system like IPFS when decentralization comes into play.
  1. The Orchestrator works with the Beacon service to set up triggers. These triggers capture signals emitted by Web2/Web3 systems.
  1. Orchestrator nodes transmit the workflow details to the Gateway service to execute the actions defined by the end user during workflow creation. The results are sent back to the Orchestrator and saved to IPFS.
  1. These steps are repeated for each workflow action until the entire workflow is completed.
This workflow lifecycle ensures that users can create intricate workflows and seamlessly execute them by leveraging the collaborative efforts of the Orchestrator and Gateway services. The signals from Web2/Web3 systems are captured, actions are executed, and the results are securely stored, enabling the smooth progression of each step until the entire workflow is fulfilled.

An interoperable world of apps

In summary, Grindery Nexus allows users to define workflows consisting of triggers and actions within their dApps. The platform stands out for its ability to create interoperable dApps with user-friendly integration. Workflows can be comprehensive, supporting multiple steps, delays, transformations, and branching. They can incorporate on-chain, off-chain, and cross-chain integrations across various blockchains. Triggers can be based on time, blockchain events, API events, and more. Connectors, which can be reused, enable payment for services. Grindery Nexus addresses the interoperability problem by facilitating seamless information exchange between previously incompatible Web2 and Web3 systems. This expands possibilities, connects diverse applications, and makes them more accessible to new users.

Decentralization of the Execution Environment

To create a comprehensive and secure solution that meets the diverse needs of users, Grindery Nexus will progressively transition into a decentralized network of nodes. This decentralization strategy aims to adapt to user requirements by establishing a peer-to-peer off-chain network of nodes. While centralized APIs like Slack and Google may not need decentralization for their interactions, it becomes crucial for inter-blockchain communication.
Our approach recognizes the importance of a customized protocol that considers the centralization or decentralization of the involved systems. Including every aspect of our workflows would lead to increased costs and decreased execution speed, which may not be necessary in all situations. For instance, integrating Slack with Google does not require on-chain storage and can be suboptimal if enforced.
The decentralization path involves several components of the system. Initially, the orchestrator, previously backed by GCP, will transition into a network of independent orchestrators. This decentralization ensures resilience against breakdowns, malfunctions, censorship, or inefficiency by building a trustless engine that distributes orders and collects information from different parties.
Similarly, the Beacon service will consist of multiple entities to avoid failures or disruptions. While decentralization is not the primary concern for capturing on-/off-chain events, multiple Beacons provide flexibility and reliability, especially considering the hazards that can affect rpc blockchains.
The most critical aspect of decentralization lies in the network of Gateway nodes, which actively interact with the blockchain, validate information, and write to the blockchain. The information from Beacons is validated through an off-chain consensus process, preventing single points of failure and ensuring the validity of the workflow. Network nodes validate information based on user-defined verification criteria, accommodating different levels of verification, including purely Web2 interactions or a combination of Web2 and Web3. Ultimately, Grindery Nexus can facilitate cross-chain messaging, enabling seamless integration between different blockchains within the Web3 ecosystem.