The Python implementation of the Ethernity CLOUD SDK protocol

Ethernity Cloud SDK PY

This project provides a set of tools and scripts to work with the Ethernity Cloud SDK in a python environment.

Pre-requisites
Installation
Usage
- Scripts
Project Structure
Contributing
License

Pre-requisites

Linux:

build-essentials
Python 3.10+
docker
docker-compose

Windows:

Python 3.13
Docker Desktop

Installation

To install the package and its dependencies, run:

python -m venv venv

source venv/bin/activate # for MacOS and Linux
venv\Scripts\activate # for Windows

pip install ethernity-cloud-sdk-py

Usage

After installation, you can use the provided scripts to build, publish, and initialize your project.

Operating System compatibility

The sdk has been tested on the following operating systems:

Windows 10
linux (Ubuntu 20.04)

Blockchain compatibility

Bloxberg:
- Testnet - tested and working. CAS-attested: the securelock is provisioned by the ethernity-cas validator set exactly as on mainnet. ecld-publish registers the securelock session on-chain in the SessionRegistry (0xcb1F389b...), resolves a CAS from the ValidatorRegistry (0x0014aB10..., or ECLD_CAS_ADDR=host:port) for the compose and the certificate harvest, and links the session to the published image. ecld-build signs the securelock --production. Harvesting the certificate needs SGX; the remote extraction service does not reach this CAS. tests/e2e_testnet_cas.sh runs the whole path -- init, build, publish, one task, and the CAS validators' verdict on it. The other testnets (Amoy, IoTeX, Sepolia, LiteForge) have no CAS deployment and self-sign from MR_ENCLAVE as before.
- Mainnet - to be provided during the following updates
Polyhon:
- Amoy Testnet - to be provided during the following updates
- Mainnet - to be provided during the following updates

Scripts

