# Lithosphere

Developer-preview toolchain for building on Lithosphere.

This repository is the source for the current GitHub release that external developers can use to start building. The public preview ships the starter CLI, the TypeScript SDK package, versioned contract artifacts, and the supporting docs needed to bootstrap projects against the Makalu network stack.

Lithosphere development in this repo is Solidity-first today. There is no standalone `lithic-compiler` package or binary in this workspace yet; existing "Lithic" references are verifier and language branding around the broader Lithosphere ecosystem.

## What Ships In The Preview

* `create-litho-app`: CLI that scaffolds official starter projects
* `@lithosphere/sdk`: TypeScript SDK package distributed as a GitHub release tarball
* Versioned contract artifacts from `Makalu/contracts`
* Developer docs and release-consumption guidance

## Start Building

### From The Monorepo

```bash
git clone https://github.com/KaJLabs/lithosphere.git
cd lithosphere/Makalu
pnpm install --frozen-lockfile
pnpm --filter create-litho-app build
node packages/create-litho-app/dist/index.cjs my-first-dapp --template contracts
```

### From A GitHub Prerelease

Download the latest prerelease assets from GitHub Releases, then install the packaged CLI or SDK tarball locally. The release guide documents the exact asset names and verification flow:

* `docs/guides/consuming-releases.md`

## Repository Layout

* `Makalu/`: developer workspace containing the CLI, SDK, contracts, templates, API, and explorer
* `docs/`: project and release documentation
* `.github/workflows/`: CI and GitHub release automation

## Documentation

* `docs/quickstart/dev-setup.md`
* `docs/developers/overview.md`
* `docs/guides/consuming-releases.md`
* `docs/guides/contributing.md`

## Requirements

* Node.js 20.x
* pnpm 9.x

## License

MIT. See `LICENSE`.


# Security Policy

## Supported Versions

| Version                  | Supported |
| ------------------------ | --------- |
| Makalu Testnet (current) | Yes       |

## Reporting a Vulnerability

We take security seriously. If you discover a security vulnerability in the Lithosphere protocol, explorer, APIs, or any associated infrastructure, please report it responsibly.

### How to Report

* **Email**: <security@litho.ai>
* **Subject line**: `[SECURITY] <brief description>`
* **Include**: Steps to reproduce, affected components, potential impact, and any suggested fixes

### What to Expect

1. **Acknowledgment**: We will acknowledge receipt of your report within 48 hours.
2. **Assessment**: Our team will assess the severity and impact within 5 business days.
3. **Resolution**: We will work on a fix and coordinate disclosure with you.
4. **Credit**: With your permission, we will credit you in the security advisory.

### Scope

The following are in scope for responsible disclosure:

* Lithosphere node software (`lithod`)
* Explorer and block explorer APIs (`makalu.litho.ai`)
* Public RPC endpoints (`rpc.litho.ai`, `api.litho.ai`)
* Smart contract standards (LEP100)
* SDKs and developer tools

### Out of Scope

* Denial-of-service attacks against production infrastructure
* Social engineering of team members
* Third-party services not operated by Lithosphere

### Disclosure Policy

* Do not publicly disclose the vulnerability before we have had a chance to address it.
* Do not exploit the vulnerability beyond what is necessary to demonstrate it.
* Do not access or modify data belonging to other users.

## Security Audits

Lithosphere is actively pursuing third-party security audits. Completed audit reports will be published here with scope statements and remediation status as they become available.


# \_sidebar

* [Home](/)
* **Introduction**
  * [What is Lithosphere?](/docs/introduction/what-is-lithosphere)
  * [Architecture Overview](/docs/introduction/architecture-overview)
  * [Glossary](/docs/introduction/glossary)
  * [FAQ](/docs/introduction/faq)
* **Quickstart**
  * [Developer Setup](/docs/quickstart/dev-setup)
  * [Validator Setup](/docs/quickstart/validator-setup)
  * [CLI Tools](/docs/quickstart/cli-tools)
* **Developers**
  * [Overview](/docs/developers/overview)
  * [LEP100 Token Standard](/docs/developers/lep100-standard)
  * [Smart Contracts](/docs/developers/smart-contracts)
  * [API & SDK](/docs/developers/api-and-sdk)
  * [Frontend Integration](/docs/developers/frontend-integration)
  * [CI/CD Guide](/docs/developers/ci-cd-guide)
  * [Hardhat Example](/docs/developers/examples/hardhat-example)
  * [Foundry Example](/docs/developers/examples/foundry-example)
  * [wagmi + Next.js Example](/docs/developers/examples/wagmi-example)
  * [ethers.js Example](/docs/developers/examples/ethers-example)
  * [Troubleshooting](/docs/developers/troubleshooting)
* **Validators**
  * [Node Deployment](/docs/validators/node-deployment)
  * [Ledger Sync Service](/docs/validators/ledger-sync-service)
  * [Monitoring & Metrics](/docs/validators/monitoring-and-metrics)
  * [Security Practices](/docs/validators/security-practices)
  * [Upgrade Procedures](/docs/validators/upgrade-procedures)
* **Network**
  * [Chain Parameters](/docs/network/chain-parameters)
  * [Tokenomics](/docs/network/tokenomics)
  * [Governance](/docs/network/governance)
  * [Roadmap](/docs/network/roadmap)
* **API Reference**
  * [REST API](/docs/api-reference/rest-api)
  * [REST OpenAPI Spec](https://github.com/KaJLabs/lithosphere/blob/main/docs/api-reference/openapi.yaml)
  * [GraphQL API](/docs/api-reference/graphql-api)
  * [GraphQL Schema](https://github.com/KaJLabs/lithosphere/blob/main/docs/api-reference/schema.graphql)
  * [SDK Reference](/docs/api-reference/sdk-reference)
* **Guides**
  * [Security Checklist](/docs/guides/security-checklist)
  * [Testing Best Practices](/docs/guides/testing-best-practices)
  * [Deployment Automation](/docs/guides/deployment-automation)
  * [Contributing](/docs/guides/contributing)
* **Governance**
  * [RFC Template](/docs/governance/rfc-template)
  * [Post-Incident Review Template](/docs/governance/pir-template)
  * [CAB Approvals](/docs/governance/cab)
  * [Key Rotation Runbook](/docs/governance/key-rotation-runbook)
  * [Release Process](/docs/governance/release-process)
  * [Observability Runbook](/docs/governance/observability)
  * [Deployment Approvals](/docs/governance/deployment-approvals)
  * [License Policy](/docs/governance/license-policy)
  * [Test Quarantine](/docs/governance/test-quarantine)
  * [RACI Matrix](/docs/governance/raci)
  * [Supply Chain Hardening](/docs/governance/supply-chain)
  * [Artifact Catalog](/docs/governance/artifact-catalog)
  * [Contract Deployment](/docs/governance/contract-deployment)
  * [Audit Trail](/docs/governance/audit-trail)
  * [Incident Response](/docs/governance/incident-response)
  * [Documentation Governance](/docs/governance/documentation)
  * [Release Calendar](/docs/governance/release-calendar)
  * [RFC 0001 — Release Trains](/docs/governance/rfcs/0001-release-trains)
* **Phase Completions**
  * [Overview](/docs/phases)
  * [Phase 6 — Test Strategy](/docs/phases/phase-6-completion)
  * [Phase 7 — Contract Tooling](/docs/phases/phase-7-completion)
  * [Phase 8 — SDKs & DX Portal](/docs/phases/phase-8-completion)
  * [Phase 9 — Observability](/docs/phases/phase-9-completion)


# .github


# PULL\_REQUEST\_TEMPLATE

### Summary

### Type of Change

* [ ] Feature (new functionality)
* [ ] Bug fix (non-breaking fix)
* [ ] Refactor (no functional change)
* [ ] Documentation
* [ ] Test
* [ ] CI/CD
* [ ] Dependencies

### Checklist

* [ ] Tests pass (`pnpm test`)
* [ ] Linting passes (`pnpm lint`)
* [ ] No breaking changes (or documented below)
* [ ] Documentation updated (if applicable)
* [ ] Follows [conventional commit](https://github.com/KaJLabs/lithosphere/blob/main/.github/docs/guides/contributing.md) convention

### Breaking Changes

N/A

### Related Issues


# GitHub Actions Secrets Configuration

This document describes the required GitHub Secrets for automated deployment.

## Required Secrets

Navigate to: **Settings** → **Secrets and variables** → **Actions** → **New repository secret**

### 1. SSH Connection Secrets

| Secret Name       | Description                       | Example                                                                                                                               |
| ----------------- | --------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
| `SSH_PRIVATE_KEY` | SSH private key for server access | <p><code>-----BEGIN OPENSSH PRIVATE KEY-----</code><br>Your private key content<br><code>-----END OPENSSH PRIVATE KEY-----</code></p> |
| `SERVER_IP`       | VPS/Server IP address             | `72.60.177.106`                                                                                                                       |
| `SERVER_USER`     | SSH username                      | `root`                                                                                                                                |

### 2. Application Configuration Secrets (Optional)

These can be added to the `.env` file on the server manually, or configured as secrets for automatic injection:

| Secret Name      | Description                  | Example                                            |
| ---------------- | ---------------------------- | -------------------------------------------------- |
| `DATABASE_URL`   | PostgreSQL connection string | `postgresql://user:pass@postgres:5432/lithosphere` |
| `LITHO_RPC_URL`  | Blockchain RPC endpoint      | `https://testnet-rpc.lithosphere.network`          |
| `LITHO_CHAIN_ID` | Chain ID                     | `61`                                               |

## Generating SSH Key Pair

If you don't have an SSH key pair, generate one:

```bash
# On your local machine
ssh-keygen -t ed25519 -C "github-actions-deploy" -f ~/.ssh/lithosphere_deploy

# Copy public key to server
ssh-copy-id -i ~/.ssh/lithosphere_deploy.pub root@72.60.177.106

# Copy private key content for GitHub Secret
cat ~/.ssh/lithosphere_deploy
# Copy the entire output including BEGIN and END lines
```

## Adding Secrets to GitHub

1. Go to your repository: <https://github.com/KaJLabs/lithosphere>
2. Click **Settings** → **Secrets and variables** → **Actions**
3. Click **New repository secret**
4. Add each secret:
   * **Name**: `SSH_PRIVATE_KEY`
   * **Value**: Paste your private key (entire content)
   * Click **Add secret**
5. Repeat for `SERVER_IP` and `SERVER_USER`

## Verifying Secrets

After adding secrets, you can trigger a deployment:

1. Go to **Actions** tab
2. Select **Deploy to VPS** workflow
3. Click **Run workflow**
4. Select environment (testnet/staging/mainnet)
5. Click **Run workflow**

The workflow will:

* Connect to your server via SSH
* Pull latest code from GitHub
* Build Docker images
* Deploy services
* Run health checks

## Deployment Workflow

The deployment happens automatically on:

* Push to `main` branch (changes in `Makalu/**`)
* Manual trigger via GitHub Actions UI

### Workflow Steps:

1. ✅ Checkout code
2. ✅ Setup SSH connection
3. ✅ Pull latest code on server
4. ✅ Build Docker images
5. ✅ Deploy services
6. ✅ Health checks
7. ✅ Rollback on failure

## Security Best Practices

* ✅ Never commit private keys to the repository
* ✅ Use SSH keys instead of passwords
* ✅ Rotate SSH keys periodically
* ✅ Use environment-specific secrets for staging/production
* ✅ Limit SSH key permissions to deployment user only
* ✅ Use read-only database credentials where possible

## Troubleshooting

### SSH Connection Failed

```
Permission denied (publickey)
```

**Solution**: Verify `SSH_PRIVATE_KEY` is correctly formatted with BEGIN/END lines

### Health Check Failed

```
API health check failed after 5 attempts
```

**Solution**: Check server logs: `ssh root@SERVER_IP "cd /opt/lithosphere/Makalu && docker compose logs api"`

### Build Failed

```
docker compose build failed
```

**Solution**: Check for syntax errors in Dockerfile or dependencies issues

## Manual Deployment

If automated deployment fails, deploy manually:

```bash
ssh root@72.60.177.106

cd /opt/lithosphere
git clone https://github.com/KaJLabs/lithosphere.git temp
cp -r temp/Makalu/* Makalu/
rm -rf temp

cd Makalu
docker compose build
docker compose up -d
docker compose ps
```


# Lithosphere Makalu Workspace

Makalu contains the developer-facing workspace used for Lithosphere GitHub developer-preview releases.

The preview release surface is intentionally small:

* `packages/create-litho-app`: official scaffolding CLI
* `templates/sdk-template`: packaged and released as `@lithosphere/sdk`
* `contracts/`: canonical contract artifacts bundled into GitHub prereleases

The rest of the workspace remains product and infrastructure source for the wider Lithosphere stack.

## Requirements

* Node.js 20.x
* pnpm 9.x

## Local Development

```bash
pnpm install --frozen-lockfile
pnpm build
pnpm test
```

## Developer Preview Packaging

```bash
pnpm --filter create-litho-app build
pnpm --filter @lithosphere/sdk build
pnpm --filter @lithosphere/sdk test
pnpm --dir contracts compile
```

## Packages And Templates

* `packages/create-litho-app`: scaffolds contracts, service, and SDK starter projects
* `templates/contracts-template`: Hardhat + Foundry starter with deploy and verification scripts
* `templates/sdk-template`: TypeScript SDK library template released as the preview SDK package
* `templates/service-template`: Fastify service starter used by the CLI

## Notes

* The workspace does not currently contain a standalone Lithic compiler package.
* GitHub prereleases are the supported external distribution channel for this preview. Public npm publishing can follow after the preview hardening phase.

## License

MIT. See `../LICENSE`.


# Lithosphere Monorepo Structure

## Overview

The repository has been reorganized into a clean monorepo structure that separates documentation from product code.

## New Structure

```
lithosphere/
├── packages/
│   ├── blockchain-core/          # Core blockchain implementation
│   │   ├── src/
│   │   │   ├── contracts/        # Smart contracts (LEP100, DeFi, etc.)
│   │   │   ├── sdk/              # TypeScript/JavaScript SDK
│   │   │   ├── chain/            # Blockchain core implementation
│   │   │   ├── consensus/        # Linear Communication BFT
│   │   │   ├── crypto/           # MDKM, ring signatures, etc.
│   │   │   └── index.ts          # Main entry point
│   │   ├── test/                 # Test files
│   │   ├── package.json
│   │   ├── tsconfig.json
│   │   └── README.md
│   │
│   └── docs/                     # All documentation
│       ├── documentation/        # Whitepaper, technical specs
│       ├── locked-account-generation-scheme/
│       ├── current-lithosphere-features/
│       ├── litho-chain/
│       ├── .gitbook/
│       ├── *.md files           # All markdown documentation
│       ├── *.pdf files          # PDF documents
│       ├── package.json
│       └── README.md
│
├── apps/                         # (Future) Application packages
├── infra/                        # (Future) Infrastructure as Code
├── tooling/                      # (Future) Build tooling
│
├── .github/                      # GitHub workflows
├── package.json                  # Root package configuration
├── pnpm-workspace.yaml          # Workspace configuration
├── turbo.json                   # Turborepo configuration
├── tsconfig.json                # Root TypeScript config
├── .eslintrc.js                 # ESLint configuration
├── .prettierrc                  # Prettier configuration
├── .gitignore                   # Git ignore rules
└── README.md                    # Main README
```

## Packages

### @lithosphere/blockchain-core

**Location**: `packages/blockchain-core/`

Core blockchain implementation containing:

* Smart contracts (LEP100 token standard, DeFi protocols)
* TypeScript/JavaScript SDK for developers
* Blockchain core implementation
* Consensus mechanism (Linear Communication BFT)
* Cryptographic utilities (MDKM, ring signatures, threshold signatures)

**Status**: Scaffold created, ready for implementation

**Key directories**:

* `src/contracts/` - Smart contract implementations
* `src/sdk/` - Developer SDK
* `src/chain/` - Core blockchain logic
* `src/consensus/` - Consensus mechanism
* `src/crypto/` - Cryptographic utilities

### @lithosphere/docs

**Location**: `packages/docs/`

Comprehensive documentation including:

* Whitepaper and technical specifications
* LEP100 token standard documentation
* Architecture and design documents
* Smart contract guides
* API documentation

**Status**: All existing documentation migrated

## Development Workflow

### Installation

```bash
pnpm install
```

### Build all packages

```bash
pnpm build
```

### Run tests

```bash
pnpm test
```

### Lint and format

```bash
pnpm lint
pnpm format
```

### Work on specific package

```bash
# Navigate to package
cd packages/blockchain-core

# Run package-specific commands
pnpm build
pnpm test
```

## Workspace Configuration

The monorepo uses:

* **pnpm workspaces** for package management
* **Turborepo** for build orchestration
* **TypeScript** for type safety
* **ESLint + Prettier** for code quality

## Next Steps

### For Product Development

1. **Implement Smart Contracts** (`packages/blockchain-core/src/contracts/`)
   * LEP100 token standard
   * DeFi protocols
   * Governance contracts
2. **Build SDK** (`packages/blockchain-core/src/sdk/`)
   * Blockchain client
   * Wallet integration
   * Transaction builders
3. **Develop Chain Logic** (`packages/blockchain-core/src/chain/`)
   * Block structures
   * Transaction handling
   * State management
4. **Implement Consensus** (`packages/blockchain-core/src/consensus/`)
   * Linear Communication BFT
   * Validator management
   * Block production
5. **Add Cryptography** (`packages/blockchain-core/src/crypto/`)
   * MDKM implementation
   * Ring signatures
   * Threshold signatures

### For Infrastructure

* Add application packages to `apps/`
* Add infrastructure code to `infra/`
* Add shared tooling to `tooling/`

## Migration Summary

### Files Moved

* ✅ All `.md` files → `packages/docs/`
* ✅ `documentation/` folder → `packages/docs/documentation/`
* ✅ `locked-account-generation-scheme/` → `packages/docs/locked-account-generation-scheme/`
* ✅ `current-lithosphere-features/` → `packages/docs/current-lithosphere-features/`
* ✅ `litho-chain/` → `packages/docs/litho-chain/`
* ✅ `.gitbook/` → `packages/docs/.gitbook/`
* ✅ PDF and DOCX files → `packages/docs/`

### Files Created

* ✅ `packages/blockchain-core/package.json`
* ✅ `packages/blockchain-core/tsconfig.json`
* ✅ `packages/blockchain-core/README.md`
* ✅ `packages/blockchain-core/src/` structure
* ✅ `packages/docs/package.json`
* ✅ `packages/docs/README.md`
* ✅ Root `.gitignore`
* ✅ Updated root `README.md`

### Configuration Updated

* ✅ `pnpm-workspace.yaml` - Already configured for packages structure
* ✅ `package.json` - Root configuration maintained
* ✅ `turbo.json` - Build configuration ready

## Benefits

1. **Clear Separation**: Documentation and code are cleanly separated
2. **Scalability**: Easy to add new packages (smart contracts, SDKs, apps)
3. **Developer Experience**: Clear structure, fast builds with Turborepo
4. **Maintainability**: Each package has its own dependencies and configuration
5. **CI/CD Ready**: Turborepo enables efficient incremental builds

## Resources

* [pnpm Workspaces Documentation](https://pnpm.io/workspaces)
* [Turborepo Documentation](https://turbo.build/repo/docs)
* [TypeScript Project References](https://www.typescriptlang.org/docs/handbook/project-references.html)


# Lithosphere Infrastructure Configuration

This directory contains all infrastructure-related configuration files for the Lithosphere Makalu deployment.

## Directory Structure

```
infra/
├── alertmanager/          # Alertmanager configuration
│   └── alertmanager-config.yaml
│
├── grafana/               # Grafana provisioning & dashboards
│   ├── provisioning/
│   │   ├── datasources/
│   │   │   └── datasources.yaml
│   │   └── dashboards/
│   │       └── dashboards.yaml
│   └── dashboards/
│       ├── system-overview.json
│       ├── api-monitoring.json
│       └── container-metrics.json
│
├── k8s/                   # Kubernetes manifests (future)
│   └── base/
│       └── kustomization.yaml
│
├── loki/                  # Loki log aggregation
│   └── loki-config.yaml
│
├── postgres/              # PostgreSQL initialization
│   └── init.sql
│
├── prometheus/            # Prometheus metrics & alerts
│   ├── prometheus.yml
│   └── alerts/
│       └── lithosphere-alerts.yml
│
└── promtail/              # Promtail log collection
    └── promtail-config.yaml
```

## Configuration Files

### Alertmanager

**File**: `alertmanager/alertmanager-config.yaml`

Handles alert routing and notifications. Currently configured with console output.

**To enable Slack notifications:**

1. Create a Slack webhook URL
2. Uncomment the `slack_configs` section
3. Add your webhook URL
4. Restart Alertmanager

**To enable email notifications:**

1. Configure SMTP settings in the `global` section
2. Uncomment email receivers
3. Restart Alertmanager

### Grafana

**Provisioning**: `grafana/provisioning/`

* Automatically configures datasources (Prometheus, Loki)
* Loads dashboards from `grafana/dashboards/`

**Pre-configured Dashboards**:

1. **System Overview** - VPS health (CPU, RAM, Disk, Network)
2. **API Monitoring** - Request rates, latencies, errors, logs
3. **Container Metrics** - Docker container resource usage

**Custom Dashboards**:

* Create JSON files in `grafana/dashboards/`
* They will be auto-loaded on Grafana restart

### Loki

**File**: `loki/loki-config.yaml`

Log aggregation and storage configuration.

**Key Settings**:

* **Retention**: 30 days (720 hours)
* **Max ingestion rate**: 4 MB/s
* **Storage**: Filesystem (`/loki`)

**To adjust retention**:

```yaml
limits_config:
  retention_period: 360h  # 15 days instead of 30
```

### Prometheus

**File**: `prometheus/prometheus.yml`

Metrics collection and scrape configuration.

**Monitored Targets**:

* Lithosphere API (port 9090)
* Lithosphere Indexer (port 9090)
* Node Exporter (port 9100) - VPS metrics
* cAdvisor (port 8080) - Container metrics
* Docker containers with `prometheus.scrape=true` label

**Alert Rules**: `prometheus/alerts/lithosphere-alerts.yml`

Defines alert conditions for:

* Service health (API down, Indexer down, DB down)
* Performance issues (high latency, error rates)
* Resource usage (CPU, memory, disk)
* Container issues (restarts, high resource usage)

**To add custom alerts**:

1. Edit `lithosphere-alerts.yml`
2. Follow Prometheus alert syntax
3. Reload Prometheus: `curl -X POST http://localhost:9091/-/reload`

### Promtail

**File**: `promtail/promtail-config.yaml`

Log collection agent that ships logs to Loki.

**Log Sources**:

* Docker container logs (`/var/lib/docker/containers`)
* System logs (`/var/log/syslog`)
* Auto-discovered containers with monitoring labels

**Pipeline**:

1. Collects logs from sources
2. Parses JSON logs
3. Extracts labels (service, environment, level)
4. Ships to Loki

### PostgreSQL

**File**: `postgres/init.sql`

Database initialization script.

**Creates**:

* Required extensions (uuid-ossp, pg\_trgm)
* `transfers` table for LEP-100 events
* `blocks` table for block metadata
* Indexes for query optimization

### Kubernetes (Future)

**Directory**: `k8s/`

Placeholder for Kubernetes manifests when deploying to K8s clusters.

***

## Environment Variables

Many configurations can be overridden with environment variables:

```bash
# Grafana
GRAFANA_PORT=3000
GRAFANA_USER=admin
GRAFANA_PASSWORD=lithosphere

# Prometheus
PROMETHEUS_PORT=9091

# Database
DATABASE_URL=postgresql://user:pass@host:5432/db

# API
API_PORT=4000
LITHO_RPC_URL=https://testnet-rpc.lithosphere.network
LITHO_CHAIN_ID=61
```

Set these in `.env` file or export them before running Docker Compose.

***

## Maintenance

### Updating Configurations

After modifying any config file:

```bash
# For Prometheus (supports hot-reload)
curl -X POST http://localhost:9091/-/reload

# For other services, restart the specific container
docker compose restart SERVICE_NAME

# Or restart the entire monitoring stack
docker compose -f docker-compose.yaml -f docker-compose.monitoring.yaml restart
```

### Backup Configurations

```bash
# Backup all configs
tar czf infra-backup-$(date +%Y%m%d).tar.gz infra/

# Restore from backup
tar xzf infra-backup-YYYYMMDD.tar.gz
```

### Volume Management

Monitoring data is stored in Docker volumes:

```bash
# List volumes
docker volume ls | grep lithosphere

# Inspect a volume
docker volume inspect lithosphere_prometheus-data

# Backup a volume
docker run --rm -v lithosphere_prometheus-data:/data -v $(pwd):/backup \
  alpine tar czf /backup/prometheus-data.tar.gz /data

# Restore a volume
docker run --rm -v lithosphere_prometheus-data:/data -v $(pwd):/backup \
  alpine tar xzf /backup/prometheus-data.tar.gz -C /
```

***

## Security Considerations

### 1. Network Exposure

By default, monitoring services are exposed on all interfaces. In production:

**Option A**: Use firewall rules

```bash
# Allow only from specific IP
ufw allow from YOUR_IP to any port 3000  # Grafana
ufw allow from YOUR_IP to any port 9091  # Prometheus
```

**Option B**: Bind to localhost only

```yaml
# In docker-compose.monitoring.yaml
grafana:
  ports:
    - "127.0.0.1:3000:3000"  # Only accessible locally
prometheus:
  ports:
    - "127.0.0.1:9091:9090"  # Only accessible locally
```

### 2. Grafana Authentication

Change default password immediately:

```bash
# Via Grafana UI: User → Change Password

# Or via Docker CLI:
docker compose exec grafana grafana-cli admin reset-admin-password NEW_PASSWORD
```

### 3. Alertmanager Secrets

Never commit credentials to version control:

```yaml
# Use environment variables
global:
  smtp_auth_password: ${SMTP_PASSWORD}

# Or use Docker secrets (Swarm mode)
secrets:
  smtp_password:
    external: true
```

***

## Troubleshooting

### Issue: Configuration not loading

```bash
# Check config syntax
docker compose config

# View container logs
docker compose logs SERVICE_NAME

# Validate specific configs
docker compose exec prometheus promtool check config /etc/prometheus/prometheus.yml
```

### Issue: Dashboards not appearing in Grafana

1. Check provisioning path is correct
2. Verify JSON syntax: `jq . dashboard.json`
3. Check Grafana logs: `docker compose logs grafana`
4. Restart Grafana: `docker compose restart grafana`

### Issue: Alerts not firing

1. Check alert rule syntax in Prometheus UI
2. Verify Alertmanager is configured in `prometheus.yml`
3. Test alert: `curl http://localhost:9091/api/v1/rules`
4. Check Alertmanager: `curl http://localhost:9093/api/v2/alerts`

***

## Performance Tuning

### Reduce Disk Usage

```yaml
# Prometheus - Reduce retention
prometheus:
  command:
    - '--storage.tsdb.retention.time=7d'

# Loki - Reduce retention
# Edit loki-config.yaml
limits_config:
  retention_period: 168h  # 7 days
```

### Reduce Memory Usage

```yaml
# Limit container memory
prometheus:
  deploy:
    resources:
      limits:
        memory: 512M

loki:
  deploy:
    resources:
      limits:
        memory: 256M
```

### Optimize Scrape Intervals

```yaml
# Prometheus - Increase scrape interval
global:
  scrape_interval: 30s  # From 15s

# Or per-job
scrape_configs:
  - job_name: 'litho-indexer'
    scrape_interval: 60s  # Less critical service
```

***

## Additional Resources

* [Prometheus Documentation](https://prometheus.io/docs/)
* [Grafana Documentation](https://grafana.com/docs/)
* [Loki Documentation](https://grafana.com/docs/loki/)
* [Alertmanager Guide](https://prometheus.io/docs/alerting/latest/alertmanager/)
* [PromQL Tutorial](https://prometheus.io/docs/prometheus/latest/querying/basics/)
* [LogQL Guide](https://grafana.com/docs/loki/latest/query/)


# docs


# architecture


# ADR-001: Environment Strategy

## Status

**Accepted**

## Date

2024-12-13

## Context

The Lithosphere L1 Blockchain Developer Infrastructure requires a multi-environment deployment strategy that supports the full software development lifecycle. The environments must accommodate:

1. **Developer Experience**: Fast feedback loops during local development
2. **Continuous Integration**: Ephemeral environments for automated testing
3. **Quality Assurance**: Persistent testnet for integration and UAT
4. **Production Safety**: Controlled mainnet deployments with approval gates

The platform follows a GitOps model with ArgoCD, requiring clear environment separation and promotion paths.

***

## Decision

We adopt a **4-environment strategy** aligned with blockchain development best practices:

| Environment | Purpose                  | Persistence | Cluster                |
| ----------- | ------------------------ | ----------- | ---------------------- |
| **Local**   | Developer workstation    | Ephemeral   | Docker Compose         |
| **Devnet**  | CI/CD automated testing  | Ephemeral   | Kubernetes (shared)    |
| **Staging** | Persistent testnet / UAT | Persistent  | Kubernetes (dedicated) |
| **Mainnet** | Production               | Persistent  | Kubernetes (dedicated) |

***

## Environment Specifications

### 1. Local Environment

| Attribute               | Specification                                         |
| ----------------------- | ----------------------------------------------------- |
| **Purpose**             | Individual developer testing and debugging            |
| **Trigger**             | Manual (`docker-compose up`)                          |
| **Data Source**         | Mock data OR Chain fork (configurable via `FORK_URL`) |
| **Deployment Strategy** | Manual, instant hot-reload                            |
| **Key Tools**           | Docker Compose, Hardhat Network, Local PostgreSQL     |
| **Node Type**           | Hardhat Node with forking capability                  |
| **Lifecycle**           | Created/destroyed per developer session               |

**Configuration:**

```yaml
# docker/local/.env
FORK_URL=https://mainnet.lithosphere.network/rpc
FORK_BLOCK_NUMBER=latest
LOCAL_RPC_PORT=8545
POSTGRES_HOST=localhost
REDIS_HOST=localhost
```

**Capabilities:**

* Hot-reload for API and frontend changes
* Contract deployment with instant mining
* Mainnet state forking for realistic testing
* Full observability stack (Grafana, Prometheus)

***

### 2. Devnet Environment (CI/CD Ephemeral)

| Attribute               | Specification                               |
| ----------------------- | ------------------------------------------- |
| **Purpose**             | Automated CI/CD testing, PR validation      |
| **Trigger**             | Push to `main` branch, Pull Request opened  |
| **Data Source**         | Seeded test fixtures (deterministic)        |
| **Deployment Strategy** | Automatic, no approval required             |
| **Key Tools**           | Kubernetes, Helm, GitHub Actions            |
| **Node Type**           | Ephemeral Lithosphere testnet node          |
| **Lifecycle**           | Created per CI run, destroyed after 24h max |

**GitOps Configuration:**

```yaml
# clusters/devnet/argocd/application.yaml
spec:
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
  source:
    targetRevision: main
```

**CI/CD Pipeline:**

```
┌─────────────┐    ┌─────────────┐    ┌─────────────┐    ┌─────────────┐
│  Git Push   │───▶│  CI Build   │───▶│  Sign/Push  │───▶│ ArgoCD Sync │
│  (main)     │    │  & Test     │    │  Artifacts  │    │  (Devnet)   │
└─────────────┘    └─────────────┘    └─────────────┘    └─────────────┘
```

**Resource Limits:**

* Max 2 concurrent devnet deployments
* Auto-cleanup after 24 hours
* Shared Kubernetes namespace: `lithosphere-devnet`

***

### 3. Staging Environment (Persistent Testnet)

| Attribute               | Specification                                |
| ----------------------- | -------------------------------------------- |
| **Purpose**             | Integration testing, UAT, partner testing    |
| **Trigger**             | Merge to `release/*` branch                  |
| **Data Source**         | Testnet chain with historical data preserved |
| **Deployment Strategy** | Automatic with smoke tests                   |
| **Key Tools**           | Kubernetes, Helm, ArgoCD, Vault              |
| **Node Type**           | Full Lithosphere testnet node (persistent)   |
| **Lifecycle**           | Persistent, data retained across deployments |

**GitOps Configuration:**

```yaml
# clusters/staging/argocd/application.yaml
spec:
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
  source:
    targetRevision: release/*
```

**Promotion Criteria:**

* [ ] All CI tests passing
* [ ] Security scan (Slither) clean
* [ ] Docker image signed
* [ ] Contract artifacts verified

**Data Management:**

* PostgreSQL: Daily snapshots retained 30 days
* Chain data: Weekly snapshots retained 90 days
* Indexer: Continuous sync with testnet

***

### 4. Mainnet Environment (Production)

| Attribute               | Specification                                   |
| ----------------------- | ----------------------------------------------- |
| **Purpose**             | Production deployment, real user traffic        |
| **Trigger**             | Git tag matching `v*.*.*` (semantic versioning) |
| **Data Source**         | Production Lithosphere mainnet                  |
| **Deployment Strategy** | **Manual approval required** (CODEOWNERS)       |
| **Key Tools**           | Kubernetes, Helm, ArgoCD, Vault, PagerDuty      |
| **Node Type**           | Full Lithosphere mainnet node (HA)              |
| **Lifecycle**           | Persistent, zero-downtime deployments           |

**GitOps Configuration:**

```yaml
# clusters/mainnet/argocd/application.yaml
spec:
  syncPolicy:
    # NO automated sync - requires manual approval
  source:
    targetRevision: HEAD  # Tags only
```

**Deployment Gate:**

```
┌─────────────┐    ┌─────────────┐    ┌─────────────┐    ┌─────────────┐
│  Git Tag    │───▶│  CI Build   │───▶│  Approval   │───▶│ ArgoCD Sync │
│  (v1.2.3)   │    │  & Sign     │    │  (CODEOWNER)│    │  (Mainnet)  │
└─────────────┘    └─────────────┘    └─────────────┘    └─────────────┘
```

**High Availability:**

* Multi-AZ deployment (3 availability zones)
* Database: RDS Multi-AZ with read replicas
* Node: 3 Lithosphere nodes behind load balancer
* CDN: CloudFront for frontend assets

**Rollback Strategy:**

* ArgoCD automatic rollback on health check failure
* Manual rollback via `argocd app rollback`
* Database: Point-in-time recovery (PITR) enabled

***

## Environment Comparison Matrix

| Aspect          | Local         | Devnet         | Staging        | Mainnet               |
| --------------- | ------------- | -------------- | -------------- | --------------------- |
| **Trigger**     | Manual        | Push/PR        | Release branch | Git tag `v*`          |
| **Approval**    | None          | None           | None           | CODEOWNER             |
| **Persistence** | Session       | 24h max        | Permanent      | Permanent             |
| **Data**        | Mock/Fork     | Fixtures       | Testnet        | Production            |
| **HA**          | No            | No             | Yes            | Yes (Multi-AZ)        |
| **Secrets**     | `.env` file   | GitHub Secrets | Vault          | Vault                 |
| **Monitoring**  | Local Grafana | Shared Grafana | Dedicated      | Dedicated + PagerDuty |
| **Cost**        | $0            | Low            | Medium         | High                  |

***

## Promotion Flow

```
        ┌─────────────────────────────────────────────────────────┐
        │                  PROMOTION PIPELINE                      │
        └─────────────────────────────────────────────────────────┘
        
        ┌─────────┐         ┌─────────┐         ┌─────────┐
        │  LOCAL  │────────▶│ DEVNET  │────────▶│ STAGING │
        │         │  push   │         │  merge  │         │
        └─────────┘         └─────────┘         └─────────┘
                                                     │
                                                     │ git tag
                                                     ▼
                                                ┌─────────┐
                                                │ MAINNET │
                                                │         │
                                                └─────────┘
```

***

## Consequences

### Positive

* Clear separation of concerns between environments
* Automated testing in devnet reduces manual QA burden
* Persistent staging enables long-running integration tests
* Mainnet approval gates prevent accidental deployments
* GitOps provides full audit trail of all changes

### Negative

* Increased infrastructure cost (multiple clusters)
* Complexity in managing environment-specific configurations
* Potential for environment drift if not properly monitored

### Mitigations

* Use Kustomize overlays to minimize configuration drift
* Implement automated environment parity checks
* Regular cost reviews and right-sizing

***

## References

* [12-Factor App: Dev/Prod Parity](https://12factor.net/dev-prod-parity)
* [GitOps Principles](https://opengitops.dev/)
* [ArgoCD Best Practices](https://argo-cd.readthedocs.io/en/stable/user-guide/best_practices/)
* [SLSA Supply Chain Security](https://slsa.dev/)


# ADR-002: Technology Stack - Bill of Materials

## Status

**Accepted**

## Date

2024-12-13

## Context

The Lithosphere L1 Blockchain Developer Infrastructure requires a well-defined technology stack that supports:

1. **Developer Experience**: Fast builds, hot-reload, comprehensive tooling
2. **Security**: Supply chain security, signed artifacts, secret management
3. **Observability**: Full-stack monitoring, logging, and alerting
4. **Scalability**: Kubernetes-native, horizontally scalable components
5. **GitOps**: Infrastructure as Code, declarative deployments

This document serves as the authoritative "Bill of Materials" for all infrastructure components.

***

## Decision

We adopt the following technology stack, organized by functional domain:

***

## 1. CI/CD Pipeline

### Primary: GitHub Actions

| Component       | Tool                                  | Version | Purpose                  |
| --------------- | ------------------------------------- | ------- | ------------------------ |
| CI Orchestrator | GitHub Actions                        | N/A     | Workflow orchestration   |
| Build Cache     | actions/cache                         | v4      | npm/Docker layer caching |
| Node.js         | actions/setup-node                    | v4      | Node.js 20 LTS           |
| Docker Build    | docker/build-push-action              | v5      | Multi-platform builds    |
| OIDC Auth       | aws-actions/configure-aws-credentials | v4      | Keyless AWS auth         |

**Workflow Structure:**

```
.github/workflows/
├── ci.yaml              # Lint, test, security scan (all branches)
├── build.yaml           # Docker build & push (main branch)
├── contracts.yaml       # Compile, test, audit contracts
├── deploy-devnet.yaml   # Auto-deploy to devnet
├── deploy-staging.yaml  # Deploy to staging (release branches)
└── deploy-mainnet.yaml  # Deploy to mainnet (tags, with approval)
```

**Security Features:**

* OIDC authentication (no long-lived credentials)
* Branch protection rules enforced
* Required status checks before merge
* Signed commits required for mainnet

***

## 2. GitOps & Deployment

### Primary: ArgoCD

| Component         | Tool                 | Version | Purpose                    |
| ----------------- | -------------------- | ------- | -------------------------- |
| GitOps Controller | ArgoCD               | v2.9+   | Kubernetes deployment sync |
| Config Management | Kustomize            | v5.0+   | Environment overlays       |
| Helm Charts       | Helm                 | v3.13+  | Package management         |
| Image Updater     | ArgoCD Image Updater | v0.12+  | Automatic image updates    |

**ArgoCD Configuration:**

```yaml
# Application-of-Applications pattern
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: lithosphere-environments
spec:
  generators:
    - list:
        elements:
          - env: devnet
            autoSync: true
          - env: staging
            autoSync: true
          - env: mainnet
            autoSync: false  # Manual approval
```

**Sync Policies:**

| Environment | Auto-Sync | Self-Heal | Prune |
| ----------- | --------- | --------- | ----- |
| Devnet      | Yes       | Yes       | Yes   |
| Staging     | Yes       | Yes       | Yes   |
| Mainnet     | **No**    | No        | No    |

***

## 3. Infrastructure as Code (IaC)

### Primary: Terraform / OpenTofu

| Component     | Tool                     | Version | Purpose                     |
| ------------- | ------------------------ | ------- | --------------------------- |
| IaC Engine    | Terraform                | v1.6+   | Infrastructure provisioning |
| Alternative   | OpenTofu                 | v1.6+   | BSL-free alternative        |
| State Backend | S3 + DynamoDB            | N/A     | Remote state with locking   |
| Secrets       | Terraform Vault Provider | v3.0+   | Secret injection            |

**Module Structure:**

```
infra/terraform/
├── modules/
│   ├── vpc/              # Network infrastructure
│   ├── eks/              # Kubernetes cluster
│   ├── rds/              # PostgreSQL databases
│   ├── elasticache/      # Redis clusters
│   ├── s3/               # Object storage
│   ├── iam/              # IAM roles & policies
│   └── security-groups/  # Network security
└── environments/
    ├── devnet/           # terraform.tfvars for devnet
    ├── staging/          # terraform.tfvars for staging
    └── mainnet/          # terraform.tfvars for mainnet
```

**State Management:**

```hcl
terraform {
  backend "s3" {
    bucket         = "lithosphere-terraform-state"
    key            = "environments/${var.environment}/terraform.tfstate"
    region         = "us-east-1"
    encrypt        = true
    dynamodb_table = "lithosphere-terraform-locks"
  }
}
```

***

## 4. Observability Stack

### Metrics: Prometheus + Grafana

| Component          | Tool                   | Version | Purpose               |
| ------------------ | ---------------------- | ------- | --------------------- |
| Metrics Collection | Prometheus             | v2.47+  | Time-series metrics   |
| Visualization      | Grafana                | v10.0+  | Dashboards & alerting |
| Kubernetes Metrics | kube-prometheus-stack  | v54+    | Full K8s monitoring   |
| Custom Metrics     | Prometheus Pushgateway | v1.6+   | Job metrics           |

### Logging: Loki + Promtail

| Component       | Tool         | Version | Purpose              |
| --------------- | ------------ | ------- | -------------------- |
| Log Aggregation | Grafana Loki | v2.9+   | Log storage & query  |
| Log Shipping    | Promtail     | v2.9+   | Log collection agent |
| Log Parsing     | Fluent Bit   | v2.2+   | Advanced parsing     |

### Tracing: OpenTelemetry

| Component | Tool             | Version | Purpose                     |
| --------- | ---------------- | ------- | --------------------------- |
| SDK       | OpenTelemetry JS | v1.18+  | Application instrumentation |
| Collector | OTel Collector   | v0.88+  | Trace collection            |
| Backend   | Grafana Tempo    | v2.3+   | Trace storage               |

### Alerting

| Component     | Tool                    | Version | Purpose            |
| ------------- | ----------------------- | ------- | ------------------ |
| Alert Manager | Prometheus Alertmanager | v0.26+  | Alert routing      |
| Incident Mgmt | PagerDuty               | N/A     | On-call escalation |
| Status Page   | Atlassian Statuspage    | N/A     | Public status      |

**Dashboard Structure:**

```
Grafana Dashboards/
├── infrastructure/
│   ├── kubernetes-cluster.json
│   ├── node-resources.json
│   └── network-traffic.json
├── application/
│   ├── api-gateway.json
│   ├── frontend-performance.json
│   └── indexer-sync.json
└── blockchain/
    ├── lithosphere-node.json
    ├── transaction-metrics.json
    └── contract-events.json
```

***

## 5. Smart Contract Tooling

### Hybrid: Hardhat + Foundry

| Component    | Tool                 | Version | Purpose                       |
| ------------ | -------------------- | ------- | ----------------------------- |
| Development  | Hardhat              | v2.19+  | TypeScript-native development |
| Testing      | Foundry (Forge)      | latest  | Fast fuzz testing             |
| Deployment   | Hardhat Ignition     | v0.15+  | Declarative deployments       |
| Gas Analysis | hardhat-gas-reporter | v1.0+   | Gas optimization              |

### Security Auditing

| Component       | Tool    | Version | Purpose                        |
| --------------- | ------- | ------- | ------------------------------ |
| Static Analysis | Slither | v0.10+  | Vulnerability detection        |
| Symbolic Exec   | Mythril | v0.24+  | Deep analysis                  |
| Fuzzing         | Echidna | v2.2+   | Property-based testing         |
| Formal Verify   | Certora | N/A     | Formal verification (optional) |

**Contract CI Pipeline:**

```yaml
contract-audit:
  steps:
    - hardhat compile
    - hardhat test --parallel
    - forge test --fuzz-runs 10000
    - slither . --sarif output.sarif
    - mythril analyze contracts/*.sol
```

***

## 6. Security & Secrets Management

### Primary: HashiCorp Vault

| Component       | Tool                 | Version | Purpose                   |
| --------------- | -------------------- | ------- | ------------------------- |
| Secret Store    | HashiCorp Vault      | v1.15+  | Centralized secrets       |
| K8s Integration | Vault Agent Injector | v1.3+   | Pod secret injection      |
| Dynamic Secrets | Vault AWS Engine     | N/A     | Temporary AWS credentials |
| PKI             | Vault PKI Engine     | N/A     | Certificate management    |

**Secret Hierarchy:**

```
vault/
├── secret/lithosphere/
│   ├── devnet/
│   │   ├── database
│   │   ├── api-keys
│   │   └── rpc-endpoints
│   ├── staging/
│   │   └── ...
│   └── mainnet/
│       └── ...
└── pki/lithosphere/
    ├── root-ca
    └── intermediate-ca
```

### Supply Chain Security

| Component          | Tool            | Version | Purpose           |
| ------------------ | --------------- | ------- | ----------------- |
| Image Signing      | Sigstore Cosign | v2.2+   | Container signing |
| SBOM               | Syft            | v0.100+ | Bill of materials |
| Vulnerability Scan | Trivy           | v0.48+  | CVE scanning      |
| Attestation        | in-toto         | v1.0+   | SLSA provenance   |

***

## 7. Container & Orchestration

### Primary: Kubernetes (EKS)

| Component    | Tool          | Version | Purpose              |
| ------------ | ------------- | ------- | -------------------- |
| Managed K8s  | AWS EKS       | v1.28+  | Kubernetes cluster   |
| Ingress      | NGINX Ingress | v1.9+   | HTTP routing         |
| Service Mesh | Istio         | v1.20+  | mTLS, traffic mgmt   |
| Autoscaling  | KEDA          | v2.12+  | Event-driven scaling |

### Local Development

| Component | Tool           | Version | Purpose             |
| --------- | -------------- | ------- | ------------------- |
| Local K8s | Docker Desktop | latest  | Development cluster |
| Compose   | Docker Compose | v2.23+  | Multi-container dev |
| K8s Dev   | Tilt           | v0.33+  | Hot-reload for K8s  |

***

## 8. Database & Storage

| Component     | Tool          | Version | Purpose             |
| ------------- | ------------- | ------- | ------------------- |
| Primary DB    | PostgreSQL    | v15+    | Application data    |
| Cache         | Redis         | v7+     | Session/cache layer |
| Object Store  | AWS S3        | N/A     | Artifacts, backups  |
| Block Storage | AWS EBS (gp3) | N/A     | Persistent volumes  |

***

## 9. Application Stack (Existing)

| Component   | Tool          | Version  | Purpose             |
| ----------- | ------------- | -------- | ------------------- |
| Frontend    | Next.js       | v14+     | React SSR framework |
| API Gateway | Apollo Server | v4+      | GraphQL gateway     |
| Indexer     | SubQuery      | v3+      | Blockchain indexing |
| Contracts   | Solidity      | v0.8.20+ | Smart contracts     |

***

## Version Pinning Strategy

| Category       | Strategy          | Example              |
| -------------- | ----------------- | -------------------- |
| Infrastructure | Minor version pin | `terraform ~> 1.6.0` |
| Runtime        | LTS versions      | Node.js 20 LTS       |
| Security       | Latest stable     | Trivy latest         |
| Contracts      | Exact version     | Solidity 0.8.20      |

***

## Dependency Update Policy

| Frequency | Scope            | Automation    |
| --------- | ---------------- | ------------- |
| Weekly    | Security patches | Dependabot    |
| Monthly   | Minor versions   | Manual review |
| Quarterly | Major versions   | RFC required  |

***

## Consequences

### Positive

* Industry-standard tooling with strong community support
* Comprehensive observability from day one
* Security-first approach with SLSA compliance path
* GitOps enables full audit trail and rollback capability

### Negative

* Learning curve for teams unfamiliar with Kubernetes/ArgoCD
* Infrastructure cost for running full observability stack
* Complexity in managing multiple tools

### Mitigations

* Provide training and runbooks for all tools
* Start with managed services (EKS, RDS) to reduce operational burden
* Implement cost monitoring from day one

***

## References

* [CNCF Landscape](https://landscape.cncf.io/)
* [SLSA Security Levels](https://slsa.dev/spec/v1.0/levels)
* [Hardhat Documentation](https://hardhat.org/docs)
* [Foundry Book](https://book.getfoundry.sh/)
* [ArgoCD User Guide](https://argo-cd.readthedocs.io/)
* [HashiCorp Vault](https://developer.hashicorp.com/vault)


# ADR-003: Promotion Gates — Makalu Testnet

## Status

**Accepted**

## Date

2026-03-06

## Context

Lithosphere Makalu testnet runs on EC2 + Docker Compose (not K8s/ArgoCD). This document defines the **actual** promotion flow and deployment gates in use today, replacing the aspirational K8s-based flow in [ADR-001](/makalu/docs/architecture/001-environment-strategy).

***

## Promotion Flow

```
LOCAL                  TESTNET (Makalu)              MAINNET
docker compose up  -->  push to main            -->  workflow_dispatch
                        deploy-simple.yaml           deploy.yaml (SLSA)
                        auto-deploy via SSH           manual trigger + approval
```

***

## Gate Definitions

### Gate 1: Local -> Testnet

| Criterion               | Enforced By              | Blocking?        |
| ----------------------- | ------------------------ | ---------------- |
| CI passes (lint, build) | `ci.yaml` status check   | Yes              |
| Gitleaks secret scan    | `ci.yaml`                | Yes              |
| CODEOWNERS review       | GitHub branch protection | Yes (1 approval) |
| Code merged to `main`   | GitHub PR merge          | Yes              |

**Trigger:** Push/merge to `main` branch. **Pipeline:** `.github/workflows/deploy-simple.yaml` — SSH via bastion to EC2, `docker compose up -d --build --remove-orphans`.

### Gate 2: Testnet -> Mainnet

| Criterion                 | Enforced By                          | Blocking? |
| ------------------------- | ------------------------------------ | --------- |
| All Gate 1 criteria       | CI + branch protection               | Yes       |
| Cosign image signing      | `deploy.yaml`                        | Yes       |
| SLSA provenance (Level 2) | `deploy.yaml`                        | Yes       |
| SBOM generated            | `release.yaml` (anchore/sbom-action) | Yes       |
| Manual trigger            | `workflow_dispatch`                  | Yes       |
| Health check post-deploy  | SSH health check in pipeline         | Yes       |

**Trigger:** Manual `workflow_dispatch` on `deploy.yaml`. **Pipeline:** `.github/workflows/deploy.yaml` — full pipeline with SLSA verification, image tagging, SSH deploy.

***

## Deployment Windows

Inherited from [security-baselines.md](/makalu/docs/governance/security-baselines) section 3.2:

| Environment      | Allowed Days | Allowed Hours (UTC) |
| ---------------- | ------------ | ------------------- |
| Testnet (Makalu) | Any          | Any                 |
| Mainnet          | Tue-Thu      | 14:00-16:00         |

**Freeze Periods:**

* No mainnet deployments during major chain events
* Minimum 48h between mainnet deployments
* Holiday freeze: Dec 20 - Jan 5

***

## Rollback Procedure

### Testnet

1. SSH to indexer via bastion:

   ```bash
   ssh -o ProxyJump="ec2-user@44.218.142.100" ec2-user@10.0.10.16
   ```
2. Roll back to previous commit:

   ```bash
   cd /opt/lithosphere/Makalu
   git log --oneline -5          # identify target commit
   git checkout <previous-sha>
   sudo docker compose up -d --build --remove-orphans
   ```
3. Verify health:

   ```bash
   curl -s http://localhost:4000/health
   curl -s http://localhost:3000
   ```

### Mainnet

Same procedure, but requires:

* Notification to on-call (minimum)
* Post-incident review within 24h
* Update to `deploy.yaml` run log

***

## Resolved Gaps

| Gap                                     | Resolution                                                                                                  |
| --------------------------------------- | ----------------------------------------------------------------------------------------------------------- |
| No automated rollback on health failure | Both `deploy-simple.yaml` and `deploy.yaml` have rollback jobs; rollback snapshots saved before each deploy |
| No blue/green or canary deploy          | `Makalu/scripts/blue-green-deploy.sh` provides blue/green for Docker Compose                                |
| No formal staging environment           | `promote.yaml` supports testnet->staging->mainnet promotion flow                                            |
| No GitHub Environment protection rules  | `promote.yaml` uses GitHub Environment approval gates for mainnet                                           |

***

## References

* [ADR-001: Environment Strategy](/makalu/docs/architecture/001-environment-strategy) — aspirational 4-env model
* [ADR-002: Tech Stack BOM](/makalu/docs/architecture/002-tech-stack)
* [Security Baselines](/makalu/docs/governance/security-baselines) — RACI, deployment windows, freeze periods
* [Promotion Playbook](/docs/guides/promotion-playbook) — SOPs for promotion and rollback
* [deploy-simple.yaml](https://github.com/KaJLabs/lithosphere/blob/main/.github/workflows/deploy-simple.yaml) — testnet CD
* [deploy.yaml](https://github.com/KaJLabs/lithosphere/blob/main/.github/workflows/deploy.yaml) — mainnet CD with SLSA
* [promote.yaml](https://github.com/KaJLabs/lithosphere/blob/main/.github/workflows/promote.yaml) — environment promotion with approval gates


# ADR-004: Security Baselines — Makalu Testnet (Enforced)

## Status

**Accepted**

## Date

2026-03-06

## Context

The canonical [Security Baselines & Governance](/makalu/docs/governance/security-baselines) document describes an aspirational posture targeting K8s, Vault, Istio, and SLSA Level 3+. This addendum documents what is **actually enforced** on the Makalu testnet today (EC2 + Docker Compose deployment).

***

## Supply Chain Security

| Control                          | Status              | Implementation                                          |
| -------------------------------- | ------------------- | ------------------------------------------------------- |
| Image signing (Cosign)           | Enforced            | `deploy.yaml`, `publish-images.yaml`                    |
| SBOM generation (SPDX)           | Enforced            | `release.yaml` via anchore/sbom-action                  |
| SLSA provenance                  | Partial (Level 2)   | GitHub-hosted runners, signed images, no hermetic build |
| Secret scanning                  | Enforced            | Gitleaks in `ci.yaml`                                   |
| Dependency scanning (Trivy/Snyk) | **Not implemented** | Gap — tracked in Phase 10                               |
| License policy                   | **Not implemented** | Gap — tracked in Phase 10                               |

**Effective SLSA Level: 2** (tamper-resistant build service + signed provenance, but not hermetic).

***

## Access Control

| Layer           | Control         | Implementation                                                   |
| --------------- | --------------- | ---------------------------------------------------------------- |
| GitHub repo     | CODEOWNERS      | `.github/CODEOWNERS` — PR reviews required                       |
| AWS credentials | OIDC federation | `aws-actions/configure-aws-credentials@v4` — no static keys      |
| EC2 access      | SSH via bastion | Bastion (44.218.142.100) + private key, no direct SSH to indexer |
| Secrets in CI   | GitHub Secrets  | Encrypted at rest, scoped to repo                                |
| Database        | RDS IAM auth    | Via AWS Secrets Manager (injected by OIDC in deploy pipeline)    |

**No Vault, no K8s RBAC, no service mesh mTLS** — these are aspirational (see parent doc).

***

## Network Security

| Control               | Status              | Notes                                           |
| --------------------- | ------------------- | ----------------------------------------------- |
| Bastion-only SSH      | Enforced            | No direct public SSH to indexer EC2             |
| Security groups       | Enforced            | AWS VPC SGs managed in litho-validator-infra    |
| WAF / DDoS            | **Not implemented** | No CloudFront/Shield on testnet                 |
| mTLS between services | **Not implemented** | Services communicate over Docker bridge network |
| Egress filtering      | **Not implemented** | Default outbound allow                          |

***

## CI/CD Security

| Control                      | Status           | Pipeline                             |
| ---------------------------- | ---------------- | ------------------------------------ |
| Branch protection (1 review) | Enforced         | GitHub repo settings                 |
| CI must pass before merge    | Enforced         | Status checks on `main`              |
| Gitleaks secret scan         | Enforced         | `ci.yaml`                            |
| Image signing before deploy  | Enforced         | `deploy.yaml` (Cosign)               |
| Manual approval for mainnet  | Enforced         | `workflow_dispatch` gate             |
| Signed commits required      | **Not enforced** | Aspirational (security-baselines.md) |

***

## Monitoring & Incident Response

| Control               | Status              | Implementation                                  |
| --------------------- | ------------------- | ----------------------------------------------- |
| Health monitoring     | Enforced            | `health-monitoring.yaml` (cron every 5 min)     |
| Prometheus metrics    | Enforced            | `:9090` (services), `:9091` (Prometheus server) |
| Grafana dashboards    | Enforced            | 7 dashboards on `:3001`                         |
| AlertManager          | Configured          | `lithosphere-alerts.yml` routing rules          |
| PagerDuty integration | **Not implemented** | Aspirational                                    |
| SIEM / audit trail    | **Not implemented** | Aspirational                                    |

***

## Gap Summary

| Gap                              | Risk                  | Mitigation                     | Target Phase |
| -------------------------------- | --------------------- | ------------------------------ | ------------ |
| No container/dependency scanning | Medium                | Manual review; add Trivy to CI | Phase 10     |
| No signed commits                | Low                   | CODEOWNERS review compensates  | Phase 10     |
| No mTLS between services         | Low (private network) | Docker bridge isolation        | Phase 10     |
| No WAF/DDoS protection           | Low (testnet)         | Nginx rate limiting on Sentry  | Post-testnet |
| No SIEM integration              | Low (testnet)         | CloudWatch logs available      | Phase 10     |

***

## References

* [Security Baselines & Governance](/makalu/docs/governance/security-baselines) — aspirational K8s/Vault posture, RACI matrix
* [ADR-003: Promotion Gates](broken://pages/VmDNdUMZIpDVqbgDtBa4) — deployment flow and gates
* [CODEOWNERS](https://github.com/KaJLabs/lithosphere/blob/main/.github/CODEOWNERS/README.md)
* [deploy.yaml](https://github.com/KaJLabs/lithosphere/blob/main/.github/workflows/deploy.yaml) — SLSA pipeline
* [ci.yaml](https://github.com/KaJLabs/lithosphere/blob/main/.github/workflows/ci.yaml) — Gitleaks, lint, build


# governance


# Security Baselines & Governance

## Document Information

| Attribute        | Value                        |
| ---------------- | ---------------------------- |
| **Status**       | Approved                     |
| **Version**      | 1.0                          |
| **Last Updated** | 2024-12-13                   |
| **Owner**        | Infrastructure Security Team |
| **Review Cycle** | Quarterly                    |

***

## 1. SLSA Compliance Target

### Overview

The Lithosphere Developer Infrastructure targets **SLSA Level 3** compliance for all production artifacts. SLSA (Supply-chain Levels for Software Artifacts) provides a security framework for ensuring the integrity of software artifacts.

### SLSA Level Requirements

| Level       | Requirement                    | Our Implementation                  |
| ----------- | ------------------------------ | ----------------------------------- |
| **Level 1** | Documentation of build process | GitHub Actions workflows documented |
| **Level 2** | Tamper-resistant build service | GitHub-hosted runners, audit logs   |
| **Level 3** | Hardened build platform        | Isolated builds, signed provenance  |
| **Level 4** | Two-person review              | Future target (not Phase 0)         |

***

### SLSA Level 3 Implementation

#### 1.1 Provenance Generation

All build artifacts MUST include SLSA provenance attestations.

```yaml
# .github/workflows/build.yaml
- name: Generate SLSA Provenance
  uses: slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml@v1.9.0
  with:
    image: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
    digest: ${{ steps.build.outputs.digest }}
```

**Provenance Contents:**

* Build timestamp
* Builder identity (GitHub Actions)
* Source repository and commit
* Build instructions (workflow file)
* Dependencies (locked versions)

#### 1.2 Artifact Signing

All container images and contract artifacts MUST be signed using Sigstore Cosign.

```bash
# Image signing (automated in CI)
cosign sign --yes \
  --key cosign.key \
  --annotations "repo=$GITHUB_REPOSITORY" \
  --annotations "sha=$GITHUB_SHA" \
  ${REGISTRY}/${IMAGE_NAME}@${DIGEST}

# Contract artifact signing
cosign sign-blob --yes \
  --key cosign.key \
  --output-signature contracts.sig \
  artifacts/contracts.tar.gz
```

**Verification (on deployment):**

```bash
cosign verify \
  --key cosign.pub \
  --annotations "repo=lithosphere/infrastructure" \
  ${REGISTRY}/${IMAGE_NAME}@${DIGEST}
```

#### 1.3 Build Isolation

| Control             | Implementation                                  |
| ------------------- | ----------------------------------------------- |
| Ephemeral Runners   | GitHub-hosted runners (fresh VM per job)        |
| Minimal Permissions | `permissions: {}` default, explicit grants only |
| Network Isolation   | No egress except approved registries            |
| Hermetic Builds     | Locked dependencies, no network fetches         |

#### 1.4 SBOM Generation

Software Bill of Materials generated for all artifacts:

```yaml
- name: Generate SBOM
  uses: anchore/sbom-action@v0
  with:
    image: ${{ env.IMAGE_NAME }}
    format: spdx-json
    output-file: sbom.spdx.json

- name: Attest SBOM
  uses: actions/attest-sbom@v1
  with:
    subject-name: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
    sbom-path: sbom.spdx.json
```

***

## 2. Security Policies

### 2.1 Secret Management

| Policy     | Requirement                                |
| ---------- | ------------------------------------------ |
| Storage    | All secrets in HashiCorp Vault             |
| Rotation   | API keys: 90 days, Signing keys: Annual    |
| Access     | RBAC with least-privilege                  |
| Audit      | All access logged and monitored            |
| Encryption | At-rest (AES-256) and in-transit (TLS 1.3) |

**Prohibited Practices:**

* Secrets in source code
* Secrets in environment variables (use Vault injection)
* Shared credentials across environments
* Long-lived tokens without rotation

### 2.2 Access Control

| Resource       | Access Model                         |
| -------------- | ------------------------------------ |
| Git Repository | GitHub Teams + Branch Protection     |
| Kubernetes     | RBAC with namespace isolation        |
| AWS            | IAM Roles with OIDC (no static keys) |
| Vault          | Policy-based with AppRole auth       |

**Branch Protection Rules (mainnet):**

* Require 2 approving reviews
* Require signed commits
* Require status checks to pass
* Require linear history
* Restrict force pushes
* Restrict deletions

### 2.3 Network Security

| Layer   | Control                                   |
| ------- | ----------------------------------------- |
| Ingress | WAF + DDoS protection (CloudFront/Shield) |
| Cluster | Network Policies (deny-all default)       |
| Service | mTLS via Istio service mesh               |
| Egress  | Explicit allowlist only                   |

### 2.4 Vulnerability Management

| Scan Type      | Tool       | Frequency   | Blocking Threshold |
| -------------- | ---------- | ----------- | ------------------ |
| Container CVE  | Trivy      | Every build | CRITICAL, HIGH     |
| Dependency     | Dependabot | Daily       | CRITICAL           |
| Smart Contract | Slither    | Every build | Medium+            |
| IaC            | Checkov    | Every build | High               |
| Runtime        | Falco      | Continuous  | Anomaly detection  |

***

## 3. RACI Matrix

### Overview

RACI defines roles and responsibilities:

* **R**esponsible: Does the work
* **A**ccountable: Final decision authority (only one per activity)
* **C**onsulted: Provides input before decision
* **I**nformed: Notified after decision

### 3.1 Smart Contract Upgrade

| Activity               | Dev Team | Security | DevOps | Product | Legal | Exec |
| ---------------------- | -------- | -------- | ------ | ------- | ----- | ---- |
| Identify upgrade need  | R        | C        | I      | A       | I     | I    |
| Develop upgrade code   | R        | C        | I      | C       | I     | I    |
| Security audit         | C        | R        | I      | I       | I     | I    |
| Audit remediation      | R        | A        | I      | C       | I     | I    |
| Testnet deployment     | R        | C        | R      | I       | I     | I    |
| QA sign-off            | C        | C        | I      | R       | I     | A    |
| Legal review           | I        | C        | I      | C       | R     | A    |
| Mainnet deployment     | I        | C        | R      | C       | I     | A    |
| Post-deploy monitoring | R        | R        | R      | I       | I     | I    |

**Escalation Path:**

```
Developer → Security Lead → Engineering Manager → CTO → CEO
```

**Approval Requirements:**

* Testnet: 1 Security + 1 DevOps approval
* Mainnet: 2 Security + 1 Legal + 1 Executive approval

***

### 3.2 Mainnet Deployment

| Activity            | Dev Team | Security | DevOps | SRE | Product | Exec |
| ------------------- | -------- | -------- | ------ | --- | ------- | ---- |
| Code complete       | R        | I        | I      | I   | A       | I    |
| Code review         | R        | C        | C      | I   | I       | I    |
| CI/CD pipeline pass | I        | I        | R      | C   | I       | I    |
| Security scan pass  | I        | R        | C      | I   | I       | I    |
| Staging validation  | C        | C        | R      | R   | A       | I    |
| Change request      | I        | C        | R      | C   | C       | A    |
| Deployment window   | I        | I        | C      | R   | C       | A    |
| Execute deployment  | I        | I        | R      | R   | I       | I    |
| Health check        | I        | I        | C      | R   | I       | I    |
| Rollback decision   | C        | C        | R      | A   | C       | I    |
| Post-deploy review  | R        | R        | R      | R   | A       | I    |

**Deployment Windows:**

| Environment | Allowed Days | Allowed Hours (UTC) |
| ----------- | ------------ | ------------------- |
| Devnet      | Any          | Any                 |
| Staging     | Mon-Thu      | 09:00-17:00         |
| Mainnet     | Tue-Thu      | 14:00-16:00         |

**Freeze Periods:**

* No mainnet deployments during major events
* Minimum 48h between mainnet deployments
* Holiday freeze: Dec 20 - Jan 5

***

### 3.3 Key Rotation

| Activity            | Dev Team | Security | DevOps | SRE | Compliance | Exec |
| ------------------- | -------- | -------- | ------ | --- | ---------- | ---- |
| Schedule rotation   | I        | A        | R      | C   | C          | I    |
| Generate new keys   | I        | R        | C      | I   | I          | I    |
| Update Vault        | I        | C        | R      | I   | I          | I    |
| Deploy new secrets  | I        | C        | R      | R   | I          | I    |
| Verify systems      | C        | C        | R      | R   | I          | I    |
| Revoke old keys     | I        | A        | R      | C   | I          | I    |
| Audit trail update  | I        | C        | R      | I   | R          | I    |
| Compliance sign-off | I        | C        | I      | I   | R          | A    |

**Key Rotation Schedule:**

| Key Type              | Rotation Frequency | Lead Time | Backup Required |
| --------------------- | ------------------ | --------- | --------------- |
| API Keys              | 90 days            | 7 days    | Yes             |
| Database Credentials  | 90 days            | 7 days    | Yes             |
| TLS Certificates      | 90 days (auto)     | Auto      | Yes             |
| Signing Keys (Cosign) | Annual             | 30 days   | Yes (HSM)       |
| SSH Keys              | Annual             | 14 days   | Yes             |
| Root CA               | 5 years            | 90 days   | Yes (offline)   |

**Emergency Rotation Trigger:**

* Suspected key compromise
* Employee with key access departs
* Security incident
* Compliance requirement

**Emergency Rotation SLA:**

| Severity | Key Revocation | New Key Deployment |
| -------- | -------------- | ------------------ |
| Critical | 1 hour         | 4 hours            |
| High     | 4 hours        | 24 hours           |
| Medium   | 24 hours       | 72 hours           |

***

## 4. Incident Response

### Severity Levels

| Level | Description                 | Response Time | Example                 |
| ----- | --------------------------- | ------------- | ----------------------- |
| P1    | Critical - Production down  | 15 min        | Mainnet RPC unavailable |
| P2    | High - Major feature broken | 1 hour        | Transactions failing    |
| P3    | Medium - Minor impact       | 4 hours       | Dashboard slow          |
| P4    | Low - Minimal impact        | 24 hours      | Typo in docs            |

### Escalation Matrix

```
P1: On-call SRE → SRE Lead (15m) → CTO (30m) → CEO (1h)
P2: On-call SRE → SRE Lead (1h) → Engineering Manager (2h)
P3: On-call SRE → Engineering Manager (next business day)
P4: Ticket queue → Sprint planning
```

***

## 5. Compliance Checklist

### Pre-Deployment Checklist

* [ ] All CI checks passing
* [ ] Security scan (Slither) clean - no high/critical
* [ ] Container scan (Trivy) clean - no critical CVEs
* [ ] SBOM generated and attested
* [ ] Artifacts signed with Cosign
* [ ] Provenance attestation generated
* [ ] Required approvals obtained
* [ ] Deployment window confirmed
* [ ] Rollback plan documented
* [ ] On-call notified

### Post-Deployment Checklist

* [ ] Health checks passing
* [ ] Metrics baseline established
* [ ] Error rates normal
* [ ] Latency within SLA
* [ ] Smoke tests passing
* [ ] Status page updated
* [ ] Change record closed

***

## 6. Document Control

### Change History

| Version | Date       | Author              | Changes         |
| ------- | ---------- | ------------------- | --------------- |
| 1.0     | 2024-12-13 | Infrastructure Team | Initial release |

### Review Schedule

| Review Type     | Frequency   | Participants             |
| --------------- | ----------- | ------------------------ |
| RACI Review     | Quarterly   | All stakeholders         |
| Security Policy | Semi-annual | Security + Compliance    |
| Full Document   | Annual      | All stakeholders + Legal |

***

## References

* [SLSA Specification v1.0](https://slsa.dev/spec/v1.0/)
* [Sigstore Cosign](https://docs.sigstore.dev/cosign/overview/)
* [NIST Cybersecurity Framework](https://www.nist.gov/cyberframework)
* [SOC 2 Type II Requirements](https://www.aicpa.org/soc2)
* [CIS Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes)


# packages


# @lithosphere/blockchain-core

Lithosphere L1 Blockchain Core Implementation

## Overview

This package contains the core blockchain implementation for Lithosphere, including:

* **Smart Contracts**: LEP100 token standard, DeFi protocols, and governance contracts
* **SDK**: Developer tools and libraries for building on Lithosphere
* **Chain Implementation**: Core blockchain protocols and consensus mechanisms

## Project Structure

```
blockchain-core/
├── src/
│   ├── contracts/       # Smart contracts (Solidity/Rust)
│   ├── sdk/            # TypeScript/JavaScript SDK
│   ├── chain/          # Blockchain core implementation
│   ├── consensus/      # Consensus mechanism (Linear Communication BFT)
│   └── crypto/         # Cryptographic utilities (MDKM, ring signatures)
├── test/               # Tests
└── docs/               # Technical documentation
```

## Getting Started

This package is currently a placeholder for future development. When implementing:

1. Add smart contracts to `src/contracts/`
2. Implement SDK in `src/sdk/`
3. Add chain logic to `src/chain/`
4. Write comprehensive tests in `test/`

## Development

```bash
# Install dependencies
pnpm install

# Build
pnpm build

# Run tests
pnpm test

# Type checking
pnpm typecheck
```

## Technologies

* **Smart Contracts**: Solidity / CosmWasm (Rust)
* **SDK**: TypeScript
* **Blockchain**: Custom L1 implementation
* **Consensus**: Linear Communication BFT
* **Cryptography**: MDKM (Myriad Distributed Key Management)

## Related Documentation

See the `@lithosphere/docs` package for:

* Whitepaper and technical specifications
* LEP100 token standard documentation
* Architecture and design documents
* API documentation

## License

\[Add your license here]


# Changelog

All notable changes to `@lithosphere/blockchain-core` are documented here.

The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/), and this project adheres to [Semantic Versioning](https://semver.org/).

## 0.1.0 — 2026-05-11

Initial release. Replaces the previous stubs-only package with real primitives.

### Added

* `NETWORKS` registry: `mainnet`, `staging`, `devnet`, `local` profiles with chainId 700777, `rpc.litho.ai`, bech32 prefix `litho`, `ulitho` denom.
* `getNetwork(name)` and `isNetworkName(value)` helpers.
* `LithoError` class and `ErrorCode` enum covering RPC, network, and validation failure modes.
* Typed ABI exports: `LEP100_ABI`, `WLITHO_ABI`, `LITHONATIVE_ABI` (extracted from `Makalu/contracts/artifacts`). Each is `as const` for `abitype` / `viem` inference.
* Shared TypeScript types: `NetworkConfig`, `TransactionResponse`, `TransactionReceipt`, `AccountBalance`, `TokenBalance`, `Log`, `CallOptions`, `SendOptions`, `ClientConfig`, `RetryConfig`.
* Dual ESM + CJS build via `tsup`; type definitions for both.

### Removed

* Stub subdirectories (`chain/`, `consensus/`, `crypto/`, `contracts/`, `sdk/`) that targeted unimplemented research features (MDKM, ring signatures, threshold signatures, Linear Comm BFT). These remain documented as planned roadmap items in `docs/` but are out of scope for this package.

### Migration

* No prior published version exists (`private: true` in 0.0.x). No breaking changes for consumers.


# create-litho-app

Official CLI for scaffolding Lithosphere developer-preview projects.

The package bundles the supported starter templates inside the release artifact, so it works both from the monorepo and from a packed GitHub release tarball.

## Requirements

* Node.js 20+
* pnpm 9+ for generated projects

## Usage

```bash
npx create-litho-app my-litho-app
```

You can also install a release tarball directly:

```bash
npm install -g ./create-litho-app-<version>.tgz
create-litho-app my-litho-app
```

## Templates

* `contracts`: Hardhat + Foundry smart contract starter
* `service`: Fastify + Docker service starter
* `sdk`: TypeScript SDK starter

## Common Commands

```bash
create-litho-app my-litho-app --template contracts
create-litho-app my-service --template service
create-litho-app my-sdk --template sdk
```

Each generated project prints its next-step commands after scaffolding.

## Development

```bash
pnpm install
pnpm build
node dist/index.cjs --help
```


# @lithosphere/docs

Comprehensive documentation for the Lithosphere L1 Blockchain platform.

## 📚 Contents

This package contains all documentation, whitepapers, technical specifications, and guides for Lithosphere.

### Core Documentation

* [**Whitepaper**](/makalu/packages/docs/documentation/whitepaper) - Complete technical whitepaper
* [**Abstract**](/makalu/packages/docs/abstract) - Project overview and vision
* [**Design Concept**](/makalu/packages/docs/design-concept) - Core design principles
* [**Architecture**](/makalu/packages/docs/lithosphere-architecture-and-technology) - System architecture overview

### Token Standards

* [**LEP100 Token Standard**](/makalu/packages/docs/lep100-token-standard) - Multi-chain token standard
* [**LEP100 Features**](/makalu/packages/docs/lep100-token-features) - Key features and capabilities
* [**LEP100 Multi-Chain**](/makalu/packages/docs/lep100-multi-chain-token-standard) - Cross-chain functionality
* [**Why Use LEP100**](/makalu/packages/docs/why-should-your-defi-project-use-the-lep100-token-standard) - Benefits for DeFi projects

### Technical Specifications

#### Consensus & Cryptography

* [**Consensus Mechanism**](/makalu/packages/docs/consensus-mechanism) - Overview
* [**Linear Communication BFT**](/makalu/packages/docs/linear-communication-bft-consensus) - Detailed consensus protocol
* [**Threshold Signature**](/makalu/packages/docs/threshold-signature) - Threshold signature scheme
* [**MDKM**](/makalu/packages/docs/myriad-distributed-key-management) - Myriad Distributed Key Management

#### Privacy & Security

* [**Locked Account Generation Scheme**](/makalu/packages/docs/locked-account-generation-scheme) - Privacy-preserving accounts
  * [Introduction](/makalu/packages/docs/locked-account-generation-scheme/introduction)
  * [Design Description](/makalu/packages/docs/locked-account-generation-scheme/design-description)
  * [Scheme Generation](/makalu/packages/docs/locked-account-generation-scheme/scheme-generation)
  * [Advantages](/makalu/packages/docs/locked-account-generation-scheme/advantages)
    * [Ring Signature Scheme](/makalu/packages/docs/locked-account-generation-scheme/advantages/ring-signature-scheme)
    * [Smart Contracts](/makalu/packages/docs/locked-account-generation-scheme/advantages/smart-contracts)
    * [Cryptography-Based Security](/makalu/packages/docs/locked-account-generation-scheme/advantages/cryptography-based-security-guarantee)

### Blockchain Implementation

* [**Litho Chain**](/makalu/packages/docs/litho-chain) - Chain implementation docs
  * [Build Instructions](https://github.com/KaJLabs/lithosphere/blob/main/packages/docs/litho-chain/build.sh)
  * [Installation](https://github.com/KaJLabs/lithosphere/blob/main/packages/docs/litho-chain/install.sh)
  * [Linux Setup](/makalu/packages/docs/litho-chain/lithod-linux)

### Network & Nodes

* [**Validators**](/makalu/packages/docs/validators) - Validator node requirements
* [**Verification Nodes**](/makalu/packages/docs/verification-nodes) - Verification node setup

### Smart Contracts & DeFi

* [**Smart Contracts Overview**](/makalu/packages/docs/smart-contracts-and-decentralized-finance-defi)
* [**Deep Neural Networks (DNN)**](/makalu/packages/docs/deep-neural-networks-dnn) - ML integration

### Cross-Chain & Interoperability

* [**Cross-Chain Integration**](/makalu/packages/docs/cross-chain-integration)
* [**Cross-Chain Transactions**](/makalu/packages/docs/cross-chain-transactions)

### Tokenomics & Economics

* [**ITHO Coin**](/makalu/packages/docs/itho-coin) - Native token
* [**LAX Cryptocurrency**](/makalu/packages/docs/lithosphere-algorithmic-cryptocurrency-lax) - Algorithmic stablecoin

### Project Information

* [**Roadmap**](/makalu/packages/docs/roadmap) - Development timeline
* [**Design Objectives**](/makalu/packages/docs/design-objectives) - Project goals
* [**Positioning**](/makalu/packages/docs/positioning) - Market positioning
* [**Current Features**](/makalu/packages/docs/current-lithosphere-features) - Existing capabilities
  * [Funding](/makalu/packages/docs/current-lithosphere-features/funding-for-the-project)
  * [Products](/makalu/packages/docs/current-lithosphere-features/lithosphere-products)
  * [Governance](/makalu/packages/docs/current-lithosphere-features/lithosphere-project-governance)

### Community & Adoption

* [**Community Operation Plan**](/makalu/packages/docs/community-operation-plan)
* [**Project Promotion**](/makalu/packages/docs/project-promotion-method)
* [**Standardization Movement**](/makalu/packages/docs/the-standardization-of-blockchain-interfaces-movement)
* [**Blockchain Technology Movement**](/makalu/packages/docs/a-movement-to-promote-blockchain-technology)

### Additional Resources

* [**Applications**](/makalu/packages/docs/lithosphere-applications) - Use cases and applications
* [**Glossary**](/makalu/packages/docs/glossary) - Terms and definitions
* [**Conclusion**](/makalu/packages/docs/conclusion) - Project summary
* [**Disclaimer**](/makalu/packages/docs/disclaimer) - Legal disclaimer

## 📖 Reading Guide

### For Developers

1. Start with the [Whitepaper](/makalu/packages/docs/documentation/whitepaper)
2. Read [LEP100 Token Standard](/makalu/packages/docs/lep100-token-standard)
3. Review [Architecture](/makalu/packages/docs/lithosphere-architecture-and-technology)
4. Explore [Smart Contracts](/makalu/packages/docs/smart-contracts-and-decentralized-finance-defi)

### For Researchers

1. [Design Concept](/makalu/packages/docs/design-concept)
2. [Consensus Mechanism](/makalu/packages/docs/linear-communication-bft-consensus)
3. [Locked Account Generation Scheme](/makalu/packages/docs/locked-account-generation-scheme)
4. [MDKM](/makalu/packages/docs/myriad-distributed-key-management)

### For Investors

1. [Abstract](/makalu/packages/docs/abstract)
2. [Roadmap](/makalu/packages/docs/roadmap)
3. [Current Features](/makalu/packages/docs/current-lithosphere-features)
4. [Applications](/makalu/packages/docs/lithosphere-applications)

## 🔗 Related Packages

* [@lithosphere/blockchain-core](/makalu/packages/blockchain-core) - Implementation code

## 📝 Contributing

Documentation contributions are welcome! Please ensure:

* Clear and concise writing
* Proper formatting (Markdown)
* Technical accuracy
* Up-to-date information

## 📄 Format

All documentation is written in Markdown format for easy readability and version control.


# Lithosphere Monorepo Structure

## Overview

The repository has been reorganized into a clean monorepo structure that separates documentation from product code.

## New Structure

```
lithosphere/
├── packages/
│   ├── blockchain-core/          # Core blockchain implementation
│   │   ├── src/
│   │   │   ├── contracts/        # Smart contracts (LEP100, DeFi, etc.)
│   │   │   ├── sdk/              # TypeScript/JavaScript SDK
│   │   │   ├── chain/            # Blockchain core implementation
│   │   │   ├── consensus/        # Linear Communication BFT
│   │   │   ├── crypto/           # MDKM, ring signatures, etc.
│   │   │   └── index.ts          # Main entry point
│   │   ├── test/                 # Test files
│   │   ├── package.json
│   │   ├── tsconfig.json
│   │   └── README.md
│   │
│   └── docs/                     # All documentation
│       ├── documentation/        # Whitepaper, technical specs
│       ├── locked-account-generation-scheme/
│       ├── current-lithosphere-features/
│       ├── litho-chain/
│       ├── .gitbook/
│       ├── *.md files           # All markdown documentation
│       ├── *.pdf files          # PDF documents
│       ├── package.json
│       └── README.md
│
├── apps/                         # (Future) Application packages
├── infra/                        # (Future) Infrastructure as Code
├── tooling/                      # (Future) Build tooling
│
├── .github/                      # GitHub workflows
├── package.json                  # Root package configuration
├── pnpm-workspace.yaml          # Workspace configuration
├── turbo.json                   # Turborepo configuration
├── tsconfig.json                # Root TypeScript config
├── .eslintrc.js                 # ESLint configuration
├── .prettierrc                  # Prettier configuration
├── .gitignore                   # Git ignore rules
└── README.md                    # Main README
```

## Packages

### @lithosphere/blockchain-core

**Location**: `packages/blockchain-core/`

Core blockchain implementation containing:

* Smart contracts (LEP100 token standard, DeFi protocols)
* TypeScript/JavaScript SDK for developers
* Blockchain core implementation
* Consensus mechanism (Linear Communication BFT)
* Cryptographic utilities (MDKM, ring signatures, threshold signatures)

**Status**: Scaffold created, ready for implementation

**Key directories**:

* `src/contracts/` - Smart contract implementations
* `src/sdk/` - Developer SDK
* `src/chain/` - Core blockchain logic
* `src/consensus/` - Consensus mechanism
* `src/crypto/` - Cryptographic utilities

### @lithosphere/docs

**Location**: `packages/docs/`

Comprehensive documentation including:

* Whitepaper and technical specifications
* LEP100 token standard documentation
* Architecture and design documents
* Smart contract guides
* API documentation

**Status**: All existing documentation migrated

## Development Workflow

### Installation

```bash
pnpm install
```

### Build all packages

```bash
pnpm build
```

### Run tests

```bash
pnpm test
```

### Lint and format

```bash
pnpm lint
pnpm format
```

### Work on specific package

```bash
# Navigate to package
cd packages/blockchain-core

# Run package-specific commands
pnpm build
pnpm test
```

## Workspace Configuration

The monorepo uses:

* **pnpm workspaces** for package management
* **Turborepo** for build orchestration
* **TypeScript** for type safety
* **ESLint + Prettier** for code quality

## Next Steps

### For Product Development

1. **Implement Smart Contracts** (`packages/blockchain-core/src/contracts/`)
   * LEP100 token standard
   * DeFi protocols
   * Governance contracts
2. **Build SDK** (`packages/blockchain-core/src/sdk/`)
   * Blockchain client
   * Wallet integration
   * Transaction builders
3. **Develop Chain Logic** (`packages/blockchain-core/src/chain/`)
   * Block structures
   * Transaction handling
   * State management
4. **Implement Consensus** (`packages/blockchain-core/src/consensus/`)
   * Linear Communication BFT
   * Validator management
   * Block production
5. **Add Cryptography** (`packages/blockchain-core/src/crypto/`)
   * MDKM implementation
   * Ring signatures
   * Threshold signatures

### For Infrastructure

* Add application packages to `apps/`
* Add infrastructure code to `infra/`
* Add shared tooling to `tooling/`

## Migration Summary

### Files Moved

* ✅ All `.md` files → `packages/docs/`
* ✅ `documentation/` folder → `packages/docs/documentation/`
* ✅ `locked-account-generation-scheme/` → `packages/docs/locked-account-generation-scheme/`
* ✅ `current-lithosphere-features/` → `packages/docs/current-lithosphere-features/`
* ✅ `litho-chain/` → `packages/docs/litho-chain/`
* ✅ `.gitbook/` → `packages/docs/.gitbook/`
* ✅ PDF and DOCX files → `packages/docs/`

### Files Created

* ✅ `packages/blockchain-core/package.json`
* ✅ `packages/blockchain-core/tsconfig.json`
* ✅ `packages/blockchain-core/README.md`
* ✅ `packages/blockchain-core/src/` structure
* ✅ `packages/docs/package.json`
* ✅ `packages/docs/README.md`
* ✅ Root `.gitignore`
* ✅ Updated root `README.md`

### Configuration Updated

* ✅ `pnpm-workspace.yaml` - Already configured for packages structure
* ✅ `package.json` - Root configuration maintained
* ✅ `turbo.json` - Build configuration ready

## Benefits

1. **Clear Separation**: Documentation and code are cleanly separated
2. **Scalability**: Easy to add new packages (smart contracts, SDKs, apps)
3. **Developer Experience**: Clear structure, fast builds with Turborepo
4. **Maintainability**: Each package has its own dependencies and configuration
5. **CI/CD Ready**: Turborepo enables efficient incremental builds

## Resources

* [pnpm Workspaces Documentation](https://pnpm.io/workspaces)
* [Turborepo Documentation](https://turbo.build/repo/docs)
* [TypeScript Project References](https://www.typescriptlang.org/docs/handbook/project-references.html)


# Table of contents

* [Lithosphere](/makalu/packages/docs)
* [Abstract](/makalu/packages/docs/abstract)
* [Design Concept](/makalu/packages/docs/design-concept)
* [Design Objectives](/makalu/packages/docs/design-objectives)
* [Smart Contracts & Decentralized Finance (DeFi)](/makalu/packages/docs/smart-contracts-and-decentralized-finance-defi)
* [Positioning](/makalu/packages/docs/positioning)
* [Lithosphere Architecture and Technology](/makalu/packages/docs/lithosphere-architecture-and-technology)
* [Myriad Distributed Key Management (MDKM)](/makalu/packages/docs/myriad-distributed-key-management-mdkm)
* [Threshold signature](/makalu/packages/docs/threshold-signature)
* [𝕃itho Coin](/makalu/packages/docs/itho-coin)
* [Lithosphere Algorithmic Cryptocurrency - LAX ⋉](/makalu/packages/docs/lithosphere-algorithmic-cryptocurrency-lax)
* [Consensus Mechanism](/makalu/packages/docs/consensus-mechanism)
* [Cross-Chain Integration](/makalu/packages/docs/cross-chain-integration)
* [Cross-Chain Transactions](/makalu/packages/docs/cross-chain-transactions)
* [Deep Neural Networks (DNN)](/makalu/packages/docs/deep-neural-networks-dnn)
* [LEP100 Multi-chain Token Standard](/makalu/packages/docs/lep100-multi-chain-token-standard)
* [Validators](/makalu/packages/docs/validators)
* [Linear-communication BFT Consensus](/makalu/packages/docs/linear-communication-bft-consensus)
* [Myriad Distributed Key Management](/makalu/packages/docs/myriad-distributed-key-management)
* [LEP100 Token Standard](/makalu/packages/docs/lep100-token-standard)
* [Why should your DeFi project use the LEP100 Token Standard?](/makalu/packages/docs/why-should-your-defi-project-use-the-lep100-token-standard)
* [LEP100 Token Features](/makalu/packages/docs/lep100-token-features)
* [Verification Nodes](/makalu/packages/docs/verification-nodes)
* [Locked Account Generation Scheme](/makalu/packages/docs/locked-account-generation-scheme)
  * [Introduction](/makalu/packages/docs/locked-account-generation-scheme/introduction)
  * [General Nodes](/makalu/packages/docs/locked-account-generation-scheme/general-nodes)
  * [Design Description](/makalu/packages/docs/locked-account-generation-scheme/design-description)
  * [Scheme Generation](/makalu/packages/docs/locked-account-generation-scheme/scheme-generation)
  * [Advantages](/makalu/packages/docs/locked-account-generation-scheme/advantages)
    * [Easy Integration and Efficient Data Storage](/makalu/packages/docs/locked-account-generation-scheme/advantages/easy-integration-and-efficient-data-storage)
    * [Smart Contract Token Transaction Anonymity](/makalu/packages/docs/locked-account-generation-scheme/advantages/smart-contract-token-transaction-anonymity)
    * [Fully Decentralized without Third-Party Participation](/makalu/packages/docs/locked-account-generation-scheme/advantages/fully-decentralized-without-third-party-participation)
    * [Secure and stable](/makalu/packages/docs/locked-account-generation-scheme/advantages/secure-and-stable)
    * [One-Time Account System](/makalu/packages/docs/locked-account-generation-scheme/advantages/one-time-account-system)
    * [Ring Signature Scheme](/makalu/packages/docs/locked-account-generation-scheme/advantages/ring-signature-scheme)
    * [Cryptography Based Security Guarantee](/makalu/packages/docs/locked-account-generation-scheme/advantages/cryptography-based-security-guarantee)
    * [Smart Contracts](/makalu/packages/docs/locked-account-generation-scheme/advantages/smart-contracts)
      * [Contract multi-triggering mechanism Diversity of triggering conditions](/makalu/packages/docs/locked-account-generation-scheme/advantages/smart-contracts/contract-multi-triggering-mechanism-diversity-of-triggering-conditions)
      * [Enhancements and compatibility](/makalu/packages/docs/locked-account-generation-scheme/advantages/smart-contracts/enhancements-and-compatibility)
      * [Contract enclosed call](/makalu/packages/docs/locked-account-generation-scheme/advantages/smart-contracts/contract-enclosed-call)
      * [Contract development](/makalu/packages/docs/locked-account-generation-scheme/advantages/smart-contracts/contract-development)
      * [Timing and trigger conditions](/makalu/packages/docs/locked-account-generation-scheme/advantages/smart-contracts/timing-and-trigger-conditions)
      * [Rapid development and interface](/makalu/packages/docs/locked-account-generation-scheme/advantages/smart-contracts/rapid-development-and-interface)
      * [To use multiple triggers to realize complex financial functions](/makalu/packages/docs/locked-account-generation-scheme/advantages/smart-contracts/to-use-multiple-triggers-to-realize-complex-financial-functions)
* [Community operation plan](/makalu/packages/docs/community-operation-plan)
* [Project promotion method](/makalu/packages/docs/project-promotion-method)
* [A movement to Promote Blockchain Technology](/makalu/packages/docs/a-movement-to-promote-blockchain-technology)
* [The Standardization of Blockchain Interfaces Movement](/makalu/packages/docs/the-standardization-of-blockchain-interfaces-movement)
* [Lithosphere Applications](/makalu/packages/docs/lithosphere-applications)
* [Current Lithosphere Features](/makalu/packages/docs/current-lithosphere-features)
  * [Lithosphere Products](/makalu/packages/docs/current-lithosphere-features/lithosphere-products)
  * [Lithosphere Project Governance](/makalu/packages/docs/current-lithosphere-features/lithosphere-project-governance)
  * [Funding for the project](/makalu/packages/docs/current-lithosphere-features/funding-for-the-project)
* [Roadmap](/makalu/packages/docs/roadmap)
* [Conclusion](/makalu/packages/docs/conclusion)
* [Disclaimer](/makalu/packages/docs/disclaimer)
* [Glossary](/makalu/packages/docs/glossary)


# A movement to Promote Blockchain Technology

The Internet of Value presently has a usability bottleneck, which will require continuing work in the future to improve. The usefulness of the Internet of Value is strongly connected to the Lithosphere project. To contribute to the usefulness of blockchain technology, we will start the “blockchain technology promotion movement.” For the Kaj Labs Foundation, this will be a long-term project.

In the form of technical salons, training camps, and seminars, this movement will continue to amass skills and technical information. We will encourage participants to provide content, which will be published on numerous websites and in the media. To grow the technical community of blockchain, we will provide monthly training sessions to recruit conventional Internet employees and other technical staff.

The blockchain technology promotion movement will bring together all forces, including universities, research institutes, businesses, institutions, governments, and alliances, to create a cooperative partnership and pool resources to support blockchain technology’s advancement.


# Abstract

In geography, a lithosphere is the rigid, outermost shell of a terrestrial-type planet or natural satellite. On Earth, it is composed of the crust and the portion of the upper mantle that behaves elastically on time scales of thousands of years or greater. – Wikipedia.&#x20;

Having closely monitored the blockchain space for the last 10 years, the KaJ Labs Foundation can build a much better blockchain network learning from mistakes made by early networks. At this time, all types of tokens have completed some basic functions of value transfer and distribution, but they are still a long way from the fully functional financial services that the real world requires, which is why, when it comes to blockchain applications in the financial sector, all we hear is thunder but no rain falls. People need a new generation of financial infrastructure based on blockchain technology that has complete financial functionality, can link different communities and tokens, and can bridge the gap between centralized and decentralized organizations as soon as possible to usher in the era of the Internet of Value.&#x20;

We created a completely new “Email system” at the dawn of the Internet of Information, rather than transforming the “postal system.” Similarly, when the Internet of Value arrives, we want to build a new system: a value transfer infrastructure based on a variety of tokens. Lithosphere (Litho) is ready for the DeFi age! By establishing a layer of control management on top of various tokens through a distributed management of the tokens’ private keys and by providing ports both for central organizations and for external data sources, Lithosphere will connect various past and next-gen smart contracts, solving the key problem of the current Internet of Value’ insufficient interoperability.&#x20;

The lithosphere is open to everybody. It connects centralized and decentralized organizations, accommodates authentication methods and anonymous trade mechanisms, and introduces on- chain data and off-chain data by integrating the cryptocurrencies and blockchains that exist today and those that may exist in the future. The lithosphere is a Turing-complete virtual computer that allows DeFi to have unlimited reverie space across multiple tokens in the future, opening up henceforth unthinkable possibilities. The Litho project’s general concept, essential technology, and development strategy are presented in this whitepaper, which presents the prospect of decentralized banking based on an examination of the history of the Internet of Value.


# Community operation plan

The KaJ Labs Foundation, as the project’s main sponsor, is aiming towards a promising blockchain ecosystem rather than corporate profitability as typical enterprise and startup initiatives do. The Lithosphere platform, which benefits all token holders, is not owned by any single entity or person. The whole blockchain token community owns the Lithosphere platform. Lithosphere makes token usage more flexible and accessible, as well as giving tokens the potential to offer sophisticated DeFi services. The value of all tokens will increase.

In reality, the Internet of Value’ cross-chain ecosystem is a massive project. The Kaj Labs Foundation must progress the ecosystem, which must be joined and participated in by the whole community, and whose blockchain must be enhanced via continual iteration. This is exactly what the features of a blockchain project are. Blockchain initiatives begin with a critical need or problem to be addressed, which must be continually investigated by participants and those in need to encourage continuous progress. At the same time, it will draw more individuals into the community, causing demand to shift the projects in a better direction and encourage the advancement of its technology. The purpose of the echoes is to generate a positive feedback loop of incentives, applications, and usage. As a result, project operations concepts must be community-oriented from the start, and community operations are linked to the success or failure of the blockchain project.

The following people make up the community:

* The Core development team and the Kaj Labs Foundation. They are the project’s platform’s sponsors and facilitators.
* Programmers who want to be a part of the project. They can join the Foundation development team or independently create and optimize Lithosphere as a third party if they are interested in projects or project technologies.
* Participating nodes in the Lithosphere They make money by keeping track of ledgers and operating smart contracts while also maintaining Lithosphere.
* Users of the Lithosphere platform. For DeFi and other services, they employ the Lithosphere platform.
* On the Lithosphere platform, DeFi service providers such as payment institutes, centralized or decentralized exchanges, lending institutes, and other financial service providers.
* Lithosphere token holders, such as private equity companies, early-stage investors, late-stage investors, and potential investors.
* Other parties involved in the development of Lithosphere, such as the media, government, and so on.
* The goal of community operations is to gather as much force as possible and arrange it in the most efficient way possible so that Lithosphere can iterate, improve, influence, and serve a wider community.

The growth of the community is inextricably linked to both the core and outlying communities. The two are mutually beneficial, with the core community serving as the focal point. The peripheral community, on the other hand, must continue to participate in the creation of the key community since the core community will originate from and borrow from the peripheral community, and the peripheral community will require the core community’s resources to support them. We discovered that Bitcoin, Ethereum, and other projects have all grown in the same way. The core community consists of early adopters, blockchain technology communities, and blockchain value communities, while peripheral resources include additional investors, users, developers, journalists, and other interested parties.


# Conclusion

The Lithosphere project has created a BFT algorithm, a new token standard, Litho currency (LITHO), and a key distribution mechanism to achieve the goal of the inclusive decentralized platform. The design of the native token is mostly comprised of the following five elements:

**1.** Number. A total of one billion tokens are available. This amount will allow the token to launch at an acceptable price and continue to grow steadily from there.

**2.** A system for distributing tokens. To achieve the idea of non-inflation, the supply of tokens should be limited. This benefits the early members and makes the system more stable in the long run.

**3.** The allocation of tokens. To realize the decentralized notion, the token distribution must be properly balanced. We award a 10% ratio to the Lithosphere team because of their continuous devotion and efforts to promote Lithosphere’s inclusivity in cross-chain, cross-organization, and cross-data source initiatives. Furthermore, because Lithosphere’s accounting nodes perform more complex functions than ordinary public chains, they will get around one-third of the entire sum. The remainder will be utilized for environmentally friendly buildings.

**4.** Environmentally-friendly construction. More than half of the funds will go to the Foundation to help the project flourish, particularly in terms of cross-chain, cross-organization, and cross-data features. To allow additional value to be conveyed on the chain and to aid the development of new smart contract applications, the project will also require a token exchange mechanism.

**5.** Fuels and miners In a distributed node control system, a range of values will enter the Lithosphere. To control tokens, the chain requires a large number of dispersed nodes. The more nodes there are, the more secure the chain will be, and the more nodes are required as the chain’s value grows. The chain must compensate miners by releasing tokens and charging service fees to sustain the number of nodes and calculation power.

Lithosphere was born out of necessity. Our development teams have always been spread throughout the world from the beginning of KaJ Labs, yet we’ve always had problems working effectively. We have to enhance our entire performance and processes for our teams to stay distributed.

We recognized there were several inefficiencies with the existing commonly utilized blockchains like Ethereum, Cardano, and others after working on numerous blockchain projects. The most serious issue was that these blockchain networks were unable to connect. You couldn’t buy ERC721 NFT using a BEP20 token, BTC, DOT, or BNB until Lithosphere. Blockchain networks must be in sync with one another for blockchain and DeFi to grow into the future we all want. Transaction expenses/gas fees are another challenges that networks like Ethereum confront. On the Ethereum network, almost every activity costs money.

The KaJ Labs team set out to create a worldwide blockchain network that is quicker, cheaper, and more environmentally friendly than existing blockchains such as Cardano, Polkadot, and Ethereum 2.0. Lithosphere may be thought of as the foundation for both old and new blockchains. The Lithosphere ecosystem is powered by the native currency $LITHO /Litho.

#### COMMUNITY:

[https:litho.ai](https://litho.ai/)

[ecosystem.litho.ai](https://ecosystem.litho.ai)\
[ignite.litho.ai](https://ignite.litho.ai)\
[Staking.litho.ai](https://staking.litho.ai)\
[whitepaper.litho.ai](https://whitepaper.litho.ai)

[GoodTokens.org](https://goodtokens.org/)\
[KaJLabs.org](https://kajlabs.org)\
[ChainFest.ai](https://chainfest.ai)\
[LAX.money](https://lax.money)

#### DEVELOPERS:

#### NETWORK STATUS & SECURITY:


# Consensus Mechanism

Lithosphere adapts a proof of stake consensus mechanism.

The goal of Lithosphere is to use blockchain technology to build an infrastructure platform to run decentralized applications and on the platform, multiple types of tokens will be able to freely interact through smart contracts to achieve value interoperability. Lithosphere aims to implement Myriad Distributed Key Management to build smart contracts for DeFi.

When an unregistered asset is moved from the originating chain to Lithosphere, Lithosphere will construct a new asset based on the cross-chain transaction information, utilizing a built-in asset template to deploy a new smart contract. When a registered asset is moved from the original chain to Lithosphere, Lithosphere will issue equal tokens in existing contracts, ensuring that the original chain assets may still be traded on Lithosphere.


# Cross-Chain Integration

Asset mapping refers to the process of producing matching tokens for bookkeeping on Lithosphere for a controlled item. One token can freely interact with other mapped assets thanks to mapping. Lock-in and Lock-out operations are used to establish and de-manage distributed control.


# Cross-Chain Transactions

![](/files/erbUNSQCzpQhKplJ4qWi)

Asset Lock-in is a process that enables myriad distributed key management and asset mapping for all key-managed tokens.

Asset Lock-out) is the reversal of Lock-in, and it consists of two parts: control rights management and asset mapping disassembly. After Lock-out is completed, control of the digital asset is returned to the owner, restoring complete key storage and centralized key management. By improving the security, liquidity, and DeFi applications of current digital assets, adopting multifarious key distribution management will improve the value of digital assets.


# Deep Neural Networks (DNN)

![](/files/cA50ia5JmuBtf6LKL3Y6)

David Yang PhD, proposes Deep neural networks (DNNs) for Lithosphere smart contracts. DNNs are very useful in blockchain applications such as DeFi and NFT trading. However, training / running large-scale DNNs as part of a smart contract is infeasible on today’s blockchain platforms, due to two fundamental design issues of these platforms. First, blockchains nowadays typically require that each node maintain the complete world state at any time, meaning that the node must execute all transactions in every block. This is prohibitively expensive for computationally intensive smart contracts involving DNNs. Second, existing blockchain platforms expect smart contract transactions to have deterministic, reproducible results and effects. In contrast, DNN is usually trained / run lock-free on massively parallel computing devices such as GPUs, TPUs, and/or computing clusters, which often do not yield deterministic results.

![](/files/SihLOqOqtlulrLd4Rd19)

For the first time in smart contracts, Lithosphere implements DNN to make smart contracts intelligent by incorporating large-scale deep neural networks (DNNs) into the code, which has numerous potential applications. For instance, in decentralized finance (DeFi), a DNN might help detect abnormal token price movements, which could be part of a flash-loan attack. A decentralized autonomous organization (DAO) might trade tokens automatically with a DNN trained continually through reinforcement learning. A content creator might apply a generative adversarial network (GAN) to generate visual art images, and subsequently tokenize them as non-fungible tokens (NFTs) tradable in a decentralized exchange.


# Design Concept

**Blockchain Emergence and Significance**

![](/files/ArGdtFRzIcb6aEEMauZG)

Due to a lack of confidence, the conventional market economy has a significant cost. The major method that individuals continuously handle trust is through a centralized organization or company. The fast growth of modern human civilization was aided by people with similar ideals who were organized into institutions such as governments, political parties, and businesses. However, centralized organizations face enormous challenges: First, owing to a lack of trust between organizations and conceptual disputes, various groups become embroiled in violent rivalry, years of warfare, and even nuclear terrorism. Second, resources have been increasingly concentrated in the hands of a small number of people, widening the divide between classes. Finally, there is the concept of a “single point of failure,” such as Solar Winds.

Because a few agencies have monopolized a huge quantity of resources such as power, wealth, skill, and data, the repercussions of them reneging or being hacked will be severe. Lithosphere’s vision is to connect all blockchains and break the barriers between blockchains by allowing them to transact with each other. The end goal is to create a connected network of blockchains, a network of blockchains able to communicate with each other in a decentralized way.

With Lithosphere, blockchains can maintain sovereignty, process transactions quickly and communicate with other blockchains in the ecosystem, making it optimal for a variety of use cases instead of being limited to one blockchain network i.e Solana / Bitcoin / Ethereum / Cardano.

A very good use case of Lithosphere will be the transfer of NFT. Presently, NFT can only be transferred to parties within a given network. At the moment one can’t send Ethereum NFT to a Smart Chain (BSC) user or vice versa. With Lithosphere, users in the eco-system will be able to receive and send tokens from any blockchain that supports Byzantine Fault-Tolerant (BFT) consensus.

The transition from central credit authorization by institutions to inviolable mathematical principles for documenting value exchange is a significant advancement. Currency is, in essence, a consensus. It’s a standard accounting symbol for more convenient value exchange. Reviewing humanity’s financial history, from bartering one thing for another, to using cattle, sheep, or shells as universal equivalents, to the use of precious metals as money, to the current use of paper currency with a strong credit base, the human currency is approaching abstract mathematics, and its nature as symbols or ledgers is more apparent. Human accounting concepts become more aligned with mathematics as a result of blockchains.

It assists the whole accounting system in moving away from a single institution’s control and toward a more fair and transparent path. Financial Inclusion is a concept that aims to provide access to the financial system and low-cost financial services for disadvantaged individuals and small businesses throughout the world. Two and a half billion individuals worldwide are unable to use banks, create savings accounts, or acquire credit cards, thus cutting them off from the global economy. Banks charge exorbitant fees for cross-border transfers. Ordinary investors can only purchase very low- end financial goods from banks and other financial institutions, and they are unable to participate in early-stage investments in technology companies such as Google and Alibaba until they are listed on the stock exchange.

Many small and medium businesses are also having difficulty obtaining loan support from banks, despite having strong credit and excellent performance, because they are not traditional banks’ target clients under the 80/20 rule. The development of blockchain technology is altering the conditions described above. Bitcoin is used to pay workers in other nations, such as El Salvador. Investors who took part in the initial coin offerings (ICO) of well-known blockchain projects like Bitcoin and Ethereum saw returns hundreds of times their initial investments. Inclusionary finance is reaching new heights thanks to blockchain technology. Many organizations are exploring ways to record traditional forms of assets, such as commercial bills and loyalty points, into blockchains, usually in the form of consortium chains. Cryptocurrencies are becoming more acceptable as a form of payment in financial transactions; many organizations are exploring ways to record traditional forms of assets, such as commercial bills and loyalty points, into blockchains, usually in the form of consortium chains. There has been the emergence of digital asset exchanges, which are comparable to traditional financial organizations.

The banking function of exchanging digital assets is performed by these exchanges. They are similar to stock exchanges in that they provide a platform for purchasing and exchanging tokens. The functionalities of a platform for cross-border token transfers are comparable to those of cross- border bank remittances. However, these platforms operate in a centralized way to varying degrees, which not only introduces security issues associated with centralization but also prevents the widespread use of blockchain technology. We need a distributed “bank” based on this phenomenon, where multiple digital currencies and digital assets may be moved in, out, and swapped via blockchains. We require a location where financial products and contracts based on digital currencies and digital assets may be developed and executed, as well as a secure environment to safeguard transaction privacy. Of course, such “banks” will be nothing like traditional banks, except for a few services like debit and credit, remittance, settlement, and financial product sales. Any company or individual with sufficient expertise and cash can open their business windows. They may offer a variety of services while maintaining the security of a distributed blockchain infrastructure, allowing them to deliver more financial services to more people. This is a future financial infrastructure built on digital assets and a distributed financial market, to be more precise.


# Design Objectives

The major benefit of blockchain is that it aids in resolving the issue of trust that plagues humanity, making blockchain technology raising human civilization’s level. Its growth is unstoppable because of the human need to reduce transactional expenses. Because each blockchain can perform peer-to-peer value transmission, unlike the original Internet of Information (IoI), blockchain technology moves us from the age of IoI to the age of the Internet of Value (IoV), which may be considered the third generation of the Internet.

Lithosphere has established the following goals based on research on cross-chain technology, AI & Machine Learning, as well as the features of decentralization and its application scenarios, to develop a more widely disseminated blockchain technology and digital asset applications:

#### **Cross-chain Asset Transfer:**

* Connecting large digital currency networks (such as Bitcoin and Ethereum) and completing asset transactions without changing the original chains’ mechanisms. This allows Lithosphere to incorporate freshly created digital currency networks at a very cheap cost.
* Integrate Lithosphere with consortium chains. This handles asset transfers from original chains to Lithosphere, asset transfers from Lithosphere back to original chains, and asset trading on Lithosphere.
* Ensure that cross-chain transactions are secure and that cross-chain transaction services are stable.

#### **Transaction Privacy Protection:**

* Allow trade parties to select whether or not to execute transactions privately.
* Provide privacy protection for digital asset transfers and exchanges.
* Provide holders of digital assets with anonymous protection.

#### **Functional Extensibility:**

* Become a decentralized platform for the trading of non-fungible assets and digital currency. Operate a deposit and lending company for several digital currencies.
* Use digital money as a vehicle for digital asset transactions.
* Create brand new digital financial assets and exchange them.

![](/files/gXvkgKPRokDooG6kL5gQ)

The world has changed dramatically as a result of the Internet of Information. Human civilization is destined to undergo massive societal transformations as a result of the Internet of Value. This is due to the qualities of digitalization, intelligence, decentralization, and inclusiveness that the Internet of Value-based on blockchain technology possesses. Digitization and intelligence, which can help the Internet of Value run more efficiently, are elements that already exist on the Internet of Information, but are now being applied to the Internet of Value.

Decentralization is an even more important feature since it will assist to eliminate the bottleneck caused by centralized organizations. People can better safeguard their personal property rights with private keys; they can better resolve conflicts with consensus mechanisms, and they can engage in collaboration in the division of labor with peer-to- peer networks with much lower obstacles. People join the Internet of the Information age when they can easily transfer information over the Internet and program information using algorithms; they will enter the Internet of Value age when they can easily send value over the Internet and program value using smart contracts. The Internet of Value benefits gives it a “high-dimensional” edge over traditional collaboration models.

On blockchains, all types of “values” will be expressed and easily exchanged and programmed. As a result, people’s collaboration relationships and human civilization would undoubtedly be drastically altered. The Internet of Value will allow individuals to handle values as if they were informed, and its primary role will be to communicate values. However, to fulfill this purpose, the Internet’s worth must improve in three areas. Interoperability is the first. Values reside on many blockchains, centralization organizations, and data centers, and the Internet of Value necessitates public chains or other solutions that can interact across blockchains, centralization organizations, and data sources, as well as transfer values and perform smart contracts.

The second factor is scalability. The Internet of Value must be adaptable to a variety of circumstances, including banking, industry, and government administration. The last point to consider is usefulness. The Internet of Value requires a robust ecosystem and the ability to operate a wide range of apps seamlessly so that developers can create applications quickly and consumers can easily utilize them. However, compared to the Internet of Information, the Internet of Value is still in its early phases, with interoperability, scalability, and usability limitations. In terms of interoperability, although the Internet of Information has been able to transmit and program words, photos, audio, and video as a unified bit of information, the Internet of Value continues to struggle with communicating values between blockchains, much alone off-chain values, and data. Not only does the Internet of Value necessitate cross-chain connectivity, but it also necessitates connection with centralized entities and external data sources.

Tokens on separate blockchains can’t trade with each other since existing blockchains can’t communicate with each other (synchronization of state machines). Because blockchains presently cannot communicate with centralized organizations outside of the blockchain, it is difficult to map off-chain assets onto the blockchain. Because existing blockchains can’t read off-chain data, “smart” contracts on them are blind or dumb, unable to see or communicate with the outside world. Taking cross-chain technology as an example, cross-chain communication, much alone building cross-chain smart contracts, is now exceedingly challenging. There are thousands of different types of tokens now available, but each one can only move freely on a single blockchain and has its ecosystem of wallets, smart contract creation tools, and so on.

Existing blockchain networks are essentially island ecosystems, and the Internet of Value is still a long way from being genuinely interoperable. In terms of scalability, while the Internet of Information is constantly expanding by encoding various data as bits and programming various scenarios’ communication logic as applications, the Internet of Value is only just getting started by tokenizing various values as tokens and mapping various scenarios’ transaction logic as smart contracts. The Internet of Value scale is severely constrained due to its lack of compatibility. The transfer of off-chain values to the Internet of Value is hampered by the difficulty of mapping actual application scenarios involving various currencies, numerous organizations, and multiple data sources to a blockchain to build a distributed solution. In terms of usability, whereas the Internet of Information’s processing power, storage capacity, and synchronous speed were sufficient to handle most information management needs, the Internet of Value can only accommodate somewhat larger projects. In terms of standardization, platformization, functional modularity, application ecology, interoperability, and anti-quantum assaults, the Internet of Value has a lot of work ahead of it. Interoperability is the most pressing of the three types of obstacles listed above, since it allows us to move assets between blockchains, design smart contracts with various currencies, and improve update scalability. Usability, on the other hand, is a long-term effort, but interoperability and scalability, which have slowed the growth of the Internet of Value, require a quick fix and have become the two most pressing barriers to be addressed.


# Disclaimer

This Lithosphere Whitepaper is for information purposes only. The KaJ Labs Foundation does not guarantee the accuracy of or the conclusions reached in this whitepaper, and this whitepaper is provided “as is”. KaJ Labs Foundation does not make and expressly disclaims all representations and warranties, express, whether explicit, implied, statutory, or otherwise, whatsoever, including, but not limited to: (i) that the contents of this whitepaper are free from error; (ii) that such contents will not infringe third-party rights; and (iii) warranties of fitness for a particular purpose, suitability or function.&#x20;

KaJ Labs Foundation and its affiliates shall have no liability for damages of any kind arising out of the use, reference to, or reliance on this whitepaper or any of the content contained herein, even if advised of the possibility of such damages. In no event will KaJ Labs Foundation or its affiliates be liable to any person or entity for any damages, losses, liabilities, costs, or expenses of any kind, whether direct or indirect, consequential, compensatory, incidental, actual, exemplary, punitive or special for the use of, reference to, or reliance on this whitepaper or any of the content contained herein, including, without limitation, any loss of business, revenues, profits, data, use, goodwill or other intangible losses.

####


# Glossary

**LEP100:** Lithosphere Evolution Proposal

**WHITE PAPER:** A guide about a specific topic and the problem that surround it. It is meant to educate readers and help them to understand and solve an issue.

**BLOCKCHAIN:** A growing list of records, called blocks, that are linked together using cryptography.

**TOKEN:** A token represent a set of rules encoded in a set of smart contracts. Each token belongs to a blockchain address. It is essentially a digital asset that is stored securely on the blockchain.

**DECENTRALIZED:** Type of cryptocurrency exchange which allows for direct peer-to- peer cryptocurrency exchange to take place online securely and without the need for an intermediary.

**EVM:** Ethereum virtual machine is a computation engine which acts like a decentralized computer that has millions of executable projects.

**BSC:** Binance smart chain

**PEGGED COINS:** LEP100 tokens pegged to external assets.

**DAPPS:** Decentralized Applications are digital applications that run on a blockchain or peer-to- peer network of computers instead of a single computer.

**NFT:** A non-fungible token is a unit of data stored on a digital ledger, called blockchain, that certifies a digital asset and therefore not interchangeable.

**INTEROPERABILITY:** The ability of computer systems or software to exchange and make use of information.&#x20;

**ERC:** Ethereum request for comments

**BURN:** A process by which digital currency miners and developers can remove tokens or coins from circulation.

**TRACTION:** Drawing or pulling rate in a business.

**DEFI:** Decentralized finance

**CROSS CHAIN:** It is the interoperability between two relatively independent blockchains.&#x20;

**DEX:** Decentralized exchange&#x20;


# Litho Coin

![](/files/caRPnY6NXEiTDYC60VvC)

𝕃itho is the native coin of 𝕃ithosphere. Both cross-and intra-chain transactions consume a certain amount of 𝕃itho. 𝕃itho is also used in security deposits for the cross-chain verification nodes. 𝕃itho / $LITHO is the currency of choice in the 𝕃ithosphere network although another crypto can be used as well since the 𝕃ithosphere blockchain supports interoperability.

𝕃ITHO Tokenomics - <https://docs.google.com/document/d/1zICM7rdkGK5BML7Jmi2OzBy5cSllTE5h3PRHZAEeoa0/edit?usp=sharing>


# LEP100 Multi-chain Token Standard

![](/files/ketKgD0T0OtCZg4M3vsX)

The LEP100 is a novel standard for multi-tokens, allowing for a single contract to represent multiple fungible(currency) and non-fungible tokens (NFT) and batched operations for increased gas efficiency proposed by Joel Kasr, creator of Lithosphere. Most importantly, LEP100 tokens can exchange for any other token equivalents. LEP100 tokens are fueled using the native Litho coin (LITHO). When pegged with the LEP100 tokens, you may also peg onto any networks utilizing any major digital assets. The token is multi-contract compliant and has basic features like transferring, returning a balance, and examining a token’s possession.&#x20;

A LEP100 token, unlike ERC20 or BEP20, allows a single contract to represent numerous fungible and non-fungible tokens, allowing for a wide range of applications in everyday use. It is the most efficient token for DeFI platforms, gaming platforms, NFT, and another high-demand contract–compatible platforms. LEP100 may also be easily integrated into any Ethereum dApps or other chains because it can be traded for ERC20, ERC-721, ERC-1155, BEP2, and BEP20 tokens.&#x20;

The LEP100 establishes best practices for managing cross-chain tokens. Due to their similarities, the tokens are compatible with ERC20, ERC-721, ERC-1155, BEP2, and BEP20. The LEP100 token standard also allows for token time-slicing in smart contracts. When a token is sliced, it is split into two parts: one is a time-limited slice (here TL is for Time-Lent), and the other is an infinite end (here TL stands for Time Restricted, since its utility is limited for a time but not locked). Both slices can be split into two more time slices if needed, allowing for sophisticated DeFi such as options and futures trading.


# LEP100 Token Features

The LEP100 token offers many outstanding features, including

* High-speed transaction speeds: the LEP100 token standard enables high-speed transaction rates, making it extremely scalable.
* Low transaction fees: unlike Ethereum Networks, users will not be charged hefty gas prices.
* Cross-chain compatibility: The LEP100 tokens are supported by ERC20, ERC-721, ERC-1155, BEP2, and BEP20 networks and blockchains.
* Compatible with nearly every major cryptocurrency wallet on the market today.
* Easy to sell on exchanges: The LEP100 tokens are simple to list on exchanges and have a better probability of being sold.

####


# LEP100 Token Standard

LEP100 specifications are followed by all Lithosphere tokens. The Lithosphere network is a multi-chain architecture that allows anybody to develop dApps and other blockchain-based digital assets. It also ensures cross-chain trade, minimal gas consumption, and quick transactions with safe transactions.

LEP100 makes it possible for tokens on the Lithosphere blockchain to function properly. As a consequence, everyone benefits from low transaction fees.

Furthermore, regardless of the blockchain network’s structure, the cross-chain DeFI mechanism improves the interoperability of all tiny contracts. The Lithosphere environment is highly supportive, and the Litho Launchpad finances all bootstraps with various DeFI programs.


# Linear-communication BFT Consensus

The Litho protocol utilizes a BFT (BFT stands for Byzantine Fault-Tolerance) algorithm to achieve this. A Byzantine Fault-Tolerant consensus algorithm guarantees safety for up to a third of Byzantine, or malicious, actors. Byzantine faults within distributed systems are some of the most difficult to deal with.

A blockchain framework like Lithosphere powered by BFT allows public and private blockchains to transfer tokens to each other.

A BFT powered blockchain network (Lithosphere) allows interoperability with other PoS / fast finality blockchains like Cosmos, Binance or Proof of Authority & PoW blockchains.

Lithosphere adapts a new consensus algorithm, LinBFT proposed by Dr. David Yang. The Linear-communication BFT Protocol (LinBFT) applies to a permissionless, public blockchain system, in which there is no public-key infrastructure, based on the classic PBFT with 4 major improvements:

* Per-block consensus. There is consensus for each block, rather than for a group of blocks. This limits the power of the block proposer, and, thus, mitigates selfish mining.
* Rotating leader. The LinBFT protocol changes the leader (i.e., block proposer) for every block, which reduces the risk of denial-of-service attacks on the leader.
* Changing honesty. In Pyramid LinBFT, a participant can be honest for one block, and malicious for another (e.g., one containing a transaction of interest to the participant), as long as over 2/3 of all participants are honest for each block. In other words, it is possible that every participant is malicious at some point, and yet the blockchain remains secure at all times.
* Dynamic participant set. LinBFT allows nodes to join and leave the protocol at the beginning of epochs. As a result, different blocks may be verified by completely different sets of nodes.

Further, in the ordinary case, LinBFT involves only a single round of voting instead of two in PBFT, which reduces both communication overhead and the confirmation time and employs the proof-of- stake scheme to reward all participants. Extensive experiments using data obtained from the Ethereum test net demonstrate that LinBFT consistently and significantly outperforms existing in- production BFT protocols for blockchains.\\

####


# Lithosphere Algorithmic Cryptocurrency - LAX ⋉

LAX ⋉ is a 𝕃ithosphere ecosystem cryptocurrency with an algorithmically adjusted circulating supply. It is designed to be the base money of the new decentralized economy, by providing an asset that cannot be diluted by supply inflation and remains decoupled to the price action of other cryptocurrencies like Bitcoin (BTC).

LAX ⋉ has a dynamic supply which is determined by supply and demand which ensures it is always worth $1. Unlike coins like U.S. Dollar Coin (USDC) and Tether (USDT) which are backed by audited holdings of U.S. dollars or crypto assets like PAX Gold (PAXG), LAX ⋉ is not pegged to the U.S. dollar or any crypto collateral.

LAX ⋉ can be used for a variety of purposes, such as generating yield, leveraging both the price & yield, providing liquidity and serving as collateral across the Lithosphere ecosystem.


# Lithosphere Applications

#### Borrowing and Lending

Using digital money to produce new value and earn revenue is an unavoidable trend as it grows in importance as a medium of value exchange and a value storage carrier. Bitcoin, for example, is used to fund blockchain mining companies and other crypto initiatives. Direct investment options for digital currency have expanded as the variety of applications for digital money has grown.

Those who generate value with digital currencies need more of them, and people who own digital currencies want to raise their value, thus demand for borrowing and lending digital currencies will rise.

Consider the cryptocurrency Ethereum (ETH). On Lithosphere, a service provider creates a deposit application and sets the interest rate using a smart contract.

Through a cross-chain transaction, a user sends ETH from the Ethereum blockchain to the Lithosphere smart contract address. The deposit on Lithosphere generates a voucher (Lithosphere tokens that look like deposit bank receipts) that is credited to the user’s Lithosphere account. The smart contract then calculates the interest for you. When the user wants to withdraw the money, the voucher is sent to an intermediate address, and a cross-chain transaction is carried out. On the original chain, the ETH corresponding to the voucher is unlocked and sent back to the original user’s account. Deposit reserves (the assets locked on the originating chain that correspond to the intermediate address) are always visible.

#### Payment and Settlement

Businesses are increasingly accepting digital assets such as Bitcoin as a form of payment. There will be more applications in the future that employ a range of digital currencies for payment. There are several payment options available today, including VISA, Paypal, and Alipay, each with its own set of payment and settlement procedures. The lithosphere is a multi-currency distributed platform that combines many banking ledgers into a single unified ledger. Without needing to install several digital currency wallets, any business or user may utilize the Lithosphere wallet to make multi- currency payments and settlements.

#### Transaction and Exchange

At the moment, centralized exchanges and over-the-counter marketplaces are required to complete digital currency trades. Every transaction is dependent on the exchanges’ and intermediaries’ confidence. After several currencies have been linked with Lithosphere, exchanges and intermediaries may use smart contracts to enable multi-currency auction trading and one-to-one curb transactions. On Lithosphere, the privacy protection transaction mechanism supports transactions that require privacy protection. Importing digital money into Lithosphere, starting private transactions on Lithosphere, and moving digital currency back to the original chain are all possible with Lithosphere. The original chain’s privacy is protected to some extent by concealing the fund tracking paths. Lithosphere can handle 1,000,000 transactions per second (TPS) compared to Bitcoin which processes 4.6 transactions per second, Ethereum does 15 TPS, and Ripple handles 1,700 TPS. Visa does around 1,700 transactions per second on average (based on a calculation derived from the official claim of over 150 million transactions per day).

#### Investment and Financing

Traditional institutions are increasingly turning to consortium chains to store assets such as commercial invoices, loyalty points, future earning rights, and accounts receivable. More financial assets will be recorded on consortium chains-based distributed ledgers in the future. When these consortium chains connect to Lithosphere, they become financial asset providers, and investors may acquire these assets with their digital currencies. It’s similar to buying financial goods at a bank, as in the traditional banking company. The main distinction is that more intermediaries can participate, and asset owners can finance themselves directly.

In the blockchain world, Initial Coin Offerings (ICOs) / initial exchange offerings (IEOs) have become a popular way to raise funds, and the practice is expanding to non-blockchain domains. Smart contracts are being used directly for ICOs by an increasing number of projects, particularly those built on Ethereum or BSC, making the process more open and equitable. However, ICOs that exclusively accept Ether annoy investors who possess other digital currencies. The ICO issuer can use Lithosphere to create a smart contract that enables multi-currency investments. Investors may invest more easily using Ethereum, Bitcoin, or any other blockchain token linked with Lithosphere, and issuers can manage their funds more simply. Furthermore, when a new blockchain is released, the Lithosphere cross-chain transactions may be used to convert the crowdfunded shares to the local currency. With Lithosphere, we’re entering a new age of blockchain-based digital right issuing

#### More Applications

The financial applications mentioned above are meant to help readers better grasp Lithosphere’s rationale and value. More examples include multi-currency credit cards based on digital money, asset- backed securities that bundle a range of assets, peer-to-peer lending firms based on digital currencies, and crowdfunding, among others.

Major banks see blockchain technology as an essential strategy, but they’re also looking at how it might be used to alter traditional business.

Banking, such as currency exchange, has been flourishing in the realm of digital money. In these sectors, blockchains are progressing on two parallel tracks, but with the emergence of digital assets and their increasing integration into the actual economy, these two tracks will eventually cross. Bank balance sheets will be largely moved to blockchains, and digital assets will be incorporated in bank balance sheets (banks that enable the loan and deposit of digital assets) (fiat money is represented and accounted for by blockchain tokens). This future integration will be supported by Lithosphere’s inter-ledger technology.


# Lithosphere Architecture and Technology

![](/files/a3MrZC9Xezv8ufaXvAfF)

#### **Distributed Private Key Management and Smart Contract Virtual Machine**

Because DeFi assets are displayed as tokens, they can substantially improve the interoperability of the Internet of Value and make increasing scalability much easier if multi-token smart contracts can be implemented. The present cross-chain technology is mostly side-chain technology, which uses a two-way peg to transfer transactions to side chains and multiple signatures to exit side chains. Such a method can only produce atomic transfers, and the results are unsatisfactory in nearly every way. We need to create a public chain that allows other tokens to be mapped to it in a more inventive fashion, so that multi-token smart contracts may be created.&#x20;

We can substantially improve the interoperability of the Internet of Value in this manner, and this public chain will undoubtedly become one of the most important DeFi infrastructures. It not only communicates value between blockchains but also enables interfaces with centralized organizations and off-chain data sources to increase the Internet of Value scalability. On a new public chain, how will various tokens be expressed? We envisage that the tokens’ private keys on various blockchains can be securely controlled in a distributed fashion by a public chain and in this way, the blockchain manages the control rights of tokens. It will be like a “freeway” on the Internet of Value, which can easily implement the value transfers between various tokens and multi-token smart contracts to provide various DeFi services.

Since almost all blockchain tokens are controlled by private keys, value on the Internet of Value can be distributedly managed by smart contracts as long as the private keys of their tokens can be controlled by distributed nodes of a public chain. With Turing-complete smart contracts, the public chain can also provide various functions of decentralized finance (DeFi) in a more sophisticated form.\
This blockchain, which connects all tokens, does not require complex logic for various application scenarios. Its purpose is to create a layer of management across all blockchains, enabling all tokens to interact. Because it does not need to run heavy application logic, in its current usability it is capable of fulfilling various DeFi functions.


# Myriad Distributed Key Management (MDKM)

![](/files/dKXeAvvCz9STdUgP3U0p)

Lithosphere is based on the theories and achievements of distributed key generation (DKG) in the field of cipher- sharing. The public key and the private key are both generated by nodes cooperating to communicate. The public key is broadcast in the public chain, the private key is separately stored by each node in a distributed manner through Variable Secret Sharing (VSS). The common public key is generated by the DKG algorithm, and then the account address of the Lock-in is generated by the corresponding algorithm to realize decentralized control. Here we refer to the domain of VSS and DKG based on elliptic curve cryptography distributed key generation protocol and application research on the process described below: Given elliptic curve E, there exists a finite field GF (q), q is a prime number with n participant sets Q = {P1, P2, …, Pn}, pi denotes the identity of the ith participant Pi, and Pi ∈ GF ∗ (q), where GF ∗ (q) is a multiplicative group on GF (q). In the meantime, pi and I are interchangeable during the calculation. E/GF (q) represents the additive group on E. T is E/GF (q), the order of E/GF (q) is a prime number or prime factor, marking this prime or prime factor as p. In this key generation protocol, it is assumed that both scalar multiplication and dot multiplications are done at δ and that the other operations are done at GF (q). To calculate Q (x) T, we first compute Q (x) and then p(x) mod p, and Q (x) mod p is the scalar multiplication on T. Let us assume that E has another base point T ′ on the elliptic curve δ.


# Myriad Distributed Key Management

Myriad Distributed Key Management realizes the generation of public-private key pairs and addresses and the transaction signatures on the target blockchain in a distributed manner through several nodes and according to digital signature algorithms adopted by the target blockchain, thus realizing the control and management of accounts and assets on the target blockchain in a distributed manner.

![](/files/14xDetTuUmsf3Gq0TuW2)

Such a technical route enables MDKM to be compatible with as many digital assets controlled by encryption algorithms as possible, whether these digital assets are generated on a centralized or decentralized basis. By supporting a signature algorithm with MDKM, a series of encrypted digital assets with the same signature algorithm can be controlled and managed.

At present, most (over 80%) of encrypted digital currencies adopt the same ECDSA signature algorithm as Bitcoin and Ethereum, so MDKM first chooses to implement support for the ECDSA signature algorithm. In addition, MDKM will support encryption currencies that use different signature algorithms, such as Stellar’s Ed25519 signature algorithm \[JL17], and Schnorr’s signature algorithm.


# Positioning

We propose the Lithosphere project in light of DeFi’s bright future and the challenges that the current Internet of Value presents. The goal of Lithosphere is to create a platform-level public chain in the digital economy era that can connect all kinds of values, provide complete financial functions, communicate diverse communities and tokens, and bridge centralized and decentralized organizations to bring the Internet of Value as soon as possible with the help of blockchain, AI, and other technologies.


# Project promotion method

The concept separates community operations into two categories: core and periphery. The former prefers the offline mode, whilst the latter prefers the internet mode. The following is the strategy for key community operations:

* Lithosphere Foundation team: the team will be rewarded with tokens. One reason is to compensate for the resources used in the previous time, and the other is to allow anybody to become a shareholder and expect them to contribute to Lithosphere in the future.
* Community for blockchain technology.
* Technology is both the most important and the most difficult aspect of blockchain development. We will utilize online and offline methods to discover and nurture a group of top-tier talents to promote the technological community, using the founding team’s technical expertise and social resources.
* Blockchain value community: Using the blockchain technology community, we can organize gatherings with holders to disseminate blockchain knowledge while also promoting opportunities for collaboration with the private value community.


# Roadmap

Updated Roadmap 2022-2024

**2022 Q4 - (Kamet)**

* Finesse Genesis Collection Drop
* $JOT IEO
* Finesse: Shadow Warriors P2E Beta Release
* Team Expansion
* More CX & DEX Listings For Litho
* Litho Staking
* Key Partnerships Announced

**2023 Q1 (Batura)**

* Litho Testnet Makalu Goes Live!
* Jot Art NFT Marketplace Launch
* DAO / Community Governance & Proposal Flow Established
* MDKM Stable Release
* JOT CEX & DEX Listings
* Finesse: The Kingdom MMORPG Public Beta Live.

**2023 Q2 (Makalu)**

* Litho Testnet #2 Everest Goes Live!
* Litho DEX
* LinBFT Stable Release
* Jot Art SDK Released
* Ego Dex / Litho Bridge Stable Release
* Lithosphere Client (Wallet) Thanos Goes Live

**2023 Q3 (Everest)**

* Lithosphere Mainnet Launch ✨
* Litho Whitepaper Update
* Fleek DAO on Lithosphere Testnets
* Finesse Series Migration To Lithosphere
* LEP100 (JOT) Launch & Contract Updates
* Litho Launchpad Testnet

**2023 Q4**

* Litho Launchpad LEP100 Projects Previews
* DNNs Concept on Litho Sidechain
* LAX Algorithmic Stablecoin
* Jot Art Upgrades
* Inaugural LITHO Super Dialogues (LSD Conference).

**2024 Q1**

* Network Upgrades
* Token Standard Upgrades
* Jot Art Studio Beta Release
* More decentralization
* More TBA


# Smart Contracts & Decentralized Finance (DeFi)

![](/files/VfC90Fc60LAkE4FjnAYU)

The goal of the Internet of Value is to link different values to blockchains so that smart contracts may control them. The Internet of Value enables decentralized, disintermediated, inclusive, and programmable collaboration among individuals. Because of these apparent benefits, diverse values will race to be mapped to blockchains. The Internet of Value will undoubtedly expand at a faster rate as blockchain constraints are addressed. The process of mapping values to blockchains necessitates decoupling financial logic from business logic, implying that the Internet of Value was created with a significant financial component.&#x20;

The financial applications of the Internet of Value are those applications on the Internet of Value that have particularly significant financial features. Decentralized Finance refers to the on-chain financial operations on the Internet of Value, as well as their corresponding off- chain financial activities (DeFi). Because the Internet of Value is built on peer-to-peer networks that use the User Datagram Protocol, there are certain obstacles. The performance of the Internet of Value will progressively approach that of the Internet of Information in the future, allowing business scenarios and financial transactions to be written in the same software.&#x20;

However, given the current state of affairs, we expect this will take a long time. The present Internet of value will primarily support financial applications, i.e., DeFi apps will be the primary applications. The Internet of Information has already had a significant influence on r lives. We may also anticipate significant changes in our lives as a result of the Internet of value. We may be familiar with the many forms of information available on the internet, but few people talk about the “value” of the Internet of value. To begin with, the values on the Internet of value are tokens represented by the blockchain, and the process of mapping values to the Internet of value is known as asset tokenization.

The connected assets will be expressed by on-chain tokens and form part of the Internet of value if the tokens on the chains represent the title, gain, and control of the underlying off-chain assets. The Internet of value allows more and more values to enter itself through this process, preventing “double spending” through distributed books and making transferring value without intermediaries as simple as sending information and programming values as simple as programming information, making the Internet of value’ prospects similar to what we have seen previously regarding telecommunications. Second, tokenization is a form of asset securitization in which off-chain values are mapped onto chains as crypto assets. Because tokens may be divided indefinitely and transferred over time and space, they can be used in financial transactions like mortgages, loans, and insurance.

As a result, tokenization is defined as the process of securitizing assets and converting off-chain assets into crypto assets that can be managed using private keys. Finally, the Internet of value will include a wider range of values. Identities, signatures, data, voting rights, and other data will be mapped to the Internet of value as long as tokenization is profitable. As a result, the Internet of value will have a wider range of values than traditional financial markets.


# The Standardization of Blockchain Interfaces Movement

The Internet of Value has interoperability and scalability problems that require many parties to address. The Lithosphere project is inextricably linked to these two obstacles’ breakthrough development and advancement. By establishing the “Blockchain Interface Standardization Movement,” we will help to enhance them. For the Lithosphere Foundation, this will be a long-term project.

The movement will encourage standardization of interfaces not just between blockchains, but also between decentralized and centralized organizations, as well as between blockchains and external data sources.


# Threshold signature

The threshold signature technique can address the issue of signatures created by Lithosphere’s departing nodes while also improving the blockchain network’s stability. According to studies on node adaptation in distributed key generation networks, Lithosphere will choose appropriate nodes to join and refresh the shared key parameters in extreme circumstances to assure the chain’s successful functioning.


# Validators

In classical Byzantine fault-tolerant (BFT) algorithms, each node has the same weight. In Lithosphere, nodes have a non-negative amount of voting power, and nodes that have positive voting power are called validators. Validators participate in the consensus protocol by broadcasting cryptographic signatures, or votes, to agree upon the next block.\
Validators’ voting powers are determined at genesis or are changed deterministically by the blockchain, depending on the application. For example, in a proof-of-stake application such as the LithoSwap, the voting power may be determined by the amount of staking tokens bonded as collateral.


# Verification Nodes

To earn a portion of the transaction fees, a Validator completes the recording of transactions on Lithosphere. According to the stake it owns, a Validator receives a corresponding key share and calculates the associated signature share to be appended to the transaction. According to the key share percentage, the Validator gets the transaction fee associated with the verification transaction. The transaction fee cannot be collected if the key sharing information is unavailable or lost. If the nodes sign the incorrect transaction, the Validator’s credentials will be removed as well.

In summary, the verification node incentive system will encourage Authenticators to give proper transaction proof, Validators to faithfully finish Lithosphere recording, and Record-keepers to stay online and keep their key shares secure.

Verification nodes are only available to individuals with a large enough stake in the Lithosphere network. General nodes are nodes that do not qualify as verification nodes. The general nodes are unable to participate in the cross-chain transaction verification process, but they can commit their stakes to the trusted verification nodes. The transaction fees received by the entrusted verification nodes are distributed to the general nodes in proportion to the entrusted stakes. General nodes will suffer a comparable loss if the delegated verification node is penalized.

Stakeholders in Lithosphere can gain stake-related advantages while also being motivated to commit their stakes to trusted verification nodes thanks to this incentive mechanism. This enhances Lithosphere’s security and stability.

####


# Why should your DeFi project use the LEP100 Token Standard?

LEP100 tokens may be used to represent a variety of assets, including stocks, fiat currency, and crypto-assets. Other tokens from various blockchains may easily be pegged to the LEP100 token. As a result, it enables developers to construct different versions of crypto assets using the same tokens.

All validators that transfer the LEP100 token will receive LITHO as a reward. The incentive is paid out in the form of a transaction charge. When compared to other token standards such as ERC20, it has minimal gas prices for all transactions. It’s built on the Lithosphere network, which offers fast transaction speeds of more than 100,000-1m TPS compared to Ethereum’s ERC20’s 15 TPS and Bitcoin’s 4 TPS.

Integrating DeFI projects with LEP100 tokens is simple. You may also list items for free on DEX such as LithoSwap, PancakeSwap, and Uniswap

####


# Current Lithosphere Features

**Interoperability**

Cross-chain interoperability through a decentralized custodian model (MDKM)

**Next-generation Blockchain for NFTs**

A scalable, decentralized, cross-chain network designed to bring non-fungible tokens to everyone.

**Time-Lock Feature**

Lithosphere’s unique Time-Lock feature enables you to extract time-value out of your digital assets

**Security**

Manage and control private keys in a distributed manner with MDKM technology

**Scalability**

Solving the scaling problem is an open issue for PoW blockchains like Bitcoin and Ethereum v1. Currently, Bitcoin & Ethereum nodes process every single transaction and also store all the states. Since Lithosphere’s proof-of-stake can commit blocks much faster than Proof-of-work, EVM zones powered by Lithopshere’s consensus and operating on bridged-crypto can provide higher performance to PoW blockchains Ethereum, Litecoin & Bitcoin.

**Digital Assets**

Create, manage or even lend your own digital assets & NFT’s using the Lithosphere’s LEP100 protocol.

**Cross-chain gaming assets.**

Game economies, owned by players.

Create in-game assets that are available forever. Bring lasting value to gamers by letting them take their loot to another game or into the real world on the JOT ART blockchain-powered by Litho.


# Funding for the project

The initial distribution of litho coin and validators on Kamet (the first version of Lithosphere network) will go to the donors of the Lithosphere Fundraiser (70%), lead donors (5%), KaJ Labs Foundation (10%), network awareness (10%) and the core team members (10%). From Kamet onward, 1/3 of the total amount of $Litho will be rewarded to bonded validators and delegators every year.\
One of the vaults / Capsules in the Lithosphere will be set up to hold marketing/awareness funds.

![](https://docs.litho.ai/wp-content/uploads/2021/11/Road-map.png)

####


# Lithosphere Products

1. Lithosphere blockchain (PoS ) Litho cross-chain native token
2. LithoSwap – cross-chain DEX with NFT exchange support.
3. LEP100 Token Launchpad – Litho Launchpad
4. Thanos Multi-currency, cross-chain wallet
5. JOT NFT Platform (NFT marketplace, NFT DEX, SDK to distribute NFT anywhere cost- effectively, cross-chain) FLEEK – Decentralized community-powered gig platform on the blockchain.
6. LAX – Algorithmic Stablecoin


# Lithosphere Project Governance

**Council Members**

Elected to represent passive stakeholders in two primary governance roles: proposing referenda and vetoing dangerous or malicious referenda. Lithosphere creator Joel Kasr chairs the council committee.

**Technical Committee**

Composed of core teams actively building Litho. Can propose emergency referenda, together with the council, for fast-tracked voting and implementation.

**Community Members**

Can make and vote on proposals to improve Lithosphere.

#### Tokenomics

Total Supply : 1 billion

![](https://docs.litho.ai/wp-content/uploads/2021/11/Lithosphere-whitepaper-1-Billion.png)


# documentation


# LEP100 paper

## LEP100 Yellowpaper

## LEP100 TOKEN STANDARD

### Joel Kasr

### Founder, KaJ Labs & Lithosphere

#### <joel@kajlabs.com>

### ABSTRACT

Thank you for your interest in the LEP100 token standard. This token standard is a set of rules that tokens on Lithosphere’s project launchpad will follow. It’s the same standard Lithosphere’s native token LITHO follows as well. This yellow paper explains all it entails. This detailed information is absolutely constituted for information only, to present the LEP100 token standard.

### DISCLAIMER

This research proposal is for information purposes only and may be subject to change without prior notice. The author does not make or purport to make, and hereby disclaims any representation, warranty, or undertaking in any form whatsoever to any entity or person, including any representation, warranty, or undertaking in relation to the accuracy and completeness of any of the information set out in this document.

The author accepts no liability for damages, whether consequential or indirectly, of any kind arising from the use, reference, or reliance on the contents of this document.

Prospective purchasers of LEP100 tokens should evaluate all risks and uncertainties associated with the token and all information set out in this document and any related terms & conditions prior to any purchase of the native Litho token or LEP100 tokens. You are not eligible to purchase the native Litho token if you are a citizen, resident (tax or otherwise) in any jurisdiction in which crypto trading is not permitted. No regulatory authority has examined or approved of any of the information set out in this document.

No advice, no information in this proposal should be considered to be business, legal, financial, or tax advice regarding this token. Please consult your own legal, financial, tax, or other professional advisers regarding buying any cryptocurrencies.

### 1 INTRODUCTION

#### 1.1 MOTIVATION

Drawing inspiration from early token standards like ERC20, BEP20, & ERC-115, the Lithosphere blockchain introduces a new token standard, the LEP100 (Lithosphere Evolution Proposal 100) token standard made by KaJ Labs founder Joel Kasr. The LEP100 is a novel standard for multi-tokens, allowing for a single contract to represent multiple fungibles and non-fungible tokens, along with batched operations for increased gas efficiency. Most importantly, LEP100 tokens can also exchange for other token equivalents.

#### 1.2 What Is Lithosphere?

Lithosphere is the next-generation platform for cross-chain decentralized applications powered by AI & Deep Learning. <https://lithosphere.network> / <https://litho.ai> Lithosphere is a blockchain platform with the ability to run smart contracts optimized for ultrafast trading with a much higher transaction throughput of more than 10,000 TPS.

Lithosphere is explicitly designed for interoperable, fast, and non-custodial (decentralized) blockchain trading. It came with a utility token called Litho / LITHO, with a fixed supply of 1 billion LITHO tokens.

Lithosphere was launched is a programmable smart contract blockchain platform. Lithosphere is fully compatible with Ethereum Virtual Machine (EVM), Binance Smart Chain (BSC) and other blockchains that support ECDSA. Developers can migrate their existing EVM or BSC-based applications directly to the Lithosphere platform.

Even though Lithosphere (Litho) runs parallel to other blockchain platforms, it shouldn't be categorized as a side-chain or a Layer-2 scalability solution. Litho is an independent and stand-alone blockchain that can keep running even if the other chains go offline.

Since Litho is multi-chain compatible, developers can steadily port their dApps, but investors can use their best-loved tools like Meta mask to interact with Lithosphere. This native compatibility will help Lithosphere take advantage of the rich blockchain ecosystem that exists today.

Lithosphere uses Proof of Stake (PoS), which helps it achieve \~3-second average block time, making it much faster than Ethereum. With PoS, validators secure the web by staking their LIT coins. Validators also receive transaction fees assembled from every block they validate.

Lithosphere has a multi-chain architecture with cross-chain compatibility to EVM, BSC, and other chains. Users can effortlessly and quickly transfer assets across various blockchains using a supported wallet, like Thanos Wallet, Meta mask or Trust Wallet.

Another cogent aspect of major assets such as BTC, ETH, and others is that they are already on Lithosphere as Pegged Coins (LITHO tokens pegged to external assets). You can effortlessly transfer these pegged coins to Lithosphere and use them in various DApps on the Litho platform. For example, you can transfer Ether from your wallet to buy NFT art on the Binance Smart Chain or any other blockchain using the Lithosphere pegged Ether - ETHL or BTC / BTCL.

#### 1.2.0 LEP100 vs. OTHER TOKENS

There are numerous programmable blockchain platforms with the capacity to run smart Contracts, and each one has a different token standard. This section will compare LEP100 with two of the most prominent and leading token standards available today:

ERC-20, ERC1155 and BEP-20.

#### 1.2.1 LEP100 vs. ERC-20, ERC1155 & BEP-20

LEP100 and ERC-20 token standards have many similarities. LEP100 is an extended Version of the ERC20 and ERC-1155 standard and has similar functions for providing Foundational elements, such as token issuance, token transfer, and ownership.

Lithosphere has recently introduced a cross-chain bridging service called the Litho Bridge, which provides interoperability between different blockchains. The Project currently supports cross chain transfers for BEP-20, ERC-20, ERC1155, and TRC-20 tokens.

With Litho Bridge, you can convert your native crypto assets to LEP100 tokens.

Let's discuss this with the following example: If you're transferring ERC-20 Stablecoin to Lithosphere, Litho Bridge will do the cross-chain conversion, from the ERC-20 to LEP100 tokens, which can be used on either Lithosphere or dapps running On the Lithosphere network.

Litho Bridge charges no conversion fees at all, and you only have to pay the network Fees of the blockchain associated with the transaction. You have to be patient for a while, waiting for conversion because it takes a few minutes.

This conversion process from the native blockchain (ERC-20, ERC1155, BEP-20) To LEP100 is called Peg-in. This conversion also works opposite (called Peg-out), i.e., Converting back from LEP100 to the native blockchain (ERC-20, ERC1155, BEP-20). A Compatible wallet such as Thanes wallet or Meta Mask is needed to complete the Peg-in and Peg-out process.

#### 1.2.2 MAJOR LEP1000 TOKENS

The Lithosphere ecosystem is thriving, and the platform is getting high amounts of Traction. This division will explain some of the most prominent and popular LEP100 Tokens launched on the Litho platform.

**1.2.2.1 Litho Pegged Tokens (Peg Coins)**

Peg Coins are a class of Litho tokens on the Lithosphere platform pegged and fully Backed by one ratio of one crypto asset. As of this writing, there are cumulatively 40 Most popular pegged LEP100 tokens available on the Litho platform, including ETH, BTC, USDT, LTC, and XXR.

The end-user can either purchase these pegged tokens or interchange them with Their existing tokens to use on the Lithosphere platform. Also, users can redeem these Pegged tokens to the native crypto assets. Many Defi dapps are launching on the Lithosphere platform, and these pegged tokens permit users to interact with them and Gain from their offerings.

#### Jot Art Token (Jot)

Jot Art is the Lithosphere counterpart of Ethereum's Enjin with added perks and features.

**1.2.3 LITHO USD ALGORITHMIC Stablecoin (LUSD)**

Litho USD coin (LUSD) is similar to algorithmic stablecoin protocols operating on the Ethereum blockchain. Still, unlike coins like U.S. Dollar Coin (USDC) and Tether (USDT), which are backed by audited holdings of U.S. dollars or crypto assets like PAX Gold (PAXG), Litho USD coin is not li to the U.S. dollar or any crypto collateral. Instead of Using crypto, fiat, or commodities as collateral, the Lithosphere protocol adjusts its LUSD Crypto supply every 24 hours in operation called "rebasing" to maintain a stable price.

**1.2.4 LITHO NATIVE TOKEN (LITHO)**

Litho coin (LITHO) is Lithosphere’s native token. It fuels all LEP100 tokens.

**1.2.5 HOW DO YOU GET LEP100 TOKENS?**

Getting LEP100 tokens is as easy as obtaining any other token. Below are four different ways you can get hold of some LEP100 tokens:

**✞ LITHOSWAP DEX AND LAUNCHPAD:** Litho DEX is a decentralized crypto exchange. You can use LithoSwap DEX to discover and buy promising LEP100 tokens in a noncustodial (decentralized) environment.

**✞ THANOS WALLET:** You can discover and purchase LEP100 tokens right from your Thanos Wallet interface, which is super convenient.

**✞ PANCAKESWAP, UNISWAP:** You can also use an AMM-based decentralized exchange to accumulate LEP100 tokens by interchanging your existing crypto assets supported on PancakeSwap.

#### 1.3 What Is LEP100?

The LEP100 is a novel standard for multi-tokens, allowing for a single contract to represent multiple fungible (currency) and non-fungible tokens (NFT) and batched Operations for increased gas efficiency proposed by Joel Kasr, creator of Lithosphere. Most importantly, LEP100 tokens can exchange for any other token equivalents. LEP100 Tokens are fueled using Litho Coin (LITHO).

LEP100 is a Lithosphere token standard that extends Ethereum's ERC-20, BSC's BEP20, and ERC1155 standards. LEP100 defines a framework and a set of rules that Lithosphere-based tokens have to follow. LEP100 is fully compatible with ERC-20, ERC-721, ERC-1155, and Binance Smart Chain's BEP-2, BEP-20 as well as other similar token standards.

The LEP100 token standard applies to all kinds of tokens that will launch on the Lithosphere platform, such as tokenized securities, stablecoins, or even NFT.

Pegged Coins, which are LEP100 tokens pegged to other crypto assets such as BTC and LINK, also follow the LEP100 token standard.

The transaction fees for all the LEP100 tokens are paid with LITHO, the native token of The Lithosphere network. This working principle is part of the pos consensus rules. It provides an incentive to the validators as they amass transaction fees for the blocks, they validate on the Lithosphere network.

Since Lithosphere supports cross-chain interoperability with several existing Chains like EVM, BSC, etc., LEP100 tokens can be used on EVM, BSC, or other Blockchains for fast trading on lithoswap DEX.

Creating your LEP100 token is relatively straightforward, even if you don't have any Prior programming experience. The Litho Launchpad provides an intuitive user interface For creating your LEP100 tokens. You need to provide the name of your token, a Symbol, and a few other parameters to successfully create your LEP100 token.

Let's summarily discuss these parameters for a better understanding of the LEP100 Token standard.

**○ Fungible & Non-Fungible:** Can represent both fungible assets, e.g., currency, or Non-fungible Assets like art, collectibles, music, etc.

**○ Time Slicing:** LEP100 is a time-slicing token standard on the Litho blockchain. It's Superior to ERC20 tokens in that it supports time slicing. Time slicing adds start Time and end time attributes. Only the tokens whose current time is within the start Time and end time are valid.

**○ Cross-chain:** Can be exchanged with ERC20, ERC-721, ERC-1155, BEP2, BEP20, or any similar token equivalents allowing interoperability within networks.

**○ Can Burn:** This parameter describes whether the LEP100 tokens can be burned To reduce the supply over time, making it deflationary.

**○ Can Mint:** This parameter is anonymous to Can Burn, and it specifies whether New LEP100 tokens can be minted to expand the supply over time, making it Inflationary.

**○ Can Pause:** This parameter is important in case of a malicious attack or software Vulnerability. It describes whether all the operations associated with your tokens Can be paused when needed. Only the generator of a token or an address with Necessary permission can pause all the operations.

**○ Blacklist:** This parameter is analogous to Can Pause. It gives you the ability to Blocklist specific addresses that are acting maliciously. These variables give a lot Of control to the central authority (the producer), so they won't be suitable for Many use cases.

Once all the parameters are described and the token is generated, you will have sole Possession of the token, and it will be dispensed to your stated address. The smart Contract for the coin will be impulsively published to Lithosphere, and you only need to Pay the required transaction fees.

#### 1.3 HOW DO YOU STORE LEP100 TOKENS?

Storing your LEP100 tokens is as simple as it can be. All you need is a wallet that allows LEP100 tokens. Below are three different ways you can store your LEP100 tokens:

**✞ METAMASK:** Even though Meta mask is a famous Ethereum wallet, you can connect Meta mask with Lithosphere and store your LEP100 tokens.

**✞ THANOS WALLET:** Thanos Wallet is a decentralized multi-currency wallet. You can send, receive, store, swap, stake, borrow, lend and purchase LEP100 tokens without even leaving the app's interface. The Thanos Wallet has iPhone, Android apps as well as browser extensions available on Chrome and Firefox. It is super simple and direct to use and helps you store LEP100 tokens and interact with DApps on the Lithosphere platform. 6

**✞ TRUST WALLE:** Trust wallet is a decentralized multi-currency wallet. Using Trust Wallet, you can send, receive, store, swap, and purchase LEP100 tokens without even leaving the app's interface.

#### 1.3.1 LEP100 TOKENS ARE FUELED USING LITHO COIN (LITHO)

This means it allows even more integrability within the Lithosphere network and other native blockchain networks like Ethereum or Cosmos since contracts can now exchange tokens that support various already available standards.

Lithosphere's native digital asset, Litho (LITHO), plays a role similar to Ethereum gas. Specifically, users can pay for fees or transfers of LEP100 tokens with $LITHO.

#### 1.3.2 FUNCTIONS OF THE LEP100 TOKEN STANDARD

LEP100 tokens can be exchanged with ERC20, ERC-721, ERC-1155, BEP2, BEP20, or any similar token equivalents allowing interoperability within networks.

LEP100 standard Supports Instant, secure, and low gas on-chain transactions

LEP100 token developers can define and configure both fungible and non-fungible tokens in a single smart contract, allowing many applications such as money transfers, staking, gaming, collectibles, voting, etc.

**✦ SAVE GAS:** Cut gas fees by up to 90% when minting new tokens.

**✦ ADVANCED FEATURES:** LEP100 token standard enables owners to use, trade, destroy, upgrade, combine, rent, loan, and lose their NFTs.

**✦ ATOMIC SWAPS:** Atomic swaps of any number of tokens in just two simple steps.

**✦ BATCH TRANSFERS:** Send multiple tokens in a single transaction.

**✦ ADOPTION:** LEP100 is inspired by ERC20, ERC-721, ERC-1155, BEP2, and BEP20, which are already used in several projects in the blockchain ecosystem.

**✞** LEP100 tokens are fueled by the Litho($LITHO) coin. The $LITHO coin is the native token on the Lithosphere network.

#### 1.3.3 LITHOSPHERE OFFERS

All Lithosphere tokens are compliant with LEP100 standards. The Lithosphere network is a multichain architecture that allows all users to create dApps and other digital assets on the blockchain. It also guarantees cross-chain, low gas, fast trading with secure transactions. LEP100 enables tokens on the Lithosphere blockchain to work accurately. Therefore, all users benefit by enjoying low transaction fees with a massive ecosystem.

Also, the cross-chain Defi mechanism increases all small contracts interoperability regardless of the nature of the blockchain network. The Lithosphere ecosystem is very supportive. The KaJ Labs Foundation funds all bootstraps with various Defi projects through the Litho Launchpad.

#### 1.3.4 Why Use LEP100 Token Standard For your Defi Project vs. ERC20 / BEP20.

* LEP100 tokens represent various things, including shares, fiat currencies, and any other crypto asset.
* It is easy to pin other tokens from different blockchains on the LEP100 token. Therefore, it allows developers to generate various versions of the crypto assets with the same tokens, e.g., BTC becomes BTCL when pegged with LEP100. LEP100 TOKEN STANDARD
* $LITHO is provided as a bonus for all validators who transfer LEP100 tokens. The bonus is collected as a transaction fee.
* The LEP100 standard offers low gas fees for all transactions compared to other token standards like ERC20.
* LEP100 token standard was invented by Joel Kasr, creator of Lithosphere, so it's native to the Lithosphere network. The Lithosphere network has the highest transaction speeds of more than 10,000 TPS.
* It is not strenuous to integrate Defi projects with the LEP100 tokens. Also, it can be listed for free on a DEX like PancakeSwap, Uniswap, Dextool, etc.

#### 1.3.5 FEATURES OF LEP100 TOKENS

The LEP100 token has various impressive features that include:

* Fast transaction: the LEP100 token supports high-speed transaction speeds, which makes it highly scalable.
* Time slicing: Time slicing adds start time and ends time attributes. Only the tokens whose current time is within the start time and end time are valid.
* Low transaction fees: Users will not have to pay high gas fees like in Ethereum Networks
* Cross Chain compatibility: the LEP100 tokens are compatible with ERC20, ERC-721, ERC-1155, BEP2, and BEP20 supporting networks/blockchains.
* Compatible with almost every major crypto wallet available today

#### 1.3.6 Crypto Wallets and LEP100 Addresses

Most wallets like Trust Wallet support LEP100 tokens. Once you generate a new wallet, you will have automatically enabled features of the Lithosphere network. If it fails to display, you can search for the Litho network in the search option.

**Step 1:** Open the wallet.

**Step 2:** Tap the Receive button to get the LEP100 address.

**Step 3:** Hit the copy button on the screen to share the QR code for the address that Lithosphere provided. Keep in touch with the core development team for more information on the public sale and more announcements. You can also find more details on diverse social media platforms.

### What Are LEP100 Tokens and LEP100 Standard?

Token monotony in crypto has helped to build a foundation for the whole digital ledger technology as we know it.

Smart contracts like Ethereum and Binance Smart Chain (BSC) allow you to build and launch your decentralized application (DApps). Each dApp comes with a quantity of value, and a tradable asset called a "token," used to provide a value or perform certain social; and governance-related activities.

These tokens tread the hills of the specific framework called a TOKEN STANDARD, a set of rules and guidelines incorporated into the smart contracts. If a token doesn't yield and comply with the desired token standard, it won't be compatible and won't interact with the ecosystem applications, such as wallets and exchanges.

Every blockchain platform has its category of token standards that smart contracts have to adhere to. You might be well accustomed to ERC-20 tokens; these are the Ethereum-based tokens that the ERC-20 token standard acts. Likewise, Binance Smart Chain (BSC) comes with a token standard called BEP-20, which has to be followed by every BEP-20 token released on the Binance Smart Chain space.

The Lithosphere network introduces a new token standard - LEP100 inspired by previous ERC20, ERC1155, BEP20, etc.

### CONCLUSION

With the ability to represent both fungible and non-fungible assets, cross-chain support, low fees, and high transaction throughput, LEP100 tokens provide a much better alternative to Ethereum's ERC-20 ERC1155 counterpart.

Seamless swapping between LEP100 and ERC-20 / ERC1155, BEP-20, BEP2, and LEP100 versions of the pegged assets, LEP100 tokens can be a game-changers entire ecosystem.

### GLOSSARY

* **LITHO:** Lithosphere’s native token.
* **LEP100:** Lithosphere Evolution Proposal 100
* **WHITE PAPER:** A guide about a specific topic and the problem that surround it. It is meant to educate readers and help them to understand and solve an issue.
* **BLOCKCHAIN:** It is a specific type of database. It differs from a typical in the way it stores information.
* **TOKEN:** A token represent a set of rules encoded in a set of smart contracts. Each token belongs to a blockchain address. It is essentially a digital asset that is stored securely on the blockchain.
* **DECENTRALIZED:** They are type of cryptocurrency exchange which allows for direct peer-to-peer cryptocurrency transactions to take place online securely and without the need for an intermediary.
* **EVM:** Ethereum virtual machine is a computation engine which acts like a decentralized computer that has millions of executable projects.
* **BSC:** Binance smart chain
* **PEGGED COINS:** LEP100 tokens pegged to external assets.
* **DAPPS:** Decentralized Applications are digital applications that run on a blockchain or peer-to-peer network of computers instead of a single computer.
* **NFT:** A non-fungible token is a unit of data stored on a digital ledger, called blockchain, that certifies a digital asset and therefore not interchangeable
* **INTEROPERABILITY:** The ability of computer systems or software to exchange and make use of information.
* **ERC:** Ethereum request for comments
* **BURN:** A process by which digital currency miners and developers can remove tokens or coins from circulation.
* **TRACTION:** Drawing or pulling rate in a business.
* **DEFI:** Decentralized finance
* **CROSS CHAIN:** It is the interoperability between two relatively independent blockchains.
* **DEX:** Decentralized exchange


# whitepaper

## Whitepaper

Version 1, July 2021

## JOEL KASR

### FOUNDER, KAJ LABS & LITHOSPHERE

<joel@kajlabs.com> lithosphere.network kajlabs.com

#### MAKING SMART CONTRACTS INTELLIGENT FOR THE DIGITAL ECONOMY

### Abstract

In geography, a lithosphere is the rigid, outermost shell of a terrestrial-type planet or natural satellite. On Earth, it is composed of the crust and the portion of the upper mantle that behaves elastically on time scales of thousands of years or greater. – Wikipedia Having closely monitored the blockchain space for the last 10 years, the KaJ Labs Foundation can build a much better blockchain network learning from mistakes made by early networks. At this time, all types of tokens have completed some basic functions of value transfer and distribution, but they are still a long way from the fully functional financial services that the real world requires, which is why, when it comes to blockchain applications in the financial sector, all we hear is thunder but no rain falls. People need a new generation of financial infrastructure based on blockchain technology that has complete financial functionality, can link different communities and tokens, and can bridge the gap between centralized and decentralized organizations as soon as possible to usher in the era of the Internet of Value.

We created a completely new “Email system” at the dawn of the Internet of Information, rather than transforming the “postal system.” Similarly, when the Internet of Value arrives, we want to build a new system: a value transfer infrastructure based on a variety of tokens. Lithosphere (Litho) is ready for the DeFi age! By establishing a layer of control management on top of various tokens through a distributed management of the tokens’ private keys and by providing ports both for central organizations and for external data sources, Lithosphere will connect various past and next-gen smart contracts, solving the key problem of the current Internet of Value’ insufficient interoperability. The lithosphere is open to everybody. It connects centralized and decentralized organizations, accommodates authentication methods and anonymous trade mechanisms, and introduces on- chain data and off-chain data by integrating the cryptocurrencies and blockchains that exist today and those that may exist in the future. The lithosphere is a Turing-complete virtual computer that allows DeFi to have unlimited reverie space across multiple tokens in the future, opening up henceforth unthinkable possibilities. The Litho project’s general concept, essential technology, and development strategy are presented in this whitepaper, which presents the prospect of decentralized banking based on an examination of the history of the Internet of Value.

### Design Concept

![spaces\_1z9NFm1PO35bMUqxrMmL\_uploads\_EGNnnLHjkJp96HUdYGsz\_Figure\_6](https://user-images.githubusercontent.com/21309333/166516882-d87ca024-4091-4e11-bc8e-a3652c49798e.png)

<p align="center">Figure 1</p>

\### Blockchain Emergence and Significance Due to a lack of confidence, the conventional market economy has a significant cost. The major method that individuals continuously handle trust is through a centralized organization or company. The fast growth of modern human civilization was aided by people with similar ideals who were organized into institutions such as governments, political parties, and businesses. However, centralized organizations face enormous challenges: First, owing to a lack of trust between organizations and conceptual disputes, various groups become embroiled in violent rivalry, years of warfare, and even nuclear terrorism. Second, resources have been increasingly concentrated in the hands of a small number of people, widening the divide between classes. Finally, there is the concept of a “single point of failure,” such as Solar Winds.

Because a few agencies have monopolized a huge quantity of resources such as power, wealth, skill, and data, the repercussions of them reneging or being hacked will be severe. Lithosphere’s vision is to connect all blockchains and break the barriers between blockchains by allowing them to transact with each other. The end goal is to create a connected network of blockchains, a network of blockchains able to communicate with each other in a decentralized way.

With Lithosphere, blockchains can maintain sovereignty, process transactions quickly and communicate with other blockchains in the ecosystem, making it optimal for a variety of use cases instead of being limited to one blockchain network i.e Polkadot / Bitcoin / Ethereum / Cardano.

A very good use case of Lithosphere will be the transfer of NFT. Presently, NFT can only be transferred to parties within a given network. At the moment one can’t send Ethereum NFT to a Smart Chain (BSC) user or vice versa. With Lithosphere, users in the eco-system will be able to receive and send tokens from any blockchain that supports Byzantine Fault-Tolerant (BFT) consensus.

The transition from central credit authorization by institutions to inviolable mathematical principles for documenting value exchange is a significant advancement. Currency is, in essence, a consensus. It’s a standard accounting symbol for more convenient value exchange. Reviewing humanity’s financial history, from bartering one thing for another, to using cattle, sheep, or shells as universal equivalents, to the use of precious metals as money, to the current use of paper currency with a strong credit base, the human currency is approaching abstract mathematics, and its nature as symbols or ledgers is more apparent. Human accounting concepts become more aligned with mathematics as a result of blockchains.

It assists the whole accounting system in moving away from a single institution’s control and toward a more fair and transparent path. Financial Inclusion is a concept that aims to provide access to the financial system and low-cost financial services for disadvantaged individuals and small businesses throughout the world. Two and a half billion individuals worldwide are unable to use banks, create savings accounts, or acquire credit cards, thus cutting them off from the global economy. Banks charge exorbitant fees for cross-border transfers. Ordinary investors can only purchase very low- end financial goods from banks and other financial institutions, and they are unable to participate in early-stage investments in technology companies such as Google and Alibaba until they are listed on the stock exchange.

Many small and medium businesses are also having difficulty obtaining loan support from banks, despite having strong credit and excellent performance, because they are not traditional banks’ target clients under the 80/20 rule. The development of blockchain technology is altering the conditions described above. Bitcoin is used to pay workers in other nations, such as El Salvador. Investors who took part in the initial coin offerings (ICO) of well-known blockchain projects like Bitcoin and Ethereum saw returns hundreds of times their initial investments. Inclusionary finance is reaching new heights thanks to blockchain technology. Many organizations are exploring ways to record traditional forms of assets, such as commercial bills and loyalty points, into blockchains, usually in the form of consortium chains. Cryptocurrencies are becoming more acceptable as a form of payment in financial transactions; many organizations are exploring ways to record traditional forms of assets, such as commercial bills and loyalty points, into blockchains, usually in the form of consortium chains. There has been the emergence of digital asset exchanges, which are comparable to traditional financial organizations.

The banking function of exchanging digital assets is performed by these exchanges. They are similar to stock exchanges in that they provide a platform for purchasing and exchanging tokens. The functionalities of a platform for cross-border token transfers are comparable to those of cross- border bank remittances. However, these platforms operate in a centralized way to varying degrees, which not only introduces security issues associated with centralization but also prevents the widespread use of blockchain technology. We need a distributed “bank” based on this phenomenon, where multiple digital currencies and digital assets may be moved in, out, and swapped via blockchains. We require a location where financial products and contracts based on digital currencies and digital assets may be developed and executed, as well as a secure environment to safeguard transaction privacy. Of course, such “banks” will be nothing like traditional banks, except for a few services like debit and credit, remittance, settlement, and financial product sales. Any company or individual with sufficient expertise and cash can open their business windows. They may offer a variety of services while maintaining the security of a distributed blockchain infrastructure, allowing them to deliver more financial services to more people. This is a future financial infrastructure built on digital assets and a distributed financial market, to be more precise.

### Design Objectives

The major benefit of blockchain is that it aids in resolving the issue of trust that plagues humanity, making blockchain technology raising human civilization’s level. Its growth is unstoppable because of the human need to reduce transactional expenses. Because each blockchain can perform peer-to-peer value transmission, unlike the original Internet of Information (IoI), blockchain technology moves us from the age of IoI to the age of the Internet of Value (IoV), which may be considered the third generation of the Internet.

Lithosphere has established the following goals based on research on cross-chain technology, AI & Machine Learning, as well as the features of decentralization and its application scenarios, to develop a more widely disseminated blockchain technology and digital asset applications:

**Cross-chain Asset Transfer:**

* Connecting large digital currency networks (such as Bitcoin and Ethereum) and completing asset transactions without changing the original chains’ mechanisms. This allows Lithosphere to incorporate freshly created digital currency networks at a very cheap cost.
* Integrate Lithosphere with consortium chains. This handles asset transfers from original chains to Lithosphere, asset transfers from Lithosphere back to original chains, and asset trading on Lithosphere.
* Ensure that cross-chain transactions are secure and that cross-chain transaction services are stable.

**Transaction Privacy Protection:**

* Allow trade parties to select whether or not to execute transactions privately.
* Provide privacy protection for digital asset transfers and exchanges.
* Provide holders of digital assets with anonymous protection.

**Functional Extensibility:**

* Become a decentralized platform for the trading of non-fungible assets and digital currency. Operate a deposit and lending company for several digital currencies.
* Use digital money as a vehicle for digital asset transactions.
* Create brand new digital financial assets and exchange them. ![spaces\_1z9NFm1PO35bMUqxrMmL\_uploads\_3S0hTZnV5BINjcGE8xpp\_Figure\_1](https://user-images.githubusercontent.com/21309333/166517531-a2a47911-00a5-427d-9614-7b7957975422.png)

<p align="center">Figure 2</p>

The world has changed dramatically as a result of the Internet of Information. Human civilization is destined to undergo massive societal transformations as a result of the Internet of Value. This is due to the qualities of digitalization, intelligence, decentralization, and inclusiveness that the Internet of Value-based on blockchain technology possesses. Digitization and intelligence, which can help the Internet of Value run more efficiently, are elements that already exist on the Internet of Information, but are now being applied to the Internet of Value.

Decentralization is an even more important feature since it will assist to eliminate the bottleneck caused by centralized organizations. People can better safeguard their personal property rights with private keys; they can better resolve conflicts with consensus mechanisms, and they can engage in collaboration in the division of labor with peer-to- peer networks with much lower obstacles. People join the Internet of the Information age when they can easily transfer information over the Internet and program information using algorithms; they will enter the Internet of Value age when they can easily send value over the Internet and program value using smart contracts. The Internet of Value benefits gives it a “high-dimensional” edge over traditional collaboration models.

On blockchains, all types of “values” will be expressed and easily exchanged and programmed. As a result, people’s collaboration relationships and human civilization would undoubtedly be drastically altered. The Internet of Value will allow individuals to handle values as if they were informed, and its primary role will be to communicate values. However, to fulfill this purpose, the Internet’s worth must improve in three areas. Interoperability is the first. Values reside on many blockchains, centralization organizations, and data centers, and the Internet of Value necessitates public chains or other solutions that can interact across blockchains, centralization organizations, and data sources, as well as transfer values and perform smart contracts.

The second factor is scalability. The Internet of Value must be adaptable to a variety of circumstances, including banking, industry, and government administration. The last point to consider is usefulness. The Internet of Value requires a robust ecosystem and the ability to operate a wide range of apps seamlessly so that developers can create applications quickly and consumers can easily utilize them. However, compared to the Internet of Information, the Internet of Value is still in its early phases, with interoperability, scalability, and usability limitations. In terms of interoperability, although the Internet of Information has been able to transmit and program words, photos, audio, and video as a unified bit of information, the Internet of Value continues to struggle with communicating values between blockchains, much alone off-chain values, and data. Not only does the Internet of Value necessitate cross-chain connectivity, but it also necessitates connection with centralized entities and external data sources. Tokens on separate blockchains can’t trade with each other since existing blockchains can’t communicate with each other (synchronization of state machines). Because blockchains presently cannot communicate with centralized organizations outside of the blockchain, it is difficult to map off-chain assets onto the blockchain. Because existing blockchains can’t read off-chain data, “smart” contracts on them are blind or dumb, unable to see or communicate with the outside world. Taking cross-chain technology as an example, cross-chain communication, much alone building cross-chain smart contracts, is now exceedingly challenging. There are thousands of different types of tokens now available, but each one can only move freely on a single blockchain and has its ecosystem of wallets, smart contract creation tools, and so on.

Existing blockchain networks are essentially island ecosystems, and the Internet of Value is still a long way from being genuinely interoperable. In terms of scalability, while the Internet of Information is constantly expanding by encoding various data as bits and programming various scenarios’ communication logic as applications, the Internet of Value is only just getting started by tokenizing various values as tokens and mapping various scenarios’ transaction logic as smart contracts. The Internet of Value scale is severely constrained due to its lack of compatibility. The transfer of off-chain values to the Internet of Value is hampered by the difficulty of mapping actual application scenarios involving various currencies, numerous organizations, and multiple data sources to a blockchain to build a distributed solution. In terms of usability, whereas the Internet of Information’s processing power, storage capacity, and synchronous speed were sufficient to handle most information management needs, the Internet of Value can only accommodate somewhat larger projects. In terms of standardization, platformization, functional modularity, application ecology, interoperability, and anti-quantum assaults, the Internet of Value has a lot of work ahead of it. Interoperability is the most pressing of the three types of obstacles listed above, since it allows us to move assets between blockchains, design smart contracts with various currencies, and improve update scalability. Usability, on the other hand, is a long-term effort, but interoperability and scalability, which have slowed the growth of the Internet of Value, require a quick fix and have become the two most pressing barriers to be addressed.

### Smart Contracts & Decentralized Finance (DeFi)

![Icon\_Template\_2](https://user-images.githubusercontent.com/21309333/166517821-d582db4d-6986-4852-961c-8bedddaae7b4.png)

<p align="center">Figure 3</p>

The goal of the Internet of Value is to link different values to blockchains so that smart contracts may control them. The Internet of Value enables decentralized, disintermediated, inclusive, and programmable collaboration among individuals. Because of these apparent benefits, diverse values will race to be mapped to blockchains. The Internet of Value will undoubtedly expand at a faster rate as blockchain constraints are addressed. The process of mapping values to blockchains necessitates decoupling financial logic from business logic, implying that the Internet of Value was created with a significant financial component.

The financial applications of the Internet of Value are those applications on the Internet of Value that have particularly significant financial features. Decentralized Finance refers to the on-chain financial operations on the Internet of Value, as well as their corresponding off- chain financial activities (DeFi). Because the Internet of Value is built on peer-to-peer networks that use the User Datagram Protocol, there are certain obstacles. The performance of the Internet of Value will progressively approach that of the Internet of Information in the future, allowing business scenarios and financial transactions to be written in the same software.

However, given the current state of affairs, we expect this will take a long time. The present Internet of Value will primarily support financial applications, i.e., DeFi apps will be the primary applications. The Internet of Information has already had a significant influence on r lives. We may also anticipate significant changes in our lives as a result of the Internet of Value. We may be familiar with the many forms of information available on the internet, but few people talk about the “value” of the Internet of Value. To begin with, the values on the Internet of Value are tokens represented by the blockchain, and the process of mapping values to the Internet of Value is known as asset tokenization.

The connected assets will be expressed by on-chain tokens and form part of the Internet of Value if the tokens on the chains represent the title, gain, and control of the underlying off-chain assets. The Internet of Value allows more and more values to enter itself through this process, preventing “double spending” through distributed books and making transferring value without intermediaries as simple as sending information and programming values as simple as programming information, making the Internet of Value’ prospects similar to what we have seen previously regarding telecommunications. Second, tokenization is a form of asset securitization in which off-chain values are mapped onto chains as crypto assets. Because tokens may be divided indefinitely and transferred over time and space, they can be used in financial transactions like mortgages, loans, and insurance.

As a result, tokenization is defined as the process of securitizing assets and converting off-chain assets into crypto assets that can be managed using private keys. Finally, the Internet of Value will include a wider range of values. Identities, signatures, data, voting rights, and other data will be mapped to the Internet of Value as long as tokenization is profitable. As a result, the Internet of Value will have a wider range of values than traditional financial markets.

### Positioning

We propose the Lithosphere project in light of DeFi’s bright future and the challenges that the current Internet of Value presents. The goal of Lithosphere is to create a platform-level public chain in the digital economy era that can connect all kinds of values, provide complete financial functions, communicate diverse communities and tokens, and bridge centralized and decentralized organizations to bring the Internet of Value as soon as possible with the help of blockchain, AI, and other technologies.

### Lithosphere Architecture and Technology

![NFT\_3-1](https://user-images.githubusercontent.com/21309333/166517918-33ea84b5-abf4-46c7-858c-3d3e3b933d99.png)

<p align="center">Figure 4</p>

\#### Distributed Private Key Management and Smart Contract Virtual Machine Because DeFi assets are displayed as tokens, they can substantially improve the interoperability of the Internet of Value and make increasing scalability much easier if multi-token smart contracts can be implemented. The present cross-chain technology is mostly side-chain technology, which uses a two- way peg to transfer transactions to side chains and multiple signatures to exit side chains. Such a method can only produce atomic transfers, and the results are unsatisfactory in nearly every way. We need to create a public chain that allows other tokens to be mapped to it in a more inventive fashion, so that multi-token smart contracts may be created.

We can substantially improve the interoperability of the Internet of Value in this manner, and this public chain will undoubtedly become one of the most important DeFi infrastructures. It not only communicates values between blockchains but also enables interfaces with centralized organizations and off-chain data sources to increase the Internet of Value’ scalability. On a new public chain, how will various tokens be expressed? We envisage that the tokens’ private keys on various blockchains can be securely controlled in a distributed fashion by a public chain and in this way, the blockchain manages the control rights of tokens. It will be like a “freeway” on the Internet of Value, which can easily implement the value transfers between various tokens and multi-token smart contracts to provide various DeFi services.

Since almost all blockchain tokens are controlled by private keys, values on the Internet of Value can be distributedly managed by smart contracts as long as the private keys of their tokens can be controlled by distributed nodes of a public chain. With Turing-complete smart contracts, the public chain can also provide various functions of decentralized finance (DeFi) in a more sophisticated form.

This blockchain, which connects all tokens, does not require complex logic for various application scenarios. Its purpose is to create a layer of management across all blockchains, enabling all tokens to interact. Because it does not need to run heavy application logic, in its current usability it is capable of fulfilling various DeFi functions.

### Myriad Distributed Key Management (MDKM)

![Figure\_7](https://user-images.githubusercontent.com/21309333/166518034-664c3655-23da-4858-9700-c105fe5e0a4f.png)

<p align="center">Figure 5</p>

The lithosphere is based on the theories and achievements of distributed key generation (DKG) in the field of cipher- sharing. The public key and the private key are both generated by nodes cooperating to communicate. The public key is broadcast in the public chain, the private key is separately stored by each node in a distributed manner through Variable Secret Sharing (VSS). The common public key is generated by the DKG algorithm, and then the account address of the Lock-in is generated by the corresponding algorithm to realize decentralized control. Here we refer to the domain of VSS and DKG based on elliptic curve cryptography distributed key generation protocol and application research on the process described below: Given elliptic curve E, there exists a finite field GF (q), q is a prime number with n participant sets Q = {P1, P2, …, Pn}, pi denotes the identity of the ith participant Pi, and Pi ∈ GF ∗ (q), where GF ∗ (q) is a multiplicative group on GF (q). In the meantime, pi and I are interchangeable during the calculation. E/GF (q) represents the additive group on E. T is E/GF (q), the order of E/GF (q) is a prime number or prime factor, marking this prime or prime factor as p. In this key generation protocol, it is assumed that both scalar multiplication and dot multiplications are done at δ and that the other operations are done at GF (q). To calculate Q (x) T, we first compute Q (x) and then p(x) mod p, and Q (x) mod p is the scalar multiplication on T. Let us assume that E has another base point T ′ on the elliptic curve δ.

### Threshold signature

The threshold signature technique can address the issue of signatures created by Lithosphere’s departing nodes while also improving the blockchain network’s stability. According to studies on node adaptation in distributed key generation networks, Lithosphere will choose appropriate nodes to join and refresh the shared key parameters in extreme circumstances to assure the chain’s successful functioning.

### Litho Coin

![LUSD\_ALGORITHMIC\_STABLECOIN-1](https://user-images.githubusercontent.com/21309333/166518948-408150ac-32e2-4341-8e60-e4a85f6e2404.png)

<p align="center">Figure 6</p>

Litho is the native coin of Lithosphere. Both cross-and intra-chain transactions consume a certain amount of Litho. Litho is also used in security deposits for the cross-chain verification nodes. Litho / $LITHO is the currency of choice in the Lithosphere network although another crypto can be used as well since the Lithosphere blockchain supports interoperability.

### LAX – Algorithmic Stablecoin

Litho Algorithmic stablecoin coin (LAX) is similar to algorithmic stable coin protocols operating on the Ethereum blockchain, but unlike coins like U.S. Dollar Coin (USDC) and Tether (USDT) which are backed by audited holdings of U.S. dollars or crypto assets like PAX Gold (PAXG), Litho USD coin is not pegged to the U.S. dollar or any crypto collateral. Rather than using crypto, fiat, or commodities as collateral, the Lithosphere protocol adjusts its LAX crypto supply every 24 hours in a process called “rebasing” to maintain a stable price.

### Consensus Mechanism

Lithosphere adapts a proof of stake consensus mechanism.

The goal of Lithosphere is to use blockchain technology to build an infrastructure platform to run decentralized applications and on the platform, multiple types of tokens will be able to freely interact through smart contracts to achieve value interoperability. Lithosphere aims to implement Myriad Distributed Key Management to build smart contracts for DeFi.

When an unregistered asset is moved from the originating chain to Lithosphere, Lithosphere will construct a new asset based on the cross-chain transaction information, utilizing a built-in asset template to deploy a new smart contract. When a registered asset is moved from the original chain to Lithosphere, Lithosphere will issue equal tokens in existing contracts, ensuring that the original chain assets may still be traded on Lithosphere.

### Cross-Chain Integration

Asset mapping refers to the process of producing matching tokens for bookkeeping on Lithosphere for a controlled item. One token can freely interact with other mapped assets thanks to mapping. Lock-in and Lock-out operations are used to establish and de-manage distributed control.

### Cross-Chain Transactions

![Figure\_2](https://user-images.githubusercontent.com/21309333/166519115-78536f64-982e-49a5-9ad8-e5f7d13d0dbd.png)

<p align="center">Figure 7</p>

Asset Lock-in is a process that enables myriad distributed key management and asset mapping for all key-managed tokens.

Asset Lock-out) is the reversal of Lock-in, and it consists of two parts: control rights management and asset mapping disassembly. After Lock-out is completed, control of the digital asset is returned to the owner, restoring complete key storage and centralized key management. By improving the security, liquidity, and DeFi applications of current digital assets, adopting multifarious key distribution management will improve the value of digital assets.

### Deep Neural Networks (DNN)

![DNN-2](https://user-images.githubusercontent.com/21309333/166519146-5d1bf086-c2eb-49df-8c95-66ea586e569e.png)

<p align="center">Figure 8</p>

David Yang PhD, proposes Deep neural networks (DNNs) for Lithosphere smart contracts. DNNs are very useful in blockchain applications such as DeFi and NFT trading. However, training / running large-scale DNNs as part of a smart contract is infeasible on today’s blockchain platforms, due to two fundamental design issues of these platforms. First, blockchains nowadays typically require that each node maintain the complete world state at any time, meaning that the node must execute all transactions in every block. This is prohibitively expensive for computationally intensive smart contracts involving DNNs. Second, existing blockchain platforms expect smart contract transactions to have deterministic, reproducible results and effects. In contrast, DNN is usually trained / run lock-free on massively parallel computing devices such as GPUs, TPUs, and/or computing clusters, which often do not yield deterministic results. !\[Lithosphere-whitepaper1 DNN]\(<https://user-images.githubusercontent.com/21309333/166519192-4d273901-0f60-4ebc-8b8f-dc59782c1f89.png>)

<p align="center">Figure 9</p>

For the first time in smart contracts, Lithosphere implements DNN to make smart contracts intelligent by incorporating large-scale deep neural networks (DNNs) into the code, which has numerous potential applications. For instance, in decentralized finance (DeFi), a DNN might help detect abnormal token price movements, which could be part of a flash-loan attack. A decentralized autonomous organization (DAO) might trade tokens automatically with a DNN trained continually through reinforcement learning. A content creator might apply a generative adversarial network (GAN) to generate visual art images, and subsequently tokenize them as non-fungible tokens (NFTs) tradable in a decentralized exchange.

### LEP100 Multi-chain Token Standard

![LEP100-TOKENS\_AND\_LITHO-LAUNCHPAD-1](https://user-images.githubusercontent.com/21309333/166519301-ea54daee-e04a-49d7-8632-6301c9157488.png)

<p align="center">Figure 10</p>

The LEP100 is a novel standard for multi-tokens, allowing for a single contract to represent multiple fungible(currency) and non-fungible tokens (NFT) and batched operations for increased gas efficiency proposed by Joel Kasr, creator of Lithosphere. Most importantly, LEP100 tokens can exchange for any other token equivalents. LEP100 tokens are fueled using the native Litho coin (LITHO). When pegged with the LEP100 tokens, you may also peg onto any networks utilizing any major digital assets. The token is multi-contract compliant and has basic features like transferring, returning a balance, and examining a token’s possession.

A LEP100 token, unlike ERC20 or BEP20, allows a single contract to represent numerous fungible and non-fungible tokens, allowing for a wide range of applications in everyday use. It is the most efficient token for DeFI platforms, gaming platforms, NFT, and another high-demand contract–compatible platforms. LEP100 may also be easily integrated into any Ethereum dApps or other chains because it can be traded for ERC20, ERC-721, ERC-1155, BEP2, and BEP20 tokens.

The LEP100 establishes best practices for managing cross-chain tokens. Due to their similarities, the tokens are compatible with ERC20, ERC-721, ERC-1155, BEP2, and BEP20. The LEP100 token standard also allows for token time-slicing in smart contracts. When a token is sliced, it is split into two parts: one is a time-limited slice (here TL is for Time-Lent), and the other is an infinite end (here TL stands for Time Restricted, since its utility is limited for a time but not locked). Both slices can be split into two more time slices if needed, allowing for sophisticated DeFi such as options and futures trading.

### Validators

In classical Byzantine fault-tolerant (BFT) algorithms, each node has the same weight. In Lithosphere, nodes have a non-negative amount of voting power, and nodes that have positive voting power are called validators. Validators participate in the consensus protocol by broadcasting cryptographic signatures, or votes, to agree upon the next block. Validators’ voting powers are determined at genesis or are changed deterministically by the blockchain, depending on the application. For example, in a proof-of-stake application such as the LithoSwap, the voting power may be determined by the amount of staking tokens bonded as collateral.

### Linear-communication BFT Consensus

The Litho protocol utilizes a BFT (BFT stands for Byzantine Fault-Tolerance) algorithm to achieve this. A Byzantine Fault-Tolerant consensus algorithm guarantees safety for up to a third of Byzantine, or malicious, actors. Byzantine faults within distributed systems are some of the most difficult to deal with.

A blockchain framework like Lithosphere powered by BFT allows public and private blockchains to transfer tokens to each other.

A BFT powered blockchain network (Lithosphere) allows interoperability with other PoS / fast finality blockchains like Cosmos, Binance or Proof of Authority & PoW blockchains.

Lithosphere adapts a new consensus algorithm, LinBFT proposed by Dr. David Yang. The Linear-communication BFT Protocol (LinBFT) applies to a permissionless, public blockchain system, in which there is no public-key infrastructure, based on the classic PBFT with 4 major improvements:

* Per-block consensus. There is consensus for each block, rather than for a group of blocks. This limits the power of the block proposer, and, thus, mitigates selfish mining.
* Rotating leader. The LinBFT protocol changes the leader (i.e., block proposer) for every block, which reduces the risk of denial-of-service attacks on the leader.
* Changing honesty. In Pyramid LinBFT, a participant can be honest for one block, and malicious for another (e.g., one containing a transaction of interest to the participant), as long as over 2/3 of all participants are honest for each block. In other words, it is possible that every participant is malicious at some point, and yet the blockchain remains secure at all times.
* Dynamic participant set. LinBFT allows nodes to join and leave the protocol at the beginning of epochs. As a result, different blocks may be verified by completely different sets of nodes.

Further, in the ordinary case, LinBFT involves only a single round of voting instead of two in PBFT, which reduces both communication overhead and the confirmation time and employs the proof-of- stake scheme to reward all participants. Extensive experiments using data obtained from the Ethereum test net demonstrate that LinBFT consistently and significantly outperforms existing in- production BFT protocols for blockchains.

### Myriad Distributed Key Management

Myriad Distributed Key Management realizes the generation of public-private key pairs and addresses and the transaction signatures on the target blockchain in a distributed manner through several nodes and according to digital signature algorithms adopted by the target blockchain, thus realizing the control and management of accounts and assets on the target blockchain in a distributed manner. ![Figure\_4](https://user-images.githubusercontent.com/21309333/166519378-71e789dd-2956-4200-a2a8-df363eeb6584.png)

<p align="center">Figure 11</p>

Such a technical route enables MDKM to be compatible with as many digital assets controlled by encryption algorithms as possible, whether these digital assets are generated on a centralized or decentralized basis. By supporting a signature algorithm with MDKM, a series of encrypted digital assets with the same signature algorithm can be controlled and managed.

At present, most (over 80%) of encrypted digital currencies adopt the same ECDSA signature algorithm as Bitcoin and Ethereum, so MDKM first chooses to implement support for the ECDSA signature algorithm. In addition, MDKM will support encryption currencies that use different signature algorithms, such as Stellar’s Ed25519 signature algorithm \[JL17], and Schnorr’s signature algorithm.

### LEP100 Token Standard

LEP100 specifications are followed by all Lithosphere tokens. The Lithosphere network is a multi-chain architecture that allows anybody to develop dApps and other blockchain-based digital assets. It also ensures cross-chain trade, minimal gas consumption, and quick transactions with safe transactions.

LEP100 makes it possible for tokens on the Lithosphere blockchain to function properly. As a consequence, everyone benefits from low transaction fees.

Furthermore, regardless of the blockchain network’s structure, the cross-chain DeFI mechanism improves the interoperability of all tiny contracts. The Lithosphere environment is highly supportive, and the Litho Launchpad finances all bootstraps with various DeFI programs.

### Why should your DeFi project use the LEP100 Token Standard?

LEP100 tokens may be used to represent a variety of assets, including stocks, fiat currency, and crypto-assets. Other tokens from various blockchains may easily be pegged to the LEP100 token. As a result, it enables developers to construct different versions of crypto assets using the same tokens.

All validators that transfer the LEP100 token will receive LITHO as a reward. The incentive is paid out in the form of a transaction charge. When compared to other token standards such as ERC20, it has minimal gas prices for all transactions. It’s built on the Lithosphere network, which offers fast transaction speeds of more than 10,000 TPS compared to Ethereum’s ERC20’s 15 TPS and Bitcoin’s 4 TPS.

Integrating DeFI projects with LEP100 tokens is simple. You may also list items for free on DEX such as LithoSwap, PancakeSwap, and Uniswap

### LEP100 Token Features

The LEP100 token offers many outstanding features, including

* High-speed transaction speeds: the LEP100 token standard enables high-speed transaction rates, making it extremely scalable.
* Low transaction fees: unlike Ethereum Networks, users will not be charged hefty gas prices.
* Cross-chain compatibility: The LEP100 tokens are supported by ERC20, ERC-721, ERC-1155, BEP2, and BEP20 networks and blockchains.
* Compatible with nearly every major cryptocurrency wallet on the market today.
* Easy to sell on exchanges: The LEP100 tokens are simple to list on exchanges and have a better probability of being sold.

### Verification Nodes

To earn a portion of the transaction fees, a Validator completes the recording of transactions on Lithosphere. According to the stake it owns, a Validator receives a corresponding key share and calculates the associated signature share to be appended to the transaction. According to the key share percentage, the Validator gets the transaction fee associated with the verification transaction. The transaction fee cannot be collected if the key sharing information is unavailable or lost. If the nodes sign the incorrect transaction, the Validator’s credentials will be removed as well.

In summary, the verification node incentive system will encourage Authenticators to give proper transaction proof, Validators to faithfully finish Lithosphere recording, and Record-keepers to stay online and keep their key shares secure.

Verification nodes are only available to individuals with a large enough stake in the Lithosphere network. General nodes are nodes that do not qualify as verification nodes. The general nodes are unable to participate in the cross-chain transaction verification process, but they can commit their stakes to the trusted verification nodes. The transaction fees received by the entrusted verification nodes are distributed to the general nodes in proportion to the entrusted stakes. General nodes will suffer a comparable loss if the delegated verification node is penalized.

Stakeholders in Lithosphere can gain stake-related advantages while also being motivated to commit their stakes to trusted verification nodes thanks to this incentive mechanism. This enhances Lithosphere’s security and stability.

### Locked Account Generation Scheme

The Locked Account Generation Scheme is based on threshold key sharing and safe multi-party computing.

#### Introduction

Distributed cryptography’s theoretical foundation and a basic challenge of distributed computing are both secure multi-party computation.

The hypothesis is based on the 1982 book “Yao’s Millionaires’ Problem.” Simply defined, secure multi-party computing refers to a set of players known as P1 Pn who collaborate to safely calculate the function f(x1, xn )=(y1, yn). Then each of the n participants has one of the function f inputs. Pi has the secret input xi and receives the output yi after calculation. In this case, security necessitates ensuring the validity of the computing result, even if some individuals cheat throughout the computation process. This implies that after the computations are finished, each participant must receive the right result yi, and all participant input is protected. Through the calculation, Pi can obtain no further information other than (xi,yi).

#### General Nodes

The threshold key sharing method is intended to address the issue of secure key management. The security of cryptography is dependent on the security of the keys, according to contemporary cryptography design principles. Cryptography’s security will be jeopardized if secure keys are compromised. As a result, key management is critical in cryptography security research and design. It might be challenging to handle the distribution of keys safely when an account is maintained by numerous persons with diverse interests. Cryptographer Adi Shamir devised the Shamir’s Secret Sharing threshold key sharing technique to tackle this problem. A key is split into n pieces and handed to n participants in this system. Each participant has a piece of the key share, and the key must be reconstructed using a minimum of k key shares. As a result, each activity on an account will need the cooperation of at least k individuals to maintain the account’s security and reliability. Based on safe multi-party computation and threshold key sharing, we created the Locked Account creation technique. Lithosphere Validators (Record-keepers) are in charge of maintaining and managing the keys to the Locked Accounts to guarantee that they are secure and reliable. Furthermore, in an ad-hoc network with no set topology, this technique reduces the danger of keys being lost and offers high flexibility and stability. The following is the Locked Account Generation Scheme:

#### Design Description

**Step 1: Choose a safe random number.** On Lithosphere, there are n validators known as P1……Pn. Each validator chooses a safe random integer di as well as a k-degree polynomial fi (x)=di+ai,1 x++ai,k-1xk-1. The technique delivers fi (j) to other validators through a secure channel and broadcasts di G to every network node, with G being the elliptic curve’s base point.

**Step 2: Verify that the messages are proper.** Pj will examine the messages’ correctness after receiving messages from other validators: lag=Check(f1 (j),……,fn (j)) lag=Check(f1 (j),. ,fn (j)) lag=Check(f1 Pj accepts and stores it locally if flag=true. If flag=false, Pj rejects the message and needs other validators to resubmit it.

**Step 3: You will be given a key to distribute.** When all messages have been delivered and checked out, each validator receives their key share as

**follows:** fj(k),k=1,……,n key sharek=(j=1) fj(k),k=1,…..,n

**Step 4: Determine the Locked Account’s address.** Locked Account Address=GenerateAddress(d1 G,…..,dn G) n Any activity on the Locked Account will necessitate the involvement of at least k of n validators.

#### Scheme Generation

The private key is never produced or reconstructed throughout the whole network during the Locked Account creation procedure. The involvement of at least k validators is required to generate the signature of the Locked Account. They compute signature shares independently using the key shares they own and then use signature shares to reconstruct the complete signature. The Signature Scheme for Locked Accounts is as follows:

Calculate the Signature Shares in **Step 1:** Using key shares, several n Lithosphere Validators compute signature shares of the message.

**Step 2:** Distribute the signatures. Each Validator transmits his or her signature share to the others.

**Step 3:** Reassemble and broadcast the whole signature. When a Validator gets more than k signature shares, it reconstructs the signature in its entirety and broadcasts it to other Validators: signature=Construct Sig(signature share1,. ,signature sharek)

**Step 4:** They produce the Locked Account’s complete signature, which includes the following information: signature sharej=Generate Sig(m,key sharej)

#### Advantages

Even if a portion of the network is paralyzed or some important shares are lost, the entire system maintains stability and security. To reduce the threat posed by key share exposure, every validator’s key share is updated regularly or when a triggering circumstance is satisfied.

**Easy Integration and Efficient Data Storage**

The initial transaction of the original chain is used to perform any operation on the Locked Account. There are no new transaction types or verification mechanisms. As a result, any chain may theoretically be merged with Lithosphere at a low cost. At the same time, unlike the multi-signature account scheme, which uses smart contract logic to accomplish multiparty management, the Locked Account creation strategy uses cryptographic principles to achieve multiparty management. There is just one signature on the final transaction, not multiple. As a result, this technique is more data storage efficient.

**Smart Contract Token Transaction Anonymity**

To achieve anonymity in smart contract token transactions on Lithosphere, ring-signature and one- time accounts are used. To make the sender anonymous, ring-signature combines the transaction sender with a group of false members. Each transaction generates a one-time account that cannot be connected to the actual owner.

A technique to lock the assets of the originating chain is required in almost all cross-chain transaction schemes. The locked assets will only be unlocked and returned to the original account or another account after the triggering condition is satisfied.

The Hashed TimeLock Contract system, the Trusted Third-Party Escrow Account strategy, and the Multi-Signature Account method are examples of existing techniques.

**Fully Decentralized without Third-Party Participation**

Secure multi-party computation is used to produce the Locked Account. A trustworthy third- participation party or endorsement is not required in this procedure. All we need is secure routes for information exchange and computation by Validators. The Locked Account generation technique is less expensive and more flexible than the trusted third-party escrow account scheme.

**Secure and stable**

Shamir’s Secret Sharing Scheme (a.k.a. Shamir’s (k, n)-threshold secret sharing scheme) is used to distribute the key for the Locked Account to Lithosphere validators. One component of the key share is held by each Validator. Even if several Validators go offline or lose their key shares, the Locked Account’s signature can still be produced, and the trans-action can still be completed with at least k validators. As a result, the creation strategy for Locked Accounts can assure that.

**One-Time Account System**

The one-time account method is particularly essential as a basis for anonymity. Each user has a single primary account as well as several sub-accounts. So, if someone wishes to remain anonymous in a smart contract token transaction, they must create a related account and a one-time primary account in addition to their original one.

**Ring Signature Scheme**

In 2001, the Ring Signature method was introduced. It’s a type of Group Signature scheme that’s a little different. A trusted centre and secure setup are required for a Group Signature scheme, which means that the signer may be tracked by the trust centre. By eliminating the trusted hub and securing the system, the Ring Signature method overcomes this major problem.

Since the introduction of the Ring Signature method, numerous practical systems based on Elliptic Curve Cryptography (ECC), such as the trapdoor approach, have been developed. Trapdoor Ring Signature, Linkable Ring Signature, Anonymity Revocable Ring Signature, and Deniable Ring Signature are the four types of Ring Signature systems.

The Ring Signature method based on ECC is developed in Lithosphere to offer anonymity in Smart Contract Token transfers.

The Ring Signature scheme is divided into three sections. The following are the details, using the signer (P,x) as an example:

Get the public parameters using GEN. The signer uses the method GeneratePublicKeySet( ) with the public key as a parameter to build a public key set with n members from the global state: publickeyset=GeneratePublicKeySet(P) I=GenerateKeyImage((P,x))=I=GenerateKeyImage((P,x))=I=GenerateKeyImage((P,x))=I=GenerateK eyImage((P,x))=I=GenerateKeyImage((P,x))=I=GenerateKeyImage((P,x))=I

RING SIGNATURE: Create the ring signature. The signer uses GenerateRingSignature( ) to produce the ring signature for message m, using public keyset, I, and x: ringsig=GenerateRingSignature(m,public keyset,I,x) VERIFY THE RING SIGNIFICANCE VerifyRingSignature( ), which returns true or false with public keyset, I, and rings: lag=VerifyRingSignature validates the ring signature of message m. (m,publickeyset,I,ringsig)

The ring signature is valid if the flag is true. Otherwise, it is void.

The key picture and ring signature in the Ring Signature scheme cannot be matched with a signer from the public key set. Anyone can check whether or not a signature is genuine, but no one can identify the signer.

**Cryptography Based Security Guarantee**

Many existing cross-chain trades employ logical security mechanisms, which rely on participants to watch out for their self-interest. To put it another way, players will not disrupt cross-chain transactions if it means harming their interests. This is known as “The Rational Participants Hypothesis.” Lithosphere employs threshold secret-sharing technology, as well as original elliptic curve cryptography, to assure the security of the original signature solution.

The multi-party computing-based locked account management solution;

The ring signatures and one-time accounts-based privacy protection method for smart contract token transactions.

After beginning a cross-chain transaction, all following actions are performed automatically between Lithosphere validator nodes and do not require coordination from transaction participants. This leaves the security of cryptographic methods to ensure the system’s seamless operation.

#### Smart Contracts

Identifying and defining various parties’ financial links Smart contract improvements.

A Smart Contract is a contract that defines the relationship and value interaction conditions of one or more digital assets among multiple participants in terms of temporal succession and spatial location and is used to complete financial transactions of one or multiple digital assets among multiple participants. The assets mapped on the Lithosphere chain by digital assets Lock-in, which allows Lithosphere’s smart contracts to specify connections among many different digital assets at the same time, are referred to as digital assets.

The owners or consumers of various digital assets are referred to as multiple participants. They are represented as accounts in the Lithosphere chain, including user and contract accounts. Contract participants in crypto smart contracts might comprise numerous user accounts as well as many contract accounts. The definition of financial transactions through smart contracts becomes a description of the connections among various digital assets and diverse ownership in time and space because the core of finance is the exchange of values across time and place.

The following are the limitations of current smart contracts:

* Can only operate on the same digital asset between two parties on the same chain;
* Can only transfer ownership of digital assets, making usage and ownership indivisible;
* Can only be triggered by a transaction, with no off-chain trigger conditions or legitimate off-chain information input.
* Realize applications of ownership and usufruct among multiple parties and multiple digital assets;
* Effectively get off-chain data input;
* Call other smart contracts in a smart contract in an enclosed or parallel manner as if the smart contract were a smart contract.

Key Distribution in Myriad Token management has permitted interaction between various digital assets and has become the object to define and program for Lithosphere’s smart contracts. As a result, it has the capacity and the need to implement DeFi features like multi-role, multi-token, and usufruct separation (rights).

The capacity of a smart contract to handle many distinct account types while also defining the connections between numerous users and various smart contracts is referred to as multi-role.

After mapping distinct digital assets to Lithosphere using Lock-in, a smart contract on Lithosphere may describe the relationship between many different digital assets at the same time.

Separation of usufructs refers to the ability to separate the usufructs (rights) and ownerships of digital assets. The present smart contract may only transfer tokens as a whole from one party to another, and it is not feasible for one party to gain ownership of a digital asset while the other party obtains the usufruct, implying that ownership and usufruct are separate in traditional smart contracts. It is simple to establish more than two user accounts or contractual accounts in a single smart contract, allowing for the separation of ownership and usage accounts as well as financial activities such as mortgage loans across various digital assets.

The transfer of digital assets will be possible if the link between them is solely specified in terms of space. It is a borrowing connection between them if the relationship is characterized in terms of time. When the connection is described in terms of object attribution, it represents the ownership and usufructs of the objects. As a result, the logical abstraction of one or more relationships in terms of time, space, and object attributions can lead to the construction of various transactions ranging from simple to complex between various digital assets, even eliciting yet-to-be-realized financial innovations, allowing for limitless imagination.

#### Contract multi-triggering mechanism Diversity of triggering conditions

![Figure\_5](https://user-images.githubusercontent.com/21309333/166519600-6a9fb980-0adf-446e-8ba3-78e6bba39c89.png)

<p align="center">Figure 12</p>

Because the present smart contract is triggered by a transfer to the contract, the current implementation of smart contracts is based on the transfer of ownership of digital assets.

When a user starts a transfer to a smart contract, for example, a node must first validate the legality of the transfer, which includes determining if the user’s current financial balance on the blockchain supports the transaction. The smart contract then runs the relevant function for accepting the gift and judges it based on the function’s predetermined response condition. For example, the smart contract will examine the entire amount of the donation and only accept it if it does not over the quota. Finally, a modified contract value or smart contract state will be placed into the block to indicate that the transaction has taken place.

We can see from the preceding analysis that the smart contract’s functions will involve judgments on some criteria, but these conditions will not be checked if the smart contract is not triggered in the first place. The execution of the following rules in the smart contract will not be triggered even if the required circumstances are satisfied. Many financial transactions scenarios, such as a passive quantitative trading strategy, are impossible to execute if a smart contract cannot be triggered by factors other than a transaction. As a result, improving the triggering mechanism is the first step towards improving smart contracts for DeFi applications. Aside from supporting the existing active triggering method, two new triggering mechanisms are introduced: time triggering and event triggering. The extended triggering mechanism is also known as the multi-triggering mechanism.

**The three trigger modes of the multiple triggering mechanisms are as follows:**

* The active triggering mode is similar to the current smart contract triggering mode and is compatible with all smart contracts.
* Timing triggering mode refers to the ability of a smart contract to be activated by time circumstances such as a time point or duration.
* Event triggering mode indicates that a smart contract will be activated when a certain event happens, such as usual swaps over time, and such applications will be fully supported by time triggering mode. Capturing events is critical in automated trading and quantitative trading, for example. The events triggering mode must be used to initiate such occurrences.

At the moment, smart contracts can only handle information from within their blockchain, however, in the event of multiple triggering mechanisms, some of the triggering information will come from outside. As a result, smart contracts will provide an external information input interface and use different techniques to verify the validity and authenticity of off-chain data.

To do so, Lithosphere will first transmit outside data through HTTP or socks to the nodes, depending on common APIs offered by third-party data sources. Lithosphere will encapsulate data calls from certain widely used off-chain data sources, which will function similarly to a system call to supply data for node acquisition. Nodes can, however, create their datasources using the aforementioned data collection routes to get important data information.

The consensus process verifies the validity of the off-chain data acquired. When a node discovers that off-chain data is linked to specific smart contract triggering circumstances, the node will run and broadcast the smart contract. If a malicious node purposefully broadcasts a smart contract over the whole network, the network may simply terminate the smart contract during the execution phase if it is judged malicious, because the smart contract will be re-verified by other honest nodes before execution. Such malevolent conduct will have no impact on the smart contract’s real operation, and there will be no opportunity to profit from unearned or arbitrage profits.

Incentive methods can also help with the issue of off-chain data entry effectiveness. Because data confirmation requires network consensus, nodes can only increase their revenue by pursuing quicker and more trustworthy data sources and accurately validating triggering circumstances. The high- efficiency network nodes would be rewarded due to the nature of the efficient market and resource allocation. The validity of the final data is unaffected by data generated by a few rogue nodes.

**Enhancements and compatibility**

Based on Ethereum and other blockchain smart contracts, Lithosphere’s smart contract will be upgraded and developed. Functionality additions, such as triggering mechanisms, will be added depending on compatibility with existing smart contracts. Smart contracts already operating on Ethereum and other blockchains will be able to simply move to Lithosphere, and smart contract developers will be able to swiftly create on Lithosphere.

The next step will be to optimize programming languages and virtual machines for a more robust application development environment, as well as to provide more intuitive application development tools and debug environments for developers with less coding knowledge.

#### Contract enclosed call

The above improvements to current smart contracts will eventually allow smart contracts on Lithosphere to define relationships and interaction rules based on various conditions, among various values and participants, in time and space, allowing smart contracts on Lithosphere to build DeFi applications. On Lithosphere, a smart contract may not only change account status and data, but it can also call another smart contract during execution if certain criteria are satisfied. The following activities must be completed to implement Smart Contract A’s call to Smart Contract B:

**(1)Create an enclosed call smart contract.**

A preset condition judgment and a preset condition rule for invoking the smart contract B are added to the code of smart contract A, and the parameter of the target smart contract address index is generated. The data input when smart contract A is triggered, as well as the outcome of the data computation, provides the foundation for the condition judgment. If the predefined criteria are met, the node will download and execute smart contract B.

The call condition is divided into two parts: rules and time. Rules are pre-programmed computation routines in a smart contract. Time conditions can be a pre-defined condition in a smart contract that is triggered when the smart contract is executed or a condition that checks the state of a smart contract regularly.

**(2)The procedure for making an enclosed call.**

i.When the smart contract A is activated, it will determine whether or not it is required to execute the smart contract B based on the preset calling circumstances. ii.When the calling circumstances are satisfied, the preset calculation function is called, and the result is used as the smart contract B’s input. iii.The node that performed the smart contract A downloads the smart contract B to the local computing environment, inputs the data determined in the preceding step as the smart contract B’s input data and starts executing the smart contract B.

The procedures outlined above can be used to execute smart contract A’s call to contract B. We call the logic link between them an enclosed call of a smart contract because smart contract B is based on the state of smart contract A as the trigger and input data.

Smart contracts not only make decisions based on their business logic, but they may also invoke other smart contracts based on predefined criteria. It is therefore simple to create network-like call interactions between distinct smart contracts, establishing the value interaction across connected financial apps and thus allowing the creation of complicated applications. As a consequence, sophisticated financial services, such as a loan application based on future cash flow, maybe developed using enclosed smart contract calls. The Lithosphere platform can achieve complicated financial activities thanks to these features and the multi-trigger mechanism, which will be explained in the section on multi-trigger mechanisms.

### Contract development

To fulfill a smart contract, the following steps need to be completed:

**(1)Build a smart contract**

The Lithosphere smart contracts are an evolution of current smart contracts. There should be two components to the contract: definition and description. The defining section is consistent and Ethereum smart contract compliant. As a result, current Ethereum smart contracts are compatible with Lithosphere. It contains contract status, contract values, and methods for defining response conditions and rules.

**(2)Release a smart contract**

Following the publication of the smart contract, the definition section is recorded on the blockchain following current smart contracts. The description section will be merged with the trigger conditions of all smart contracts in the current blockchain to create a calling list that will be recorded in the block and accessible to the whole network. Each row of entries in the calling list corresponds to a smart contract. In addition to the material in the description, each record has an index address that corresponds to the stored smart contract.

The next step will be to optimize programming languages and virtual machines for a more robust application development environment, as well as to provide more intuitive application development tools and debug environments for developers with less coding knowledge.

### Timing and trigger conditions

Proactive triggers are similar to how smart contracts in Ethereum are activated, which is by a transfer to a contract address. The following procedures will be used to create the new time triggering mode and event triggering mode:

**(1)Judge the trigger conditions by nodes**

For execution, the Calling list is downloaded to the local node. To determine if each item in the list matches the trigger condition, the node will poll the list and download matching or local data.

**(2)Trigger a smart contract**

When the accounting node discovers that the condition of a certain smart contract is met while polling at a specific time, the node acquires the smart contract address from the Calling list and sends a particular transaction to activate the smart contract. At the same moment, the smart contract for the selected transaction will be downloaded by the whole network of accounting nodes.

**(3)Execute the smart contract**

A smart contract is performed in the same way as the current smart contract, that is, it is executed in the node’s operational environment (virtual machine). The contract differs in that it has additional triggers and may be integrated into other contracts through triggering conditions, resulting in a chain of occurrences.

### Rapid development and interface

Lithosphere will provide development environments for smart contracts as well as function libraries. These functions may be used by developers to speed up the creation of smart contracts. To make it simpler to access and interact with data, the development environment will encapsulate different blockchain, smart contracts, data sources, and so on as interfaces.

Here are some typical interfaces:

**(1)Key management**

Initializing the key pair, creating and returning the public key address are all functions that must be implemented. Returning the signature hash value after entering the public key address and the associated signature.

**(2)Blockchain data acquisition**

If blockchains are thought of as systems that allow distributed applications (DApps), smart contracts collecting blockchain data will be the same as getting the blockchain system’s global variables. Smart contracts can access the following information on the blockchain using this interface: Aim for a specific block height. The sender’s information. The recipient’s information.

**(3)Call of smart contracts**

Smart contracts are used to implement all of the Lithosphere’s functionalities. The use of a transfer smart contract may be used to make a transfer in a smart contract. To encompass typical financial applications, Lithosphere will employ more basic smart contracts. As a result, developing a smart contract on Lithosphere entails embedding simple smart contracts into conventional financial apps and then enhancing their functionality by adding more complicated functionalities. Lithosphere will identify fundamental financial contracts, resulting in a smart contract library for developers to employ.

**(4)Off-chain Datasource interface**

On trigger circumstances, smart contracts employ off-chain data. Such data is frequently obtained using a standard HTTP or socks-based API supplied by a third party. A third-party interface call function, for example, will obtain the destination URL’s address through HTTP and return a JSON packet. This interface method can also be used to get information from other blockchains, such as querying and confirming whether a transaction in another chain is confirmed by the block where it is located. The Foundation will be used by Lithosphere to discover third-party interfaces and create third-party interfaces for smart contracts to call.

**(5)Rapid development**

Lithosphere will provide several smart contract templates for common applications for reference and usage by application developers in the early phases of the project. However, application developers must still fulfill certain code standards. Application developers can use smart contracts by creating preconditions to actualize the desired financial apps as the platform’s underlying functionalities and common financial basic applications grow more resourceful and complex. To further improve such a development environment and drastically reduce the development threshold for developers, Lithosphere’s plan includes visual and modular application development tools, a compilation environment, an application test environment, which will allow smart contract developers to focus on innovations in financial applications and a Launchpad to launch dApps.

**(6)Programming language and virtual machine**

For interoperability with smart contracts and quick porting of existing smart contracts, Lithosphere will initially employ Ethereum’s Solidity programming language. We will provide compilers for several languages in the future to accommodate more smart contract development languages. We’ll create a smart contract sandboxing system that performs particular fail-safe checks and fuel cost minimization using a browser or programming editor.

### To use multiple triggers to realize complex financial functions

Existing smart contracts can only passively wait for a transaction’s trigger to be performed by a transaction, which presents the issue of needing the introduction of a trusted broker to establish who has the right to trigger a smart contract and under what conditions. On the Lithosphere platform, smart contracts will describe the relationships between parties through code (whether by common smart contract or by enclosed contracts). Multiple triggers will automate the execution of these smart contracts, allowing them to be engaged one after the other without the need for human interaction. As a result, many parties may trust each other using smart contract codes to perform a range of complicated financial activities. Lithosphere smart contracts provide the capacity to program ownership and usufruct independently, allowing triggers to lend usufruct to another depending on time or other conditions and execute them as promised until the final right of usufruct and ownership is restored to the participants.

Smart contracts may now perform a wide range of financial activities thanks to this functionality. For example, if you want to borrow money, you may design the Lithosphere smart contract to borrow tokens, return fresh currency, and pay interest. Using the Lithosphere platform as an example, a smart contract may autonomously administer a fund, including taking the usufruct of various tokens into a smart contract, keeping various digital assets, producing management fees, paying the dividend, and so on. Using the example of various derivatives, the smart contract may take margins and perform operations such as modifying margins, liquidating, and settling using external data source triggers.

### Community operation plan

The KaJ Labs Foundation, as the project’s main sponsor, is aiming towards a promising blockchain ecosystem rather than corporate profitability as typical enterprise and startup initiatives do. The Lithosphere platform, which benefits all token holders, is not owned by any single entity or person. The whole blockchain token community owns the Lithosphere platform. Lithosphere makes token usage more flexible and accessible, as well as giving tokens the potential to offer sophisticated DeFi services. The value of all tokens will increase.

In reality, the Internet of Value’ cross-chain ecosystem is a massive project. The Kaj Labs Foundation must progress the ecosystem, which must be joined and participated in by the whole community, and whose blockchain must be enhanced via continual iteration. This is exactly what the features of a blockchain project are. Blockchain initiatives begin with a critical need or problem to be addressed, which must be continually investigated by participants and those in need to encourage continuous progress. At the same time, it will draw more individuals into the community, causing demand to shift the projects in a better direction and encourage the advancement of its technology. The purpose of the echoes is to generate a positive feedback loop of incentives, applications, and usage. As a result, project operations concepts must be community-oriented from the start, and community operations are linked to the success or failure of the blockchain project.

The following people make up the community:

* The Core development team and the Kaj Labs Foundation. They are the project’s platform’s sponsors and facilitators.
* Programmers who want to be a part of the project. They can join the Foundation development team or independently create and optimize Lithosphere as a third party if they are interested in projects or project technologies.
* Participating nodes in the Lithosphere They make money by keeping track of ledgers and operating smart contracts while also maintaining Lithosphere.
* Users of the Lithosphere platform. For DeFi and other services, they employ the Lithosphere platform.
* On the Lithosphere platform, DeFi service providers such as payment institutes, centralized or decentralized exchanges, lending institutes, and other financial service providers.
* Lithosphere token holders, such as private equity companies, early-stage investors, late-stage investors, and potential investors.
* Other parties involved in the development of Lithosphere, such as the media, government, and so on.
* The goal of community operations is to gather as much force as possible and arrange it in the most efficient way possible so that Lithosphere can iterate, improve, influence, and serve a wider community.

The growth of the community is inextricably linked to both the core and outlying communities. The two are mutually beneficial, with the core community serving as the focal point. The peripheral community, on the other hand, must continue to participate in the creation of the key community since the core community will originate from and borrow from the peripheral community, and the peripheral community will require the core community’s resources to support them. We discovered that Bitcoin, Ethereum, and other projects have all grown in the same way. The core community consists of early adopters, blockchain technology communities, and blockchain value communities, while peripheral resources include additional investors, users, developers, journalists, and other interested parties.

### Project promotion method

The concept separates community operations into two categories: core and periphery. The former prefers the offline mode, whilst the latter prefers the internet mode. The following is the strategy for key community operations:

* Lithosphere Foundation team: the team will be rewarded with tokens. One reason is to compensate for the resources used in the previous time, and the other is to allow anybody to become a shareholder and expect them to contribute to Lithosphere in the future.
* Community for blockchain technology.
* Technology is both the most important and the most difficult aspect of blockchain development. We will utilize online and offline methods to discover and nurture a group of top-tier talents to promote the technological community, using the founding team’s technical expertise and social resources.
* Blockchain value community: Using the blockchain technology community, we can organize gatherings with holders to disseminate blockchain knowledge while also promoting opportunities for collaboration with the private value community.

### A movement to Promote Blockchain Technology

The Internet of Value presently has a usability bottleneck, which will require continuing work in the future to improve. The usefulness of the Internet of Value is strongly connected to the Lithosphere project. To contribute to the usefulness of blockchain technology, we will start the “blockchain technology promotion movement.” For the Kaj Labs Foundation, this will be a long-term project.

In the form of technical salons, training camps, and seminars, this movement will continue to amass skills and technical information. We will encourage participants to provide content, which will be published on numerous websites and in the media. To grow the technical community of blockchain, we will provide monthly training sessions to recruit conventional Internet employees and other technical staff.

The blockchain technology promotion movement will bring together all forces, including universities, research institutes, businesses, institutions, governments, and alliances, to create a cooperative partnership and pool resources to support blockchain technology’s advancement.

### The Standardization of Blockchain Interfaces Movement

The Internet of Value has interoperability and scalability problems that require many parties to address. The Lithosphere project is inextricably linked to these two obstacles’ breakthrough development and advancement. By establishing the “Blockchain Interface Standardization Movement,” we will help to enhance them. For the Lithosphere Foundation, this will be a long-term project.

The movement will encourage standardization of interfaces not just between blockchains, but also between decentralized and centralized organizations, as well as between blockchains and external data sources.

### Lithosphere Applications

**Borrowing and Lending**

Using digital money to produce new value and earn revenue is an unavoidable trend as it grows in importance as a medium of value exchange and a value storage carrier. Bitcoin, for example, is used to fund blockchain mining companies and other crypto initiatives. Direct investment options for digital currency have expanded as the variety of applications for digital money has grown.

Those who generate value with digital currencies need more of them, and people who own digital currencies want to raise their value, thus demand for borrowing and lending digital currencies will rise.

Consider the cryptocurrency Ethereum (ETH). On Lithosphere, a service provider creates a deposit application and sets the interest rate using a smart contract.

Through a cross-chain transaction, a user sends ETH from the Ethereum blockchain to the Lithosphere smart contract address. The deposit on Lithosphere generates a voucher (Lithosphere tokens that look like deposit bank receipts) that is credited to the user’s Lithosphere account. The smart contract then calculates the interest for you. When the user wants to withdraw the money, the voucher is sent to an intermediate address, and a cross-chain transaction is carried out. On the original chain, the ETH corresponding to the voucher is unlocked and sent back to the original user’s account. Deposit reserves (the assets locked on the originating chain that correspond to the intermediate address) are always visible.

**Payment and Settlement**

Businesses are increasingly accepting digital assets such as Bitcoin as a form of payment. There will be more applications in the future that employ a range of digital currencies for payment. There are several payment options available today, including VISA, Paypal, and Alipay, each with its own set of payment and settlement procedures. The lithosphere is a multi-currency distributed platform that combines many banking ledgers into a single unified ledger. Without needing to install several digital currency wallets, any business or user may utilize the Lithosphere wallet to make multi- currency payments and settlements.

**Transaction and Exchange**

At the moment, centralized exchanges and over-the-counter marketplaces are required to complete digital currency trades. Every transaction is dependent on the exchanges’ and intermediaries’ confidence. After several currencies have been linked with Lithosphere, exchanges and intermediaries may use smart contracts to enable multi-currency auction trading and one-to-one curb transactions. On Lithosphere, the privacy protection transaction mechanism supports transactions that require privacy protection. Importing digital money into Lithosphere, starting private transactions on Lithosphere, and moving digital currency back to the original chain are all possible with Lithosphere. The original chain’s privacy is protected to some extent by concealing the fund tracking paths. Lithosphere can handle 10,000 transactions per second (TPS) compared to Bitcoin which processes 4.6 transactions per second, Ethereum does 15 TPS, and Ripple handles 1,700 TPS. Visa does around 1,700 transactions per second on average (based on a calculation derived from the official claim of over 150 million transactions per day).

**Investment and Financing**

Traditional institutions are increasingly turning to consortium chains to store assets such as commercial invoices, loyalty points, future earning rights, and accounts receivable. More financial assets will be recorded on consortium chains-based distributed ledgers in the future. When these consortium chains connect to Lithosphere, they become financial asset providers, and investors may acquire these assets with their digital currencies. It’s similar to buying financial goods at a bank, as in the traditional banking company. The main distinction is that more intermediaries can participate, and asset owners can finance themselves directly.

In the blockchain world, Initial Coin Offerings (ICOs) / initial exchange offerings (IEOs) have become a popular way to raise funds, and the practice is expanding to non-blockchain domains. Smart contracts are being used directly for ICOs by an increasing number of projects, particularly those built on Ethereum or BSC, making the process more open and equitable. However, ICOs that exclusively accept Ether annoy investors who possess other digital currencies. The ICO issuer can use Lithosphere to create a smart contract that enables multi-currency investments. Investors may invest more easily using Ethereum, Bitcoin, or any other blockchain token linked with Lithosphere, and issuers can manage their funds more simply. Furthermore, when a new blockchain is released, the Lithosphere cross-chain transactions may be used to convert the crowdfunded shares to the local currency. With Lithosphere, we’re entering a new age of blockchain-based digital right issuing

**More Applications**

The financial applications mentioned above are meant to help readers better grasp Lithosphere’s rationale and value. More examples include multi-currency credit cards based on digital money, asset- backed securities that bundle a range of assets, peer-to-peer lending firms based on digital currencies, and crowdfunding, among others.

Major banks see blockchain technology as an essential strategy, but they’re also looking at how it might be used to alter traditional business.

Banking, such as currency exchange, has been flourishing in the realm of digital money. In these sectors, blockchains are progressing on two parallel tracks, but with the emergence of digital assets and their increasing integration into the actual economy, these two tracks will eventually cross. Bank balance sheets will be largely moved to blockchains, and digital assets will be incorporated in bank balance sheets (banks that enable the loan and deposit of digital assets) (fiat money is represented and accounted for by blockchain tokens). This future integration will be supported by Lithosphere’s inter-ledger technology.

### Current Lithosphere Features

**Interoperability**

Cross-chain interoperability through a decentralized custodian model (MDKM)

**Next-generation Blockchain for NFTs**

A scalable, decentralized, cross-chain network designed to bring non-fungible tokens to everyone.

**Time-Lock Feature**

Lithosphere’s unique Time-Lock feature enables you to extract time-value out of your digital assets

**Security**

Manage and control private keys in a distributed manner with MDKM technology

**Scalability**

Solving the scaling problem is an open issue for PoW blockchains like Bitcoin and Ethereum v1. Currently, Bitcoin & Ethereum nodes process every single transaction and also store all the states. Since Lithosphere’s proof-of-stake can commit blocks much faster than Proof-of-work, EVM zones powered by Lithopshere’s consensus and operating on bridged-crypto can provide higher performance to PoW blockchains Ethereum, Litecoin & Bitcoin.

**Digital Assets**

Create, manage or even lend your own digital assets & NFT’s using the Lithosphere’s LEP100 protocol.

**Cross-chain gaming assets.**

Game economies, owned by players.

Create in-game assets that are available forever. Bring lasting value to gamers by letting them take their loot to another game or into the real world on the JOT ART blockchain-powered by Litho.

### Lithosphere Products

1. Lithosphere blockchain (PoS ) Litho cross-chain native token
2. LithoSwap – cross-chain DEX with NFT exchange support.
3. LEP100 Token Launchpad – Litho Launchpad
4. Thanos Multi-currency, cross-chain wallet
5. JOT NFT Platform (NFT marketplace, NFT DEX, SDK to distribute NFT anywhere cost- effectively, cross-chain) FLEEK – Decentralized community-powered gig platform on the blockchain.
6. LAX – Algorithmic Stablecoin

### Lithosphere Project Governance

**Council Members**

Elected to represent passive stakeholders in two primary governance roles: proposing referenda and vetoing dangerous or malicious referenda. Lithosphere creator Joel Kasr chairs the council committee.

**Technical Committee**

Composed of core teams actively building Litho. Can propose emergency referenda, together with the council, for fast-tracked voting and implementation.

**Community Members**

Can make and vote on proposals to improve Lithosphere.

**Tokenomics**

Total Supply : 1 billion

### Funding for the project

The initial distribution of litho coin and validators on Kamet (the first version of Lithosphere network) will go to the donors of the Lithosphere Fundraiser (70%), lead donors (5%), KaJ Labs Foundation (10%), network awareness (10%) and the core team members (10%). From Kamet onward, 1/3 of the total amount of $Litho will be rewarded to bonded validators and delegators every year.

One of the vaults / Capsules in the Lithosphere will be set up to hold marketing/awareness funds.

### Updated Roadmap 2022-2024

#### 2022 Q4 - (Kamet)

* Finesse Genesis Collection Drop
* $JOT IEO
* Finesse: Shadow Warriors P2E Beta Relase
* Team Expansion
* More CX & DEX Listings For Litho
* Litho Staking
* Key Parterships Announced

#### 2023 Q1 (Batura)

* Litho Testnet Makalu Goes Live!
* Jot Art NFT Marketplace Launch
* DAO / Community Governance & Proposal Flow Established
* MDKM Stable Release
* JOT CEX & DEX Listings
* Finesse: The Kingdom MMORPG Public Beta Live.

#### 2023 Q2 (Makalu)

* Litho Testnet #2 Everest Goes Live!
* Litho DEX
* LinBFT Stable Release
* Jot Art SDK Released
* Ego Dex / Litho Bridge Stable Relase
* Lithosphere Client (Wallet) Thanos Goes Live

#### 2023 Q3 (Everest)

* Lithosphere Mainnet Launch ✨
* Litho Whitepaper Update
* Fleek DAO on Lithosphere Testnets
* Finesse Series Migration To Lithopshere
* LEP100 (JOT) Launch & Contract Updates
* Litho Launchpad Testnet

#### 2023 Q4

* Litho Launchpad LEP100 Projects Previews
* DNNs Concept on Litho Sidechain
* LAX Algorithmic Stablecoin
* Jot Art Upgrades
* Inagural LITHO Super Dialogues (LSD Conference).

#### 2024 Q1

* Network Upgrades
* Token Standard Upgrades
* Jot Art Studio Beta Relase
* More decentralization
* More TBA

### Conclusion

The Lithosphere project has created a BFT algorithm, a new token standard, Litho currency (LITHO), and a key distribution mechanism to achieve the goal of the inclusive decentralized platform. The design of the native token is mostly comprised of the following five elements:

1. Number. A total of one billion tokens are available. This amount will allow the token to launch at an acceptable price and continue to grow steadily from there.
2. A system for distributing tokens. To achieve the idea of non-inflation, the supply of tokens should be limited. This benefits the early members and makes the system more stable in the long run.
3. The allocation of tokens. To realize the decentralized notion, the token distribution must be properly balanced. We award a 10% ratio to the Lithosphere team because of their continuous devotion and efforts to promote Lithosphere’s inclusivity in cross-chain, cross-organization, and cross-data source initiatives. Furthermore, because Lithosphere’s accounting nodes perform more complex functions than ordinary public chains, they will get around one-third of the entire sum. The remainder will be utilized for environmentally friendly buildings.
4. Environmentally-friendly construction. More than half of the funds will go to the Foundation to help the project flourish, particularly in terms of cross-chain, cross-organization, and cross-data features. To allow additional value to be conveyed on the chain and to aid the development of new smart contract applications, the project will also require a token exchange mechanism.
5. Fuels and miners In a distributed node control system, a range of values will enter the Lithosphere. To control tokens, the chain requires a large number of dispersed nodes. The more nodes there are, the more secure the chain will be, and the more nodes are required as the chain’s value grows. The chain must compensate miners by releasing tokens and charging service fees to sustain the number of nodes and calculation power.

Lithosphere was born out of necessity. Our development teams have always been spread throughout the world from the beginning of KaJ Labs, yet we’ve always had problems working effectively. We have to enhance our entire performance and processes for our teams to stay distributed.

We recognized there were several inefficiencies with the existing commonly utilized blockchains like Ethereum, Cardano, and others after working on numerous blockchain projects. The most serious issue was that these blockchain networks were unable to connect. You couldn’t buy ERC721 NFT using a BEP20 token, BTC, DOT, or BNB until Lithosphere. Blockchain networks must be in sync with one another for blockchain and DeFi to grow into the future we all want. Transaction expenses/gas fees are another challenges that networks like Ethereum confront. On the Ethereum network, almost every activity costs money.

The KaJ Labs team set out to create a worldwide blockchain network that is quicker, cheaper, and more environmentally friendly than existing blockchains such as Cardano, Polkadot, and Ethereum 2.0. Lithosphere may be thought of as the foundation for both old and new blockchains. The Lithosphere ecosystem is powered by the native currency $LITHO /Litho.

### Disclaimer

This Lithosphere Whitepaper is for information purposes only. The KaJ Labs Foundation does not guarantee the accuracy of or the conclusions reached in this whitepaper, and this whitepaper is provided “as is”. KaJ Labs Foundation does not make and expressly disclaims all representations and warranties, express, whether explicit, implied, statutory, or otherwise, whatsoever, including, but not limited to: (i) that the contents of this whitepaper are free from error; (ii) that such contents will not infringe third-party rights; and (iii) warranties of fitness for a particular purpose, suitability or function.

KaJ Labs Foundation and its affiliates shall have no liability for damages of any kind arising out of the use, reference to, or reliance on this whitepaper or any of the content contained herein, even if advised of the possibility of such damages. In no event will KaJ Labs Foundation or its affiliates be liable to any person or entity for any damages, losses, liabilities, costs, or expenses of any kind, whether direct or indirect, consequential, compensatory, incidental, actual, exemplary, punitive or special for the use of, reference to, or reliance on this whitepaper or any of the content contained herein, including, without limitation, any loss of business, revenues, profits, data, use, goodwill or other intangible losses.

### Glossary

**LEP100:** Lithosphere Evolution Proposal

**WHITE PAPER:** A guide about a specific topic and the problem that surround it. It is meant to educate readers and help them to understand and solve an issue.

**BLOCKCHAIN:** A growing list of records, called blocks, that are linked together using cryptography.

**TOKEN:** A token represent a set of rules encoded in a set of smart contracts. Each token belongs to a blockchain address. It is essentially a digital asset that is stored securely on the blockchain.

**DECENTRALIZED:** Type of cryptocurrency exchange which allows for direct peer-to- peer cryptocurrency exchange to take place online securely and without the need for an intermediary.

**EVM:** Ethereum virtual machine is a computation engine which acts like a decentralized computer that has millions of executable projects.

**BSC:** Binance smart chain

**PEGGED COINS:** LEP100 tokens pegged to external assets.

**DAPPS:** Decentralized Applications are digital applications that run on a blockchain or peer-to- peer network of computers instead of a single computer.

**NFT:** A non-fungible token is a unit of data stored on a digital ledger, called blockchain, that certifies a digital asset and therefore not interchangeable.

**INTEROPERABILITY:** The ability of computer systems or software to exchange and make use of information.

**ERC:** Ethereum request for comments

**BURN:** A process by which digital currency miners and developers can remove tokens or coins from circulation.

**TRACTION:** Drawing or pulling rate in a business.

**DEFI:** Decentralized finance

**CROSS CHAIN:** It is the interoperability between two relatively independent blockchains.

**DEX:** Decentralized exchange


# litho-chain

Lithosphere Network – lithod Binary Build Package

Source Repository: <https://github.com/KaJLabs/lithosphere> Branch: main

This package builds the canonical lithod Linux x86\_64 binary directly from source.

Requirements:

* Linux x86\_64
* Go >= 1.22
* git, make

Build Instructions:

1. ./build.sh
2. ./checksums.sh

Output:

* lithod
* checksums.txt


# Lithosphere Network – Node Chain Binary

## GitHub Repository

* **Repo URL:** [https://github.com/KaJLabs/lithosphere](https://github.com/KaJLabs/lithosphere/)
* **Branch:** `main`

***

## Binary Name

`lithod`

## Chain Framework

* **Framework:** Cosmos-SDK–based chain
* **Consensus:** CometBFT (Tendermint Core)
* **Execution:** LithoVM (EVM-compatible runtime)

## Source Repository

<https://github.com/KaJLabs/lithosphere/litho-chain>

***

## Pre-built Binary

* **Platform:** Linux x86\_64
* **Binary:** `lithod`

**Latest release binary:**\
<https://github.com/lithosphere-network/litho-chain/releases/latest>

> If no release binary is provided, you can build from source (see below).

***

## Build Instructions (From Source)

### Requirements

* Go ≥ 1.22
* GNU Make
* Linux x86\_64

### Steps

```bash
git clone https://github.com/lithosphere-network/litho-chain
cd litho-chain
make install
```

### This installs:

$GOPATH/bin/lithod

### Verify:

lithod version

## Default Node Directories

```bash
~/.lithod/
├── config/
│   ├── app.toml
│   ├── config.toml
│   ├── genesis.json
├── data/
└── keyring/
```

## Node Startup

```bash
lithod init <moniker> --chain-id lithosphere_700777-2
lithod start
```

## Genesis & Config

genesis.json provided separately (chain launch package)\
Seed & persistent peers injected via config.toml\
Remote signer / HSM supported via CometBFT signer

## Validator Compatibility

Cosmovisor supported\
Remote signer (tmkms / KMS / HSM) supported\
Prometheus metrics enabled

This keeps **all your content in one Markdown file** and uses proper code formatting for commands and paths.\
If you want, I can make an **even cleaner single README.md** that’s ready for GitHub with headings, bolds, and copyable commands. Do you want me to do that?


# Locked Account Generation Scheme

The Locked Account Generation Scheme is based on threshold key sharing and safe multi-party computing.


# Design Description

**Step 1: Choose a safe random number.**

On Lithosphere, there are n validators known as P1……Pn. Each validator chooses a safe random integer di as well as a k-degree polynomial fi (x)=di+ai,1 x++ai,k-1xk-1. The technique delivers fi (j) to other validators through a secure channel and broadcasts di G to every network node, with G being the elliptic curve’s base point.

**Step 2: Verify that the messages are proper.**

Pj will examine the messages’ correctness after receiving messages from other validators: lag=Check(f1 (j),……,fn (j)) lag=Check(f1 (j),. ,fn (j)) lag=Check(f1 Pj accepts and stores it locally if flag=true. If flag=false, Pj rejects the message and needs other validators to resubmit it.

**Step 3: You will be given a key to distribute.**

When all messages have been delivered and checked out, each validator receives their key share as

follows: fj(k),k=1,……,n key sharek=(j=1) fj(k),k=1,…..,n

**Step 4: Determine the Locked Account’s address.**

Locked Account Address=GenerateAddress(d1 G,…..,dn G) n Any activity on the Locked Account will

necessitate the involvement of at least k of n validators.


# General Nodes

The threshold key sharing method is intended to address the issue of secure key management. The security of cryptography is dependent on the security of the keys, according to contemporary cryptography design principles. Cryptography’s security will be jeopardized if secure keys are compromised. As a result, key management is critical in cryptography security research and design. It might be challenging to handle the distribution of keys safely when an account is maintained by numerous persons with diverse interests. Cryptographer Adi Shamir devised the Shamir’s Secret Sharing threshold key sharing technique to tackle this problem.

A key is split into n pieces and handed to n participants in this system. Each participant has a piece of the key share, and the key must be reconstructed using a minimum of k key shares. As a result, each activity on an account will need the cooperation of at least k individuals to maintain the account’s security and reliability.

Based on safe multi-party computation and threshold key sharing, we created the Locked Account creation technique. Lithosphere Validators (Record-keepers) are in charge of maintaining and managing the keys to the Locked Accounts to guarantee that they are secure and reliable. Furthermore, in an ad-hoc network with no set topology, this technique reduces the danger of keys being lost and offers high flexibility and stability.

The following is the Locked Account Generation Scheme:

{% content-ref url="/pages/azIMmagdz0IxDFCZF742" %}
[Broken mention](broken://pages/azIMmagdz0IxDFCZF742)
{% endcontent-ref %}

{% content-ref url="/pages/Mpp83rfUsIMCmj73PIKu" %}
[Scheme Generation](/makalu/packages/docs/locked-account-generation-scheme/scheme-generation)
{% endcontent-ref %}

{% content-ref url="/pages/8dZ5NJOsKFMzhr19JFQK" %}
[Broken mention](broken://pages/8dZ5NJOsKFMzhr19JFQK)
{% endcontent-ref %}

<br>


# Introduction

Distributed cryptography’s theoretical foundation and a basic challenge of distributed computing are both secure multi-party computation.

The hypothesis is based on the 1982 book “Yao’s Millionaires’ Problem.” Simply defined, secure multi-party computing refers to a set of players known as P1 Pn who collaborate to safely calculate the function f(x1, xn )=(y1, yn). Then each of the n participants has one of the function f inputs. Pi has the secret input xi and receives the output yi after calculation. In this case, security necessitates ensuring the validity of the computing result, even if some individuals cheat throughout the computation process. This implies that after the computations are finished, each participant must receive the right result yi, and all participant input is protected. Through the calculation, Pi can obtain no further information other than (xi,yi).


# Scheme Generation

The private key is never produced or reconstructed throughout the whole network during the Locked Account creation procedure. The involvement of at least k validators is required to generate the signature of the Locked Account. They compute signature shares independently using the key shares they own and then use signature shares to reconstruct the complete signature. The Signature Scheme for Locked Accounts is as follows:

Calculate the Signature Shares in Step 1 Using key shares, several n Lithosphere Validators compute signature shares of the message.

**Step 2**: Distribute the signatures.

Each Validator transmits his or her signature share to the others.

**Step 3**: Reassemble and broadcast the whole signature.

When a Validator gets more than k signature shares, it reconstructs the signature in its entirety and broadcasts it to other Validators:

signature=Construct Sig(signature share1,. ,signature sharek)

**Step 4:** They produce the Locked Account’s complete signature, which includes the following information: signature sharej=Generate Sig(m,key sharej)


# Advantages

Even if a portion of the network is paralyzed or some important shares are lost, the entire system maintains stability and security. To reduce the threat posed by key share exposure, every validator’s key share is updated regularly or when a triggering circumstance is satisfied.


# Cryptography Based Security Guarantee

Many existing cross-chain trades employ logical security mechanisms, which rely on participants to watch out for their self-interest. To put it another way, players will not disrupt cross-chain transactions if it means harming their interests. This is known as “The Rational Participants Hypothesis.” Lithosphere employs threshold secret-sharing technology, as well as original elliptic curve cryptography, to assure the security of the original signature solution.

The multi-party computing-based locked account management solution;

The ring signatures and one-time accounts-based privacy protection method for smart contract token transactions.

After beginning a cross-chain transaction, all following actions are performed automatically between Lithosphere validator nodes and do not require coordination from transaction participants. This leaves the security of cryptographic methods to ensure the system’s seamless operation.

####


# Easy Integration and Efficient Data Storage

The initial transaction of the original chain is used to perform any operation on the Locked Account. There are no new transaction types or verification mechanisms. As a result, any chain may theoretically be merged with Lithosphere at a low cost. At the same time, unlike the multi-signature account scheme, which uses smart contract logic to accomplish multiparty management, the Locked Account creation strategy uses cryptographic principles to achieve multiparty management. There is just one signature on the final transaction, not multiple. As a result, this technique is more data storage efficient.


# Fully Decentralized without Third-Party Participation

Secure multi-party computation is used to produce the Locked Account. A trustworthy third- participation party or endorsement is not required in this procedure. All we need is secure routes for information exchange and computation by Validators. The Locked Account generation technique is less expensive and more flexible than the trusted third-party escrow account scheme.


# One-Time Account System

The one-time account method is particularly essential as a basis for anonymity. Each user has a single primary account as well as several sub-accounts. So, if someone wishes to remain anonymous in a smart contract token transaction, they must create a related account and a one-time primary account in addition to their original one.


# Ring Signature Scheme

In 2001, the Ring Signature method was introduced. It’s a type of Group Signature scheme that’s a little different. A trusted centre and secure setup are required for a Group Signature scheme, which means that the signer may be tracked by the trust centre. By eliminating the trusted hub and securing the system, the Ring Signature method overcomes this major problem.

Since the introduction of the Ring Signature method, numerous practical systems based on Elliptic Curve Cryptography (ECC), such as the trapdoor approach, have been developed. Trapdoor Ring Signature, Linkable Ring Signature, Anonymity Revocable Ring Signature, and Deniable Ring Signature are the four types of Ring Signature systems.

The Ring Signature method based on ECC is developed in Lithosphere to offer anonymity in Smart Contract Token transfers.

The Ring Signature scheme is divided into three sections. The following are the details, using the signer (P,x) as an example:

Get the public parameters using GEN. The signer uses the method GeneratePublicKeySet( ) with the public key as a parameter to build a public key set with n members from the global state: publickeyset=GeneratePublicKeySet(P) I=GenerateKeyImage((P,x))=I=GenerateKeyImage((P,x))=I=GenerateKeyImage((P,x))=I=GenerateK eyImage((P,x))=I=GenerateKeyImage((P,x))=I=GenerateKeyImage((P,x))=I

RING SIGNATURE: Create the ring signature. The signer uses GenerateRingSignature( ) to produce the ring&#x20;

signature for message m, using public keyset, I, and x: ringsig=GenerateRingSignature(m,public keyset,I,x) VERIFY THE RING SIGNIFICANCE VerifyRingSignature( ), which returns true or false with public keyset, I, and rings: lag=VerifyRingSignature validates the ring signature of message m. (m,publickeyset,I,ringsig)

The ring signature is valid if the flag is true. Otherwise, it is void.

The key picture and ring signature in the Ring Signature scheme cannot be matched with a signer from the public key set. Anyone can check whether or not a signature is genuine, but no one can identify the signer.

####


# Secure and stable

Shamir’s Secret Sharing Scheme (a.k.a. Shamir’s (k, n)-threshold secret sharing scheme) is used to distribute the key for the Locked Account to Lithosphere validators. One component of the key share is held by each Validator. Even if several Validators go offline or lose their key shares, the Locked Account’s signature can still be produced, and the trans-action can still be completed with at least k validators. As a result, the creation strategy for Locked Accounts can assure that.


# Smart Contract Token Transaction Anonymity

To achieve anonymity in smart contract token transactions on Lithosphere, ring-signature and one- time accounts are used. To make the sender anonymous, ring-signature combines the transaction sender with a group of false members. Each transaction generates a one-time account that cannot be connected to the actual owner.

A technique to lock the assets of the originating chain is required in almost all cross-chain transaction schemes. The locked assets will only be unlocked and returned to the original account or another account after the triggering condition is satisfied.

The Hashed TimeLock Contract system, the Trusted Third-Party Escrow Account strategy, and the Multi-Signature Account method are examples of existing techniques.


# Smart Contracts

Identifying and defining various parties’ financial links Smart contract improvements.

A Smart Contract is a contract that defines the relationship and value interaction conditions of one or more digital assets among multiple participants in terms of temporal succession and spatial location and is used to complete financial transactions of one or multiple digital assets among multiple participants.

The assets mapped on the Lithosphere chain by digital assets Lock-in, which allows Lithosphere’s smart contracts to specify connections among many different digital assets at the same time, are referred to as digital assets.

The owners or consumers of various digital assets are referred to as multiple participants. They are represented as accounts in the Lithosphere chain, including user and contract accounts. Contract participants in crypto smart contracts might comprise numerous user accounts as well as many contract accounts.

The definition of financial transactions through smart contracts becomes a description of the connections among various digital assets and diverse ownership in time and space because the core of finance is the exchange of values across time and place.

The following are the limitations of current smart contracts:

* Can only operate on the same digital asset between two parties on the same chain;
* Can only transfer ownership of digital assets, making usage and ownership indivisible;
* Can only be triggered by a transaction, with no off-chain trigger conditions or legitimate off-chain information input.
* Realize applications of ownership and usufruct among multiple parties and multiple digital assets;
* Effectively get off-chain data input;
* Call other smart contracts in a smart contract in an enclosed or parallel manner as if the smart contract were a smart contract.

Key Distribution in Myriad Token management has permitted interaction between various digital assets and has become the object to define and program for Lithosphere’s smart contracts. As a result, it has the capacity and the need to implement DeFi features like multi-role, multi-token, and usufruct separation (rights).

The capacity of a smart contract to handle many distinct account types while also defining the connections between numerous users and various smart contracts is referred to as multi-role.

After mapping distinct digital assets to Lithosphere using Lock-in, a smart contract on Lithosphere may describe the relationship between many different digital assets at the same time.

Separation of usufructs refers to the ability to separate the usufructs (rights) and ownerships of digital assets. The present smart contract may only transfer tokens as a whole from one party to another, and it is not feasible for one party to gain ownership of a digital asset while the other party obtains the usufruct, implying that ownership and usufruct are separate in traditional smart contracts. It is simple to establish more than two user accounts or contractual accounts in a single smart contract, allowing for the separation of ownership and usage accounts as well as financial activities such as mortgage loans across various digital assets.

The transfer of digital assets will be possible if the link between them is solely specified in terms of space. It is a borrowing connection between them if the relationship is characterized in terms of time. When the connection is described in terms of object attribution, it represents the ownership and usufructs of the objects. As a result, the logical abstraction of one or more relationships in terms of time, space, and object attributions can lead to the construction of various transactions ranging from simple to complex between various digital assets, even eliciting yet-to-be-realized financial innovations, allowing for limitless imagination.


# Contract development

To fulfill a smart contract, the following steps need to be completed:

**(1)Build a smart contract**

The Lithosphere smart contracts are an evolution of current smart contracts. There should be two components to the contract: definition and description.

The defining section is consistent and Ethereum smart contract compliant. As a result, current Ethereum smart contracts are compatible with Lithosphere. It contains contract status, contract values, and methods for defining response conditions and rules.

**(2)Release a smart contract**

Following the publication of the smart contract, the definition section is recorded on the blockchain following current smart contracts. The description section will be merged with the trigger conditions of all smart contracts in the current blockchain to create a calling list that will be recorded in the block and accessible to the whole network.

Each row of entries in the calling list corresponds to a smart contract. In addition to the material in the description, each record has an index address that corresponds to the stored smart contract.

The next step will be to optimize programming languages and virtual machines for a more robust application development environment, as well as to provide more intuitive application development tools and debug environments for developers with less coding knowledge.

####


# Contract enclosed call

The above improvements to current smart contracts will eventually allow smart contracts on Lithosphere to define relationships and interaction rules based on various conditions, among various values and participants, in time and space, allowing smart contracts on Lithosphere to build DeFi applications.

On Lithosphere, a smart contract may not only change account status and data, but it can also call another smart contract during execution if certain criteria are satisfied.

The following activities must be completed to implement Smart Contract A’s call to Smart Contract B:

**(1)Create an enclosed call smart contract.**

A preset condition judgment and a preset condition rule for invoking the smart contract B are added to the code of smart contract A, and the parameter of the target smart contract address index is generated. The data input when smart contract A is triggered, as well as the outcome of the data computation, provides the foundation for the condition judgment. If the predefined criteria are met, the node will download and execute smart contract B.

The call condition is divided into two parts: rules and time. Rules are pre-programmed computation routines in a smart contract. Time conditions can be a pre-defined condition in a smart contract that is triggered when the smart contract is executed or a condition that checks the state of a smart contract regularly.

**(2)The procedure for making an enclosed call.**

i.When the smart contract A is activated, it will determine whether or not it is required to execute the smart contract B based on the preset calling circumstances.

ii.When the calling circumstances are satisfied, the preset calculation function is called, and the result is used as the smart contract B’s input.

iii.The node that performed the smart contract A downloads the smart contract B to the local computing environment, inputs the data determined in the preceding step as the smart contract B’s input data and starts executing the smart contract B.

The procedures outlined above can be used to execute smart contract A’s call to contract B. We call the logic link between them an enclosed call of a smart contract because smart contract B is based on the state of smart contract A as the trigger and input data.

Smart contracts not only make decisions based on their business logic, but they may also invoke other smart contracts based on predefined criteria. It is therefore simple to create network-like call interactions between distinct smart contracts, establishing the value interaction across connected financial apps and thus allowing the creation of complicated applications. As a consequence, sophisticated financial services, such as a loan application based on future cash flow, maybe developed using enclosed smart contract calls. The Lithosphere platform can achieve complicated financial activities thanks to these features and the multi-trigger mechanism, which will be explained in the section on multi-trigger mechanisms.

####


# Contract multi-triggering mechanism Diversity of triggering conditions

![](/files/r9MFKeJx9VHyIe1Nw8VB)

Because the present smart contract is triggered by a transfer to the contract, the current implementation of smart contracts is based on the transfer of ownership of digital assets.

When a user starts a transfer to a smart contract, for example, a node must first validate the legality of the transfer, which includes determining if the user’s current financial balance on the blockchain supports the transaction. The smart contract then runs the relevant function for accepting the gift and judges it based on the function’s predetermined response condition. For example, the smart contract will examine the entire amount of the donation and only accept it if it does not over the quota. Finally, a modified contract value or smart contract state will be placed into the block to indicate that the transaction has taken place.

We can see from the preceding analysis that the smart contract’s functions will involve judgments on some criteria, but these conditions will not be checked if the smart contract is not triggered in the first place. The execution of the following rules in the smart contract will not be triggered even if the required circumstances are satisfied. Many financial transactions scenarios, such as a passive quantitative trading strategy, are impossible to execute if a smart contract cannot be triggered by factors other than a transaction. As a result, improving the triggering mechanism is the first step towards improving smart contracts for DeFi applications. Aside from supporting the existing active triggering method, two new triggering mechanisms are introduced: time triggering and event triggering. The extended triggering mechanism is also known as the multi-triggering mechanism.

**The three trigger modes of the multiple triggering mechanisms are as follows:**\\

* The active triggering mode is similar to the current smart contract triggering mode and is compatible with all smart contracts.
* Timing triggering mode refers to the ability of a smart contract to be activated by time circumstances such as a time point or duration.
* Event triggering mode indicates that a smart contract will be activated when a certain event happens, such as usual swaps over time, and such applications will be fully supported by time triggering mode. Capturing events is critical in automated trading and quantitative trading, for example. The events triggering mode must be used to initiate such occurrences.

At the moment, smart contracts can only handle information from within their blockchain, however, in the event of multiple triggering mechanisms, some of the triggering information will come from outside. As a result, smart contracts will provide an external information input interface and use different techniques to verify the validity and authenticity of off-chain data.

To do so, Lithosphere will first transmit outside data through HTTP or socks to the nodes, depending on common APIs offered by third-party data sources. Lithosphere will encapsulate data calls from certain widely used off-chain data sources, which will function similarly to a system call to supply data for node acquisition. Nodes can, however, create their datasources using the aforementioned data collection routes to get important data information.

The consensus process verifies the validity of the off-chain data acquired. When a node discovers that off-chain data is linked to specific smart contract triggering circumstances, the node will run and broadcast the smart contract. If a malicious node purposefully broadcasts a smart contract over the whole network, the network may simply terminate the smart contract during the execution phase if it is judged malicious, because the smart contract will be re-verified by other honest nodes before execution. Such malevolent conduct will have no impact on the smart contract’s real operation, and there will be no opportunity to profit from unearned or arbitrage profits.

Incentive methods can also help with the issue of off-chain data entry effectiveness. Because data confirmation requires network consensus, nodes can only increase their revenue by pursuing quicker and more trustworthy data sources and accurately validating triggering circumstances. The high- efficiency network nodes would be rewarded due to the nature of the efficient market and resource allocation. The validity of the final data is unaffected by data generated by a few rogue nodes.

####


# Enhancements and compatibility

Based on Ethereum and other blockchain smart contracts, Lithosphere’s smart contract will be upgraded and developed. Functionality additions, such as triggering mechanisms, will be added depending on compatibility with existing smart contracts. Smart contracts already operating on Ethereum and other blockchains will be able to simply move to Lithosphere, and smart contract developers will be able to swiftly create on Lithosphere.

The next step will be to optimize programming languages and virtual machines for a more robust application development environment, as well as to provide more intuitive application development tools and debug environments for developers with less coding knowledge.

####


# Rapid development and interface

Lithosphere will provide development environments for smart contracts as well as function libraries. These functions may be used by developers to speed up the creation of smart contracts. To make it simpler to access and interact with data, the development environment will encapsulate different blockchain, smart contracts, data sources, and so on as interfaces.

Here are some typical interfaces:

**(1)Key management**

Initializing the key pair, creating and returning the public key address are all functions that must be implemented.

Returning the signature hash value after entering the public key address and the associated signature.&#x20;

**(2)Blockchain data acquisition**

If blockchains are thought of as systems that allow distributed applications (DApps), smart contracts collecting blockchain data will be the same as getting the blockchain system’s global variables. Smart contracts can access the following information on the blockchain using this interface:

Aim for a specific block height. The sender’s information. The recipient’s information.

**(3)Call of smart contracts**

Smart contracts are used to implement all of the Lithosphere’s functionalities.

The use of a transfer smart contract may be used to make a transfer in a smart contract. To encompass typical financial applications, Lithosphere will employ more basic smart contracts. As a result, developing a smart contract on Lithosphere entails embedding simple smart contracts into conventional financial apps and then enhancing their functionality by adding more complicated functionalities.

Lithosphere will identify fundamental financial contracts, resulting in a smart contract library for developers to employ.

**(4)Off-chain Datasource interface**

On trigger circumstances, smart contracts employ off-chain data. Such data is frequently obtained using a standard HTTP or socks-based API supplied by a third party. A third-party interface call function, for example, will obtain the destination URL’s address through HTTP and return a JSON packet.

This interface method can also be used to get information from other blockchains, such as querying and confirming whether a transaction in another chain is confirmed by the block where it is located.

The Foundation will be used by Lithosphere to discover third-party interfaces and create third-party interfaces for smart contracts to call.

**(5)Rapid development**

Lithosphere will provide several smart contract templates for common applications for reference and usage by application developers in the early phases of the project. However, application developers must still fulfill certain code standards.

Application developers can use smart contracts by creating preconditions to actualize the desired financial apps as the platform’s underlying functionalities and common financial basic applications grow more resourceful and complex. To further improve such a development environment and drastically reduce the development threshold for developers, Lithosphere’s plan includes visual and modular application development tools, a compilation environment, an application test environment, which will allow smart contract developers to focus on innovations in financial applications and a Launchpad to launch dApps.

**(6)Programming language and virtual machine**

For interoperability with smart contracts and quick porting of existing smart contracts, Lithosphere will initially employ Ethereum’s Solidity programming language. We will provide compilers for several languages in the future to accommodate more smart contract development languages.

We’ll create a smart contract sandboxing system that performs particular fail-safe checks and fuel cost minimization using a browser or programming editor.

####


# Timing and trigger conditions

Proactive triggers are similar to how smart contracts in Ethereum are activated, which is by a transfer to a contract address. The following procedures will be used to create the new time triggering mode and event triggering mode:

**(1)Judge the trigger conditions by nodes**

For execution, the Calling list is downloaded to the local node. To determine if each item in the list matches the trigger condition, the node will poll the list and download matching or local data.

**(2)Trigger a smart contract**

When the accounting node discovers that the condition of a certain smart contract is met while polling at a specific time, the node acquires the smart contract address from the Calling list and sends a particular transaction to activate the smart contract. At the same moment, the smart contract for the selected transaction will be downloaded by the whole network of accounting nodes.

**(3)Execute the smart contract**

A smart contract is performed in the same way as the current smart contract, that is, it is executed in the node’s operational environment (virtual machine). The contract differs in that it has additional triggers and may be integrated into other contracts through triggering conditions, resulting in a chain of occurrences.

####


# To use multiple triggers to realize complex financial functions

Existing smart contracts can only passively wait for a transaction’s trigger to be performed by a transaction, which presents the issue of needing the introduction of a trusted broker to establish who has the right to trigger a smart contract and under what conditions. On the Lithosphere platform, smart contracts will describe the relationships between parties through code (whether by common smart contract or by enclosed contracts). Multiple triggers will automate the execution of these smart contracts, allowing them to be engaged one after the other without the need for human interaction. As a result, many parties may trust each other using smart contract codes to perform a range of complicated financial activities. Lithosphere smart contracts provide the capacity to program ownership and usufruct independently, allowing triggers to lend usufruct to another depending on time or other conditions and execute them as promised until the final right of usufruct and ownership is restored to the participants.

Smart contracts may now perform a wide range of financial activities thanks to this functionality. For example, if you want to borrow money, you may design the Lithosphere smart contract to borrow tokens, return fresh currency, and pay interest. Using the Lithosphere platform as an example, a smart contract may autonomously administer a fund, including taking the usufruct of various tokens into a smart contract, keeping various digital assets, producing management fees, paying the dividend, and so on. Using the example of various derivatives, the smart contract may take margins and perform operations such as modifying margins, liquidating, and settling using external data source triggers.


# @lithosphere/sdk

High-level TypeScript client for the Lithosphere chain.

```bash
pnpm add @lithosphere/sdk
# or
npm install @lithosphere/sdk
```

## Quickstart

```ts
import { LithoClient, NETWORKS, LithoError, ErrorCode } from '@lithosphere/sdk';

const client = new LithoClient('mainnet');

const height = await client.getBlockNumber();
const { formatted } = await client.getBalance('0x22d279d24f0b7ca5d49c5a7a7f032da416f72387');
console.log(`Head block: ${height}, balance: ${formatted} LITHO`);
```

## Error handling

Every failure path throws a `LithoError` with a typed `code`:

```ts
try {
  await client.getBalance('0xnot-a-real-address');
} catch (err) {
  if (err instanceof LithoError && err.code === ErrorCode.INVALID_ADDRESS) {
    // user input is bad — surface a friendly message
  }
}
```

## Retry / backoff

The client retries on transient failures (network errors, 5xx, 429) with exponential backoff. Defaults: 3 retries, base delay 250ms, exponentially doubled per attempt. Tune via the constructor:

```ts
const client = new LithoClient('mainnet', {
  timeout: 10_000,
  retry: { count: 5, delay: 500 },
});
```

## Contract calls

Pair with viem (or ethers) and the ABIs from `@lithosphere/blockchain-core`:

```ts
import { LEP100_ABI } from '@lithosphere/sdk';
import { createPublicClient, http } from 'viem';

const viemClient = createPublicClient({ transport: http('https://rpc.litho.ai') });
const balance = await viemClient.readContract({
  address: '0xtoken-contract...',
  abi: LEP100_ABI,
  functionName: 'balanceOf',
  args: ['0xholder...'],
});
```

## Network registry

```ts
import { NETWORKS } from '@lithosphere/sdk';
console.log(NETWORKS.mainnet.chainId);   // 700777
console.log(NETWORKS.mainnet.explorerUrl); // https://makalu.litho.ai
```

## Indexer REST API (typed)

`LithoClient` talks to the EVM JSON-RPC. For the **indexer's REST API** (`/blocks`, `/txs`, `/validators`, `/tokens`, …), use the typed REST client built on `openapi-fetch` and the auto-generated OpenAPI types:

```ts
import { createLithoRestClient } from '@lithosphere/sdk';

const api = createLithoRestClient({ baseUrl: 'https://makalu.litho.ai/api' });

// Path + query are type-checked against the OpenAPI spec.
// Autocomplete suggests valid path strings and surfaces parameter shapes.
const { data, error } = await api.GET('/blocks', {
  params: { query: { limit: 10 } },
});
if (error) throw new Error(`API error: ${JSON.stringify(error)}`);
console.log(data); // type-narrowed to the /blocks 200 response
```

The types are regenerated from `docs/api-reference/openapi.yaml` on every push (drift-gated in CI). You can also import them directly:

```ts
import type { paths } from '@lithosphere/sdk';
type BlocksResp = paths['/blocks']['get']['responses']['200']['content']['application/json'];
```

See [`examples/`](https://github.com/KaJLabs/Lithosphere/tree/main/Makalu/packages/sdk/examples) for runnable scripts that exercise both clients.

See [docs/api-reference/sdk-reference.md](https://github.com/KaJLabs/Lithosphere/blob/main/docs/api-reference/sdk-reference.md) for the full API.


# Changelog

## 0.1.0 — 2026-05-11

Initial release.

### Added

* `LithoClient` with constructor taking either a `NetworkName` or a custom RPC URL.
* Read methods: `getChainId`, `getBlockNumber`, `getBalance`, `getTransaction`, `getTransactionReceipt`, `waitForTransaction`.
* Retry with exponential backoff on transient failures (network errors, 5xx, 429).
* Typed errors via `LithoError` + `ErrorCode` (re-exported from `@lithosphere/blockchain-core`).
* Re-exports of network registry, ABIs (LEP100, WLITHO, LITHONative), and shared types so a single install is enough for most consumers.
* Dual ESM + CJS build via `tsup`; bundled `.d.ts` for both.

### Dependencies

* Runtime: `@lithosphere/blockchain-core` (workspace).
* Built on `fetch` — no viem / ethers / web3 dependency.


# @lithosphere/sdk examples

Self-contained scripts that exercise each public surface. They're not unit tests — they hit the **live** Makalu testnet, so a quick run also serves as a smoke check that the chain is healthy.

| Script                 | What it exercises                                                                                                         |
| ---------------------- | ------------------------------------------------------------------------------------------------------------------------- |
| `01-balances.ts`       | `LithoClient` against the EVM JSON-RPC: chain head + native balance                                                       |
| `02-rest-blocks.ts`    | `createLithoRestClient` against the indexer REST API: paginated `/blocks` + per-height detail with end-to-end type safety |
| `03-contracts-viem.ts` | Pair `LEP100_ABI` (from `@lithosphere/blockchain-core`) with `viem` for a typed read of an ERC-1155 token balance         |

## Run from the monorepo

```bash
cd Makalu/packages/sdk
pnpm exec tsx examples/01-balances.ts
pnpm exec tsx examples/02-rest-blocks.ts
# 03 needs viem; install it first:
pnpm add -D viem
pnpm exec tsx examples/03-contracts-viem.ts
```

## Run from a standalone npm install (consumer flow)

```bash
mkdir litho-sdk-demo && cd litho-sdk-demo
pnpm init
pnpm add @lithosphere/sdk
pnpm add -D tsx typescript @types/node
# Copy one of the examples in, then:
pnpm exec tsx 02-rest-blocks.ts
```


# templates


# @lithosphere/contracts-template

Official smart contract starter used by `create-litho-app` for the Lithosphere developer preview.

## Requirements

* Node.js 20+
* pnpm 9+
* Foundry is optional unless you want to run the Forge-specific commands

## Quick Start

```bash
pnpm install --ignore-workspace
cp .env.example .env
pnpm compile
pnpm test:hardhat
```

## Common Commands

```bash
pnpm compile
pnpm test:hardhat
pnpm test:forge
pnpm test:all
pnpm deploy:local
pnpm verify
```

## Included Tooling

* Hardhat compile, test, deploy, and verify scripts
* Foundry config and example Forge tests
* Solhint and Prettier Solidity formatting
* Slither config for security analysis

## Notes

* The CLI excludes local build artifacts when copying this template into a new project.
* `verify` depends on network-specific explorer credentials in `.env`.


# Lithosphere SDK starter

Starter scaffold for **building a custom SDK** on top of Lithosphere. Copied verbatim by `create-litho-app` when you pick the `sdk` template.

This is **not** the published `@lithosphere/sdk` — that package is already a runtime dependency of this scaffold. The scaffold is here to give you the publishing infrastructure (tsup dual-output, vitest, linting, sizing) plus one worked example of layering domain helpers on top of `LithoClient`.

## Quick start

```bash
# Inside the scaffolded directory:
pnpm install
pnpm test
pnpm build
```

## What you get

```
src/
  index.ts            # Re-exports your extension class (rename freely)
  extensions.ts       # Example: LithosphereExtensions wrapping LithoClient
  __tests__/
    extensions.test.ts
```

`extensions.ts` shows the pattern: own a `LithoClient`, expose your own methods, let the SDK handle retry/backoff/typed errors at the RPC layer. Replace its body with whatever your project actually needs (or delete it entirely — the directory structure is the load-bearing part).

## Using the underlying SDK

The SDK is already a dependency, so you can `import` from it directly:

```typescript
import { LithoClient, NETWORKS, LithoError, ErrorCode } from '@lithosphere/sdk';

const client = new LithoClient('mainnet');
const { formatted, symbol } = await client.getBalance('0x22d...387');
console.log(`${formatted} ${symbol}`);
```

For the full surface (LEP-100 ABI exports, network registry, error codes, retry config) see [`@lithosphere/sdk`](https://www.npmjs.com/package/@lithosphere/sdk).

## Layering on top — the `LithosphereExtensions` example

```typescript
import { LithoClient } from '@lithosphere/sdk';
import { LithosphereExtensions } from 'your-package-name';

const client = new LithoClient('mainnet');
const ext = new LithosphereExtensions(client);

const activity = await ext.recentActivity(
  '0x22d279d24f0b7ca5d49c5a7a7f032da416f72387',
  ['0xtxhash1...', '0xtxhash2...'],
);

console.log(`${activity.count} known txs for ${activity.address}`);
for (const entry of activity.entries) {
  console.log(`  ${entry.hash}: ${entry.status} at block ${entry.blockNumber}`);
}
```

## Publishing your package

1. **Rename it.** Edit `package.json` — change `name`, `description`, `repository`, `author`, `keywords`, `homepage`, `bugs.url`.
2. **Drop `"private": true`** when you're ready to publish.
3. **Pick an npm scope you control** — the scaffold uses `@lithosphere/...` placeholders that are reserved for the Lithosphere org.
4. `pnpm build` → produces `dist/index.{mjs,cjs,d.ts,d.cts}`.
5. `npm publish --access public` (or `pnpm publish` if you use pnpm's publish flow).

## What changed in this scaffold refresh

Prior versions of this scaffold copied `@lithosphere/sdk`'s `client.ts`, `types.ts`, and an ABI file directly into the new project. That made the scaffold easy to fork but locked the resulting package onto a frozen snapshot of the SDK — a published `@lithosphere/sdk` bug fix never reached the user.

Today the scaffold depends on `@lithosphere/sdk` as a regular npm dependency. Use `pnpm update @lithosphere/sdk` to pick up upstream fixes; build your domain-specific work in `extensions.ts` (or your own renamed modules). If you genuinely need to fork the client — e.g. for a non-EVM chain — clone the SDK's `Makalu/packages/sdk/` directory instead.


# @lithosphere/service-template

Production-grade Node.js/TypeScript microservice template for the Lithosphere blockchain ecosystem.

## Features

* **Fastify** HTTP framework with Pino structured logging
* **Health & readiness** endpoints for container orchestration
* **Prometheus metrics** via `prom-client` (HTTP latency, active connections, business ops)
* **OpenTelemetry** distributed tracing with auto-instrumentation
* **Zod** config validation at startup
* **Docker** multi-stage build with non-root user
* **Vitest** test runner with coverage

## Getting Started

```bash
# Install dependencies
pnpm install

# Run in development (hot reload)
pnpm dev

# Run tests
pnpm test

# Build
pnpm build

# Start production
pnpm start

# Docker
pnpm docker:build
pnpm docker:run
```

## Endpoints

| Path       | Method | Description                                     |
| ---------- | ------ | ----------------------------------------------- |
| `/`        | GET    | Service info (name, version, environment)       |
| `/health`  | GET    | Liveness probe (always 200 if running)          |
| `/ready`   | GET    | Readiness probe (200 when ready, 503 otherwise) |
| `/metrics` | GET    | Prometheus metrics                              |

## Environment Variables

| Variable                      | Default               | Description                                          |
| ----------------------------- | --------------------- | ---------------------------------------------------- |
| `NODE_ENV`                    | `development`         | Environment (`development`, `staging`, `production`) |
| `PORT`                        | `3000`                | HTTP server port                                     |
| `HOST`                        | `0.0.0.0`             | Bind address                                         |
| `LOG_LEVEL`                   | `info`                | Pino log level                                       |
| `LOG_PRETTY`                  | `false`               | Pretty-print logs in dev                             |
| `METRICS_ENABLED`             | `true`                | Enable `/metrics` endpoint                           |
| `SERVICE_NAME`                | `lithosphere-service` | Service identifier for metrics/tracing               |
| `SERVICE_VERSION`             | `0.1.0`               | Reported in health checks and traces                 |
| `OTEL_EXPORTER_OTLP_ENDPOINT` | *(disabled)*          | OTLP collector URL (e.g. `http://localhost:4318`)    |
| `DATABASE_URL`                | *(optional)*          | PostgreSQL connection string                         |
| `RPC_URL`                     | *(optional)*          | Blockchain RPC endpoint                              |
| `SHUTDOWN_TIMEOUT_MS`         | `30000`               | Graceful shutdown timeout                            |

## Project Structure

```
src/
  server.ts    # Entry point (imports tracing, starts Fastify)
  tracing.ts   # OpenTelemetry SDK init (must be first import)
  app.ts       # Fastify app builder, routes, plugins
  config.ts    # Zod-validated environment config
  metrics.ts   # Prometheus metrics registry and helpers
```


# Lithosphere Documentation

Official documentation for the Lithosphere blockchain — an Ethermint-based (Cosmos SDK + EVM) Layer 1 network.

## Contents

| Section                                                                                        | Description                                             |
| ---------------------------------------------------------------------------------------------- | ------------------------------------------------------- |
| [Introduction](https://github.com/KaJLabs/lithosphere/blob/main/docs/introduction/README.md)   | Overview of Lithosphere and its architecture            |
| [Quickstart](https://github.com/KaJLabs/lithosphere/blob/main/docs/quickstart/README.md)       | Get up and running quickly                              |
| [Network](https://github.com/KaJLabs/lithosphere/blob/main/docs/network/README.md)             | Chain parameters, endpoints, and configuration          |
| [Developers](https://github.com/KaJLabs/lithosphere/blob/main/docs/developers/README.md)       | Build on Lithosphere — smart contracts, SDKs, and tools |
| [API Reference](https://github.com/KaJLabs/lithosphere/blob/main/docs/api-reference/README.md) | REST and RPC API documentation                          |
| [Validators](https://github.com/KaJLabs/lithosphere/blob/main/docs/validators/README.md)       | Run a validator node                                    |
| [Guides](https://github.com/KaJLabs/lithosphere/blob/main/docs/guides/README.md)               | Step-by-step tutorials and how-tos                      |

## Links

* **Explorer**: [makalu.litho.ai](https://makalu.litho.ai)
* **RPC**: [rpc.litho.ai](https://rpc.litho.ai)
* **API**: [api.litho.ai](https://api.litho.ai)
* **Status**: [status.litho.ai](https://status.litho.ai)
* **Website**: [litho.ai](https://litho.ai)

## Chain Details

| Parameter     | Value                  |
| ------------- | ---------------------- |
| Chain ID      | `lithosphere_700777-2` |
| EVM Chain ID  | `700777`               |
| Bech32 Prefix | `litho`                |
| Native Denom  | `ulitho`               |
| Decimals      | 18                     |


# Faucet Setup Instructions — Validator Team

**Priority:** Required for Makalu testnet faucet to function\
**Component:** `litho-faucet` Docker container on EC2 indexer\
**Status:** Faucet UI is live at <https://makalu.litho.ai/faucet> but claims fail with "Could not send tokens" because no faucet wallet is configured.

***

## Problem

The faucet service (`litho-faucet`) needs a funded EVM wallet to send test LITHO to users. The `FAUCET_PRIVATE_KEY` environment variable is currently empty, so all faucet claims fail with a 500 error.

***

## Step-by-Step Setup

### 1. Generate a new faucet wallet

On any machine with `cast` (Foundry) or `node`:

**Option A — Using Foundry (`cast`):**

```bash
cast wallet new
```

This outputs an address and private key. Save both.

**Option B — Using Node.js:**

```bash
node -e "const w = require('ethers').Wallet.createRandom(); console.log('Address:', w.address); console.log('Private Key:', w.privateKey);"
```

**Option C — Using any EVM wallet (MetaMask, etc.):**\
Create a new account and export the private key.

> **Save the output — you need both:**
>
> * **Address**: `0x...` (the faucet's public address)
> * **Private Key**: `0x...` (64 hex chars after `0x`)

***

### 2. Fund the faucet wallet

Send LITHO to the faucet address from a funded account (e.g., a genesis account or validator account).

**Recommended initial funding:** 100,000 LITHO (enough for 10,000 claims at 10 LITHO each)

**Using `litho` CLI (Cosmos SDK):**

```bash
lithod tx bank send <funded-account> <faucet-0x-address> 100000000000000000000000ulitho \
  --chain-id lithosphere_700777-2 \
  --gas auto --gas-adjustment 1.5 \
  --fees 1000ulitho \
  --node https://rpc.litho.ai:26657
```

**Or using cast (EVM):**

```bash
cast send <faucet-address> --value 100000ether \
  --private-key <funded-wallet-private-key> \
  --rpc-url http://localhost:8545
```

> Note: `100000ether` = 100,000 LITHO (both use 18 decimals)

***

### 3. Configure the environment variable

SSH to the EC2 indexer via bastion:

```bash
ssh -o ProxyJump="ec2-user@44.218.142.100" ec2-user@10.0.10.16
```

Edit the `.env` file in the Makalu directory:

```bash
cd /opt/lithosphere/Makalu
sudo nano .env
```

Add or update these lines:

```env
# Faucet wallet (REQUIRED - private key of the funded wallet from Step 1)
FAUCET_PRIVATE_KEY=0x<your-64-char-hex-private-key>

# EVM JSON-RPC endpoint the faucet uses to send transactions
# Use localhost if the Ethermint node runs on this machine, otherwise use the NLB
FAUCET_RPC_URL=http://localhost:8545

# Optional overrides (defaults are fine)
# FAUCET_DRIP_AMOUNT=10        # Default LITHO per claim when amount is omitted
# FAUCET_COOLDOWN_HOURS=24     # Hours between claims per address (default: 24)
# FAUCET_CHAIN_ID=700777       # EVM chain ID (default: 700777)
```

The public faucet supports claims of **10 / 25 / 50 LITHO**. If no amount is supplied, the faucet defaults to **10 LITHO**.

***

### 4. Restart the faucet container

```bash
cd /opt/lithosphere/Makalu
sudo docker compose up -d faucet
```

***

### 5. Verify it's working

**Check the container is running:**

```bash
sudo docker ps | grep faucet
```

**Check the faucet logs for startup confirmation:**

```bash
sudo docker logs litho-faucet --tail 20
```

You should see:

```
[faucet] Listening on http://0.0.0.0:8081
[faucet] RPC: http://localhost:8545 | Chain: 700777
[faucet] Drip: 10 LITHO | Cooldown: 24h
```

**Check the health endpoint:**

```bash
curl http://localhost:8081/health
```

**Test a drip manually:**

```bash
curl -X POST http://localhost:8081/drip \
  -H "Content-Type: application/json" \
  -d '{"address": "0xba2b6fA3758296c5237235b2aF3Ba2a96D36A860", "amount": "10"}'
```

Expected success response:

```json
{
  "success": true,
  "txHash": "0x...",
  "amount": "10 LITHO",
  "recipient": "0xba2b6fA3758296c5237235b2aF3Ba2a96D36A860",
  "cooldownHours": 24
}
```

**Test from the public API:**

```bash
curl -X POST https://makalu.litho.ai/api/faucet/claim \
  -H "Content-Type: application/json" \
  -d '{"address": "0xba2b6fA3758296c5237235b2aF3Ba2a96D36A860", "walletType": "WEB3", "amount": "10 LITHO"}'
```

***

### 6. Verify via the UI

1. Open <https://makalu.litho.ai/faucet>
2. Connect a wallet (MetaMask / WalletConnect)
3. Click "Add Makalu Network" if prompted
4. Enter an address or use the connected wallet address
5. Select amount and click "Claim Testnet LITHO"
6. Should see a success message with a transaction hash

***

## Troubleshooting

| Symptom                              | Cause                          | Fix                                                                              |
| ------------------------------------ | ------------------------------ | -------------------------------------------------------------------------------- |
| `FAUCET_PRIVATE_KEY not set` in logs | Missing env var                | Add to `.env` and restart                                                        |
| `insufficient funds` in logs         | Faucet wallet has no LITHO     | Fund the address from Step 2                                                     |
| `connection refused` or timeout      | Wrong RPC URL                  | Check `FAUCET_RPC_URL` — try `http://localhost:8545` or the NLB URL              |
| `chain ID mismatch`                  | Wrong chain ID                 | Ensure `FAUCET_CHAIN_ID=700777`                                                  |
| Container not starting               | Redis not running              | Check `sudo docker ps \| grep redis` — faucet depends on Redis for rate limiting |
| 502 from API                         | Faucet container not reachable | Check container is on `litho-network` Docker network                             |

***

## Security Notes

* The faucet private key should **only** exist in the `.env` file on the server — never commit it to git
* The faucet wallet should **only** hold test tokens — never use a wallet that holds real assets
* Rate limiting is enforced: 1 claim per address per 24 hours (configurable via `FAUCET_COOLDOWN_HOURS`)
* The faucet only accepts EVM (`0x...`) addresses

***

## Architecture Reference

```
User Browser
    |
    | POST /api/faucet/claim
    v
litho-api (Express, port 3010)
    |
    | POST /drip (internal Docker network)
    v
litho-faucet (Fastify, port 8081)
    |
    | sendTransaction via viem
    v
Lithosphere EVM (port 8545)
```

**Docker service name:** `faucet` (aliased as `litho-faucet`)\
**Internal URL used by API:** `http://faucet:8081`\
**Env file location:** `/opt/lithosphere/Makalu/.env`\
**Docker compose file:** `/opt/lithosphere/Makalu/docker-compose.yaml`


# Lithosphere Makalu (Testnet) — Phase Completion Tracker

> Last updated: 2026-03-06 Context: Assessed against "L1 Developer Infrastructure Engineer Work Scope" PDF Scope: Makalu testnet (EC2 + Docker Compose deployment, NOT K8s)

***

## Summary Scorecard

| Phase | Name                     | %     | Status       |
| ----- | ------------------------ | ----- | ------------ |
| 0     | Discovery & Architecture | 100%  | Done         |
| 1     | Source Control & Repo    | 100%  | Done         |
| 2     | CI Foundations           | 100%  | Done         |
| 3     | Artifact & Package Mgmt  | 100%  | Done         |
| 4     | GitOps CD & Promotion    | 100%  | Done         |
| 5     | Developer Local Env      | 100%  | Done         |
| 6     | Test Strategy            | \~5%  | CRITICAL GAP |
| 7     | Contract Tooling         | \~30% | Partial      |
| 8     | SDKs & DX Portal         | \~35% | Partial      |
| 9     | Observability            | \~70% | Mostly done  |
| 10    | Security & Compliance    | \~25% | Partial      |
| 11    | Governance               | \~0%  | Not started  |

***

## Phase 0 — Discovery & Architecture (100%)

* [x] Languages/toolchains inventoried (Node/TS, Solidity/Hardhat, pnpm, Turbo)
* [x] Environments defined (.env.local, .env.testnet, .env.mainnet)
* [x] Core stack picked (GitHub Actions, Docker Compose, Prometheus/Grafana)
* [x] Architecture diagrams (14 in docs/diagrams/)
* [x] RACI matrix — `Makalu/docs/governance/security-baselines.md` section 3
* [x] Security baselines (aspirational) — `Makalu/docs/governance/security-baselines.md` sections 1-2
* [x] Security baselines (Makalu-enforced) — `Makalu/docs/architecture/004-security-baselines-makalu.md`
* [x] Promotion gates — `Makalu/docs/architecture/003-promotion-gates.md`
* [x] Phase 0 sign-off checklist — `docs/phase-0/SIGNOFF.md`

## Phase 1 — Source Control & Repo Strategy (100%)

* [x] Monorepo with pnpm workspaces + Turbo
* [x] contracts-template — real (compiled artifacts, tests)
* [x] service-template — Fastify, health/ready/metrics, OTel tracing, Dockerfile, README (entry: `src/server.ts`)
* [x] sdk-template — dual ESM/CJS via tsup, retry/backoff, publishConfig, README
* [x] create-litho-app CLI — fully functional
* [x] CODEOWNERS + ESLint + Prettier
* [x] PR template — `.github/PULL_REQUEST_TEMPLATE.md`
* [x] GitHub developer-preview release workflow — validation + packed CLI/SDK tarballs + contract bundles in `release.yaml`

## Phase 2 — CI Foundations (100%)

* [x] ci.yaml with pnpm/node\_modules/Turbo caching — parallel jobs (build, lint, test, typecheck, gitleaks)
* [x] Turbo pipeline (build/test/lint with --filter)
* [x] Gitleaks secret scanning in CI
* [x] Contract pipeline — `ci-contracts.yaml` (compile, test, lint, gas report, slither, ABI export)
* [x] Services pipeline — SBOM in release.yaml; vitest + smoke tests added to api and indexer
* [x] SDK pipeline — `ci-sdk.yaml` (test on Node 18/20/22 LTS matrix, build, lint, typecheck, size check)
* [x] Parallelization — ci.yaml split into parallel jobs; contract CI has 6 parallel jobs; SDK uses matrix strategy
* [x] Test summaries posted to PR — `$GITHUB_STEP_SUMMARY` in all CI workflows
* [x] Flaky-test quarantine strategy documented in `docs/guides/ci-cache-strategy.md`
* [x] Cache strategy doc — `docs/guides/ci-cache-strategy.md`
* [x] API + Indexer test scripts — vitest with health smoke tests (turbo run test no longer a no-op)

## Phase 3 — Artifact & Package Management (100%)

* [x] Docker image build & push (publish-images.yaml — 3 images, semver + sha tags)
* [x] Cosign image signing (publish-images.yaml)
* [x] SBOM generation SPDX (publish-images.yaml)
* [x] GitHub prerelease package bundles — `@lithosphere/sdk` + `create-litho-app` packed as release assets; npm publish deferred
* [x] Contract versioned artifacts — ABI/bytecode/metadata tarball + SHA256 checksums uploaded to GitHub Releases
* [x] OCI registry — GHCR with semver tags (`1.2.3`, `1.2`), sha-based immutable tags, retention policy
* [x] Immutable artifact conventions + retention policy — `docs/guides/consuming-releases.md`
* [x] "How to consume releases" guide with cosign verification commands

## Phase 4 — GitOps CD & Environment Promotion (100%)

* [x] deploy-simple.yaml — SSH via bastion to EC2, docker compose up (WORKING)
* [x] deploy.yaml — full pipeline with SLSA + image tagging (WORKING)
* [x] Health monitoring — health-monitoring.yaml cron every 5 min
* [x] K8s/ArgoCD — N/A, out of scope for Makalu (production is EC2 + Docker Compose)
* [x] Kustomize overlays — N/A, out of scope for Makalu
* [x] Blue/green deploy — `Makalu/scripts/blue-green-deploy.sh` (Docker Compose based)
* [x] Automated rollback — rollback jobs in both deploy workflows + rollback snapshots saved pre-deploy
* [x] Formal staging->mainnet approval flow — `promote.yaml` with GitHub Environment protection rules
* [x] Rollback script — `Makalu/scripts/rollback.sh` for manual rollback
* [x] Promotion & rollback playbook — `docs/guides/promotion-playbook.md`

## Phase 5 — Developer Local Environment (100%)

* [x] `make up` one-command stack with health checks
* [x] docker-compose.dev.yml with LithoVM/Anvil (7 services incl. faucet)
* [x] seed-local.ts (27KB) — funds wallets, deploys LEP100, generates transfers
* [x] .env profiles (local, testnet, staging, mainnet)
* [x] VS Code devcontainers (root + Makalu)
* [x] VS Code workspace config — `.vscode/settings.json`, `launch.json` (debugger attach), `extensions.json`
* [x] Onboarding doc (docs/quickstart/dev-setup.md — thorough)
* [x] Makefile targets (up, down, clean, logs, seed, status, restart, dev, test, faucet-fund, help)
* [x] Faucet service — `Makalu/faucet/` (Fastify + viem, Redis rate limiting, HTML frontend)
* [x] Faucet in production compose — `docker-compose.yaml` with Traefik routing
* [x] `make dev` — one-command full setup (up + seed + endpoints)

## Phase 6 — Test Strategy & Ephemeral Environments (\~5%) — CRITICAL GAP

* [ ] Unit tests — ZERO test files in API, indexer, explorer
* [ ] Integration tests — none
* [ ] E2E tests — none
* [x] Contract template tests — LithoBase.test.ts + LithoBase.t.sol in template
* [ ] PR-based preview environments — not implemented
* [ ] Data fixtures / chain state replayers — not implemented
* [ ] Test coverage dashboard — not implemented
* [ ] Flake tracker / quarantine — not implemented

## Phase 7 — Contract Tooling & Safety Rails (\~30%)

* [x] Hardhat config in contracts/ and contracts-template/
* [x] Solidity contracts (LEP100, WLITHO, LITHONative) in Makalu/contracts/src/
* [x] Foundry config (foundry.toml in contracts-template)
* [x] Slither config (.slither.config.json) — NOT wired to CI
* [x] Gas reporter configured in hardhat — REPORT\_GAS=false, not in CI
* [ ] Deployment framework (multi-sig, Ledger, EIP-712) — basic deploy.ts only
* [ ] ABI -> SDK auto-publish — not implemented
* [ ] solidity-coverage — installed but not in CI

## Phase 8 — SDKs & DX Portal (\~35%)

* [ ] @lithosphere/blockchain-core — 100% STUBS (every module is `export {}` with TODOs)
* [ ] SDK typed ABIs, retry/backoff — not implemented
* [ ] Auto-publish on release (npm) — not implemented
* [x] Developer docs portal — Docsify site, 48 markdown files, docs-deploy.yml
* [x] Code samples — docs/developers/examples/ (hardhat, foundry)
* [ ] wagmi/ethers frontend samples — not implemented
* [ ] OpenAPI/GraphQL schema auto-gen — not implemented

## Phase 9 — Observability, Quality & Cost (\~70%)

* [x] Prometheus config + lithosphere-alerts.yml
* [x] 7 Grafana dashboards (JSON, provisioned)
* [x] Loki + Promtail configs
* [x] AlertManager config with routing
* [x] Node exporter (deploy script + compose service)
* [x] health-monitoring.yaml (cron every 5 min)
* [x] monitoring-diagnostics.yaml workflow
* [ ] SLO dashboard — not implemented
* [ ] Cost dashboard — not implemented
* [ ] Correlation IDs (commit->build->deploy->trace) — not implemented

## Phase 10 — Security, Compliance & Supply Chain (\~25%)

* [x] AWS OIDC federation (no long-lived keys in CI)
* [x] Gitleaks secret scanning in CI
* [x] Cosign image signing (release + publish-images)
* [x] SBOM SPDX generation (release workflow)
* [ ] Image/dependency scanning (Trivy/Snyk) — not implemented
* [ ] License allow/deny policy — not implemented
* [ ] Policy as code (OPA/Conftest) — not implemented
* [ ] Key rotation playbook — not documented
* [ ] Audit trail -> SIEM — not implemented

## Phase 11 — Governance & Change Management (\~0%)

* [ ] Release trains (weekly dev, bi-weekly staging, on-demand hotfix)
* [ ] RFC process / template
* [ ] CAB approvals for mainnet
* [ ] PIR template
* [ ] Release calendar

***

## Out of Scope (for Makalu testnet)

| Item                               | Reason                                        |
| ---------------------------------- | --------------------------------------------- |
| Terraform/IaC (VPC, RDS, clusters) | Lives in litho-validator-infra repo           |
| K8s cluster provisioning           | Production is EC2 + Docker Compose            |
| ArgoCD server deployment           | SSH-based CD in use                           |
| Vault/KMS                          | AWS Secrets Manager used instead              |
| Self-hosted CI runners             | GitHub-hosted sufficient at current scale     |
| SIEM integration                   | Enterprise requirement, premature for testnet |
| Multi-AZ / HA deployment           | Single EC2 for testnet                        |
| CDN (CloudFront)                   | Not needed for testnet                        |
| Nix flakes                         | Docker Compose chosen                         |
| Binary releases for CLIs           | create-litho-app is npm-distributed           |

***

## Priority Actions (Next Steps)

1. **Phase 6 — Write deeper tests** for API, indexer, explorer (smoke tests added; need integration/E2E)
2. **Phase 8 — Implement blockchain-core SDK** or remove stubs
3. **Phase 10 — Add Trivy/Snyk** to CI for dependency scanning


# Lithosphere Explorer & Indexer — Production Deployment Report

**Prepared by:** KaJ Labs Development Team **Date:** March 1, 2026 **Status:** Production Live

***

## Executive Summary

The Lithosphere block explorer and indexer stack has been fully deployed to production and is now live at **<https://makalu.litho.ai>**. This report documents everything that was built, every problem that was identified and resolved, and the current state of the production infrastructure.

The original issue — a **522 Connection Timeout** error that made the explorer unreachable — has been permanently resolved. The root cause was that the explorer service had never been deployed to the production server. We rebuilt the entire deployment pipeline from scratch, aligned all configuration with the live chain infrastructure, and shipped a fully automated CI/CD system that handles all future deployments.

***

## What Was Delivered

### 1. Live Production Infrastructure

All endpoints are live, HTTPS-secured, and verified:

| Service         | URL                       | Status                      |
| --------------- | ------------------------- | --------------------------- |
| Block Explorer  | <https://makalu.litho.ai> | Live — 200 OK               |
| Network Status  | <https://status.litho.ai> | Live — `{"status":"ok"}`    |
| Public RPC      | <https://rpc.litho.ai>    | Live — 200 OK, rate-limited |
| Public REST API | <https://api.litho.ai>    | Live — 200 OK, rate-limited |

**Live chain stats (verified March 1, 2026):**

* Network: `lithosphere_700777-1` (reset from `lithosphere_777777-1` on 2026-03-23)
* Latest Block Height: `779,841`
* Node: `sentry-01` (evmosd v20.0.0)
* Sync Status: In sync (not catching up)

***

### 2. The 522 Timeout — Root Cause & Fix

**What was happening:** Cloudflare was proxying traffic for the explorer domain to the production server on port 3000. Nothing was listening on port 3000 — the explorer Docker service had never been added to the production `docker-compose.yaml`. Cloudflare couldn't reach the origin server, so it returned a 522 timeout to every visitor.

**What we fixed:** Added the full explorer service to the production compose stack, wired it to the correct endpoints, and deployed it to the production EC2 node via an automated pipeline.

***

### 3. Full List of Issues Found and Resolved

During deployment we audited the entire stack and resolved **14 separate issues**:

| #  | Issue                                                  | Impact                                                                                 | Fix                                                                      |
| -- | ------------------------------------------------------ | -------------------------------------------------------------------------------------- | ------------------------------------------------------------------------ |
| 1  | Explorer service missing from production compose       | **Critical** — caused the 522 timeout                                                  | Added complete explorer service definition                               |
| 2  | Grafana and Explorer both assigned port 3000           | **Critical** — port conflict, one service would fail                                   | Moved Grafana to port 3001 across all config files                       |
| 3  | CI/CD only deployed to one path, not the explorer path | **Critical** — explorer never deployed by pipeline                                     | Added `/opt/lithoscan` deploy path to pipeline                           |
| 4  | No `.env` file being written for explorer on deploy    | **High** — explorer would start with no config                                         | Added `.env` write step to pipeline                                      |
| 5  | No explorer deploy step in CI/CD pipeline              | **High** — explorer stack never started automatically                                  | Added `docker compose up` step for explorer stack                        |
| 6  | Health monitoring checking wrong service on port 3000  | **Medium** — alerts were mislabeled (said "Grafana")                                   | Fixed to monitor Explorer on :3000, Grafana on :3001                     |
| 7  | All RPC endpoints pointed at Validator internal IP     | **High** — violates security architecture; Validator should never be accessed directly | Replaced all with Sentry node IPs, then upgraded to public HTTPS domains |
| 8  | EVM Chain ID default was `61` (wrong network)          | **High** — transactions would target wrong chain                                       | Changed to `777777` (Lithosphere mainnet)                                |
| 9  | No mainnet environment config file existed             | **High** — no production `.env` to deploy from                                         | Created `.env.mainnet` with all production values                        |
| 10 | Database address column too narrow (42 chars)          | **High** — Cosmos bech32 addresses (`litho1...`) don't fit in `VARCHAR(42)`            | Widened to `VARCHAR(100)`, added `evm_address` column                    |
| 11 | Database permissions only granted to one role          | **Medium** — deployment would fail if using `litho` or `lithoscan_admin` DB user       | Updated GRANT block to cover all three application roles                 |
| 12 | `DATABASE_URL` pointed at local container, not RDS     | **Critical** — production has no local Postgres; uses AWS RDS                          | Updated to RDS endpoint with Secrets Manager credentials                 |
| 13 | No AWS authentication in deployment pipeline           | **High** — couldn't fetch RDS credentials securely                                     | Added OIDC role assumption + Secrets Manager fetch                       |
| 14 | Database schema incompatible with Ethermint chain      | **Critical** — simplified EVM-only schema couldn't store Cosmos transactions           | Replaced entirely with canonical dual-layer schema                       |

***

### 4. Production Architecture

The production stack runs across AWS infrastructure with the following layout:

```
Internet
    │
    ▼
Cloudflare (DNS + DDoS protection + CDN)
    │
    ├── makalu.litho.ai ──► Indexer EC2 :3000 (Explorer frontend)
    │
    ├── rpc.litho.ai ─────► Sentry 1 Nginx :443 ──► CometBFT RPC :26657
    │                                                 (10 req/s rate limit)
    ├── api.litho.ai ─────► Sentry 1 Nginx :443 ──► Cosmos REST :1317
    │                                                 (30 req/s rate limit)
    └── status.litho.ai ──► Sentry 1 (Network status dashboard)

EVM JSON-RPC ──► AWS Network Load Balancer ──► Validator EVM :8545
```

**Security layers in place:**

* TLS 1.2/1.3 only, strong cipher suite (ECDHE + AES-GCM)
* HSTS with 2-year max-age on all HTTPS endpoints
* Cloudflare Full (strict) mode — end-to-end TLS, no unencrypted hops
* Rate limiting on public RPC/API (Nginx)
* AWS OIDC — no plaintext credentials in CI/CD
* RDS credentials managed via AWS Secrets Manager
* Validator node never exposed directly (only via Sentry)

***

### 5. Database — Canonical Production Schema

The production database (AWS RDS PostgreSQL) is initialised with the full Ethermint dual-layer schema, supporting both Cosmos and EVM transaction types:

| Table              | Purpose                                                                 |
| ------------------ | ----------------------------------------------------------------------- |
| `blocks`           | Block headers with height, hash, proposer, tx count                     |
| `transactions`     | Cosmos-layer transactions (staking, governance, IBC, etc.)              |
| `evm_transactions` | EVM transactions (smart contracts, token transfers) linked to Cosmos tx |
| `accounts`         | All accounts with both `litho1...` bech32 and `0x...` EVM addresses     |
| `validators`       | Validator set with commission, uptime, jailed status                    |
| `token_transfers`  | LEP-20 token transfer events                                            |
| `contracts`        | Deployed smart contracts with verification status                       |
| `proposals`        | Governance proposals with vote tallies                                  |
| `network_stats`    | Time-series network statistics for dashboard                            |
| `indexer_state`    | Indexer progress tracking (last indexed block)                          |

**15 genesis accounts pre-seeded** from the official `address_mapping_litho.csv`, covering all initial token allocations (Ecosystem, Foundation Treasury, Team, Private Sale, Public Sale, Liquidity, Marketing, Advisors). Balances stored at full 18-decimal precision (`ulitho`).

***

### 6. Automated CI/CD Pipeline

Every push to the `main` branch now triggers a fully automated deployment pipeline:

```
Push to main
    │
    ├── 1. Checkout code
    ├── 2. AWS OIDC authentication (→ Secrets Manager for RDS credentials)
    ├── 3. SSH to production server
    ├── 4. Pull latest code, select correct .env (mainnet/testnet/staging)
    ├── 5. Build Docker images (api, indexer, explorer)
    ├── 6. Inject RDS DATABASE_URL from Secrets Manager
    ├── 7. Deploy Makalu stack (docker compose up)
    ├── 8. Write explorer .env to /opt/lithoscan
    ├── 9. Deploy Lithoscan explorer stack (docker compose up)
    ├── 10. Health check — API (:4000/health) with 5 retries
    ├── 11. Health check — Explorer (:3000) with 6 retries
    └── 12. Generate deployment summary
         │
         └── On failure → Automatic rollback to previous version
```

The pipeline supports three environments: `mainnet`, `staging`, `testnet`, selectable via manual trigger or automatically from branch.

***

### 7. Health Monitoring

Automated health checks run every 5 minutes via GitHub Actions and alert on failures:

| Check              | Endpoint                  | Alert On         |
| ------------------ | ------------------------- | ---------------- |
| Explorer Frontend  | <https://makalu.litho.ai> | Non-2xx response |
| Network Status     | <https://status.litho.ai> | Non-2xx response |
| API Service        | `:4000/health`            | Non-200 response |
| Prometheus Metrics | `:9091/-/healthy`         | Non-200 response |
| Grafana Dashboard  | `:3001`                   | Non-2xx response |

***

### 8. Chain Configuration (Verified)

All services are configured for the correct Lithosphere mainnet parameters:

| Parameter               | Value                     |
| ----------------------- | ------------------------- |
| Cosmos Chain ID         | `lithosphere_700777-1`    |
| EVM Chain ID            | `700777`                  |
| Native Token            | `LITHO`                   |
| Base Denomination       | `ulitho`                  |
| Decimals                | `18`                      |
| Address Prefix (bech32) | `litho`                   |
| Explorer Domain         | `https://makalu.litho.ai` |
| Public RPC              | `https://rpc.litho.ai`    |
| Public API              | `https://api.litho.ai`    |

***

## Current Status

**Everything is live and operational.**

The 522 timeout error that was reported has been resolved. The block explorer is accessible at <https://makalu.litho.ai>, the public RPC and API are serving traffic with rate limiting and TLS, and the deployment pipeline is fully automated for all future releases.

If links are not loading in your browser, this is most likely a DNS propagation delay — the domain was recently pointed to the new server and DNS changes can take a few hours to reach all networks globally. To verify from your end:

1. Try in a private/incognito window
2. Try on mobile data (different DNS resolver)
3. Check propagation status at: <https://dnschecker.org/#A/makalu.litho.ai>

The infrastructure is confirmed live from multiple locations.

***

*Report generated March 1, 2026 — KaJ Labs Development Team*


# Validator / Infra Team — Action Items from Security Audit

**Date**: 2026-03-30 **From**: Dev Team **Context**: We've addressed all code-level findings from the security audit in our repo. The items below require infra team action — either infrastructure changes, access we don't have, or coordination with external services.

***

## 1. Deploy Status API Fixes to Production (from your DEV\_TEAM\_UPDATE.md)

Your endpoint sanitization and real block time fixes are committed but not yet deployed. Per your doc:

```bash
cd ansible
export ANSIBLE_ROLES_PATH=./roles ANSIBLE_HOST_KEY_CHECKING=False
ansible-playbook -i inventory/hosts.ini playbooks/deploy-explorer-sentry.yml \
  -e "postgres_password=<PW>" -e "redis_password=<PW>"
```

This rebuilds the `network-status` container with sanitized endpoints and real metrics on Sentry-1.

***

## 2. Finding #3 (High): Weak Decentralization Signal

**What we did**: Explorer already displays validator list with voting power and commission.

**What we need from you**:

* Publish a **seed node list** (node IDs + addresses) that external validators can use to bootstrap
* Confirm the **active validator set size** and current validator count so we can display it accurately
* Provide **sentry topology guidance** — minimum recommended peers, geographic distribution recommendations
* Clarify: should we label Makalu as "testnet" explicitly in the explorer UI and status API? The audit flagged that we're presenting testnet posture as mainnet.

***

## 3. Finding #4 (High): Binary Provenance

**What we need from you**:

* Publish **reproducible build instructions**: exact repo URL, commit hash, Go compiler version, and build command for `lithod`
* Publish **signed release manifests** with SHA256 digests for all official binaries
* Document the **exact Evmos upstream fork point** and patch delta (which Evmos commit was forked, what was changed)
* Host deterministic binaries at a **single canonical release location** (GitHub Releases on KaJLabs/Lithosphere, or a dedicated downloads page)
* Generate and publish an **SBOM** (Software Bill of Materials) — this is planned for Phase 2/3 of the infrastructure roadmap

***

## 4. Finding #9 (Medium): NLB Environment Naming

The NLB is named `litho-mainnet-rpc-*` but serves Makalu testnet. Your doc says this requires downtime to rename.

**Request**: Schedule this for the next maintenance window. No rush — just don't forget it.

***

## 5. Finding #10 (Medium): Rate Limits and Anti-Spam

We've documented what we know in `docs/network/chain-parameters.md`. But we need authoritative numbers from you:

* **Minimum gas price** enforced by validators (exact value in `ulitho`)
* **Mempool configuration**: max mempool size, tx queue limits
* **Nginx/Cloudflare rate limits** on `rpc.litho.ai` and `api.litho.ai` (requests per second per IP)
* **Pruning configuration**: what's the pruning strategy on sentry nodes? What's the recommendation for indexers that need archive data?
* **WebSocket connection limits** on the EVM WS endpoint

***

## 6. gRPC TLS Proxy (from your DEV\_TEAM\_UPDATE.md)

Your endpoint cleanup changed the default gRPC to `grpc.litho.ai:9090`. We've used this in our `network-parameters.json`. Is TLS actually configured on this endpoint now, or is it still direct/plaintext? If plaintext, we should note that in our docs.

Same question for **EVM WebSocket** — is `wss://` available via Nginx, or still `ws://54.163.248.63:8546` direct?

***

## 7. Open GitHub Issues on KaJLabs/Lithosphere

The audit flagged issue #3 ("\[TESTNET] Deployment Failure") — it's now closed. But two issues remain open:

* **#5**: "Fix grammatical error in 'What is Lithosphere?'" (opened 2026-03-24)
* **#4**: "Update deploy-indexer-ec2.sh" (opened 2026-03-23)

**Request**: Triage these — close, assign, or comment with status. Open unattended issues on a public repo hurt credibility per the audit.

***

## 8. Network Parameters JSON

We've published a machine-readable `docs/network/network-parameters.json` with canonical chain config for wallets and operators. Please review it and confirm all values are correct — especially:

* `networkType`: We set `"testnet"` — confirm this is correct for Makalu
* `apis.grpc` address: `grpc.litho.ai:9090`
* `apis.evmJsonRpc`: We pointed at `https://rpc.litho.ai` — is this the correct public EVM JSON-RPC endpoint?

***

## 9. Directory Rename: Makulu → Makalu (CRITICAL for next deploy)

We've renamed the monorepo directory from `Makulu/` to `Makalu/` to match the network name. All CI/CD pipelines, deploy scripts, and env files now reference `/opt/lithosphere/Makalu`.

**Before the next deploy**, you must rename the directory on the production server:

```bash
ssh ec2-user@<INDEXER_IP> -o ProxyJump="ec2-user@44.218.142.100"
sudo mv /opt/lithosphere/Makulu /opt/lithosphere/Makalu
```

If the deploy runs before this rename, it will create a new `/opt/lithosphere/Makalu` directory alongside the old one, and the existing containers under `Makulu` will keep running on stale code.

***

## 10. EVM RPC routing — diagnosis corrected (2026-04-23)

**Original severity**: High (raised 2026-04-22). **Status**: Dev-side root cause resolved; infra ask reduced.

**Corrected diagnosis** (per your reply dated 2026-04-22): Our original report had the diagnosis inverted. `rpc.litho.ai` IS the live EVM JSON-RPC for `lithosphere_700777-2`. The NLB serves the abandoned `700777-1` fork. The `0x` returns we observed for `eth_getCode` on `0xEB6cfcC…` were correct — that address does not exist on the live chain; it was deployed pre-reset on `700777-1`.

**Actual root cause (dev side)**: The `SEEDED_TOKENS` constant in `Makalu/indexer/src/mappings.ts` had all 10 pre-reset contract addresses. The explorer's `/tokens` page was displaying those stale addresses. When users pasted them into MetaMask, `eth_getCode` on `rpc.litho.ai` returned `0x` because the contracts genuinely don't exist on `700777-2`.

**Dev-side fixes applied (2026-04-23)**:

* Updated all 10 `SEEDED_TOKENS` to canonical `700777-2` addresses (deployer `0x10ed4F…`)
* Added `migrateTokenAddresses()` startup step to evict stale DB rows on next deploy
* Updated `EVM_RPC_URL` and `FAUCET_RPC_URL` in `.env.mainnet` from NLB → `https://rpc.litho.ai`
* `WalletContext.tsx` already used `rpc.litho.ai` — no change needed there

**Remaining infra ask**: `evm-rpc.litho.ai` as a dedicated EVM subdomain is still welcome for industry convention, but no longer blocking wallet UX. When you stand it up, please point it at `mtest-sentry-01:8545` (live chain), not the NLB.

**Verification** (after our next deploy):

```bash
$ curl -sS -X POST https://rpc.litho.ai -H 'Content-Type: application/json' \
    -d '{"jsonrpc":"2.0","method":"eth_getCode","params":["0x599a7E135f1790ae117b4EdDc0422D24Bc766161","latest"],"id":1}'
# Must return ~2KB bytecode (active 2026-04-24 wLITHO deployment)
```

***

## Summary

| Item                                            | Severity              | Action                                                    |
| ----------------------------------------------- | --------------------- | --------------------------------------------------------- |
| **Rename `/opt/lithosphere/Makulu` → `Makalu`** | **Critical**          | **Must happen before next deploy**                        |
| Deploy status API fixes                         | Critical              | Run ansible playbook on Sentry-1                          |
| Seed node list + topology guidance              | High                  | Publish for external validators                           |
| Binary provenance (builds, SBOM, fork docs)     | High                  | Publish reproducible build instructions                   |
| EVM wallet UX (token addresses)                 | ~~High~~ **Resolved** | Dev-side fix: canonical addresses + EVM\_RPC\_URL updated |
| NLB decommission / re-target                    | Medium                | Per your revised plan for item #4                         |
| Rate limit / anti-spam numbers                  | Medium                | Provide authoritative config values                       |
| gRPC/WSS TLS status                             | Medium                | Confirm endpoint TLS configuration                        |
| GitHub issue triage                             | Medium                | Close or update #4 and #5                                 |
| Review network-parameters.json                  | Low                   | Confirm values are correct                                |


# Makalu "Extra Works" — Dependency Requests

These are the concrete inputs needed from external teams to unblock streams 2–6 of the Makalu extra-works backlog. Each block is written so it can be forwarded as-is. Full plan: `~/.claude/plans/have-some-extra-works-warm-rossum.md`.

> Status snapshot (2026-06-21): Stream 1 (LEP100 faucet) is **done** — verified working in prod, fixed an FGPT/MUSA metadata swap. Stream 7 (toolchain) is unblocked and independent of all teams below.

***

## Stream 2 — MultX Swap (→ Backend / Bridge team)

The MultXBridge contract is deployed at `0x5832D5E609c6690f74c7683606Eb20F89ff096a6` on chain 700777, but there is **no bridge/swap code in the Makalu monorepo**. To build the in-repo swap UI + API + indexing, we need:

1. **MultXBridge ABI** (JSON) — the deployed contract's ABI, plus its source if available.
2. **Counterpart-chain details** — the bridge contract address(es) on the other chain(s) and which chains are supported, plus the **token map** (which LEP-100 / ERC-20 tokens bridge to what on each side).
3. **Lock/release event signatures** — the exact events emitted on lock and on release/claim (names + indexed topics) so the indexer can ingest them into a `bridge_transfers` table.
4. **Claim/release flow spec** — since release is claim-based (no auto-executor), what exactly does a user submit to claim? The proof/attestation format (signature scheme, message structure, who signs), and the function signature they call.
5. **Where the existing bridge UI lives** — prior notes reference `BridgeRelease.jsx` and `relay-release.js` from the 2026-06-17 deploy. Which repo/path? We may port that logic rather than rewrite it.

With the above we can ship: SDK ABI export, `/api/bridge/*` (tokens, history, claimable), indexer ingestion, and an explorer `bridge.tsx` + claim component.

***

## Stream 3 — Thanos Wallet (→ Wallet team)

The explorer already uses Web3Modal v5 + WalletConnect (`Makalu/explorer/context/WalletContext.tsx`). Wiring Thanos in is small once we know **what kind of wallet it is**:

1. **If Thanos is a WalletConnect wallet:** its **WalletConnect Explorer (registry) ID** (the hex ID used in `featuredWalletIds`). Confirm it is listed in the WalletConnect registry.
2. **If Thanos is a browser extension / injected wallet:** its **EIP-6963 provider RDNS** (and whether it exposes a standard EIP-1193 provider), or a link to its SDK/integration docs.
3. Confirm Thanos supports **chain 700777** (EVM RPC `https://rpc.litho.ai`); if it needs a custom add-chain config, provide the expected parameters.

With (1) or (2) we can make Thanos the primary/featured wallet and smoke-test connect + a signed tx.

***

## Stream 4 — DNNS integration (→ DNNS team, dnns.litho.ai)

The explorer currently resolves only literal `0x…` and `litho1…` addresses. To add `*.litho`-style name resolution we need the **resolution interface** — either:

* **On-chain resolver:** resolver **contract address + ABI** on 700777, with the methods for forward (`name → address`) and reverse (`address → name`) resolution, and the domain suffix convention; **or**
* **REST API:** base URL + endpoints for forward/reverse lookup, the response schema, auth (if any), and rate limits.

Also useful: a couple of **known registered names** for testing, and whether resolution should be cached (TTL guidance). The public docs page renders client-side and didn't expose these — a short integration spec or OpenAPI/ABI file is ideal.

***

## Stream 5 — Quantts integration (→ Quantt team, research.quantt.at / dev.quantt.at)

Greenfield; the public endpoint returns 403 so we have no contract to build against. We need:

1. **API base URL** (prod + dev) and **auth scheme** — API key? OAuth? Where do we get a key/credentials?
2. **Endpoints + response schemas** for the data we'd surface — confirm with the product owner *what* should appear in the explorer (e.g. token analytics, risk metrics, quant research, price feeds).
3. **Rate limits / caching guidance** (we'll proxy server-side via `/api/quant/*` and cache in Redis so the key never reaches the browser bundle).

With the API spec + a key we can build the server-side proxy and the explorer analytics widget(s).

***

## Stream 6 — Validator infra cleanup (→ Validator infra team)

This is ops work in the **Ansible/validator-infra repo, which is not in this monorepo**. To execute we need:

1. **Repo access** to the validator Ansible repo (and confirmation of which inventory is authoritative).
2. **A change window** for config pushes / sentry restarts.

Scope once unblocked (from prior findings):

* Clean `app.toml.j2` so an `ansible --tags config` dry-run shows **only** intended deltas — today it carries 40+ pending drift changes (RPC `0.0.0.0` exposure, telemetry flips, economics) that make `--tags config` unsafe, forcing surgical `sed` edits and defeating intent-as-code.
* Align the 4 drifted sentries (AWS `10.0.1.218`, `10.1.1.227` + 2 Hostinger) from `timeout_commit=3s / timeout_propose=900ms` to match the active validators (`timeout_commit=500ms`).
* Add **automated drift detection** (scheduled diff of live `config.toml`/`app.toml` vs. Ansible intent), since drift has recurred (Kamet val-04 2026-05-05, mtest-val-01 2026-05-08).


# api-reference


# GraphQL API Reference

> **Work in Progress** -- This document is under active development. Some schemas and details may change.

## Overview

The Lithosphere GraphQL API is built with **Apollo Server v4+** and serves as the primary GraphQL gateway for querying blockchain data, interacting with smart contracts, and subscribing to real-time events on the Lithosphere network.

## Features

* **Blockchain data querying and indexing** -- Query blocks, transactions, accounts, and token balances.
* **Smart contract interactions** -- Read contract state and submit transactions through GraphQL mutations.
* **Real-time event subscriptions** -- Subscribe to on-chain events via GraphQL subscriptions for live updates.

## Endpoint

The GraphQL API is typically available at:

```
/graphql
```

In development mode, a **GraphQL Playground** is available at the same endpoint, allowing you to explore the schema, build queries interactively, and inspect documentation.

## Local Development

Start the GraphQL server locally using:

```bash
pnpm dev:api
```

This launches the Apollo Server with hot-reload enabled. The GraphQL Playground will be accessible at `http://localhost:<port>/graphql`.

## SubQuery Indexer

The GraphQL backend is powered by a **SubQuery indexer** that indexes on-chain events from the Lithosphere network. The indexer processes blocks and transactions, storing structured data in PostgreSQL for efficient querying through the GraphQL layer.

## Example Query

```graphql
query GetBlockInfo {
  block(number: 12345) {
    hash
    number
    timestamp
    transactions {
      hash
      from
      to
      value
    }
  }
}
```

```graphql
query GetAccountBalance {
  account(address: "0x...") {
    balance
    nonce
    transactions(first: 10) {
      hash
      value
      timestamp
    }
  }
}
```

> **Note:** The schema above is illustrative. The full schema will be documented once it is finalized.

## Further Reading

Detailed schema documentation, mutation references, and subscription guides are coming soon.




---

[Next Page](/llms-full.txt/1)