One of the challenges with adopting smart contracts is that they are computationally expensive. This is due to the complex way most smart contracts are set up to compute multiple variables to perform an action. For example, a smart contract for a loan transaction must compute the time of the loan, the amount lent out and repaid, the current price of the collateral, and the liquidation price. All of the variables impact the amount of energy, time, and space that each contract takes up on the blockchain.  

Accumulate has developed Delegated Transactions, which are aimed at enabling tokens to be transferred by third parties on behalf of a person or entity. While Delegated Transactions can be an alternative to some smart contract use cases, they don’t replace all smart contract use cases. Read on to learn about use cases with Accumulate’s Delegated Transactions.

Delegated Transactions function in such a way as to limit all transactions to a static amount of computation, ensuring that they take up a known amount of time, space, and energy on the blockchain. This allows them to be more computationally efficient and less costly than traditional smart contracts.  

Delegated Transactions are transactions that can be initiated by an external authority based on 3rd party verification. For example, companies managing funds on-chain can use delegated transactions to grant a manager within the company or an entity outside of the company the authority to spend a portion of the funds based on certain criteria (e.g hitting certain project milestones in order to continue tapping into the company budget).  

Similar to how a lending smart contract must verify information from an external source like a price oracle to determine whether to liquidate collateral, Delegated Transactions can be set up to receive data inputs from wallets, price feeds, or other custom on-chain or off-chain data sources. 

Delegated Transactions are part of a broad menu of customizable transaction types that are enabled using the Accumulate networks authorization schemes. Other types of transactions include single signature transactions, multi-sig transactions (transactions that require 2 or more digital signatures), and managed transactions (transactions that include self-imposed limits on spending or frequency).

On Accumulate, Delegated Transactions will typically be set up to include multi-sig and managed transaction features. This is especially true if large entities like a University endowment, a hedge fund, or a DAO want to manage their treasury.   

Delegated transactions give other members or external parties authority to spend funds, while managed transactions can be applied to impose limits on the number of funds that can be spent and how often. Multisig transactions require multiple users to provide a digital signature before any funds can be spent. 

All of these processes are based on Accumulate’s key management system, which allows entities to generate multiple wallet keys that are linked to a decentralized digital identifier or Accumulate Digital Identifier (ADI).

Entities organize their various wallet keys inside key books that contain multiple key pages.  

Key Books can allow ADIs to update their security settings to include multi-sig transactions (transactions that require 2 or more digital signatures), delegated transactions (transactions that can be initiated by an external authority based on 3rd party verification), managed transactions (transactions that include self-imposed limits on spending or frequency) or other conditions without having to touch high-priority keys, thereby maintaining the highest possible security standards and minimizing vulnerabilities. 

Delegated Transactions increase the speed at which large organizations can execute operations while relying on a decentralized structure. For example, an electronics hardware manufacturer that works with suppliers located in various jurisdictions can coordinate projects by tying every task to a set of milestones and every milestone to a delegated transaction that funds the project. 

Similar to how smart contract loans use data points like time, price, and the repayment of a certain quantity of assets as inputs to inform the contract, a delegated transaction could have its own set of data points and sequence of events that must occur in order for certain transactions to be authorized:

• Participants in Delegated Transaction:
  • Entity (Key signer of a delegated transaction)
  • Subsidiary (custodian of funds)
  • Project Contractor (recipient of funds) 
• Milestone 1 (Timeline: 6 weeks)
  • Deliverable A (Timeline: 2 weeks)
    • Pass Criteria: 
      • Contractor.ADI must complete delivery of A by Y date 
      • Deliverable is ‘confirmed’ if a transaction is signed by Entity   
      • Following Action: Subsidiary sends 40% of available funds to Contractor.ADI
    • Fail Criteria:
      • Contractor.ADI did not complete delivery of A, or Delivered A by T >Y date
      • Following Action: Subsidiary retains funds  
  • Deliverable B (4 weeks)
    • Pass Criteria: 
      • Contractor.ADI must complete delivery B, C & F by Y date 
      • Deliverable is ‘confirmed’ if the transaction is signed by Entity   
      • Following Action: Subsidiary sends 60% of available funds to Contractor.ADI
    • Fail Criteria:
      • Contractor.ADI did not complete delivery of either B, C, or F, or Delivered B, C, or F by T >Y date
      • Following Action: Subsidiary retains funds  

Each section of this table can effectively be programmed into one or multiple delegated transactions, with each variable taking up a fixed amount of computation within the broader sequence, enabling tokens to be transferred by third parties on behalf of a person or entity.  

Ultimately, delegated transactions to provide a cheaper and more efficient alternative to smart contracts for permissioned entities to process transactions between each other in a trustless and transparent manner.