---
# System prepended metadata

title: "\U0001F9D9‍♂️ saga-contracts \U0001F9D9‍♂️ insights \U0001F9D9‍♂️"

---

# 🧙‍♂️ saga-contracts 🧙‍♂️ insights 🧙‍♂️

## Scenario

While translating Solidity source code into FRAME, we should guide our implementation through coverage of EVM ABI. This strategy would help us make sure we are able to cover 100% of the functionality in our Solidity->FRAME translation.

EVM ABI metadata can be categorized in terms of:
- functions
- events
- errors

I wrote a crate called [`catabi`](https://github.com/paritytech/catabi) that prints a report with all the EVM ABI metadata from a given truffle project.

## Reflections

`catabi` deterministically generates a report on all the on-chain functionality that must be covered during the FRAME translation of `saga-contracts`. This report gives us insight on the funcionality landscape contained within the Solidity contracts.

While translating the Solidity contracts into FRAME, we should write the following pallets:
- `pallet-saga`: covers `SAGA20.sol`. Loosely couples with `pallet-balances` or `pallet-assets` (TBD).
- `pallet-marketplace`: covers `SAGAMarketplace.sol`. Loosely couples with `pallet-nft` or `pallet-uniques` (TBD).
- `pallet-parking-lot`: covers `SAGAParkingLot.sol`. Loosely couples with `pallet-nft` or `pallet-uniques` (TBD).

The `ERC20` and `ERC721` standards are covered via loose coupling with FRAME pallets.

This makes me lean once again towards the EVMless approach.  We should take advantage from the fact that we have [a (presumably stable) truffle test suite](https://github.com/MythicalGames/saga-contracts/tree/develop/test) available to guide a Test-Driven-Development approach (TDD).

The Truffle testing suite is a language that the MG team seems confortable in speaking, and sticking to this test coverage would bring clarity and transparency to our FRAME deliverables. We should do TDD with the goal of ensuring 100% coverage of ABI functionality on our FRAME pallet code and a smooth handover process.

On this TDD EVMless approach, we deploy a shell EVM Runner, where actual EVM execution is disabled. Each precompile implementation re-routes EVM ABI calls (incoming as Eth RPCs) through Substrate Runtime APIs that are made available via `pallet-saga`, `pallet-maketplace` and `pallet-parking-lot`.

Finally, I learned through some interactions during Consensus that this EVMless approach is getting momentum in our emerging  Hybrid Chain community (Interlay + Centrifuge + HydraDX). People are calling it "WrappedEVM" instead of "EVMless", but the idea is pretty much the same.

While we shouldn't rely on community efforts for our MG deliverables, we should still aim to leverage their momentum, especially if we take leadership in standardization via upstream Frontier contributions.

## saga-contracts ABIs

Here is the output of running `catabi` over a local clone of [`github.com/MythicalGames/saga-contracts`](https://github.com/MythicalGames/saga-contracts) loaded into `$SAGA_PATH`:

### functions

```
$ catabi --path $SAGA_PATH --mode abi_list_functions

```

### events
```
$ catabi --path $SAGA_PATH --mode abi_list_events

```

### errors
```
$ catabi --path $SAGA_PATH --mode abi_list_errors
# empty
```

There are no errors on the `saga-contracts` ABIs.