Smart Contract Automation Protocol (SCAP) is a unique auto-executing smart contract protocol which empower faster, more innovative and groundbreaking applications. SCAP enables developers to trigger smart contract functionalities in an automated way. By building on the currently available open source architecture, Vingt.io is creating its own off-chain node operator network and providing on-chain transaction execution service.
Smart contracts are not self-executing, meaning their code will not run and make state changes on a blockchain until triggered by an on-chain transaction. There are many instances in which smart contracts must perform on-chain functions to maintain the health and utility of the protocol, with no direct user interactions to trigger them.
SCAP enables conditional execution of smart contracts functions through a decentralized automation platform that uses Vingt.io external network of node operators.
SCAP Automation enable you to execute smart contract functions based on conditions that you specify without having to create and maintain your own centralized stack. SCAP is highly reliable and decentralized and enables developers to deploy applications faster..
There are three main actors in the smart contract automation protocol:
•Upkeeps: These are the jobs or tasks that you execute on-chain. For example, you can call a smart contract function if a specific set of conditions are met.
•Automation registry: The contract that you use to register and manage upkeeps.
•tomation Nodes: Nodes in the Vingt.io Automation Network that service registered and funded upkeeps in the Automation registry.
The following diagram describes the architecture of the Vingt.io Automation Network. The Automation Registry governs the actors on the network and compensates Automation Nodes for performing successful upkeeps. Developers can register their Upkeeps, and Node Operators can register as Automation Nodes.
Automation Nodes follow a turn-taking algorithm to service upkeeps. A turn is a number of blocks and in the case of BNB-chain it would be 20. During a turn Upkeeps on the registry are randomly split, ordered into buckets, and assigned to an Automation Node to service them. Even if an Automation Node goes down, the network has built-in redundancy and your Upkeep will be performed by the next Automation Node in line.
During every block, the Automation Node reviews all of the upkeeps in its bucket to determine which upkeeps are eligible. This check is done off-chain. The Automation Node checks both the 'checkUpkeep' and 'performUpkeep' conditions independently using simulation. If both are true (eligible), and the upkeep is funded, the Automation Node proceeds to execute the transaction on-chain.
While only one Automation Node monitors an upkeep at any point during a turn, an upkeep can have multiple on-chain transaction executions per turn. This is accomplished with a buddy-system. After a transaction is confirmed, the next Automation Node in the line monitors the upkeep. After a new transaction is confirmed, the previous Automation Node steps in again to monitor the upkeep until the end of the turn or until another transaction confirmation is complete. This creates a system that is secure and highly available. If a node becomes faulty and executes a transaction that is not eligible, the next node does not execute a transaction, which breaks the process.
This creates a hyper-reliable automation service that can execute and confirm transactions even during intense gas spikes.
Externally Owned Accounts (EOAs) are incentivized to trigger the execution of smart contracts based on predefined conditions. Conditions are defined in jobs and submitted by a development team, DAO, or protocol users to a decentralized network, along with rewards subject to performance. Conditions for smart contract automation are generally based on time (e.g. trigger x function every day at 5:00 pm EST) or events (e.g. trigger y function only when the asset’s price crosses a certain threshold).
Decentralized automation nodes check conditions and make transactions once those predefined conditions have been satisfied. This process often involves the nodes using off-chain computation to execute the same smart contract function that it may eventually call on-chain. Once the function returns true, then the node calls that function on-chain by issuing an on-chain transaction. When the function is called, the conditions can be verified on-chain by the protocol’s smart contract before it undergoes a state change, helping ensure that the node is correct. The end result is smart contracts that only run on blockchains when needed and according to clearly defined conditions.
Instead of relying on centralized setups or taking a risk on competitive public bounties, projects can outsource their smart contract execution to SCAP, a decentralized smart contract automation tool.
Some of the benefits of SCAP services include:
SCAP offers a simple framework where users can clearly outline jobs and rewards that a decentralized network of nodes commits to, removing competition and creating predictable financial incentives.
SCAP has several gas-optimizing features that lower the costs of dApp automation, including a rotating node selection process to prevent PGA wars and stabilize costs for users.
SCAP leverages a decentralized and transparent pool of nodes for strong guarantees around secure and timely smart contract execution, saving teams time and mitigating manual intervention or centralized server risks.
SCAP can perform advanced off-chain computation and generate call data that’s verifiable by smart contracts, allowing developers to build advanced functionality that was not possible before and without any additional trust assumptions.
SCAP can be integrated in a matter of hours to trigger smart contracts, with developers provided with simple documentation and step-by-step setup guides.
A few of the many smart contract use cases enabled by SCAP are listed below. There are many other use cases still yet to be created that are waiting on innovative and creative developers to pioneer.
• Automated Yield Harvesting and Debt Repayment
• Decentralized Rebasing of Elastic Supply Tokens
• Optimal Rebalancing of Liquidity Provisions
• Minting of Limited-Edition NFTs When Specific Events Happen
• Time-Based Smart Contract Automation
• Starting, Stopping, or Settling Games or Rounds
• Triggering DEX Limit Orders
• Automated On-Chain Payments
• Triggering Automated Rewards Distribution
• Timely Liquidations on Decentralized Money Markets
• Automated Dynamic NFT Updates
• Automated DAO Governance Processes