# Overview [Palliora](https://palliora.org/) is a public blockchain that empowers its user to selectively share their data for trusted, confidential and verifiable computation, knowing that only the intended recipients will have access. Moreover, it guarantees fairness to all participants in an AI ecosystem: data providers, model providers, training providers, model user; an essential feature for an unplugged growth of AI technology. Among the actors of Palliora we have DA nodes, which take care of Data Availability, Guardians, which take care of a decentralized access-control system, Calculators, which perform outsourced computations(whth varying confidentiality levels), and Verifiers, which check the quality and consistency of input and output data. Palliora's design permits free negotiations among all user and all actors, while enforcing correct execution and fair distribution of rewards.
Manas is the live testnet of Palliora. Explore the testnet here - [https://manas.palliora.org](https://manas.palliora.org/) # Become a Guardian ### **Manas Network** Manas network supports open ecosystem of Guardians to join & leave at their will without negatively impacting the network. Being a Guardian on the Manas means contributing to building a DA with customized privacy & security. A Guardian can also share their resources for performing compute or verification on the network helping grow the data, compute & AI ecosystem. The participants only need to follow the rules laid out in the runtime so that they do not face any negative economic impact. ### System Requirements {% tabs %} {% tab title="Standard Guardian" %} | Resource | Minimum | Recommended | | ------------ | -------------- | ---------------------------------------- | | RAM | 8 GB | 16 GB | | Processor | 8 cores | 16 cores | | Disk | 200 GB | 1 TiB NVME | | Bandwidth | 1 Gbps | 5 Gbps | | GPU | - | - | | Extras | Virtualization | Virtualization, CPU TEE (Future Updates) | | {% endtab %} | | | {% tab title="Compute" %} | Resource | Minimum | Recommended | | ------------ | --------------- | ---------------------------------------------- | | RAM | 16 GB | 32 GB | | Processor | 8 cores | 16 cores | | Disk | 200 GiB NVME | 2 TiB NVME | | Bandwidth | 5 Gbps | 10 Gbps | | GPU | Nvidia Tesla T4 | Nvidia Tesla T4 and above | | Extras | Virtualization | Virtualization, CPU & GPU TEE (Future Updates) | | {% endtab %} | | | {% tab title="Verifier" %} *Coming in Future Updates* {% endtab %} {% endtabs %} ### Supported Platforms The Palliora node client supports containerized environment for running a node. The container images are currently available for the following platforms - * Linux/amd64 - Ubuntu 24.04 * Mac/arm64 ### Pre-Requisites * Docker * Nvidia Drivers (only for Nvidia GPUs on Linux) * Ollama (along with pre-installed models) * NodeJs, npm * Palliora-cli #### **Install dependencies** **Docker**\ Install docker on MacOS - \ Install docker on Linux - **Nvidia Drivers** ``` sudo apt install nvidia-headless-535-server nvidia-utils-535-server -y ``` **Ollama**\ Download and install ollama from here - **NodeJs**\ Install nodejs environment - *NOTE: Prefer install using nvm* ``` # Download and install nvm: curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.3/install.sh | bash # in lieu of restarting the shell \. "$HOME/.nvm/nvm.sh" # Download and install Node.js: nvm install 22 # Verify the Node.js version: node -v # Should print "v22.21.1". # Verify npm version: npm -v # Should print "10.9.4". ``` **Palliora-cli** ``` npm i -g @palliora.org/cli ``` ### Setup a Guardian Node The pre-requisites for an active Guardian participant requires them to do the following: 1. [Node client docker setup](#docker-compose-config) 2. [Ollama setup](#ollama-setup) 3. [Stake tokens on Manas](#bond-tokens) 4. [Provide node preferences](#guard) to activate the Guardian services {% file src="/files/8I72Ci82QN4p016J6L6G" %} {% file src="/files/HFcwlWGGP8NETiQXHcrO" %} #### **Docker-compose config** 1. Save the attached `palliora-manas.json`. 2. Save the attached `docker-compose.yml` . 3. Open a terminal where you have saved the downloaded files and run the following commands #### Configure Result Submission To configure the environment variable in Docker Compose, add it to a `.env` file in the same directory as your `docker-compose.yml` file: ``` PRIVATE_KEY= ``` **What is this account?**\ *This is an external account that should have PALI tokens to submit results of compute on the Palliora DA on-chain.* **How to get the SEED?**\ *Use the palliora-cli (`palliora-cli account-show --secret` to export/view the seeds of an account. See following sample output for getting the privateKey.* ``` $ palliora-cli account-show --secret Starting Palliora CLI Account Info: name: default address: 5GrwvaEF5zXb26Fz9rcQpDWS57CtERHpNehXCPcNoHGKutQY publicKey: 0xd43593c715fdd31c61141abd04a99fd6822c8558854ccde39a5684e7a56da27d type: sr25519 privateKey: 0x98319d4ff8a9508c4bb0cf0b5a78d760a0b2082c02775e6e82370816fedfff48925a225d97aa00682d6a59b95b18780c10d7032336e88f3442b42361f4a66011d43593c715fdd31c61141abd04a99fd6822c8558854ccde39a5684e7a56da27d ``` #### **Command** 1. Store the docker login auth token in the Environment by executing ``` export AUTH_TOKEN= ``` 2. Perform Docker login by executing ``` echo $AUTH_TOKEN | docker login --username AWS --password-stdin 434856701645.dkr.ecr.us-east-1.amazonaws.com ``` 3. Run the docker compose with following command: ``` docker compose pull && docker compose up --force-recreate -d ``` #### Ollama setup 1. Pull relevant model (e.g. \`llama3.1:latest\`) ``` ollama pull llama3.1:latest ``` 2. Start ollama server ``` ollama serve ``` #### Create an account To create a fresh account, run the palliora-cli with following command ``` palliora-cli account-create ``` #### Get test tokens Use the palliora-cli to receive test tokens on your new account. The following command funds your account with 1000 PALI tokens. ``` palliora-cli fund --amount 1005000 ``` #### Bond Tokens The next step is bonding PALI. A bonded account, holds your staked tokens (PALI) that back your guardian node. Bonding your PALI means locking it for a period, during which it cannot be transferred or spent but is used to secure your guardian's role in the network. The Minimum Bond Requirement is 1,000 PALI tokens. \ The following sections will guide you through bonding PALI for your guardian. #### Bonding PALI Using the palliora-cli use the `stake-new` command to bond your tokens as follows: ``` # fresh stake of minimum guardian stake with default reward destination palliora-cli stake-new --amount=1000000 ``` (*Optional*) Node operators can increase/decrease their existing stake using this command. ``` palliora-cli stake-add --amount=10 palliora-cli stake-reduce --amount=10 ``` The `amount` flag signifies how much of PALI tokens will be staked. This value must be equal or greater than the minimum guardian stake. The parameters accepts floating values upto 18 decimal places. The reward-destination gives the node operators an option to provide an alternate address to receive the stake rewards into. By default the account that is setup will receive the staking rewards but any valid address can be set as the reward destination using this option. #### Guard ***NOTE: Wait for the chain to sync before performing the following action.*** Using the palliora-cli use the `join-guardian` command to participate as guardian (*NOTE: **Joining as a standard guardian with trusted compute services***): ``` PALLIORA_WS=ws://127.0.0.1:9944 palliora-cli join-guardian --standard --compute="trusted" ``` # Run Palliora Node on a TEE This document walks Palliora node operators through running their infrastructure inside a hardware‑backed Trusted Execution Environment (TEE) using Dstack. The goal is to move from “ordinary Docker deployment” to a setup where every Palliora node runs inside an Intel TDX Confidential VM, with **hardware‑enforced isolation and remotely verifiable attestations**. Instead of trusting a generic cloud VM or Kubernetes cluster, operators will be able to show cryptographic proof that their node—and its configuration—ran in a specific, measured environment. Dstack acts as the bridge between Palliora’s existing Docker‑based node stack and low‑level TEE features. It lets us: * Take the standard Palliora `docker-compose.yml`. * Run it inside a dedicated, attested CVM per deployment. * Expose the same networking interfaces node operators expect. * Generate TDX quotes directly from inside the node container for downstream verification. This guide focuses on three practical outcomes: 1. **Provisioning a TEE‑ready host**\ Renting an Intel TDX‑capable machine from a cloud provider and preparing it to run confidential workloads. 2. **Running Palliora under Dstack**\ Installing Dstack’s components on the host, adapting Palliora’s `docker-compose.yml` for this environment, and deploying via Dstack’s UI. 3. **Proving and observing execution**\ Pulling TDX attestation reports and node logs from inside the TEE, so operators and verifiers can build higher‑level trust tools (e.g., a Palliora trust dashboard) on top. By the end of this document, Palliora community members should be able to reproducibly launch their own TEE‑protected nodes, without relying on a specific managed cloud, while keeping the operational model as close as possible to “just run Docker Compose.” *** ### 1. What Dstack Is Dstack is an SDK and orchestration layer that runs your existing Docker apps inside **Confidential VMs (CVMs)** backed by hardware TEEs (Intel TDX, etc.). ### Core Components * **dstack‑vmm**\ Runs on the bare‑metal TDX host. Manages CVMs: creates, boots and stops them. Provides CVM orchestration and monitoring service right out of the box. * **dstack‑gateway**\ Reverse proxy on the host. Terminates TLS and routes `https://-.` to services inside CVMs. * **dstack‑kms**\ Key Management Service. Generates and seals keys; only unseals them inside attested CVMs, secluded from the host (prevents host/operator access). **Serves key derivation requests** from `dstack-guest-agent` inside running CVMs via RPC. * **dstack‑guest‑agent**\ Runs inside each CVM. Handles key derivation, remote attestation, and exposes `/var/run/dstack.sock` so containers can request TDX quotes. * **meta‑dstack (Yocto layer)**\ Builds the minimal, hardened Linux image that runs inside CVMs and hosts Docker + guest‑agent. This uses the Yokto Linux guest image and provides dedicated memory/resources (secluded from the host) for confidentiality guarantees. ### Key Features * **Drop‑in for Docker**: Use your existing `docker-compose.yml`, no app code changes. * **Per‑app CVM isolation**: Each compose app runs in its own TDX CVM with encrypted memory. * **Remote attestation**: Containers can request TDX quotes via `dstack.sock` and prove they ran in the expected environment. * **Network ingress out of the box**: Gateway gives you HTTPS endpoints for node RPCs, APIs, etc., without manual nginx. > See “[Dstack – Getting Started](https://docs.phala.com/dstack/getting-started)” for architecture and concepts.​ *** ### 2. Renting an Intel TDX Machine To self‑host Dstack, you need a VM that supports Intel TDX Confidential VMs (C3‑class or similar) on your cloud provider. ### Typical Requirements * **Machine family**: Intel Sapphire Rapids with TDX enabled (for example, C3 `c3-standard-*` on some providers). * **vCPU/RAM**: At least 8 vCPU, 32–64 GB RAM for comfortable Dstack builds and CVMs. * **Disk**: 200+ GB SSD (Balanced PD/NVMe). * **OS**: Recent Linux with TDX‑capable kernel (e.g., Ubuntu 24.04 LTS with `TDX_CAPABLE` flag). * **Security:** Enable Confidential VM service > Intel TDX under security menu. ### Checklist When Creating the Host VM * Enable **Confidential VM / Intel TDX** in the provider’s UI. * Use a **TDX‑capable** OS image (check provider docs for “TDX\_CAPABLE” images). * Ensure firewall/security groups allow: * SSH: 22 (admin access) * Dstack‑vmm UI: 9080 * Dstack‑gateway HTTP/HTTPS: 80, 443, and optionally 9070 for the gateway dashboard.\[[docs.phala](https://docs.phala.com/dstack/getting-started)]​ Example firewall rule (conceptually): ```bash bash# conceptual: open needed ports to your IP or trusted ranges allow tcp:22,tcp:80,tcp:443,tcp:9070,tcp:9080 to host_ip ``` *** ### 3. Installing and running Dstack (vmm, gateway, kms) On your Intel TDX host VM, follow the[ upstream Dstack- Get started guide](https://docs.phala.com/dstack/getting-started#install-dependencies). ### 3.1 Summary of Dstack setup ```bash bash# Install build deps (example for Ubuntu) sudo apt update sudo apt install -y build-essential chrpath diffstat lz4 wireguard-tools xorriso # Install Rust curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh # Clone meta-dstack git clone https://github.com/Dstack-TEE/meta-dstack.git --recursive cd meta-dstack mkdir build && cd build # Generate config template ../build.sh hostcfg # Edit build-config.sh to match your environment (domain, ports, etc.) vim ./build-config.sh # Re-run host build ../build.sh hostcfg # You should now see artifacts: ls # certs images dstack-kms kms.toml run dstack-vmm vmm.toml dstack-gateway gateway.toml ``` You can either **download a prebuilt CVM guest image**: ```bash ../build.sh dl 0.5.2 ``` or **build it from source**: ```bash ../build.sh guest ``` ### 3.2 Run Core Services Run three terminals on the host: ```bash ./dstack-kms -c kms.toml ``` ```bash sudo ./dstack-gateway -c gateway.toml ``` ```bash ./dstack-vmm -c vmm.toml ``` * `dstack-vmm` UI: `http://:9080` * `dstack-gateway` dashboard: `https://:9070` (if configured) *** ### 4. Preparing Palliora’s docker-compose for Dstack Palliora’s existing compose uses host‑mounted genesis config and private ECR images. For TDX+Dstack we’ll make it **TEE‑friendly and easy for operators**. ### 4.a Genesis Config from Remote Instead of mounting a local path like: ``` volumes: - "./palliora-manas.json:/root/palliora-manas.json" ``` Publish the Palliora genesis config in a **public Google Drive/GitHub repo/Gist**, then adjust compose to fetch it on container start. Example pattern: ``` services: # New service to fetch the config file fetch-config: image: alpine:3.19 volumes: - palliora-config-data:/root working_dir: /root command: wget -O /root/palliora-manas.json "https://drive.google.com/uc?export=download&id=1VX0Ei12kvGU2nnjXlzjMfAd53tVAaF42" restart: "no" palliora-node: image: public-registry/palliora-node:latest entrypoint: ["/bin/sh", "-c"] volumes: - palliora-config-data:/root/ volumes: palliora-config-data: ``` I've hosted one on Google Drive at ### 4.b Switch to Public Images To avoid ECR auth complexity for community operators we've pushed Palliora images to a **public registry** on public AWS ECR and reference them directly in compose: ``` services: palliora-node: image: public.ecr.aws/palliora/palliora/node:latest ``` This removes the need for AWS credentials or ECR login inside TEEs. ### 4.c Mount `/var/run/dstack.sock` for Attestation To allow the node container to request TDX quotes, mount the Dstack socket as documented. Example Palliora service snippet: ``` palliora-node: image: public.ecr.aws/palliora/palliora/node:latest working_dir: / volumes: - /var/run/dstack.sock:/var/run/dstack.sock - palliora-config-data:/root/ ``` The `/var/run/dstack.sock` path is provided by the dstack guest‑agent inside the CVM; the mount just passes it into your container. Here's the compiled changes to Palliora's docker-compose.yml {% file src="/files/NZqKAxISIo34usmGP8cX" %} *** ### 5. Deploying Palliora via Dstack UI For the community doc, describe deployment entirely via the generic Dstack‑vmm UI. ### 5.1 Open Dstack-vmm Navigate to: ``` http://:9080 ``` You’ll see the **dstack‑vmm web interface**. ### 5.2 Upload and Deploy docker-compose * Click **“Deploy App”** (or equivalent button). * Paste or upload the Palliora `docker-compose.yml` prepared in section 4. * (Optional) Configure **Encrypted Environment Variables** if Palliora needs secrets, incase of using private ECR images — they are encrypted client‑side and only decrypted inside the CVM. * Click **Deploy**. Dstack will: 1. Create a new TDX CVM. 2. Boot the Yocto guest image with guest‑agent. 3. Pull the public Palliora node image. 4. Start the Palliora containers inside the CVM. ### 5.3 Checking Status In the vmm UI: * **Logs**: For CVM boot logs and container startup; use the **\[Logs]** button. * **Dashboard**: See container status, resource usage, and guest‑agent health. {% hint style="info" %} On shutdown, TEE setup will wipe away the ollama and model installations to enable a clean slate boot expected from the TEE. In order to persist it, we need to move the ollama dir into the persistent storage of the TEE. {% endhint %} 5.4 Palliora Setup Once you have the Palliora client running, next up is setting up:\ 1\. Ollama 2. Installing models 3. Creating a Palliora account 4. Staking 5. Finally joining as a guardian For the above steps, you can follow our [Becoming a Guardian](/participate/become-a-guardian) guide. *** ### 6. Getting TDX Attestations and Logs from the TEE Once the Palliora node is running inside the TDX CVM, operators can generate attestation reports and fetch logs programmatically or use the Trust-Centre to verify attestations automatically. ### 6.1 Trust Centre A comprehensive open-source platform for managing and verifying Trusted Execution Environment (TEE) attestations in the dstack ecosystem. The Trust Center provides end-to-end verification of hardware attestation, OS integrity, source code authenticity, and domain ownership for TEE-protected applications. Repo: \ The following is verified automatically by the Trust Centre client: * **Verify Hardware Authenticity**: Cryptographically prove your app runs on genuine Intel TDX and Nvidia CC hardware * **Confirm Code Integrity**: Verify the exact Docker compose configuration deployed matches your source code * **Validate OS Security**: Ensure the operating system hasn’t been tampered with * **Prove Zero Trust**: For gateway deployments, verify domain certificates are managed entirely within the TEE For automated verification of your application’s attestation, see the [Trust Centre Technical Documentation](https://docs.phala.com/dstack/trust-center-technical) which explains how to use these quotes with the Trust Centre verification platform. ### 6.2 Requesting a TDX Quote from the Container With `/var/run/dstack.sock` mounted, use the documented curl command from inside the Palliora container: ```bash # inside the palliora-node container curl -X POST --unix-socket /var/run/dstack.sock \ -H 'Content-Type: application/json' \ -d '{ "reportData": "0x1234deadbeef00000000000000000000000000000000000000000000000000" }' \ http://dstack/GetQuote | jq . ``` Or, with the newer interface ```bash curl --unix-socket /var/run/dstack.sock \ "http://localhost/GetQuote?report_data=0x1234deadbeef" | jq . ``` ### Code integrity verification * `reportData` is a **64‑byte app‑defined field** (hex string) that is hashed into the TDX report; Palliora can use it to bind the quote to a particular genesis hash or config version. * The response JSON contains: * The TDX quote (base64) * The embedded `report_data` * Measurement fields and signatures *** ### Recap * You rented a TDX‑capable machine. * Installed and ran Dstack (vmm, gateway, kms). * Adapted Palliora’s `docker-compose.yml` for Dstack (remote genesis, public images, `dstack.sock` mount). * Deployed via the Dstack UI. * Verified attestation through Trust Centre/Retrieved TDX quotes from inside the TEE. # Become a Validator (P2) # Account Management This document explains how to log in to Palliora and view your account details using either a wallet or an email address. #### Step 1: Open the Palliora explorer Go to #### Step 2: Connect your account * Click the Connect wallet button. * A pop-up will open with two login options: Wallet or Email.
#### Step 3: Connect using a wallet (Metamask) * Make sure Metamask is installed in your browser. * Select the option to connect with a wallet * Click Connect wallet * Confirm the connection in Metamask * Once confirmed, you will be logged in. #### Step 4: Connect using an email address * Click Login with email * Enter your email address * Click Login / Sign up * Enter the code sent to your email * After entering the code, you will be logged in. #### Step 5: View your account details After logging in, your balance is shown in the bottom-left corner. Click on your address to open a pop-up showing: * Your Palliora address * Your Ethereum address

# Get Test Tokens This document explains how to claim test tokens so you can start using Palliora features. ### Before You Begin Make sure you are [logged in](/use/account-management) to your Palliora account. If you are not logged in, connect your wallet or email first. #### Step 1: Open the Faucet In the app, click **Faucet**.
#### Step 2: Complete Security Verification Follow the on-screen security verification process to continue.
#### Step 3: Claim Tokens Click **Claim tokens**. Once the request is successful, a confirmation message will appear. #### Step 4: Verify Your Balance Check your balance in the app to confirm that the test tokens have been added. Your updated balance should appear shortly after the claim is completed.
# Use a Model You can use any of the available Models on Palliora. To use a Model, you will need to first get access to the Model. Do the following to get access to a Model: {% hint style="info" %} Make sure you have the required amount of tokens before requesting access. To get tokens on the test network, you can use the [faucet](https://manas.palliora.org/faucet) {% endhint %} 1. Open [Explorer](https://manas.palliora.org/browse) 2. Click **Models** to view all available Models
3. Select the Model that you want to get access to 4. On the Model details page, click **Use This Model** > **Get Access**
5. Select a [Guardian](link://concept/gaurdian) from the list and click **Get Access** to pay for the Model access
Congrats, access to the Model is successfully granted!
See private AI inference on sensitive data while maintaining user privacy at # Upload Your Data As a user you can upload your data / models and start monetizing on it To upload, go to the data / models tab and click on "Upload" button
Add the appropriate name, description, refs -> enter the price you want to sell access for -> select the desired guardian group -> sign the transaction and upload # Train a Model # Use Lynra - DeFi Agent This guide will take you through the steps of using Lynra, a DeFi ReAct AI Agent, that helps you strategise your DeFi investments, execute swaps and put your assets to work on your behalf! 1. Head to [Lynra's website](https://lynra.ai/) to know everything you can do with Lynra agents and the infrastructure that makes Lynra stand out, through properties like decentralisation and privacy. 2. Next, you can explore the various agents Lynra offers by clicking on Explore Agents button on the website or [clicking here](https://agent.lynra.ai/). 3. The dapp will prompt to connect your wallet and sign a message. This is a crucial step as this signature is required for generating a key-pair for your public address on the [Manas testnet (Palliora).](https://palliora.org/)
4. Once connected, we should be able to see your **$PALI test token** balance on the left. We require **$PALI tokens** to access and run Lynra agents on the Palliora network, in a decentralised way.
5. If you have generated a fresh **Palliora account,** we can get $PALI tokens from Palliora's faucet. Head over to [Palliora's faucet](https://manas.palliora.org/faucet) on the Manas testnet explorer, connect your wallet with the same public account you used on Lynra, and click on the **Claim Faucet** button.
6. We will see a success popup, indicating your Palliora account is topped up with $PALI test tokens. Now its time to head back to the Lynra app, which should show the updated $PALI token balance on the left.
7. Once you have some $PALI test tokens, you're good to spin up your Lynra DeFi Agent. Lynra offers 3 agents for you to select from depending on the task you want to get done: 1. **Analyser Agent:** This is an informative agent that helps you analyse the current market state and startegize. 2. **Yeilder Agent:** This is a ReAct agent which can put your funds to use by lending/withdrawing them from yield protocols like Morpho and Pendle. 3. **Swapper Agent:** This one's also a ReAct agent, which makes swapping tokens a breeze, just through natural language!
8. Once you've selected an agent to run, a `daccRunAgent` event will be emitted on the Palliora network. A calculator node on the Palliora network will pick up this event, perform a threshold decryption of the requested agent's config, to get the agent's container image and .env variables, and run the agent on their end.
9. Finally the running agent's **access URL** (end-to-end encrypted) is returned by the calculator node in the `daccComputeResult` event, which is encrypted against your Palliora's public key. 10. The agent's access URL is finally decrypted on your end, and a *connection is established* between your machine and the running agent on the calculator node. An **agent wallet** is also created per user, and any funds required by the agent to perform on-chain task will be deducted from this agent wallet. The agent wallet is created to provide limited funds the agent has access to [(more about agent wallet here)](https://app.gitbook.com/o/c6nOxq8qsXa7V5clr4UF/s/G042xWWqiDkSJlg00aF9/~/changes/24/use/use-lynra-defi-agent#about-the-agent-wallet).
11. You can now prompt the agent to perform a task and the agent should do that for you! *We suggest using the pre-engineered prompts curated for you, as they have been designed and tested to tackle the probabilistic nature of AI agents.*
#### **About the Agent Wallet** If the task requires the agent to make on-chain calls, it is done using the **agent wallet** generated during the initialisation of the agent. Agent wallet has the following properties: 1. A new agent wallet per user will be generated. 2. The user will deposit only the funds required by the agent to perform its task to the agent wallet. This will limit access to funds by the agent, instead of giving agent access to the user wallet directly. 3. The user session will store the mnemonics to this generated user wallet, meaning, the users can also recover their agent's wallet using the Secret Phrase option in popular wallets like Metamask, anytime they want direct access to their funds deposited in the agent wallet. 4. Certain tasks like swapping and generating yield require the users to fund their agent wallet with the required gas token and the token needed for the task, for eg, the yielder agent requires USDC token to supply to Morpho markets. The required tokens funding and their balances can be managed by clicking the "Fund your agent" button on the top right of the chat interface
Hope this guide gave you a glimpse of how to use Lynra DeFi AI Agents for your needs, performing multi-steps on-chain actions, using just natural language prompts, abstracting away the complexities of on-chain actions. Hope this adds tremendous value to your workflows. # Deploy an Agent ### Architecture
### Publishing your agent container 1. Containerise your app 2. Publish it on Docker hub and get the reference to the container ### UI- Palliora Explorer 1. Open up the explorer and connect your wallet 2. Go to the Agents tab 3. You will find a "Upload Agent" button on the top right 4. Fill in the agent details. 1. Name 2. Description 3. Price: The amount of Palliora tokens you want to charge from the users running your agent 4. Container Image: The image reference pointing to your agent container image on docker hub. 5. Environment Variables: The .env variables required for your agent to run. This will be passed to the agent container along with the `docker run` cmd. Make sure to include:\ `TEST_OLLAMA_MODEL_ID` : The id of the model from the ollama registry to run your agent against. For eg:\ `TEST_OLLAMA_MODEL_ID=gpt-oss:20b` 6. Port: The port on which your agent container will open up the websocket server to enable interaction with it.\ WS Port: `8080` 5. Click Upload! 6. The network encrypts the agent details using **threshold encryption** by the guardian network and upload encrypted agent reference to Palliora's DA layer. The network will emit a `submitData` event to notify the participants of the upload. 7. The agent's metadata event will also be emitted as `daccRegisterData` which will hold a reference `refList` to the previously emitted `submitData` event. 8. Both these events will confirm the uploading of your agent! ### CLI 1. Define a json object with the agent properties, reference to its container and the `.env` variables required to have a functioning agent: ``` { "name": "Defi-agent", "description": "A DeFi trading agent", "price": 1, "deploymentRef": { "containerImg": "0xshiven/defi-swapper-agent:latest", "envs": "APIKEY=apikeyvalue\nAPIKEY1=apikeyvalue1\nAPIKEY2=apikeyvalue3\n", "port": 8080 } } ``` 2. Add this json file under `Palliora-cli/data/agent.json` 3. Use our Palliora CLI to upload the agent onto the Palliora network ``` pnpm run:upload-agent ``` 6. This script will pick your agent's details from the `agent.json` file you added `Palliora-cli/data/agent.json` , encrypt the `deploymentRef` object using **threshold encryption** by the guardian network and upload encrypted agent reference to Palliora's DA layer. The network will emit a `submitData` event to notify the participants of the upload. 7. The agent's metadata event will also be emitted as `daccRegisterData` which will hold a reference `refList` to the previously emitted `submitData` event. 8. Both these events will confirm the uploading of your agent! See a private, accountable DeFi agent in action on [https://www.lynra.ai](https://www.lynra.ai/) # Run an Agent ### Architecture
### UI - Palliora Explorer 1. Go to the Agents tab on Palliora Explorer. 2. Select the agent you want to run. 3. Pay the Palliora tokens required for running that agent. 4. You will be redirected to a chat UI where you can start interacting with the agent. ### CLI 1. Use the Palliora indexer to fetch the `agentRef` ciphertext's using the API call:
```` Implement an API to do the following: Fetch the blockHt & extrinsic from agentConfigRef: ``` statescan-polkadot-agent -> registry collection -> Agent doc.agentConfigRef -> blockHt ``` Use the blockHt & extrinsic to get the agent ciphertext data ``` statescan-polkadot-data -> blob collection -> "indexer.blockHeight": blockHt -> data ``` ```` 2. Once you have the `agentConfig` ciphertext, run the following cmd from Palliora CLI
``` node mindcrypt-cli/dist run-agent --agentRef ${agentRefCipherText} ``` 3. This will emit a `daccRunAgent` event to notify the guardian network's calculator nodes to run the agent. 4. The guardian network will perform threshold decryption on the agent's ciphertext which will expose the agent container reference and .env variables to the node. 5. The calculator node will then be able to pull the agent container image, serve the model required by the agent through ollama and execute `docker run` for the agent to start running. 6. The node will also expose an access url for your client to establish a connection with the agent, which will be encrypted against the client's public key. 7. You can fetch the result of the run agent call from the `daccComputeResult` event, decrypt the `data` to get the `accessURL` . This should be a websocket URL. 8. Use the `accessURL` to establish a direct connection with your agent and start interacting! # Palliora-cli ### 1 - Overview Palliora CLI (`palliora-cli`) is a command-line tool for interacting with the Palliora ecosystem: uploading models and datasets, managing accounts and keys, and interacting with on-chain storage and staking features. The codebase is implemented in TypeScript and compiled to a single executable script in `dist/palliora-cli.js`. Primary capabilities (examples): * Create/import/show account keys and info (see `src/account/*`). * Join the network as a guardian or validator (see `src/join/*`). * Manage staking operations (add, reduce, remove, withdraw) under `src/stake/*`. * On-chain interactions and Palliora-specific utilities under `src/palliora/*` and `src/paliCrypto/*`. Common commands (high level) * Account management: create/import/show/info - manage keys and account metadata (see `src/account`). * Join network: guardian/validator - join as a guardian or validator and submit relevant transactions (`src/join`). * Stake operations: add/new/reduce/remove/withdraw - staking flows and helpers (`src/stake`). See [Commands List](#command-reference) Examples * Create an account (example): `pnpm start account-create` * Show account info: `pnpm start account-show` ## Command Reference This file is a concise command cheat-sheet for the `palliora-cli`. Use `pnpm dev ` while developing or `palliora-cli ` after installation. #### Global flags * \--help - show help * \--version - show CLI version #### Account commands * account-show * Description: Show local account information * Options: --secret (show private key material) * Examples: * palliora-cli account-show * palliora-cli account-show --secret * account-create * Description: Create a new account and save it locally * Options: --dry (dry run) * Examples: * palliora-cli account-create * palliora-cli account-create --dry * account-import * Description: Import an account from private key / mnemonic / derived * Options: * \--private-key \ * \--mnemonic * \--derived * \--dry * Notes: private-key, mnemonic and derived flags conflict with each other (only one allowed) * Examples: * palliora-cli account-import --private-key 0xabc... * palliora-cli account-import --mnemonic "seed phrase" * account-info * Description: Show on-chain account details (balances, ledger) * Example: palliora-cli account-info * account-remove * Description: Delete the locally saved account file * Example: palliora-cli account-remove #### Funding * fund * Description: Fund an account (developer/test helper) * Options: * \--amount (coerced to bigint; default: 1000000) * \--address * Example: palliora-cli fund --amount 5000000 --address 5F... #### Staking * stake-new * Description: Create a new stake (bond) * Options: * \--amount (required) * \--reward-destination * Example: palliora-cli stake-new --amount 1000000 * stake-add * Description: Add tokens to an existing stake * Options: --amount (required) * Example: palliora-cli stake-add --amount 500000 * stake-reduce * Description: Unbond a portion of stake * Options: --amount (required) * Example: palliora-cli stake-reduce --amount 200000 * stake-remove * Description: Unbond the entire staked amount * Example: palliora-cli stake-remove * stake-withdraw * Description: Withdraw unbonded funds * Example: palliora-cli stake-withdraw #### Uploads (placeholders) * upload-model * Description: Upload a model (handler currently TODO) * Example: palliora-cli upload-model * upload-dataset * Description: Upload a dataset (handler currently TODO) * Example: palliora-cli upload-dataset #### Join network * join-guardian * Description: Join as a guardian * Options: * \--standard (boolean) * \--verifier (boolean) * \--compute - comma-separated compute prefs from: trusted,tee,mpc,fhe,zkp * Example: palliora-cli join-guardian --standard --compute trusted,tee * join-validator * Description: Join as a validator * Options: --commission (default 0) * Example: palliora-cli join-validator --commission 5 * join-idle * Description: Join as an idle staker (chill) * Example: palliora-cli join-idle ***Notes & caveats*** * The CLI uses `milliPALI` units for token amounts and coerces values to `bigint` using helpers in `src/utils/helper.ts` - supply integer values (no decimals). * `upload-model` and `upload-dataset` are TODO placeholders in code and currently have no implemented behavior or options. # Architecture We have implemented a working prototype or testnet for Palliora, that we call Manas. On the infrastructure side, Manas consists of a set of Validators under Proof of Stake consensus mechanism and [Guardian Network](/learn/concepts/guardian) (that can scale to a few hundred participants). Manas [Validators](/learn/concepts/validator) maintain the [Data Availability (DA) ](/learn/concepts/data-availability)capabilities of the network, including the storage, verification. Validators maintain the blockchain state, therefore complying with both block production and transaction validation and interactions with Guardians. On the other hand, Manas Guardians are responsible for enabling both data accountability and [confidential computation](/learn/concepts/confidential-compute). The standard Guardian network implements flexible threshold setting among a selected subgroup of Guardian nodes participating in managing access to the data on-chain, catering to user-driven/chosen trusted security circle on the Manas network. The Guardian protocol implements the [Silent-Threshold Encryption](https://eprint.iacr.org/2024/263) as the cryptographic protocol that provides a safe environment for on-chain requests when they are in-transit or at rest in the DA service.\ The integrated Trusted and Confidential computing services of the Manas Guardians nodes or Calculators allow for enhanced sources for data generation with built-in confidentiality. Manas enables two crucial roles of Publishers and Retrievers who can submit encrypted data (new or duplicate) and access existing data, respectively. The value of the data posted on the Manas is determined by the Publisher (i.e. its Owner) and the Retriever must provide the set price to have access. The price is set in PALI tokens; in this way, the network's economics is balanced with the associated cost of maintaining the DAC service of Manas.
The Guardian network participation is open for anyone who follows certain rules set in the runtime contract, As long as they can setup a Palliora node client and stake a minimum amount of PALI tokens. During a node client setup, the operator manages a KeyPair (sk, pk) secret to have ownership of rewards and stakes. When the guardian set evolves, then the guardian set parameter gets updated in the runtime contract. This update is linked to a configured numbers of blocks (termed as an epoch). The KeyPair acts as both an identifier (for the node client) and a security parameter for the threshold decryption.\ Guardian nodes are capable of downloading the computation program in the containerized framework (e.g. Docker) so that Calculator (a sub-category of Guardian node) can execute a trusted or confidential setup (e.g. TEE). ### Lifecycle of the request A dApp is a decentralized application that works with a user-owned software wallet. Any dApp interacts with the Manas network through RPC calls, mainly to submit compute requests to the Guardians. Several reference dApps are available that have served as early users of Palliora: * [**Veilnyx** ](https://veilnyx.com/)– Compliant privacy by selective disclosures * [**Valorae** ](https://valorae.tech/)– Private AI chatbot * [**Lynra** ](https://www.lynra.ai/)– Accountable and Private DeFi and AI agents * [**Datari** ](https://datari.app/)– Fine-tuning of LLM models using privately shared data
The request starts with the data submission in encrypted format, where standard Guardian nodes are entrusted with safeguarding the private data. The Manas Data Availability layer utilizes erasure encoding and KZG commitments to offer recoverability, proof of existence, and a confidence metric to its application layers. Erasure encoding introduces data redundancy, safeguarding against potential losses with a degree of recoverability. KZG commitments enable efficient proof of data existence without revealing the data itself. Once this Guardian receives the compute request, it generates a shared key and decrypts the encrypted request. The decrypted ciphertext contains the necessary payload for the compute service. If the node that receives the request does not process it, even a corrupt node will fail to access the requested data due to the encryption encapsulating it. The request follows the Palliora protocol for selective data sharing and pricing between the Publisher and the Retriever. The request flow continues with the dApp creating a [**Compute Contract Agreement Request**](/learn/concepts/compute-contracts). This contract specifies the economic parameters of the computation, including the cost of the computation the user is willing to pay, threshold decryption fees, and the list of Guardians that the user wants to involve. This contract proposal (agreement request) formalizes the terms under which the computation will be executed. The dApp sends this proposal to an RPC node. The transaction enters the transaction mempool and is broadcast to the specified Guardian nodes. Each Guardian reviews the contract parameters and provides its agreement. Once all required Guardians have signed their agreement on the contract, the finalized contract is included in a block on the Manas blockchain and assigned a unique **Contract ID (CID)**. This CID serves as the reference on the chain for subsequent computation operations. The fees are locked at this point. After the agreement is finalized on-chain, the dApp submits the actual **Compute Request**, explicitly referencing the CID. The compute payload is submitted in encrypted format, where the selected Guardian group is entrusted with safeguarding and threshold decrypting the private data in accordance with the contract. After decryption, the compute request is forwarded to the designated computing node (the so-called **Calculators**). As a matter of fact, depending on the configuration, in Manas any Guardian node can be a **Standard node**, a **Computing node**, or even a **Verifier node**. As regards computing nodes, they can be either **trusted** or **confidential**, where *trusted* means they can see the input and confidential means they cannot. Users can select the type of computing nodes. Interestingly, in the current implementation, a Manas Guardian can choose to act simultaneously as both a **Trusted** and a **Confidential Compute** node, appropriately serving each type of compute request. The properties of the Manas network ensure that once decrypted and forwarded according to the contract, the data is processed by the requested computation (for example, a pre-trained AI model), which generates a suitable response.
The dApp continuously monitors block production events on the Manas blockchain. Upon detecting the desired result, the dApp fetches it, decrypts it (if necessary at the application layer), and finally presents it to the user. Another important aspect of the computation handling is the interaction between blockchain blocks and the dApp. Due to the off-chain nature of the processing, when a Compute Request referencing a specific CID reaches the Manas blockchain in block number **t**, the computation result will not be available until a future block with block number **(t + n)**, where **n** represents the total time required for agreement finalization, threshold decryption, and computation. ### Performance The Palliora Manas network comes with a runtime contract that enables 4MB-sized blocks with a block time of 6.0 seconds. The block sizes can be increased in future to accommodate higher throughput. The current testent network can reach a TPS of 700 tx/sec. The Manas testnet is running a BABE-GRANDPA protocol for block authoring, finality, and fork selection, providing a finality time in the range of 15-20 seconds. The DA Manas network incorporates an archive store of block history, as well as large-file storage. Currently, Manas storage node is configured for 300GB of raw storage, served by an erasure encoding-enabled database. Guardian clients can join the network every 4-hour interval. # How the Compute Contract Works This document explains the full lifecycle of a Compute Contract, from agreement creation to result retrieval and fund settlement. ## Overview A Compute Contract combines: * On-chain economic agreement * Guardian-based threshold decryption * Off-chain computation * Verifiable result publication * Automatic fund settlement It ensures that computation happens only after economic terms are agreed upon, and payment is released only after execution is completed. ## Architecture Components
#### **User**\ Initiates the request through a dApp. **dApp**\ Creates the agreement and a compute request transaction. **RPC Node**\ Gateway between the dApp and the Palliora network. **Guardian Nodes**\ Selected nodes that: * Agree to the computation terms * Perform threshold decryption * Coordinate secure execution **Guardian Service**\ Service layer responsible for: * Threshold decryption * Forwarding decrypted payloads to the Compute Node **Compute Node**\ Executes the requested computation (AI model, logic, etc.). **Data Availability Layer**\ Stores published results with recoverability and proof guarantees. **Consensus Layer**\ Finalizes transactions, locks funds, and triggers settlement. ## Step-by-Step Flow *** ### 1. Agreement Creation The flow begins when the User interacts with the dApp. The dApp creates a Compute Contract Agreement Request, which defines: * Compute the cost the user is willing to pay * Threshold decryption fees * List of selected Guardians * Execution parameters This formalizes the economic and trust assumptions before any computation begins. *** ### 2. Agreement Submission The dApp sends the Agreement Request to an RPC Node. The transaction: 1. Enters the transaction mempool 2. Funds are locked 3. Is broadcast to the selected Guardians Each Guardian reviews the request and submits an Agreement confirmation. When all required Guardians agree: * The agreement is included in a block * A unique Agreement ID is generated At this stage, the Compute Contract is officially established on-chain. *** ### 3. Compute Request Submission After the Agreement is finalized: * The dApp submits the Compute Request * The request references the Agreement ID * The compute payload is submitted encrypted The encryption ensures that no single Guardian can access the payload alone, and decryption requires the agreed threshold *** ### 4. Threshold Decryption Once the Compute Request is confirmed on-chain: * The Guardian Service initiates threshold decryption * A minimum number of Guardians must participate * The payload is decrypted collectively This guarantees privacy, shared trust, and resistance to single-node compromise *** ### 5. Execution by Compute Node After decryption: * The request is forwarded to the Compute Node( Trusted or Confidential) * The computation is executed The Compute Node only processes the decrypted payload, and does not control private keys, nor can it alter economic terms *** ### 6. Result Publication When computation completes: * The result is published to the Data Availability Layer The Data Availability Layer ensures Proof of existence, Data recoverability and Verifiability *** ### 7. Consensus & Fund Release Once the result is published: * The Consensus Layer finalizes it * Settlement logic is triggered * Funds are released according to the Agreement Payments are distributed to the Compute provider and Guardians who participated in threshold decryption *** ### 8. Result Retrieval While execution happens off-chain: * The dApp polls for the result * When available, it retrieves it from the Data Availability Layer * The result is presented to the User
# Overview **Introduction** ISHTA (Inflation Stabilized Hybrid Token Architecture) is a next-generation Proof-of-Stake (PoS) consensus mechanism designed to address the volatility and instability inherent in traditional PoS reward systems. It introduces a novel inflation curve alongside a layered security architecture leveraging Confidential Compute and Threshold Encryption to ensure robustness, scalability, and data integrity. This document details the architectural components, core concepts, and security mechanisms underpinning the ISHTA protocol. **High-Level System Diagram:**
**Key Architectural Principles:** * **Hybrid Inflation Curve:** ISHTA employs a dynamic inflation curve with two phases: initial growth and stabilization. The initial phase sees a moderate inflation to incentivize early adoption. The stabilization phase uses a decreasing inflation rate, governed by network activity (transaction volume, staking ratio), aiming for a low and predictable inflation rate. Formula Example: `InflationRate = BaseRate * (1 - (StakingRatio * StabilityFactor))` * **Layered Security:** Defense in depth is achieved through combining Confidential Compute, Threshold Encryption, and a robust data availability solution. * **Decentralized Governance:** The Guardian manages protocol parameters through on-chain voting, ensuring community participation. * **Scalability:** The system utilizes techniques like data sharding and efficient consensus algorithms to handle high transaction throughput. **Components Overview:** * **Stakers:** Token holders delegate tokens to Validators, earning rewards proportional to their stake and Validator performance. Delegation is handled through smart contracts. * **Validators:** Nodes responsible for validating transactions, creating blocks, and participating in consensus. Validators run within secure enclaves (Section 2.3). They are rewarded with transaction fees and staking rewards. * **Guardian:** Elected committee managing protocol parameters. Parameter changes require a majority vote. The Guardian also handles emergency situations. * **Confidential Compute Enclave:** Secure environments (e.g., Intel SGX) protecting sensitive data and execution. * **Data Availability Layer:** Ensuring transaction data is accessible for verification. (e.g., using KZG commitments – see below). # Dataflow (P2) # Concepts ###
/pages/9usFlfafTzPiaw2aWpWXA neutral node that coordinates data access and computation across the network. Guardians work as a group, so no single node can access data or change a contract on its own.
/pages/uD3DfeiXrRRn5kua7kyyDefines what data is used, how computation runs, who can see the results, and how participants get paid. If you are building on Palliora, this is the best place to start.
/pages/fEwwtB7QxA73lWoN0XpHValidators maintain the blockchain, confirm transactions, and agree on the order of blocks. They keep the on-chain record that everything else in Palliora depends on.
/pages/xu1SA1qEpaGdTrPJH4yKRuns computation on sensitive data without exposing it to the machine or anyone operating it, using secure processor enclaves called TEEs. Only the outputs allowed by the contract are ever revealed.
/pages/WaEAtoHo2352DgoMIZnYMakes sure that data stored on the network can always be retrieved and has not been changed. Uses erasure coding and compact proofs so nodes can verify data exists without downloading all of it.
/pages/7tW368C6yOezFvPudK6iSplits the ability to decrypt data across multiple Guardian nodes so no single party can unlock it alone. A minimum number of Guardians must cooperate before any protected data can be accessed.
## Palliora's white paper Read the white paper #### Previous versions of the white paper {% file src="/files/h3BjfqtJPo9oNX8VaGE7" %} ### Our path to the white paper Seminal idea by Dr. Amit Chaudhary presented at CIFIRIS24 Lite paper on the intermediate status Preprint on computable contracts Preprint on tokenization # Guardian ### What is a Guardian? A Guardian is one of the core actors in the Palliora network. Its role is to ensure that data and computation are handled exactly as agreed, even when the data is sensitive and the parties involved do not trust each other. You can think of a Guardian as a neutral enforcer. It does not own data, does not set protocol policy, and does not benefit from bending the rules. It exists to ensure that Palliora contracts are executed faithfully and transparently. ```mermaid --- config: layout: dagre theme: neutral --- flowchart LR subgraph s1["Gaurdian Network"] Center["Threshold Decryption"] A(("Gaurdian")) B(("Gaurdian")) C(("Gaurdian")) n1(("Gaurdian")) end A --- Center Center --- B & C n1 --- Center n2["App"] -- Compute Request --> s1 s1 -- Publish Result --> n3["Data Availbility"] Center@{ shape: text} n2@{ shape: rect} n3@{ shape: rect} ``` *** ### Why Palliora needs Guardians Palliora is designed for situations where people want to share data or run computations without giving up control. In practice, this requires enforcing clear rules around who can access data, how computations are executed, and when results can be revealed. Blockchains are good at recording agreements, but they are not well suited to handling private data or complex computation. Centralised servers can do those things, but they require trust. Guardians bridge that gap. They coordinate data access and computation off-chain, while remaining accountable to the on-chain contract that defines what is allowed. *** ### How Guardians operate Guardians do not act individually. They operate as a coordinated set. For many actions, a predefined quorum is required. This means no single Guardian can unilaterally release data or override contract conditions. Instead, a threshold of participating Guardians must cooperate before sensitive actions occur. This protects against compromise or malicious behaviour by any one node. The term “Guardian” is an umbrella term. A Guardian node may: * coordinate data access and enforcement * perform computation as a calculator * verify inputs or outputs These roles are explicitly defined in the contract and economically separated. Importantly, Guardians do not need to see the underlying data. Data is typically encrypted or split into shares, which allows them to enforce rules without learning anything sensitive. *** ### Trust and accountability Guardians are not trusted because they are elected or centrally appointed. They are trusted because they have economic stake and cryptographic accountability. To participate, Guardians must stake tokens as collateral. Every action they take is signed, recorded, and tied to a specific contract. If a Guardian deviates from the contract, it can be penalised financially. The system is designed to remain secure even if some Guardians are malicious or unavailable. Through quorum requirements and Byzantine Fault Tolerant coordination, Palliora can tolerate a subset of dishonest actors without compromising contract execution. All Guardian actions are auditable through the blockchain, ensuring transparency. *** ### What Guardians are not Guardians do not define monetary policy, adjust inflation, or decide protocol upgrades. They do not act as a governance council. Their responsibility is operational. They enforce contracts, coordinate execution, and uphold the integrity of data handling. Governance, where present, is handled separately at the protocol level. *** ### How Guardians fit into Palliora Guardians sit at the centre of Palliora’s execution layer. * Data Availability ensures that data exists and remains retrievable. * Computable contracts define the rules of engagement. * Validators secure the ledger that records those rules and their outcomes. Guardians ensure that real-world execution matches what was agreed, even when confidentiality, verification, and economic incentives are involved. # Compute Contracts A **Compute Contract** is how Palliora turns an agreement into something that can actually be executed. It describes not just what parties agree on, but how data is accessed, how computation is performed, who is allowed to see the results, and how everyone involved is rewarded. In Palliora, contracts are not passive records. They actively coordinate real computation on real data. ```mermaid --- config: layout: dagre theme: neutral --- flowchart TB subgraph s1["Compute contract"] n5["Agreement
Fee Locking
Execution Rules
Incentives"] end n4["Guardians"] <-- Provide Agreement --> n5 n5 <-- Execute --> n4 n4 -- Publish Result --> n3["Data Availability"] n2["App"] -- Agreement Request --> s1 n2 L_n2_s1_2@-- Compute Request --> s1 n5@{ shape: rect} n4@{ shape: rect} n3@{ shape: rect} n2@{ shape: rect} L_n2_s1_2@{ curve: linear } ``` *** ### The problem Compute Contracts solve Traditional smart contracts are good at enforcing simple rules on-chain, but they struggle with real-world workloads. They cannot handle large datasets, private inputs, or complex computation without either exposing data or becoming impractical. Off-chain agreements solve the scalability problem, but they reintroduce trust. Once computation happens outside the chain, there is no strong guarantee that it was done correctly, privately, or according to the original agreement. Compute Contracts close this gap. They allow parties to agree on off-chain computation while keeping execution accountable, verifiable, and aligned with the original agreement. *** ### How a Compute Contract works At a high level, a Compute Contract defines the full lifecycle of a computation: * **Inputs**: what data is involved and where it lives * **Computation**: what should be executed * **Confidentiality**: who can see what, and under what constraints * **Roles**: who executes, who verifies, who can retrieve outputs * **Incentives**: how rewards are distributed and under what conditions Once agreed, the contract is recorded immutably. Guardians then enforce it step by step, coordinating data access, computation, and verification exactly as specified. Each action is tied back to the contract, so execution and rewards remain linked to what was originally agreed. The contract itself does not perform computation. It acts as the shared source of truth that coordinates all actors involved. *** ### Trust and guarantees Compute Contracts do not assume trust between participants. They rely on a combination of cryptography, verification, and economic incentives: * Data can remain encrypted * Computation can be verified * Actors are rewarded only if they follow the contract This allows parties to collaborate without trusting each other directly, as long as they trust the protocol and its incentives. Compute Contracts are flexible. They can support different confidentiality levels, verification strategies, and economic arrangements depending on the use case. *** ### What a Compute Contract is not A Compute Contract is not: * A traditional smart contract that runs entirely on-chain * A legal agreement written in natural language * A loose workflow description that cannot be executed It is precise enough to be enforced by the protocol, but flexible enough to support real-world data and computation. It does not remove responsibility from participants. It defines responsibilities clearly and enforces them through the system. *** ### How Compute Contracts fit into Palliora Compute Contracts sit at the heart of Palliora: * They define the rules * Guardians enforce them * Data Availability ensures inputs and outputs exist * Calculators and verifiers execute and validate the work Without Compute Contracts, Palliora would be a collection of components. With them, it becomes a coordinated system for trusted computation. *** ### When you need to care about Compute Contracts If you are simply using an app built on Palliora, you may never need to think about Compute Contracts directly. They operate behind the scenes. If you are building on Palliora, designing workflows, or monetising data or models, understanding Compute Contracts becomes essential. They are the mechanism that turns intent into enforceable execution. # Validator ### What is a Validator? Validators are the actors responsible for keeping the Palliora network running correctly. They maintain the blockchain, validate transactions, and participate in consensus to agree on the order and validity of blocks. In short, validators ensure that Palliora has a reliable, tamper-resistant ledger that everyone can depend on. While many Palliora features happen off-chain, validators are what make those features accountable on-chain. *** ### The problem Validators solve Any decentralised system needs a shared source of truth. Without validators, there is no reliable way to agree on which transactions happened, in what order, or whether protocol rules were followed. Contracts would be unenforceable, rewards disputable, and the system vulnerable to manipulation. Validators solve this by collectively maintaining and securing the Palliora blockchain. They ensure that once something is recorded and finalised, it cannot be quietly changed or ignored. *** ### What Validators do Validators verify incoming transactions before including them in blocks. This includes checking digital signatures, account balances, and adherence to protocol rules. They propose new blocks and participate in a Byzantine Fault Tolerant consensus process to agree on block order and validity. Through this process, the network can continue operating correctly even if a subset of validators behaves maliciously or becomes unavailable. Each validator maintains a full copy of the blockchain state, including account balances and smart contract data. This allows them to independently verify correctness rather than relying on other nodes. Once consensus is reached, validators attest to block validity and participate in finalisation. After finalisation, the recorded state becomes irreversible under normal operating conditions. *** ### Trust, staking and operational requirements Validators are not trusted by reputation. They are trusted because they have economic stake and operational responsibility. To participate, validators must lock up tokens as collateral. The size of the stake determines eligibility and may influence rewards. In return, validators earn staking rewards and a share of transaction fees generated by the network. Because validators secure the foundation of the system, they are expected to meet strict operational standards. This includes high uptime requirements, sufficient hardware capacity, and secure key management practices. Hardware security modules are recommended to protect private keys. Validators may also undergo security audits or meet other infrastructure requirements defined by the network. *** ### Rewards and penalties Validators are rewarded for honest participation and penalised for misconduct or negligence. They earn rewards proportionally to their stake and network activity. However, if a validator behaves maliciously, part of their stake can be slashed. Examples of slashable behaviour include: * Signing conflicting blocks * Proposing invalid blocks * Extended periods of downtime This economic design ensures that acting honestly is the rational strategy. *** ### What Validators are not Validators do not handle private data. They do not decrypt inputs, run confidential computation, or decide who can access data. Those responsibilities belong to Guardians, calculators, and verifiers. Validators also do not define protocol policy or upgrades. Their role is operational. They enforce the current rules of the network, not decide future ones. *** ### How Validators fit into Palliora Validators secure the foundation on which everything else in Palliora is built. Computable contracts, Guardian coordination, rewards, penalties, and data commitments all rely on the blockchain maintained by validators. The Data Availability layer records commitments and proofs on-chain, and validators ensure those records are correct and final. Without validators, Palliora would have no reliable execution history. With them, off-chain computation and data sharing remain anchored to an immutable ledger. # Confidential Compute ### What is Confidential Compute? Confidential Compute allows computation to be performed on sensitive data without exposing that data to the parties running the computation. In Palliora, this means data can be processed while remaining hidden from infrastructure operators, other network participants, and even the host operating system. Only the intended outputs are revealed, and only under the conditions defined in the contract. Confidential Compute is a core security capability that allows Palliora to support sensitive workloads without relying on trust in the underlying infrastructure. *** ### The problem Confidential Compute solves In many real-world scenarios, data cannot be shared in plain form. It may be commercially sensitive, personally identifiable, or legally restricted. Traditional computation models force a trade-off. Either the data is revealed to the party performing the computation, or computation is avoided altogether. Encryption protects data at rest and in transit, but in most systems, it must be decrypted before it can be used. Confidential Compute removes this trade-off. It allows data to be processed without being exposed to the machine operators or external observers. *** ### How Confidential Compute works Palliora enables Confidential Compute primarily through the use of Trusted Execution Environments, or TEEs. A TEE is a secure enclave within a processor. It provides a protected memory region where code can execute in isolation from the rest of the system, including the operating system and administrators. Data loaded into the enclave cannot be accessed from outside it. Before computation begins, the enclave generates an attestation report. This is a cryptographic proof that confirms the enclave is genuine and that it is running the expected code. Other network participants, including verifiers, can check this proof before allowing sensitive data to be processed. Once verified, encrypted data is provided to the enclave. Inside the enclave, the data can be decrypted and processed securely. The intermediate state remains confined to the enclave. Sensitive data can also be sealed, meaning it is encrypted with a key derived from within the enclave itself. Sealed data cannot be accessed outside that enclave instance, preventing extraction or reuse in an unintended context. In practice, a contract may require that certain operations run inside a TEE. Guardians coordinate access, and a designated compute node executes the workload inside the enclave. The output is then encrypted and released according to the contract’s rules. *** ### Trust and guarantees Confidential Compute significantly reduces the trust required in infrastructure operators. Even if the host machine is compromised, the data and execution inside the enclave remain protected. Attestation ensures that only approved code is running. Sealed data ensures that sensitive material cannot be extracted or reused outside the trusted boundary. However, Confidential Compute does not eliminate all trust assumptions. It relies on hardware security guarantees and the correct implementation of the TEE technology. Palliora therefore treats it as one option within a broader confidentiality spectrum, chosen explicitly in the contract. *** ### What Confidential Compute is not Confidential Compute is not a complete privacy solution. It does not replace encryption, access control, threshold decryption, or verification. It also does not guarantee the correctness of computation on its own. A computation can still be incorrect or malicious if it is not properly verified. For this reason, Palliora combines Confidential Compute with other mechanisms such as threshold encryption, verifiers, and computable contracts. *** ### How Confidential Compute fits into Palliora Confidential Compute is one of the execution modes available to Palliora contracts. A contract can specify that certain computations must run inside a TEE. Guardians coordinate access to encrypted data. A compute node processes the request inside an enclave. Verifiers can check attestation and validate outputs where required. This enables use cases such as private model training, secure data analysis, protected key handling, and agent execution without exposing raw inputs. # Data Availability ### What is Data Availability? Data Availability ensures that data referenced in Palliora actually exists, remains accessible, and has not been tampered with. In Palliora, contracts, computations, and verification all depend on data being reliably retrievable. Data Availability guarantees that once data is committed to the network, it cannot be silently removed, censored, or altered. It is a foundational layer that makes off-chain computation enforceable. *** ### The problem Data Availability solves In decentralised systems, it is not enough to agree on data. Participants must also be confident that the data can be retrieved later by anyone authorised to access it. As systems scale, this becomes difficult. Large volumes of data are expensive to store and distribute. Requiring every node to download and verify all data does not scale. At the same time, relying on a small number of storage providers introduces censorship risks and trust assumptions. Without strong Data Availability guarantees: * Contracts become fragile * Computation can stall * Verification becomes impossible * Malicious actors can withhold data without detection Data Availability addresses scalability, cost, and censorship resistance simultaneously. *** ### How Data Availability works Palliora uses a dedicated Data Availability layer designed to scale while remaining verifiable. When data is submitted: 1. **Encryption (if required)**\ Data is encrypted if confidentiality is needed. 2. **Data sharding**\ The data is split into smaller chunks, known as shards. 3. **Erasure coding**\ Reed–Solomon erasure coding is applied to introduce redundancy. This allows the original data to be reconstructed even if some shards are missing. 4. **KZG commitments**\ Each shard is committed to using a KZG polynomial commitment scheme. These commitments are small, efficient, and immutable once recorded. Rather than storing all raw data directly on-chain, the network stores cryptographic commitments to the data. *** ### Sampling and verification Nodes do not need to download the full dataset. Instead, they randomly sample a subset of commitments and request the corresponding shards. If the sampled shards are available and match their commitments, this provides strong probabilistic evidence that the entire dataset is available. If a node fails to provide the requested data, this can be proven. A fraud-proof can be submitted, and the responsible node may be penalised. This creates economic incentives for honest storage. *** ### Why KZG commitments are used KZG commitments provide several important properties: * **Succinct proofs** — proof sizes remain small * **Non-interactive verification** — no multi-round communication required * **Strong cryptographic binding** — committed data cannot be altered This allows Palliora to scale without sacrificing integrity. *** ### Trust and guarantees This design provides clear guarantees: * Data cannot be silently censored or removed * Data cannot be altered without detection * Nodes can challenge availability at any time * The system scales without requiring full data downloads Importantly, Data Availability does not require trust in a single storage provider. It relies on cryptography and economic incentives rather than reputation or permission. Confidentiality remains separate. Data may be encrypted before entering the Data Availability layer, so availability does not imply visibility. *** ### What Data Availability is not Data Availability does not decide who is allowed to access data or when. It does not execute computation.\ It does not verify computation results.\ It does not enforce contract logic. Its responsibility is deliberately narrow: to ensure that committed data exists, remains intact, and can be retrieved when required. *** ### How Data Availability fits into Palliora Data Availability underpins Palliora’s execution model. Computable contracts reference data without embedding it directly. Guardians rely on the Data Availability layer to retrieve inputs and store outputs. Verifiers use it to check integrity. Calculators depend on it to access data reliably. Without Data Availability, Palliora contracts would be promises. With it, they become enforceable. *** ### A simple example Imagine a dataset of 100 GB. Instead of storing it as a single object, Palliora splits it into 1,000 smaller shards, adds redundancy through erasure coding, and commits to each shard using compact KZG commitments. Nodes randomly sample a subset of shards, for example, 100, and request them. If the sampled shards are available and valid, it is overwhelmingly likely that the entire 100 GB dataset is available, without requiring anyone to download all of it. This is how Palliora achieves scalability with strong guarantees. # Threshold Encryption ### What is Threshold Encryption? Threshold Encryption is a cryptographic technique that protects data by ensuring that no single party can decrypt it on their own. Instead of relying on one secret key, decryption power is split across multiple participants. Only when a predefined number of them cooperate can decryption happen. If too few participate, the data remains encrypted. In Palliora, threshold encryption is used to protect sensitive data, encrypted payloads, and even critical keys such as validator keys. It ensures that secrets are never controlled by a single entity. *** ### The problem Threshold Encryption solves Traditional encryption creates a single point of failure. Whoever controls the secret key controls the data. If that key is compromised, lost, or misused, confidentiality is broken. In decentralised systems like Palliora, this model does not work well. Validators, Guardians, data providers, and computation providers may all be independent and untrusted. There is often no single party that should hold full decryption authority. Threshold encryption removes this single point of trust. Compromising one participant is not enough to compromise the data. It also improves resilience. Even if some participants fail or go offline, decryption can still proceed as long as the required threshold is met. *** ### How Threshold Encryption works At a high level, a secret key is never stored in one place. Instead, a master secret is split into multiple cryptographic shares using a threshold scheme, typically based on Shamir’s Secret Sharing. Each authorised participant receives one share. To decrypt data, a minimum number of participants, known as the threshold, must cooperate. They combine their shares to reconstruct the decryption capability. If fewer than the required number participate, reconstruction is mathematically impossible. In Palliora: * Guardian nodes typically hold decryption shares * Shares may also be used to protect validator keys * Decryption only occurs when the conditions defined in a computable contract are satisfied This allows data to remain encrypted during storage, coordination, and even parts of execution. It is only decrypted at the precise moment authorised by the contract. *** ### Trust and guarantees Threshold encryption significantly reduces trust assumptions. Compromising a single Guardian or validator is not sufficient to access protected data. The system can tolerate the failure or compromise of a limited number of participants, as long as the threshold is not reached by malicious actors. This provides: * Enhanced security * Fault tolerance * Reduced reliance on any single entity Economic incentives further reinforce correct behaviour. Participants are rewarded for cooperating when required and penalised for misbehaviour. *** ### What Threshold Encryption is not Threshold encryption does not decide who should have access to data or when. Those rules are defined in computable contracts. It does not execute computation or verify results. It is a confidentiality mechanism that works alongside other techniques, such as confidential compute and verification frameworks. On its own, threshold encryption is not a complete security model. It is one of the core building blocks Palliora uses to enforce trust without centralisation. *** ### How Threshold Encryption fits into Palliora Threshold encryption is a key mechanism used by Guardians to enforce confidentiality. It allows the Data Availability layer to store encrypted data without knowing its contents. It prevents any single Guardian or validator from unilaterally decrypting data. It enables computable contracts to define precise, enforceable release conditions. Together with Data Availability, Confidential Compute, and Validators, it makes selective and secure data sharing possible in a decentralised environment. # Veilnyx App Guide: Private Transactions This guide outlines the process for connecting your wallet, creating a private account, depositing tokens, and conducting shielded transactions on the Veilnyx app. #### Phase 1: Setup and Account Registration 1. Access the Application: 1. Navigate to the Veilnyx application at app.veilnyx.com/discover to view all supported applications and protocols.
2. Connect Your Wallet: 1. Go to the Home tab. 2. First-time users must connect their non-custodial wallet (e.g., MetaMask, WalletConnect) to the application. 3. Register Your Wallet: 1. Once your wallet is connected, a "Register" modal will appear. 2. Click "Register" to begin the process of linking your wallet to Veilnyx.
4. Generate Your Shielded Account: 1. You will be prompted to sign a wallet message (this is an app-specific signature, not a transaction). 2. This signature is required to generate your unique Shielded Account on Veilnyx, which is necessary for all private transactions.
5. Acknowledge Compliance Authority (Revoker Selection): * Before using the shielded account, you will typically be prompted to acknowledge or select the Compliance Authority (the Revoker/Guardian network) under the Selective De-Anonymization (SeDe) framework. * This step is crucial as it confirms your agreement to the protocol's compliance measures, which are necessary for the transaction to be validly included in the Veilnyx privacy pool. * *Note: This selection usually acknowledges that the network's decentralized Revokers and Guardians exist to monitor and selectively de-anonymize transactions only if illicit activity is detected.*
#### Phase 2: Depositing Tokens for Privacy 5. Deposit Tokens: 1. After your Shielded Account is generated, you can deposit tokens from your regular External Owned Account (EOA) wallet (the one you connected) into your Veilnyx Shielded Account. This action moves your funds into the privacy layer.
6. Manage Your Balance State: 1. If you see your deposited token balance but cannot use it immediately, it might be in a "Pending" state. 2. You need to move the balance from the "Pending" state to the "Spending" (or "Available") state before you can use it for transactions. 3. This transfer may happen automatically after a short period, or you may be able to manually call a function within the app to initiate the state change immediately (settle all balance).
#### Phase 3: Conducting Private Transactions 7. Send Private Transactions: 1. Once your tokens are in the Spending state within your Shielded Account, you can start sending tokens privately on Veilnyx. 2. The recipient address must also be registered on the Veilnyx app with their own Shielded Account to receive the private transaction.