CIP Draft: Extending Plutus with SQL Transcomplier



The current state of the Plutus smart contract DSL limits the range of applications that can be built upon the Cardano blockchain. This is proven by contrasting the capabilities offered by Ethereum to its developers to those Cardano offers us. This CIP is solely concerned with the ability to query the Cardano blockchain from within a Plutus smart contract.

The Plutus smart contracts are run on the chain as Plutus-core bytecode; this should allow the contract to query the chain in the same way that is possible with a DB-sync server such as blockfrost. The current state of Plutus allows some limited querying of the chain but cannot enable the flexibility required for building something like a systematic Deadman switch.

This CIP outlines a method for enabling the full querying possibilities of SQL within Plutus and attempts to discuss the possible ramifications of doing so. This CIP will attempt to provide a method of deterministic fees and backwards compatibility with the blocks predating the CIP. It also attempts to provide a degree of security checking/assurance alongside the querying capabilities.


The success of any DLT solution is in part determined by the range of applications it can enable. The current state of Plutus limits the applications that can be built on Cardano – a prominent example of this is the systematic Deadman switch I am attempting to develop (This is proposed in a separate CIP as an update to the ouroboros protocol). The reason the switch cannot exist with the current state of Plutus is due to the requirement of requirement the transaction history of an address, on the Cardano blockchain, from within the Plutus smart contract.

Whilst this is an isolated example, it is trivial to deduce that the lack of native querying capabilities does limit the scope of the applications that can be built upon the chain drastically. It is the hope of this CIP that the equate extension of the Plutus capabilities would result in the rapid expansion of the Cardano ecosystem; as a result of developers pursuing their economic interests and porting the existing design patterns from other ecosystems into Cardano.


The central idea is to add the DB-Sync server functionality into the chains node operations, then to construct a SQL to Haskell transcomplier that will enable the user to interact with the node’s new capabilities directly from the Plutus Contract.

The transcomplier allows the user to query the node using the same type of code interface that is used for the PlutusTx module. The data received is given to the contract as a custom datatype specified by the user within the transcomplier.

The Haskel to Plutus-core complier then acts as a safeguarding mechanism that ensures the output of the Haskel code complies with the requirements of the chain and therefore ensures that the SQL query and result operate as intended.


In the current state of Plutus some limited ability to query the chain exist in the ledger.contracts.request module, however, this is far from sufficient and will lead to inefficient market pricing with API providers acting as middlemen. By moving the querying functionality directly into the node operations and allowing the use of SQL the markets become efficient and API providers are phased out over time. This results in cheaper contract execution for users of the chain, without increasing the risk to the chain.

By employing two compliers we gain the ability to do arbitrary querying in the Haskell-SQL complier and the ability to do arbitrary checking in the Haskell-Plutus-core complier. This would allow all queries in the contract but enable the only valid smart contracts (I.e. those passing valid SQL queries) to be converted into Plutus-core bytecode.

This dual compiler system was the design I settled on as it allows us to fix any issues that may arise in the Plutus-core complier and constructs an adversarial relationship between the compilers which is beneficial to the ecosystem.

This allows for maintaining things like deterministic fees in the face of variable querying. On a Twitter space, @LidoNation raised a valid and insightful critique of the notion of in contract SQL querying. This was if the same query is made on two different address onchian, then the returned data could be of two different lengths. When this happens the node operator must be paid for both queries proportionally to their computational demands and as such may jeopardise Cardano’s deterministic fees and move the chain to a gas-based system such as Ethereum, however, this is solved through the employment of the Plutus-core compiler. By having the compiler ensure the maximum return length of a query the deterministic fees can be maintained as each use of the contract is charged for the computational resources for the full query regardless of how much data exist at the address to be received. This would allow node operators to extract excess profits, which should incentivise developers to write more efficient contracts that only use the minimal possible query length for their needs. This then acts as an economic-based incentive for the optimization of on-chain code execution.

Backwards Compatibility

Due to the structure of the new changes proposed inside this CIP, backwards compatibility is guaranteed; and therefore, not a concerning factor. This is due to the CIP attempting to make Cardano’s development capabilities a superset of what they currently are and therefore there is no loss of generality.


This CIP is explicitly licensed to comply with the CIP rules. This means that any code generated as part of this CIP or attached to it is done so under the Apache-2.0 license, whilst the documentation is provided under the CC-BY-4.0 license (this is inclusive of the CIP document itself). It should be noted that I, the author of this document, do intend for any and all changes/ updates to this document to be done in a manner compliment with the above licensing – as I have described it.

1 Like