TLDR: The Atlas framework significantly abstracts away the complexity that comes with building Cardano transactions and interacting with Plutus smart contracts. Different data providers can be configured to power the Atlas framework. Learn more about Atlas.
Atlas is a Haskell Plutus application backend for writing off-chain code for Cardano smart contracts, designed by Genius Yield, in collaboration with MLabs, Well-Typed, and Plank. Atlas streamlines the process of building transactions and executing smart contracts. The Atlas framework provides the following benefits:
Use an intuitive API to abstract away the complexity around building transactions, balancing UTxOs, and interfacing with Plutus smart contracts.
Avoid code duplication between on-chain and off-chain code, interoperate with advanced functionalities offered by IOG's Cardano/Plutus libraries, and easily convert between Atlas and Cardano/Plutus types.
Query ledger state information from Maestro, a local node, or Cardano DB Sync. You can also build and contribute your own data provider.
Use Atlas' test harness to write realistic unit tests that correspond to on-chain behavior, and execute integration tests against the Cardano node in a private network.
Benefit from Cardano's latest innovations such as Reference Inputs, Inline Datums and Reference Scripts.
The Atlas framework streamlines the process of writing off-chain code that can interact with on-chain code such as Plutus smart contracts. Therefore, we need a smart contract in order to illustrate the framework's most important features. For example, you could use the Sports Betting contract from the Atlas documentation.
Atlas provides convenient abstractions around building transactions and balancing UTxOs for a smart contract. As a result, you only need to define the desired transaction requirements and the framework will handle the rest.
For instance, let’s take the Sports Betting contract from above as an example. You may want to place a bet (create a UTxO at the script address) or take the bet pot (consume a UTxO at the script address). In both cases, the framework will:
These transaction requirements are captured by the GYTxSkeleton data type which is composed of the following fields:
Fields |
Description |
Inputs |
List of transaction input UTxO references |
Outputs |
List of transaction output UTxO references |
Reference Inputs |
Set of transaction reference inputs |
Mints |
Tokens which the transaction must exactly mint |
Signatories |
Set of Public Key Hash of signatories |
Valid before |
Slot before which the transaction is valid |
Valid after |
Slot after which the transaction is valid |
When constructing a transaction, the desired requirements can be combined into a single skeleton by leveraging the utility functions defined in Class.hs.
For example, we can specify that the transaction has the following:
For more details, checkout the Atlas documentation.
We now only have one piece missing, when building a transaction Atlas needs access to live blockchain data. For this reason, Atlas must be configured with a data provider in order to interface with Cardano. Users have the choice to host their own node locally or use a managed service such as Maestro.
Learn more about what data providers are available on Atlas in the next article in the series.
---
Author: Marvin Bertin, CSO at Genius Yield and CEO at Maestro