Initialize: To initialize the project, run:
```
ecld-init
```
at this step, all the initial configurations will be set up and the project will be ready to be built, published and run.
Build: To build the project, run:
```
ecld-build
```
the project will be built and the docker repository output will be stored in the registry/ directory. This is the stage where the backend functions are added to the secure images.
Publish: To publish the project, run:
```
ecld-publish
```
Required after build, to build and integrate the secure certificates that will be used during executions and to register the project to the Ethernity Cloud Image Register. DEVELOPER_FEE in .config.json is your fee as the image's publisher, in percent of each task's base price (the node's price): the network adds it to what the dApp user pays and pays it to the image's reward address when the task is validated. Default 0; the registry accepts up to 15, and the fee is fixed once the image is registered. The reward address is the publishing wallet unless REWARD_ADDRESS names another one; the image's owner can change it later with the registry's changeImageRewardAddress.
Test (local, no chain): To run your backend locally with the enclave's own executor â€” no SGX, no gas, instant â€” run:
```
ecld-test 'hello("World")'
ecld-test --file payload.py
ecld-test --input data.json 'process(___etny_data_set___)'
```
This validates the call (function names, arguments, result wiring) before a single on-chain request is paid for. If your dApp uses ESR (Enclave State Registry), state is emulated locally and on by default: StateRegistry get/commit, ownership/ACL, and task_caller() all work in-process against an in-memory registry, and persist between runs in .ecld-esr-local.*.json. The task caller defaults to your developer address; override it with --caller. ecld-test serve starts a local API so the runner's LOCAL mode drives your real integration end to end. Exit code 0 on SUCCESS, 1 otherwise.
Run (on the network): To submit a payload to the network and print the decrypted result, run:
```
ecld-run 'hello("World")'
ecld-run --file payload.py
ecld-run --input data.json 'process(___etny_data_set___)'
ecld-run --json 'esr_increment()'
```
This is the network-side sibling of ecld-test: instead of executing locally it drives the runner end to end â€” encrypt â†’ IPFS â†’ on-chain request â†’ wait for a node â†’ download and decrypt the result. It costs gas and needs a funded key. Network and enclaves come from .config.json (BLOCKCHAIN_NETWORK, PROJECT_NAME, TRUSTED_ZONE_IMAGE), overridable with --network/--securelock/--trustedzone; the signing key is ECLD_PRIVATE_KEY (plaintext) or the encrypted ENC_PRIVATE_KEY unlocked with ECLD_KEY_PASSWORD (or an interactive prompt). Resources are tunable with --task-price/--cpu/--memory/--storage/--bandwidth/--duration/--validators. Exit code 0 on a SUCCESS task result, 1 otherwise. (python src/ethernity_task.py remains available as a scriptable template if you prefer driving the runner yourself.) --unsafe runs the network's -unsafe variant (see below).
The testnets and their unsafe networks: Bloxberg Testnet (BLOXBERG_TESTNET) and LitVM LiteForge (LITVM_LITEFORGE) run your securelock in an enclave attested through that chain's Ethernity CAS validator set, on nodes whose platform the CAS can attest (DCAP). Each has an unsafe network beside it, Bloxberg Testnet unsafe (no CAS) (BLOXBERG_TESTNET_UNSAFE) and LitVM LiteForge unsafe (no CAS) (LITVM_LITEFORGE_UNSAFE): the same chain and contracts, for hardware SGX platforms the CAS cannot attest (EPID-only, SGX1). No CAS: enclaves are debug-signed and self-signed from their measurement, so a result proves which image ran but not that an enclave ran it. You choose an unsafe network by name, and the runner runs an -unsafe trustedzone on nothing else, so a dApp that runs without a CAS always says so in the network it names. A dApp publishes one securelock per network from two project directories with the same project name: the unsafe one is registered as <project>-unsafe and runs on the etny-pynithy-testnet-unsafe (ecld-pynithy-litvm-testnet-unsafe) trustedzone. Mainnet has no unsafe network.
Inspect (read-only): To read enclave and on-chain diagnostics â€” network, trustedzone/securelock registration, and ESR state â€” without spending gas, run:
```
ecld-info
ecld-info esr state <key>
```

Usage

To use the SDK:

after installation, run ecld-init to initialize the project
in you workspace, you will find the scr/serverless directory, this contains a backend.py file. This file will be imported in the dApp images to provide the backend functions for calling from the frontend of your application, eg.:

def hello(msg='World'):
    return "Hello "+msg

From your py application, using the ethernity cloud runner library, you will be calling the function as seen in the below example, where we pass hello("World") to be executed on the backend which will run in the Blockchain:

import os
import sys
from dotenv import load_dotenv

load_dotenv()

from ethernity_cloud_runner_py.runner import EthernityCloudRunner  # type: ignore


def execute_task() -> None:
    ipfs_address = "https://ipfs.ethernity.cloud/api/v0"

    code = 'hello("Hello, Python World!")'

    runner = EthernityCloudRunner()
    runner.initialize_storage(ipfs_address)

    resources = {
        "taskPrice": 8,
        "cpu": 1,
        "memory": 1,
        "storage": 1,
        "bandwidth": 1,
        "duration": 1,
        "validators": 1,
    }
    # this will execute a new task using Python template and will run the code provided above
    # the code will run on the TESTNET network
    runner.run(
        os.getenv("PROJECT_NAME"),
        code,
        "0xd58f5C1834279ABD601df85b3E4b2323aDD4E75e",
        resources,
        os.getenv("TRUSTED_ZONE_IMAGE", ""),
    )


if __name__ == "__main__":
    execute_task()

you are able to define the functions needed to be used in the backend, while making sure that the function that is script is compilable and that it exports the function that will be called from the frontend, in the above example, the hello function.

Contributing

Contributions are welcome! Please open an issue or submit a pull request.

License

This project is licensed under the AGPL-3.0 License. See the LICENSE file for details.

Metadata

Release files for ethernity-cloud-sdk-py 0.9.3

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for ethernity-cloud-sdk-py 0.9.3
File	Size	Uploaded
ethernity_cloud_sdk_py-0.9.3.tar.gz	176.1 kB	Oct 4, 2026	Details

Built distribution (wheel)

Table of built distributions (wheels) for ethernity-cloud-sdk-py 0.9.3
File	Interpreter	ABI	Platform	Reset
ethernity_cloud_sdk_py-0.9.3-py3-none-any.whl 196.2 kB Oct 4, 2026	Python 3	none	any	Details

Total release size: 372.3 kB

Release files / ethernity_cloud_sdk_py-0.9.3.tar.gz

Download URL	ethernity_cloud_sdk_py-0.9.3.tar.gz
Size	176.1 kB
Tags	Source
SHA-256 checksum How to use checksums	`3c93bd2ded4f9e791cebbc9a10fdd6c9f006ba6bc2e3ff83b74075e730e86c28`
BLAKE2b-256 checksum How to use checksums	`664cedfc29d130791e9f545257c0847840763e59f0cc7b4a59ec924a4db92bb7`
Upload date	Oct 4, 2026
Uploaded using Trusted Publishing? What is trusted publishing?	No
Uploaded via	`twine/6.2.0 CPython/3.11.5`

Release files / ethernity_cloud_sdk_py-0.9.3-py3-none-any.whl

Download URL	ethernity_cloud_sdk_py-0.9.3-py3-none-any.whl
Size	196.2 kB
Tags	Python 3
SHA-256 checksum How to use checksums	`b42c798d2df00cbf31abc1bf7b6b63df4e0df39bd5e882e7f54b815ccb3d4e02`
BLAKE2b-256 checksum How to use checksums	`3f07134b7eab6f7700f122d12697061a5dec8175b77a30cf1180e35bd08ab982`
Upload date	Oct 4, 2026
Uploaded using Trusted Publishing? What is trusted publishing?	No
Uploaded via	`twine/6.2.0 CPython/3.11.5`