mirror of
https://gitlab.com/pezkuwichain/pezkuwi-sdk.git
synced 2026-10-30 23:49:54 +00:00
sync: mirror deployed github repo (chains + sanitized bridge), keep GitLab CI
Make this monorepo's tracked tree identical to the deployed github repo (github.com/pezkuwichain/pezkuwi-DKS): all RC/AH/People runtimes and framework carry the mainnet fixes (incl. U128CurrencyToVote everywhere, so the staking election stall cannot recur), and tools/usdt-bridge matches the current, public-safe custody tooling (real config/deploy units gitignored, secret-file locations and server IPs stripped, sanitized *.example templates committed). Only exception to the mirror: GitLab-native CI is preserved (.gitlab-ci.yml and .gitlab/), to be rebuilt to match the github CI pipeline in a follow-up.
This commit is contained in:
Satoshi Qazi Muhammed committed
1 parent
82543bdfab
commit
d285d59108
736 files changed
+15082
-16359
No files matched your search
@@ -0,0 +1,136 @@
|
||||
# PezkuwiChain — Brand Heritage & Cultural Etymology
|
||||
|
||||
**The naming origins, etymology, and cultural foundations of the Digital Kurdistan State's blockchain.**
|
||||
|
||||
---
|
||||
|
||||
## 1. Purpose
|
||||
|
||||
This document records the cultural, linguistic, and symbolic foundations of PezkuwiChain — the
|
||||
sovereign blockchain of the **Digital Kurdistan State (DKS)** — so that the meaning behind the
|
||||
project's name, symbols, and visual identity is clear to the community, partners, and the public.
|
||||
|
||||
---
|
||||
|
||||
## 2. Etymology of "Pezkuwi"
|
||||
|
||||
### 2.1 Kurdish and its dialects
|
||||
|
||||
Kurdish is an Indo-Iranian language with two major dialect groups:
|
||||
|
||||
- **Kurmancî (Northern Kurdish)** — spoken in Bakur, Rojava, and much of the diaspora; written
|
||||
in the Hawar (Latin) alphabet.
|
||||
- **Soranî (Central Kurdish)** — spoken in Başûr (Kurdistan Region of Iraq) and Rojhilat;
|
||||
written in a modified Arabic alphabet.
|
||||
|
||||
### 2.2 "Pez"
|
||||
|
||||
**"pez"** is one of the most ancient words in the Kurdish lexicon — small livestock, the
|
||||
*Caprinae* family. It descends from the Avestan root *pasu-* ("sheep, domestic animal") and
|
||||
belongs to the Proto-Indo-European *peḱu-* family, with cognates including Sanskrit *paśu-*,
|
||||
Latin *pecus*, and German *Vieh*.
|
||||
|
||||
### 2.3 "Kûvî"
|
||||
|
||||
**"kûvî"** (also *kuwî*, *kîwî*) means wild, untamed, mountain-dwelling — used productively in
|
||||
Kurdish to mark the wild counterpart of a domestic animal.
|
||||
|
||||
### 2.4 "Wild goat" across dialects
|
||||
|
||||
| Dialect | Compound | Composition |
|
||||
| --- | --- | --- |
|
||||
| **Kurmancî** | *pezkûvî*, *bizina kûvî* | pez (livestock) + kûvî (wild) |
|
||||
| **Soranî** | *bizinîkûvî*, *bizinîkîwî* | bizin (she-goat) + kûvî / kîwî (wild) |
|
||||
|
||||
Both refer to the same animal: *Capra aegagrus*, the bezoar wild goat. The difference is
|
||||
purely dialectal.
|
||||
|
||||
### 2.5 The project name
|
||||
|
||||
**"Pezkuwi"** (from Kurmancî *pezkûvî*) is the public-facing brand — Kurmancî is the most widely
|
||||
spoken Kurdish dialect and uses the Latin alphabet, well-suited to international branding. The
|
||||
**Soranî** form appears in internal technical naming — e.g. **"Bizinikiwi"** (the core
|
||||
framework, from *bizinîkîwî*) — acknowledging the dialect of the Kurdistan Region of Iraq where
|
||||
the project is based. Both name the same animal: the wild goat, national totem of the Kurds.
|
||||
|
||||
### 2.6 Scientific & geographic note
|
||||
|
||||
The bezoar wild goat (*Capra aegagrus*) is the wild ancestor of the domestic goat. Its densest
|
||||
populations occur in the **Zagros Mountains** of the Kurdistan Region of Iraq, extending into
|
||||
eastern Turkey and western Iran. It was the first wild caprine domesticated by humans —
|
||||
in the Zagros, ~10,000 years ago (Zeder & Hesse, 2000) — making it a foundational species in
|
||||
the history of civilization, originating in the Kurdish homeland.
|
||||
|
||||
### 2.7 Cultural significance
|
||||
|
||||
In Kurdish tradition the *pezkuwi* is a **national totem animal**, paralleling the gray wolf for
|
||||
Turkic peoples, the lion for Persians, or the eagle for many nations. It embodies **resilience**
|
||||
(surviving harsh mountains), **freedom** (wild, never subjugated), and **connection to the
|
||||
homeland**. As the saying goes, *"Kurdên çiyayî ne"* — "The Kurds are people of the mountain."
|
||||
|
||||
---
|
||||
|
||||
## 3. Naming of PezkuwiChain
|
||||
|
||||
- **"PezkuwiChain"** — the chain of the mountain goat; metaphorically, the chain of the
|
||||
mountain people.
|
||||
- **"PEZ KIWI Company"** — the Latin-alphabet transliteration of *pez kûvî*, the project's
|
||||
registered company in the Kurdistan Region of Iraq.
|
||||
|
||||
The name reflects the mission: decentralized digital infrastructure for stateless peoples and
|
||||
sovereign communities — for those whose freedom has always been tied to their mountains and to
|
||||
their ability to govern themselves.
|
||||
|
||||
---
|
||||
|
||||
## 4. Visual Identity (summary)
|
||||
|
||||
The PezkuwiChain identity draws exclusively on Kurdish national iconography:
|
||||
|
||||
- **Central Roj (sun)** — from the flag of Kurdistan; its rays evoke *Newroz*.
|
||||
- **Six petals** — the four regions of Kurdistan plus the global diaspora, in the organic
|
||||
rosette form of Kurdish textile and carpet tradition.
|
||||
- **Kesk / Sor / Zer** — the green, red, and yellow of the Kurdistan flag.
|
||||
|
||||
Full specification: [VISUAL_IDENTITY.md](./VISUAL_IDENTITY.md).
|
||||
|
||||
---
|
||||
|
||||
## 5. Independence & Open-Source Foundation
|
||||
|
||||
PezkuwiChain is an **independent** Kurdish project, not affiliated with or endorsed by any other
|
||||
blockchain project or foundation. Its software is built upon the open-source **polkadot-sdk**,
|
||||
used under the **Apache-2.0** and **GPL-3.0** licenses, which expressly permit forking,
|
||||
modification, and redistribution. Attribution to the original authors is provided in the
|
||||
repository [`NOTICE`](../NOTICE) file.
|
||||
|
||||
The name "Pezkuwi" is a Kurdish word with its own language of origin, etymology, meaning, and
|
||||
cultural reference frame — a coherent native term (with a documented Soranî counterpart,
|
||||
*bizinîkîwî*), independent in origin and meaning.
|
||||
|
||||
---
|
||||
|
||||
## 6. Concluding Statement
|
||||
|
||||
PezkuwiChain draws its name from the Kurdish language, its symbols from Kurdish national
|
||||
iconography, its colors from the Kurdish flag, and its mission from the Kurdish people's
|
||||
long experience of building resilient communities in defiance of external power. It is a
|
||||
Kurdish project — built for the Kurdish nation and for all peoples who share its values of
|
||||
sovereignty, freedom, and self-determination.
|
||||
|
||||
---
|
||||
|
||||
## References
|
||||
|
||||
**Linguistic:** Glosbe English–Kurmancî dictionary; Kurdayety etymological dictionary ("pez");
|
||||
Chyet, M. L. (2003), *Kurdish–English Dictionary (Ferhenga Kurmancî–Inglîzî)*, Yale University Press.
|
||||
|
||||
**Scientific:** Zeder, M. A., & Hesse, B. (2000), "The Initial Domestication of Goats in the
|
||||
Zagros Mountains 10,000 Years Ago," *Science* 287(5461); Weinberg, P., & Ambarli, H. (2020),
|
||||
*Capra aegagrus*, IUCN Red List.
|
||||
|
||||
**Cultural:** Kurdistan Regional Government, *Flag of Kurdistan: Official Symbolism*.
|
||||
|
||||
---
|
||||
|
||||
*PEZ KIWI Company · info@pezkuwichain.io · https://pezkuwichain.io*
|
||||
@@ -0,0 +1,58 @@
|
||||
# About PezkuwiChain — Brand & Identity
|
||||
|
||||
## An Independent Kurdish Blockchain Project
|
||||
|
||||
**PezkuwiChain** is the sovereign blockchain of the **Digital Kurdistan State (DKS)**,
|
||||
developed by **PEZ KIWI Company**, a private company registered with the Kurdistan
|
||||
Regional Government, Ministry of Trade and Industry (Registration No. 40633, Erbil, Iraq).
|
||||
|
||||
PezkuwiChain is an **independent project**. It is built upon the open-source
|
||||
**polkadot-sdk** codebase, licensed under the **Apache License 2.0** and **GPL-3.0** —
|
||||
licenses that expressly permit independent forking, modification, and redistribution.
|
||||
PezkuwiChain is **not affiliated with, endorsed by, or sponsored by** Parity Technologies,
|
||||
the Web3 Foundation, or the Polkadot project. Full attribution to the original authors is
|
||||
provided in the repository [`NOTICE`](../NOTICE) file.
|
||||
|
||||
---
|
||||
|
||||
## The Name: "Pezkuwi"
|
||||
|
||||
**"Pezkuwi"** is the **Kurmancî Kurdish** word for the **wild mountain goat** — the bezoar
|
||||
wild goat (*Capra aegagrus*) native to the Zagros mountains of Kurdistan. The Soranî dialect
|
||||
equivalent, **"bizinîkîwî"**, is used in internal technical naming (e.g. `Bizinikiwi`, the
|
||||
core framework). Both refer to the same animal — the national totem of the Kurdish people,
|
||||
symbolizing resilience, freedom, and the bond between Kurds and their mountains.
|
||||
|
||||
The Kurmancî compound combines **"pez"** (small livestock/caprine, from the ancient
|
||||
Indo-Iranian root *pasu-*) and **"kûvî"** (wild, mountain-dwelling).
|
||||
|
||||
---
|
||||
|
||||
## The Logo & Colors
|
||||
|
||||
- **Central sun (Roj)** — the national symbol of the Kurdish people, from the Kurdistan flag.
|
||||
- **Six petals** in a floral/rosette arrangement — the four regions of Kurdistan (Bakur,
|
||||
Başûr, Rojava, Rojhilat) plus the global diaspora, drawn from Kurdish carpet and textile motifs.
|
||||
- **Kurdish national colors** — *kesk* (green: land), *sor* (red: sacrifice), *zer* (yellow: sun).
|
||||
|
||||
PezkuwiChain uses no color outside the Kurdish national palette. The red is the deep
|
||||
Kurdish flag red (*sor*).
|
||||
|
||||
---
|
||||
|
||||
## Mission
|
||||
|
||||
PezkuwiChain exists to build decentralized, borderless digital infrastructure for the
|
||||
Kurdish nation and for all stateless peoples and sovereign communities who share the values
|
||||
of freedom, resilience, and self-determination.
|
||||
|
||||
---
|
||||
|
||||
## Further Reading
|
||||
|
||||
- [BRAND_HERITAGE.md](./BRAND_HERITAGE.md) — naming origins, etymology, and cultural foundations
|
||||
- [VISUAL_IDENTITY.md](./VISUAL_IDENTITY.md) — color palette, logo variants, and usage guidelines
|
||||
|
||||
## Contact
|
||||
|
||||
**PEZ KIWI Company** · info@pezkuwichain.io · https://pezkuwichain.io
|
||||
+91
-172
@@ -1,191 +1,110 @@
|
||||
# Release
|
||||
# Release & runtime-upgrade runbook
|
||||
|
||||
The outputs of a stable release are:
|
||||
PezkuwiChain holds real user funds. A runtime upgrade is the single most dangerous
|
||||
operation we perform — a bad migration or a wrong WASM can corrupt state or brick the
|
||||
chain. This runbook is the required, repeatable process. Do not skip steps.
|
||||
|
||||
- The binaries:
|
||||
- `pezkuwi`
|
||||
- `pezkuwi-execute-worker`
|
||||
- `pezkuwi-prepare-worker`
|
||||
- `pezkuwi-teyrchain`
|
||||
- `pezkuwi-omni-node`
|
||||
- `chain-spec-builder`
|
||||
- `frame-omni-bencher`
|
||||
## What a release produces
|
||||
|
||||
built for the `x86_64-unknown-linux-gnu` and `aarch64-apple-darwin` targets. The gpg signatures and sha256 checksums.
|
||||
- **Runtime WASM blobs** for the deployable runtimes (relay `pezkuwichain`, system
|
||||
teyrchains `asset-hub-pezkuwichain`, `people-pezkuwichain`), built by
|
||||
`.github/workflows/release.yml`.
|
||||
- For each blob: the **blake2-256 hash** (the value `authorizeUpgrade` commits to),
|
||||
the sha256, and an **SLSA build-provenance attestation**.
|
||||
- A **draft GitHub release** (human review before publishing a fund-critical artifact).
|
||||
|
||||
- The runtimes for Zagros and its system teyrchains.
|
||||
- The new crate versions published to `crates.io`.
|
||||
- Debian package for the Pezkuwi binary.
|
||||
- Docker images for:
|
||||
- `pezkuwi` (includes `pezkuwi-execute-worker` & `pezkuwi-prepare-worker`)
|
||||
- `pezkuwi-teyrchain`
|
||||
- `pezkuwi-omni-node`
|
||||
- `chain-spec-builder`
|
||||
The node binary is built from the same tag with the pinned toolchain.
|
||||
|
||||
## CI tiers (what gates what)
|
||||
|
||||
# Timeline
|
||||
`Stable` releases are scheduled on a quarterly basis, usually by the end of the last month of each quarter. The exact
|
||||
schedule can be found on the [Release Registry](https://github.com/pezkuwichain/release-registry/).It is possible to
|
||||
subscribe to a [calendar link](https://raw.githubusercontent.com/pezkuwichain/release-registry/main/releases-v1.ics)
|
||||
to have it in your personal calendar.
|
||||
| Tier | When | Gates |
|
||||
|---|---|---|
|
||||
| Fast gate (`check`, `quick-checks`, `security`) | every push/PR | compile, 6-runtime WASM build, **try-runtime**, fmt, supply-chain (cargo-deny), zepter/taplo |
|
||||
| Heavy suite (`test`) | nightly + `workflow_dispatch` | full nextest tests, workspace clippy, benches, doc-tests |
|
||||
| Release (`release`) | tag `v*`/`runtime-*` + `workflow_dispatch` | builds WASM, hashes, attestation, draft release |
|
||||
|
||||
Each stable release is supported for a period of one year from its first release. For example, `Pezkuwi stable2412`
|
||||
was released on `2024-12-17` and its end of life is set to `2025-12-16`.
|
||||
Before any mainnet upgrade the **heavy suite must be green on the release commit** —
|
||||
trigger it with `workflow_dispatch` and wait for it; do not rely only on the fast gate.
|
||||
|
||||
During this period, each stable release is updated with patch releases, which are scheduled on a monthly basis
|
||||
and contain fixes for any bugs that may be found.
|
||||
## spec_version policy
|
||||
|
||||
ℹ️ Note: the binaries and runtimes (if needed) are only provided for the latest `stable` release, for the previous
|
||||
releases only the crates.io release takes place.
|
||||
- `spec_name` is the chain identity and **must never change** for a live chain.
|
||||
- `spec_version` is a single monotonically increasing integer (schema `M_mmm_ppp`;
|
||||
current relay `1_020_007`). Bump it on **every** runtime change that ships — nodes use
|
||||
it to detect the upgrade.
|
||||
- Bump `transaction_version` only when extrinsic encoding/call indices change.
|
||||
- `impl_version` is informational.
|
||||
|
||||
This three month period between `stable` releases includes a 1.5 month QA period. This means that for each upcoming
|
||||
`stable` release, the branch from which that release will be made is created 1.5 months before the release date.
|
||||
This time is used to test the upcoming release candidate and find any issues that may arise with publishing crates
|
||||
to crates.io, binary artifacts and template synchronisation before the final release. The findings should be fixed
|
||||
and backported to the release branch. During this time, multiple release candidates may be built and rolled out.
|
||||
## Runtime-upgrade procedure (mainnet, fund-critical)
|
||||
|
||||
# Setup
|
||||
1. **Freeze the change set** on `main`; fast gate green.
|
||||
2. **Bump `spec_version`** (+ `transaction_version` if call encoding changed) in the
|
||||
affected runtime(s).
|
||||
3. **Run the heavy suite** (`workflow_dispatch` → `test.yml`) on that commit → all green.
|
||||
4. **try-runtime against live state** — dry-run the migrations on a snapshot of the live
|
||||
chain and confirm they succeed and post-upgrade invariants hold, *before* touching
|
||||
mainnet. (Pre-upgrade gate.)
|
||||
5. **Tag** `runtime-<name>-vX` → `release.yml` builds the WASM and publishes the
|
||||
**blake2-256** hash + sha256 + attestation as a draft release.
|
||||
6. **Reproduce & verify**: independently rebuild the tag with the pinned toolchain
|
||||
(`rust-toolchain.toml`) + committed `Cargo.lock`; confirm the blake2-256 matches.
|
||||
Publish the release only after the hash is confirmed.
|
||||
7. **Authorize on-chain**: governance/sudo `system.authorizeUpgrade(<blake2-256>)`, then
|
||||
`system.applyAuthorizedUpgrade(<wasm>)`. The hash authorized on-chain must equal the
|
||||
one in the release.
|
||||
8. **Watch**: confirm blocks are still produced and finalized after the upgrade.
|
||||
|
||||
We have two types of branches related to the releases: `master` and `stableYYMM`:
|
||||
- `master` is the main development branch where normal Pull Requests are opened. Developers need to mostly only care
|
||||
about this branch.
|
||||
- `stableYYMM` branch contains a version of the code that is ready to be released. Each `stableYYMM` branch corresponds
|
||||
to the corresponding stable release, which is in the maintenance or in a QA period. Its contents should be always
|
||||
audited. Merging to it is restricted to [Backports](#backports).
|
||||
## Pending bundle (next mainnet spec_version)
|
||||
|
||||
# Versioning
|
||||
These repo changes are ready and green but **not yet deployed**; they ship together in
|
||||
one coordinated upgrade after the heavy suite is fully green and reviewed:
|
||||
|
||||
We are releasing multiple different things from this repository in one release, but we don't want to use the same
|
||||
version for everything. Thus, in the following we explain the versioning story for the crates, node and Zagros.
|
||||
- Token symbol standardized to **HEZ** (metadata-hash, claims `Prefix`, chain-spec).
|
||||
- Claims statements repointed to **statement.pex.network** (hash-pinned; see
|
||||
[statement/README.md](statement/README.md)).
|
||||
- `tiki` pallet: 12 new functional/professional roles.
|
||||
- RuntimeVersion identity cleanup (dropped `parity-*` / `westmint`).
|
||||
- **Security-audit fix set** (AI-assisted internal review; commits `14cbf1a`, `9afd99a`
|
||||
on `main`) — 11 findings closed across `identity-kyc`, `messaging`, `perwerde`,
|
||||
`presale`, `tiki`, `welati`, plus the relay `SendXcmOrigin` narrowing in
|
||||
`xcm_config.rs`. No storage migration required (all changes are new storage items or
|
||||
Config/logic-only).
|
||||
- `staking-score`: noter submissions now require a posted bond
|
||||
(`register_as_noter`/`unregister_as_noter`) and sit in a 1-hour dispute window
|
||||
(`DisputeWindow`) before taking effect, disputable by any Council member and
|
||||
slashable by `RootOrDiwanOrTechnical` on confirmed fraud. Root/XCM-Transact
|
||||
submissions are unaffected (chain-authenticated, not a personal key).
|
||||
- Fixed `MONTH_IN_BLOCKS`/`HOUR_IN_BLOCKS` in `staking-score`: was silently assuming
|
||||
6s blocks (10/min) against this chain's actual 12s (5/min), doubling every
|
||||
duration-tier threshold in production.
|
||||
- `staking-score`'s weights are now real benchmark output (previously manual
|
||||
estimates); `presale::withdraw_funds` had no benchmark case at all until
|
||||
commit `dc6d29e` — real weight pending a benchmark run.
|
||||
- Dependency-security cleanup: `rand`/`tar`/`rpassword` patched (commit `2cbf2b3`);
|
||||
`wasmtime` (2 critical, aarch64-specific sandbox-escape CVEs; our fleet is x86_64)
|
||||
and a handful of other client-networking deps (`hickory-proto`, `rustls-webpki`,
|
||||
`yamux`) remain — each pinned by a deeper Substrate/Polkadot-SDK dependency and
|
||||
needing a coordinated major-version bump plus real node testing. Tracked as a
|
||||
separate task, not part of this bundle.
|
||||
|
||||
To easily refer to a release, it shall be named by its date in the form `Pezkuwi stableYYMM`. Patches to stable releases
|
||||
are tagged in the form of `Pezkuwi stableYYMM-PATCH`, with `PATCH` ranging from 1 to 99. For example, the fourth patch
|
||||
to `Pezkuwi stable2409` would be `Pezkuwi stable2409-4`.
|
||||
**Note on Zagros testnet validation:** the live "Zagros Testnet" chain (217.77.6.126)
|
||||
runs the `pezkuwichain`/`asset-hub-pezkuwichain`/`people-pezkuwichain` runtime family
|
||||
(spec_name confirmed via live RPC), not the `zagros`/`asset-hub-zagros`/`people-zagros`
|
||||
family. The latter is a CI-checked-only reference implementation (never released — see
|
||||
`release.yml`), left over from before this repo's clean-room rewrite. Bump
|
||||
`spec_version` and build WASM from the `*-pezkuwichain` crates when validating a bundle
|
||||
on Zagros before it ships to mainnet; the `*-zagros` crates are not deployed anywhere.
|
||||
|
||||
## Crate
|
||||
## Changing a claim statement
|
||||
|
||||
We try to follow [SemVer 2.0.0](https://semver.org/) as best as possible for versioning our crates. The definitions of
|
||||
`major`, `minor` and `patch` version for Rust crates are slightly altered from their standard for pre `1.0.0` versions.
|
||||
Quoting [rust-lang.org](https://doc.rust-lang.org/cargo/reference/semver.html):
|
||||
A statement edit changes its hash → changes the runtime → is a runtime upgrade and
|
||||
invalidates prior signatures. Procedure: edit `docs/statement/*.html`, redeploy to
|
||||
`statement.pex.network`, recompute sha256, update `StatementKind::to_text()`, bump
|
||||
`spec_version`, ship. The repo copy, the served copy, and the runtime hash must stay
|
||||
identical.
|
||||
|
||||
>Initial development releases starting with "0.y.z" can treat changes in "y" as a major release, and "z" as a minor
|
||||
release. "0.0.z" releases are always major changes. This is because Cargo uses the convention that only changes in the
|
||||
left-most non-zero component are considered incompatible.
|
||||
## Reproducibility note
|
||||
|
||||
SemVer requires a piece of software to first declare a public API. The public API of the Pezkuwi SDK
|
||||
is hereby declared as the sum of all crates' public APIs.
|
||||
|
||||
Inductively, the public API of our library crates is declared as all public items that are neither:
|
||||
- Inside a `__private` module
|
||||
- Documented as "unstable" or "experimental" in the first line of docs
|
||||
- Bear `unstable` or `experimental` in their absolute path
|
||||
|
||||
## Node
|
||||
|
||||
The versioning of the Pezkuwi node is done most of the time by only incrementing the `minor` version. The `major`
|
||||
version is only bumped for special releases and the `patch` is used for a patch release that happens every month and
|
||||
fixes found issues. The node version is not following SemVer. This means that the version doesn't express if there are
|
||||
any breaking changes in the CLI interface or similar. The node version is declared
|
||||
in the [`NODE_VERSION`](https://docs.pezkuwichain.io/sdk/master/polkadot_pez_node_primitives/constant.NODE_VERSION.html)
|
||||
variable.
|
||||
|
||||
## Zagros
|
||||
|
||||
For the Westene testnet, in addition to incrementing the `Cargo.toml` version we also increment the `spec_version` and
|
||||
sometimes the `transaction_version`. The spec version is also following the node version. Its schema is: `M_mmm_ppp` and
|
||||
for example `1_002_000` is the node release `1.2.0`. This versioning has no further meaning, and is only done to map
|
||||
from an on chain `spec_version` easily to the release in this repository.
|
||||
|
||||
|
||||
# Backports
|
||||
|
||||
**From `master` to `stable`**
|
||||
|
||||
Backports in this direction can be anything that is audited and either a `minor` or a `patch` bump.
|
||||
See [BACKPORT.md](./BACKPORT.md) for more explanation. [Security fixes](#bug-and-security-fix)
|
||||
should be prioritized over additions or improvements. Crates that are declared as internal API can
|
||||
also have `major` version bumps through backports.
|
||||
|
||||
**From `stable` to `master`**
|
||||
|
||||
Backports to `master` only happen after a `stable` or `patch` release has been made for the current stable release,
|
||||
and include node version and spec version bumps, plus reorganizing the prdoc files
|
||||
(they should go into the appropriate release folder under the [prdoc](./proc) folder).
|
||||
This is done by the release team to keep things organized. Developers need not to care about such backports.
|
||||
|
||||
# Processes
|
||||
|
||||
The following processes are necessary to actualize our releases. Each process has a *Cadence* on which it must execute
|
||||
and a *Responsible* that is responsible for autonomously doing so and reporting back any error in the *RelEng: Pezkuwi
|
||||
Release Coordination* Matrix channel. All processes should be automated as much as possible.
|
||||
|
||||
## Crate Bumping
|
||||
|
||||
Cadence: currently every 3 months for new `stable` releases and monthly for existing `stables`.
|
||||
Responsible: Developer that opened the Pull Request.
|
||||
|
||||
Following SemVer isn't easy, but there exists [a guide](https://doc.rust-lang.org/cargo/reference/semver.html) in the
|
||||
Rust documentation that explains the small details on when to bump what. This process is supported with a CI check that
|
||||
utilizes [`cargo-semver-checks`](https://github.com/obi1kenobi/cargo-semver-checks).
|
||||
|
||||
### Steps
|
||||
|
||||
1. Developer opens a Pull Request with changed crates against `master`.
|
||||
2. They mention the type of the bump of all changed crates according to SemVer in the prdoc file attached to the PR.
|
||||
Note that this includes any crates that expose the changed behaviour in their *public API* and also transitive dependencies
|
||||
for whom the same rule applies.
|
||||
3. The bump itself happens during the release and is done by a release engineer using the
|
||||
[Parity-Publish](https://github.com/paritytech/parity-publish) tool.
|
||||
|
||||
## Stable Release
|
||||
|
||||
Cadence: every 3 months for new `stable` releases and monthly for existing `stables`. Responsible: Release Team.
|
||||
|
||||
### Steps to execute a new stable binary release
|
||||
|
||||
From the main Pezkuwi-sdk repository in the paritytech org:
|
||||
|
||||
1. On the cut-off date, create a new branch with the name `satbleYYMM`
|
||||
using combined [Branch-off stable/tag rc flow](/.github/workflows/release-10_branchoff-stable.yml)
|
||||
2. Create a new rc tag from the stable branch using combined
|
||||
[Branch-off stable/tag rc flow](/.github/workflows/release-10_branchoff-stable.yml)
|
||||
|
||||
ℹ️ These first two steps can be done all in one if there are no extra actions (like crates release) are needed
|
||||
to be done in between.
|
||||
In case of a crates release: when it is done, the changes done by the Parity-Publish needs to be revereted and
|
||||
merged back to the stable branch via a PR as the direct pushes are restricted. When this is done,
|
||||
the new RC tag can be created using the flow from above.
|
||||
|
||||
From the forked Pezkuwi-sdk repository in the [paritytech-release org](https://github.com/paritytech-release/polkadot-sdk/actions):
|
||||
|
||||
1. Sync the forks before continuing with the release using
|
||||
[Sync the forked repo with the upstream](https://github.com/paritytech-release/polkadot-sdk/actions/workflows/fork-sync-action.yml)
|
||||
2. To build binaries or testnet runtimes and to create a release draft in the github
|
||||
trigger [Release - Combined Builds Flow](/.github/workflows/release-22_combined-rc-runtime-builds-release-draft.yml)
|
||||
3. Repeat steps 1 and 2 to prepare a new rc if there are any changes were pushed to release branch
|
||||
4. When the release is finalized and ready to go, publish crates using `parity-publish` tool and push changes
|
||||
to the release branch
|
||||
5. Trigger [Release - Promote RC to final candidate on S3](/.github/workflows/release-31_promote-rc-to-final.yml)
|
||||
to have it as a final rc on the S3
|
||||
6. Publish deb package for the `pezkuwi` binary using
|
||||
[Release - Publish Pezkuwi deb package](/.github/workflows/release-40_publish-deb-package.yml)
|
||||
7. Adjust the release draft and publish release on GitHub.
|
||||
8. Publish docker images using [Release - Publish Docker Image](/.github/workflows/release-50_publish-docker.yml)
|
||||
|
||||
From the main Pezkuwi-sdk repository in the paritytech org:
|
||||
|
||||
1. Synchronize templates using [Synchronize templates](/.github/workflows/misc-sync-templates.yml)
|
||||
2. Update the [Release Registry](https://github.com/pezkuwichain/release-registry/)
|
||||
follwoing the [instructions](https://github.com/pezkuwichain/release-registry?tab=readme-ov-file#maintenance)
|
||||
in the repo with the actual release dates.
|
||||
|
||||
## Patch release for the latest stable version
|
||||
|
||||
Cadence: every month. Responsible: Developer
|
||||
|
||||
Backporting rules can be found in the [BACKPORT.md](/docs/BACKPORT.md)
|
||||
|
||||
The release itself is similar to [the new stable release](#steps-to-execute-a-new-stable-release) process without
|
||||
the branching-off step, as the branch already exists and depending on the patch
|
||||
(whether it is for the current `stable` release or one of the previous ones) the binary build can be skipped
|
||||
and only crates and GitHub publishing is done.
|
||||
Builds are pinned-toolchain reproducible (deterministic given `rust-toolchain.toml` +
|
||||
`Cargo.lock` + flags). Fully hermetic srtool builds are pending a Rust 1.96 srtool image
|
||||
(latest published is 1.93); the release pipeline will adopt srtool once available.
|
||||
@@ -0,0 +1,50 @@
|
||||
# PezkuwiChain — Token & Network Standard
|
||||
|
||||
This is the single source of truth for token symbols across PezkuwiChain networks.
|
||||
Any new chain-spec, runtime, or document must follow it.
|
||||
|
||||
## Principle
|
||||
|
||||
A system teyrchain (Asset Hub, People, Coretime, Bridge Hub) does **not** have its own
|
||||
native token — it shares the relay chain's native token for fees and existential
|
||||
deposits. Its `tokenSymbol` therefore equals the relay's symbol (exactly as
|
||||
`asset-hub-polkadot` reports `DOT`, not a symbol of its own).
|
||||
|
||||
## Mainnet — PezkuwiChain
|
||||
|
||||
| Item | Value |
|
||||
|------|-------|
|
||||
| Relay native token | **HEZ** |
|
||||
| Decimals | 12 (`UNITS = 10^12`) |
|
||||
| System teyrchains (asset-hub / people / coretime / bridge-hub-pezkuwichain) | **HEZ** (shared relay native) |
|
||||
| Asset Hub governance token | **PEZ** (a token/asset on Asset Hub — 5,000,000,000 supply; *not* the native fee token) |
|
||||
| ss58Format | 42 (generic; registering a dedicated prefix is tracked separately) |
|
||||
|
||||
`HEZ` total issuance on the relay: 200,000,000. Genesis allocation constants are
|
||||
named `HEZ_*`. Where an amount is just a base-unit multiple in a non-native context
|
||||
(e.g. PEZ allocations on Asset Hub), use plain `UNITS`, not a token-named alias.
|
||||
|
||||
## Testnets & dev networks
|
||||
|
||||
| Network | Symbol | Notes |
|
||||
|---------|--------|-------|
|
||||
| Zagros | **ZGR** | Primary public testnet |
|
||||
| Dicle | **DCL** | Testnet |
|
||||
| Versi | **VRS** | Staging/dev network |
|
||||
| Paseo | **PAS** | Dev network |
|
||||
|
||||
Testnet symbols are intentionally distinct from `HEZ` so that testnet tokens can never
|
||||
be confused with mainnet value — this is a deliberate safety property, not an
|
||||
inconsistency. Testnet system teyrchains share their own relay's symbol (e.g. the
|
||||
Zagros system teyrchains report `ZGR`).
|
||||
|
||||
## Notes for maintainers
|
||||
|
||||
- The token symbol is embedded in three runtime-level places, so changing it on a live
|
||||
network requires a coordinated runtime upgrade + chain-spec redeploy:
|
||||
1. `build.rs` → `enable_metadata_hash("HEZ", 12)` (drives the CheckMetadataHash
|
||||
extension used by hardware/offline signers).
|
||||
2. The Claims `Prefix` signed-payload (`b"Pay HEZ to the Pezkuwichain account:"`).
|
||||
3. The chain-spec `properties.tokenSymbol`.
|
||||
- `TYR` was an earlier placeholder that had leaked into the mainnet runtimes/specs; it
|
||||
has been fully standardized to `HEZ`. Do not reintroduce it.
|
||||
@@ -0,0 +1,99 @@
|
||||
# PezkuwiChain — Visual Identity
|
||||
|
||||
**Brand color palette, logo variants, and usage guidelines for the Digital Kurdistan State.**
|
||||
|
||||
---
|
||||
|
||||
## 1. Purpose
|
||||
|
||||
This document specifies the official visual identity of the PezkuwiChain blockchain — its
|
||||
color palette, logo variants, and their cultural-symbolic foundations — as a brand guideline
|
||||
for the project and its ecosystem.
|
||||
|
||||
---
|
||||
|
||||
## 2. Brand Color Palette
|
||||
|
||||
The palette consists of the **three national colors of the Kurdistan flag**, plus neutral
|
||||
black and white for typography and backgrounds.
|
||||
|
||||
### 2.1 Primary Colors
|
||||
|
||||
| Color | Kurdish | Symbolic Meaning | Approx. Hex |
|
||||
| --- | --- | --- | --- |
|
||||
| **Green** | *kesk* (کەسک) | Land, mountains, fertility of Kurdistan | `#018000` – `#1E9C29` |
|
||||
| **Red** | *sor* (سۆر) | Blood of martyrs, national sacrifice | `#C8102E` – `#E2231A` |
|
||||
| **Yellow / Gold** | *zer* (زەر) | Sun, hope, the eternal Kurdish spirit | `#F8D02C` – `#FEBD11` |
|
||||
|
||||
### 2.2 Support Colors
|
||||
|
||||
| Color | Use | Hex |
|
||||
| --- | --- | --- |
|
||||
| **Black** | Dark backgrounds, primary typography | `#000000` |
|
||||
| **White** | Light backgrounds, contrast typography | `#FFFFFF` |
|
||||
|
||||
### 2.3 Excluded Colors
|
||||
|
||||
Pink / magenta (and visually similar shades) are **not** part of the PezkuwiChain identity.
|
||||
This is a cultural choice — pink carries gendered connotations inappropriate for a national
|
||||
project — and a brand-distinctiveness choice. The red used is always the Kurdish flag red
|
||||
(*sor*), never a Western pink/magenta tone.
|
||||
|
||||
---
|
||||
|
||||
## 3. Logo Variants
|
||||
|
||||
All variants use the approved palette and a consistent symbolic composition: a floral/rosette
|
||||
of six petals around a central Roj (sun), with the **"Pezkuwichain"** wordmark in a flowing
|
||||
italic typeface.
|
||||
|
||||
### 3.1 Primary — Horizontal, Light Background
|
||||
Symbol at left, wordmark at right in black; white background. Default for documentation,
|
||||
websites, light-mode interfaces, and official correspondence.
|
||||
|
||||
### 3.2 Dark — Green / Black Background
|
||||
Symbol with central Roj, wordmark in white, vertical green divider; black background. For
|
||||
dark-mode interfaces, video, and banners.
|
||||
|
||||
### 3.3 Cultural — with Pezkuwi Head
|
||||
Floral/rosette with a stylized **pezkuwi** (mountain goat) head at center; sor + kesk + white.
|
||||
For cultural and heritage contexts and community events.
|
||||
|
||||
---
|
||||
|
||||
## 4. Symbolic Composition
|
||||
|
||||
- **Central Roj (sun):** the foundational symbol of Kurdish identity, present on the Kurdistan
|
||||
flag; its rays evoke *Newroz* (Kurdish New Year, March 21).
|
||||
- **Six petals:** the four regions of Kurdistan (Bakur, Başûr, Rojava, Rojhilat) plus the
|
||||
global diaspora and the unifying homeland. The petal form draws from Kurdish carpet, textile,
|
||||
and architectural rosette motifs — organic, not abstract-geometric.
|
||||
- **Pezkuwi head (select variants):** the bezoar wild goat (*Capra aegagrus*) of the Zagros,
|
||||
national totem of the Kurdish people.
|
||||
- **Wordmark:** "Pezkuwichain" in a flowing italic typeface, black on light / white on dark.
|
||||
|
||||
The identity is derived exclusively from the flag of Kurdistan, Kurdish ornamental tradition,
|
||||
and the natural and cultural heritage of the Kurdish people.
|
||||
|
||||
---
|
||||
|
||||
## 5. Usage Guidelines
|
||||
|
||||
**Do:**
|
||||
- Use logos only in their official, unmodified forms; preserve proportions.
|
||||
- Choose the variant that suits the background (light vs. dark).
|
||||
- Reproduce colors per Section 2.
|
||||
|
||||
**Don't:**
|
||||
- Alter the logo colors, or substitute the Kurdish red (*sor*) with pink/magenta.
|
||||
- Separate the symbol from the wordmark in primary applications (symbol-only is permitted only
|
||||
for favicons / space-constrained icons).
|
||||
- Stretch, distort, rotate, or recolor the logo outside the approved variants.
|
||||
|
||||
---
|
||||
|
||||
## 6. Brand Inquiries
|
||||
|
||||
**PEZ KIWI Company** · info@pezkuwichain.io · https://pezkuwichain.io
|
||||
|
||||
*Companion document: [BRAND_HERITAGE.md](./BRAND_HERITAGE.md).*
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 535 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 265 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 70 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 226 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 126 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 179 KiB After Width: | Height: | Size: 188 KiB |
@@ -0,0 +1,32 @@
|
||||
# PezkuwiChain claim statements (canonical, hash-pinned)
|
||||
|
||||
These are the **canonical** legal attestation documents that a token claimant agrees
|
||||
to in the `claims` pallet (`pezkuwi-runtime-common`). The SHA-256 hash of each file is
|
||||
embedded in `StatementKind::to_text()`, which is part of the payload the claimant signs.
|
||||
|
||||
**The bytes in this directory, the bytes served at `statement.pex.network`, and the hash
|
||||
in the runtime MUST stay identical.** If they ever diverge, claimants can no longer
|
||||
verify what they signed. These files are version-controlled here precisely so the exact
|
||||
bytes are always recoverable and re-deployable.
|
||||
|
||||
| Document | URL | SHA-256 (in `to_text()`) |
|
||||
|---|---|---|
|
||||
| `regular.html` | https://statement.pex.network/regular.html | `95bf22e1fd1bbcd6a06ccac523a391a94e48c517c7db183b734ba72f955c21e8` |
|
||||
| `saft.html` | https://statement.pex.network/saft.html | `3921445529820f15f000cef9f143b74194516c96873fff4a829bac0162b35c59` |
|
||||
|
||||
Verify:
|
||||
|
||||
```sh
|
||||
sha256sum docs/statement/regular.html docs/statement/saft.html
|
||||
curl -s https://statement.pex.network/regular.html | sha256sum
|
||||
```
|
||||
|
||||
## Changing a statement
|
||||
|
||||
Editing a statement changes its hash, which changes `to_text()`, which changes the
|
||||
on-chain runtime — so it is a **runtime upgrade** and invalidates signatures made against
|
||||
the previous text. To change one: edit the file, re-deploy to `statement.pex.network`,
|
||||
recompute the SHA-256, update `StatementKind::to_text()`, bump `spec_version`, and ship a
|
||||
runtime upgrade. Treat the legal wording as reviewed-and-final before pinning.
|
||||
|
||||
Hosting: served as a static nginx vhost on the bootnode host (TLS via Let's Encrypt).
|
||||
@@ -0,0 +1,23 @@
|
||||
<!doctype html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta charset="utf-8" />
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1" />
|
||||
<title>PezkuwiChain Statements</title>
|
||||
<style>
|
||||
body{max-width:680px;margin:4rem auto;padding:0 1.25rem;font:16px/1.6 system-ui,sans-serif;color:#111}
|
||||
h1{font-size:1.5rem} a{color:#018000} .meta{color:#555;font-size:.9rem}
|
||||
</style>
|
||||
</head>
|
||||
<body>
|
||||
<h1>PezkuwiChain — Token Claim Statements</h1>
|
||||
<p>These are the canonical attestation statements referenced by the PezkuwiChain
|
||||
on-chain token claim process. The SHA-256 hash of each document is embedded in the
|
||||
payload that a claimant signs.</p>
|
||||
<ul>
|
||||
<li><a href="/regular.html">Regular statement</a></li>
|
||||
<li><a href="/saft.html">SAFT statement</a></li>
|
||||
</ul>
|
||||
<p class="meta">Kurdistan Tech Institute · PEZ KIWI Company · <a href="https://pezkuwichain.io">pezkuwichain.io</a></p>
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,47 @@
|
||||
<!doctype html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta charset="utf-8" />
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1" />
|
||||
<title>PezkuwiChain — Token Claim Statement (Regular)</title>
|
||||
<style>
|
||||
body{max-width:720px;margin:3rem auto;padding:0 1.25rem;font:16px/1.6 system-ui,sans-serif;color:#111}
|
||||
h1{font-size:1.4rem} .meta{color:#555;font-size:.9rem} hr{border:none;border-top:1px solid #ddd;margin:2rem 0}
|
||||
code{background:#f4f4f4;padding:.1rem .3rem;border-radius:3px}
|
||||
</style>
|
||||
</head>
|
||||
<body>
|
||||
<h1>PezkuwiChain — Token Claim Statement</h1>
|
||||
<p class="meta">Regular statement · Version 1.0 · PEZ KIWI Company / Pezkuwi Foundation</p>
|
||||
|
||||
<hr/>
|
||||
|
||||
<p>I acknowledge and agree to the following in connection with claiming PezkuwiChain
|
||||
native tokens (the “Tokens”) to a PezkuwiChain account:</p>
|
||||
|
||||
<ol>
|
||||
<li>I am the lawful holder of, and entitled to claim, the allocation associated with the
|
||||
address from which this statement is signed.</li>
|
||||
<li>The Tokens are a native utility token of the PezkuwiChain network used for transaction
|
||||
fees, staking, network security and on-chain governance participation. They are not
|
||||
offered or represented as shares, securities, or an investment, and confer no equity,
|
||||
debt, dividend or profit-participation rights.</li>
|
||||
<li>The PezkuwiChain network is decentralized, experimental software provided “as is”,
|
||||
without warranties of any kind. I accept the technical, economic and regulatory risks of
|
||||
holding and using the Tokens, including the risk of total loss.</li>
|
||||
<li>I am not a person or entity subject to sanctions, I am not claiming on behalf of any
|
||||
sanctioned person, and my claim does not violate the laws applicable to me.</li>
|
||||
<li>I am solely responsible for the security of my keys and for any tax obligations arising
|
||||
from my holding or use of the Tokens.</li>
|
||||
<li>This statement is governed by the laws applicable to PEZ KIWI Company (Kurdistan Region of
|
||||
Iraq) and the Pezkuwi Foundation, without prejudice to mandatory consumer protections of
|
||||
my place of residence.</li>
|
||||
</ol>
|
||||
|
||||
<p>By signing the payload that embeds the SHA-256 hash of this document, I confirm that I
|
||||
have read, understood and agreed to this statement.</p>
|
||||
|
||||
<hr/>
|
||||
<p class="meta">Canonical URL: <code>https://statement.pex.network/regular.html</code></p>
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,44 @@
|
||||
<!doctype html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta charset="utf-8" />
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1" />
|
||||
<title>PezkuwiChain — Token Claim Statement (SAFT)</title>
|
||||
<style>
|
||||
body{max-width:720px;margin:3rem auto;padding:0 1.25rem;font:16px/1.6 system-ui,sans-serif;color:#111}
|
||||
h1{font-size:1.4rem} .meta{color:#555;font-size:.9rem} hr{border:none;border-top:1px solid #ddd;margin:2rem 0}
|
||||
code{background:#f4f4f4;padding:.1rem .3rem;border-radius:3px}
|
||||
</style>
|
||||
</head>
|
||||
<body>
|
||||
<h1>PezkuwiChain — Token Claim Statement (SAFT Holders)</h1>
|
||||
<p class="meta">SAFT statement · Version 1.0 · PEZ KIWI Company / Pezkuwi Foundation</p>
|
||||
|
||||
<hr/>
|
||||
|
||||
<p>This statement applies to claimants whose allocation arises under a Simple Agreement for
|
||||
Future Tokens (“SAFT”) or comparable instrument. In addition to the Regular statement, I
|
||||
acknowledge and agree that:</p>
|
||||
|
||||
<ol>
|
||||
<li>My allocation derives from a SAFT or comparable agreement entered into with PEZ KIWI
|
||||
Company and/or the Pezkuwi Foundation, the terms of which I have read and continue to be
|
||||
bound by.</li>
|
||||
<li>At the time I entered into that agreement, I made the representations required therein,
|
||||
including as to my eligibility and, where applicable, my status as an accredited or
|
||||
otherwise qualified investor under the laws applicable to me.</li>
|
||||
<li>I understand that the delivery of Tokens discharges the relevant obligations under that
|
||||
agreement, and that the Tokens are a native utility token of the PezkuwiChain network as
|
||||
described in the Regular statement.</li>
|
||||
<li>I am not subject to sanctions, my claim does not violate the laws applicable to me, and I
|
||||
will comply with any applicable transfer restrictions and lock-up or vesting schedule
|
||||
associated with my allocation.</li>
|
||||
</ol>
|
||||
|
||||
<p>By signing the payload that embeds the SHA-256 hash of this document, I confirm that I
|
||||
have read, understood and agreed to this statement and to the Regular statement.</p>
|
||||
|
||||
<hr/>
|
||||
<p class="meta">Canonical URL: <code>https://statement.pex.network/saft.html</code></p>
|
||||
</body>
|
||||
</html>
|
||||
+107
-59
@@ -1,62 +1,40 @@
|
||||
# PezkuwiChain: A Sovereign Blockchain for a Digital Nation
|
||||
**Technical Whitepaper v4.0**
|
||||
**December 10, 2025**
|
||||
**Prepared by:** Kurdistan Tech Ministry & PezkuwiChain Contributors
|
||||
**Technical Whitepaper · Version 3.0 · June 2026**
|
||||
|
||||
*Revision 3.0 supersedes v2.0 (October 2025): restructured with a dedicated Philosophy section and a code-verified TNPoS trust-score model — main formula, the four component scores, and on-chain constants — with module terminology corrected to* pezpallet*.*
|
||||
**Prepared by:** Digital Kurdistan Tech Institute & PezkuwiChain Contributors
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
## Abstract: THE PEZKUWICHAIN MANIFESTO - BUILDING TRUTH IN AN AGE OF NOISE
|
||||
## Abstract
|
||||
|
||||
We are in the midst of a digital dark age.
|
||||
PezkuwiChain is a sovereign Layer-1 blockchain engineered to provide digital public infrastructure for the Kurdish people and their global diaspora. It is built on the **Pezkuwi SDK** — a self-contained, modular runtime framework derived from battle-tested open-source components and now fully independent, building entirely from source with no dependency on any external package registry.
|
||||
|
||||
Blockchain technology arrived with the promise of decentralization, transparency, and freedom for humanity. Yet, what we see today when we look back is a colossal casino built upon these sacred promises. Thousands of projects, tens of thousands of tokens, millions of empty vows... all designed to glitter for a moment as a line item on the shimmering lists of exchanges, only to be swallowed by darkness after exploiting the hopes of investors.
|
||||
The protocol's central contribution is **Trust-enhanced Nominated Proof-of-Stake (TNPoS)**, a consensus and reward model that augments conventional economic stake with an on-chain reputation signal — the *trust score* — computed by the `pezpallet-trust` module from each account's staking activity, referrals, on-chain education credentials, and community participation. By weighting influence and rewards by both stake and trust, PezkuwiChain mitigates the stake-only plutocracy of traditional Proof-of-Stake while preserving its economic security guarantees.
|
||||
|
||||
Exchanges have become the gatekeepers of volume, not technology. True engineering has been crushed under the weight of marketing noise. Genuine projects that could add value to humanity, spread financial freedom, and digitize identity and reputation have been lost among a sea of "scam" projects, meme tokens, and digital refuse with no technological substance. This chaos was not created by external forces, but by the blockchain world's own insatiable greed.
|
||||
PezkuwiChain pairs a **dual-token economy** — HEZ (the inflationary security and fee token) and PEZ (a fixed 5-billion-supply governance and reward token) — with a multi-chain **"teyrchain" architecture**: a Relay Chain for shared security, an Asset Hub for the economy, and a People Chain for identity and governance. A suite of **14 custom pezpallets** provides digital identity, education, reputation, and governance as native on-chain primitives.
|
||||
|
||||
**Enough.**
|
||||
This document specifies the PezkuwiChain architecture, the TNPoS consensus and trust-score model, the dual-token economy, the custom pezpallet suite, and the network's technical parameters.
|
||||
|
||||
We, as PezkuwiChain, reject this noise. We see technology not as a tool for speculation, but as a tool for building a civilization.
|
||||
## Our Philosophy
|
||||
|
||||
### THE PARADIGM SHIFT: T-NPoS (Trust-Nominated Proof of Stake)
|
||||
### The Age of Noise
|
||||
|
||||
Throughout history, power has always been concentrated in the hands of capital. Traditional Proof of Stake (PoS) systems have unfortunately carried this old-world disease into the digital realm: "He who has the gold makes the rules." This is an oligarchy we refuse to accept.
|
||||
Blockchain technology arrived with the promise of decentralization, transparency, and freedom. Much of that promise, however, was turned into a speculative casino — thousands of projects and tens of thousands of tokens engineered to glitter briefly on exchange listings before fading, exploiting the hopes of their holders. Exchanges became gatekeepers of volume rather than technology, and genuine engineering was lost amid meme tokens and projects of no technical substance. PezkuwiChain is built in deliberate opposition to that noise: we treat technology not as an instrument of speculation, but as infrastructure for building a society.
|
||||
|
||||
With PezkuwiChain, we are initiating a revolution: **T-NPoS.**
|
||||
### Trust, Not Capital
|
||||
|
||||
T-NPoS is a consensus mechanism based not only on the balance in your wallet (Stake), but on the value you bring to the network, your reputation, and your trustworthiness (Trust). As a philosopher, I say: Capital is not character. Money is not merit.
|
||||
Power has historically concentrated around capital, and traditional Proof-of-Stake carried that pattern into the digital realm — those who hold the most tokens make the rules. PezkuwiChain rejects *pure* stake-plutocracy. In its trust model (Section 4.2), stake is a necessary foundation — and is itself rewarded — but per unit, verifiable contribution (referrals, education, community) is weighted three times more heavily than capital (300 vs 100). Capital opens the door; contribution earns standing within it.
|
||||
|
||||
In PezkuwiChain:
|
||||
- The network is governed not just by the wealthy, but by the trustworthy.
|
||||
- Validators are chosen not just by locking tokens, but by proving their loyalty to the community and the network.
|
||||
- The **HEZ Token** provides the network's security and economic foundation (Layer 1), while the **PEZ Token** is a currency of reputation that rewards labor, participation, and trust.
|
||||
TNPoS is therefore based not only on the balance in a wallet (stake), but on the value an account brings to the network — its reputation and trustworthiness (trust). The network is governed by the trustworthy as well as the wealthy; validators earn standing by demonstrating contribution, not only by locking tokens. The **HEZ** token provides security and economic foundation, while the **PEZ** token rewards labor, participation, and trust. This balance between the power of capital and the value of contribution is enforced in code (Section 4.2), not by policy alone.
|
||||
|
||||
This dual structure balances the power of capital with the honor of contribution. Our custom modules, such as `Identity`, `Society`, and `RankedCollective`, are the technical proof of this philosophy. We are not building a mechanized financial system; we are building a human-centric, trust-based digital society.
|
||||
### A Clean Slate: The Stateless Advantage
|
||||
|
||||
### THE ANSWER TO THE LOST AND THE ERASED
|
||||
PezkuwiChain also reflects a particular historical circumstance. Established states must refactor centuries of bureaucracy and centralized, paper-based institutions to enter the blockchain era; they cannot build anew without first dismantling the old. A stateless people carries no such legacy — no inefficient bureaucracies to transform, no decrepit institutions to tear down. That absence becomes a digital clean slate: an opportunity to **build rather than adapt**, constructing advanced technology, transparent governance, and an equitable economy directly from the ground up.
|
||||
|
||||
Unlike the endless stream of projects that appear daily only to be listed and disappear on exchanges, PezkuwiChain is not a "pump-and-dump" scheme. Our code is built on a robust, open-source foundation, but it has forged its own soul, its own economy, and its own form of governance.
|
||||
|
||||
We trust in the code of developers, not the listing fees of exchanges. We believe in sustainable ecosystems, not fleeting hype.
|
||||
|
||||
### CONCLUSION: THE HISTORICAL PARADOX AND THE JOURNEY TO A TYPE-1 CIVILIZATION
|
||||
|
||||
PezkuwiChain is a technological cry emanating from Erbil to the world, yet this cry contains one of history's greatest paradoxes.
|
||||
|
||||
The Kurdish people's centuries-long state of "statelessness" has, ironically, become their greatest advantage and superpower in this technological age. Established states must expend immense time and energy to refactor their cumbersome centuries-old bureaucracies, inefficient paper-based institutions, and centralized structures for the blockchain era. They are the ones who cannot build anew without first demolishing the old.
|
||||
|
||||
The Kurdish people, however, do not carry the burden of these legacy systems. They have no inefficient bureaucracies to transform, no decrepit institutions to tear down. This situation presents us with a digital "clean slate."
|
||||
|
||||
**Building, Not Adapting:** We will not waste time transforming the old; we will directly build the most advanced technology, the most transparent governance, and the most equitable economy from the ground up.
|
||||
|
||||
**A Leap to a Type-1 Civilization:** While other nations struggle with their internal resistance to change, PezkuwiChain will bring the children of this region to the level of a digital "Type-1 Civilization" far faster than any other nation.
|
||||
|
||||
**From the Age of Race to the Age of Culture:** Borders are no longer drawn with soil, but with code. The era of the nation-state centered "only on race" has closed; a new era of the nation centered on "Race + Culture + Technology" has begun.
|
||||
|
||||
PezkuwiChain is the digital fortress of this new age. We are building a new world where trust, not capital, and values, not borders, reign supreme.
|
||||
|
||||
We are here. We have no baggage, only velocity. We are PezkuwiChain.
|
||||
In an age where borders are increasingly drawn in code rather than soil, this is PezkuwiChain's ambition — to give the people of this region a direct path to an advanced, fully digital civic infrastructure: a **Type-1 digital civilization** founded on trust and shared values rather than capital and borders alone.
|
||||
|
||||
---
|
||||
|
||||
@@ -70,7 +48,7 @@ The project's vision is to empower the Kurdish nation through decentralized tech
|
||||
* **TNPoS Consensus:** The world's first trust-augmented PoS mechanism.
|
||||
* **Dual-Token Economy:** HEZ (inflationary) + PEZ (fixed 5B supply).
|
||||
* **Multi-Layered "Teyrchain" Architecture:** A Relay Chain for consensus, an Asset Hub for economy, and a People Chain for identity and governance.
|
||||
* **The Pezkuwi SDK:** A powerful and flexible framework with **14** specialized modules for digital sovereignty.
|
||||
* **The Pezkuwi SDK:** A powerful and flexible framework with **14** specialized pezpallets for digital sovereignty.
|
||||
|
||||
---
|
||||
|
||||
@@ -101,8 +79,76 @@ Our choice of a modular, open-source framework provides PezkuwiChain with a robu
|
||||
|
||||
*Figure 1: PezkuwiChain System Architecture*
|
||||
|
||||
### 4.1.1. Technological Heritage & Independence
|
||||
PezkuwiChain did not begin in a vacuum. We laid our first stone upon **Polkadot SDK** — the open-source framework engineered by Parity Technologies and the Web3 Foundation, among the most rigorously battle-tested infrastructure ever written for decentralized systems. We are grateful for it, and we say so plainly. The open-source ideal exists precisely so that a stateless nation — with no treasury to commission an army of engineers, and no sovereign to grant it permission — can stand on solid ground and build something of its own. Polkadot gave us that ground, and we honor it.
|
||||
|
||||
From there our paths diverged — deliberately, and in time, completely. What began as a fork has forged its own soul: its own framework (**Bizinikiwi**), its own SDK (**Pezkuwi SDK**), its own brand, governance, token economy, and chain identity. Today the entire stack lives in a single self-contained repository that builds from source with **zero dependency on any external registry** — because a sovereign chain must remain buildable and verifiable no matter what happens to any third-party platform.
|
||||
|
||||
We preserve our origins in full. Every license, attribution, and record of change is kept in our `NOTICE` and `LICENSE` files, exactly as the Apache-2.0 and GPL-3.0 licenses intend — not as a footnote, but as a matter of honor. We took what was freely given, we gave thanks, and we made it our own. This is the open-source ideal working as it was meant to: not extraction, but inheritance; not imitation, but independence.
|
||||
|
||||
### 4.2. Consensus Innovation: Trust-enhanced Nominated Proof-of-Stake (TNPoS)
|
||||
PezkuwiChain introduces a groundbreaking enhancement to traditional NPoS consensus by directly integrating a **Trust System**. This novel approach, termed TNPoS, combines the economic security of NPoS with a social reputation layer provided by the custom `pezpallet-trust`.
|
||||
PezkuwiChain extends conventional Nominated Proof-of-Stake (NPoS) by integrating an on-chain reputation layer into validator selection and reward distribution. This mechanism, **TNPoS**, combines the economic security of NPoS with a social-reputation signal computed by the custom `pezpallet-trust`.
|
||||
|
||||
**The Trust Score.** A citizen's trust score is computed by `pezpallet-trust::calculate_trust_score` from four component scores — staking, referral, education (*perwerde*), and community (*tiki*) — combined as a weighted sum that is then gated and scaled by staking:
|
||||
|
||||
```
|
||||
weighted_sum = 100·staking + 300·(referral + perwerde + tiki)
|
||||
trust_score = staking × weighted_sum / base
|
||||
```
|
||||
|
||||
where `base` is the configurable `ScoreMultiplierBase`, set to **10,000** in the production People-chain runtime. An account with zero staking has a trust score of zero, regardless of its other components.
|
||||
|
||||
| Component | Source pezpallet | Weight | Signal |
|
||||
|---|---|---|---|
|
||||
| `staking_score` | `pezpallet-staking-score` | 100 (also gate & multiplier) | Economic commitment and staking history |
|
||||
| `referral_score` | `pezpallet-referral` | 300 | Verified network growth contributed by the account |
|
||||
| `perwerde_score` | `pezpallet-perwerde` | 300 | On-chain education and certification credentials (*perwerde* = "education") |
|
||||
| `tiki_score` | community participation | 300 | Social-graph and engagement signal |
|
||||
|
||||
Two design properties follow directly from this formula. First, **staking is the foundation**: trust is gated on economic commitment — zero stake yields zero trust — and stake also enters the formula multiplicatively, amplifying the entire score. Second, **contribution outweighs capital per unit**: referral, education, and community signals each carry three times the per-unit weight of staking (300 vs 100), rewarding verifiable contribution over capital alone, once the staking foundation is met.
|
||||
|
||||
**Component Scores.** Each input to the trust score is itself computed on-chain by a dedicated pezpallet.
|
||||
|
||||
*Staking score* (`pezpallet-staking-score`) rewards both the size and the duration of a citizen's stake. A tiered amount score (by total HEZ staked) is multiplied by a duration factor:
|
||||
|
||||
| Staked (HEZ) | Amount score | | Stake duration | Multiplier |
|
||||
|---|---|---|---|---|
|
||||
| ≤ 100 | 20 | | ≥ 12 months | ×2.0 |
|
||||
| ≤ 250 | 30 | | 6–11 months | ×1.7 |
|
||||
| ≤ 750 | 40 | | 3–5 months | ×1.4 |
|
||||
| 751+ | 50 | | 1–2 months | ×1.2 |
|
||||
| | | | < 1 month | ×1.0 |
|
||||
|
||||
`staking_score = amount_score × duration_multiplier` — zero if the citizen has no stake.
|
||||
|
||||
*Referral score* (`pezpallet-referral`) rewards verified network growth, counting only *good* referrals (total minus those later revoked) on a saturating tiered curve capped at 500, less any accumulated penalty:
|
||||
|
||||
```
|
||||
good = total_referrals − revoked_referrals
|
||||
base = good × 10 for 1–10 (→ 10…100)
|
||||
= 100 + (good − 10) × 5 for 11–50 (→ 105…300)
|
||||
= 300 + (good − 50) × 4 for 51–100 (→ 304…500)
|
||||
= 500 for 101+
|
||||
referral_score = base − penalty
|
||||
```
|
||||
|
||||
*Education score* (`pezpallet-perwerde`; *perwerde* = "education") is the sum of points earned across all **completed** courses, each capped by `MaxPointsPerCourse` (**1,000** points):
|
||||
|
||||
`perwerde_score = Σ points_earned` (over completed course enrollments)
|
||||
|
||||
*Community score* (`pezpallet-tiki`) is the sum of fixed bonuses attached to the role and contribution badges ("tikis") a citizen holds; each tiki type carries a protocol-defined value:
|
||||
|
||||
`tiki_score = Σ bonus(tiki)` (over the citizen's tikis)
|
||||
|
||||
The composite trust score is cached per account in `pezpallet-trust` (alongside a network-wide `TotalActiveTrustScore`) and consumed by other modules through the `TrustScoreProvider` interface — most notably the reward module (`pezpallet-pez-rewards`), which weights PEZ reward distribution by trust, and the governance layer.
|
||||
|
||||
### Computation Model and State Efficiency
|
||||
|
||||
Trust scores are maintained through a hybrid of event-driven updates and bounded periodic reconciliation, rather than by a naïve full-population recomputation. When an account's underlying data changes — a new confirmed referral, a completed course, or a staking update — the corresponding component pezpallet (`pezpallet-staking-score`, `pezpallet-referral`, `pezpallet-perwerde`, `pezpallet-tiki`) notifies `pezpallet-trust` via a callback (`on_score_component_changed`), which immediately recomputes and caches the trust score for that single account. A periodic reconciliation pass also exists, but it is explicitly bounded: each cycle processes only an optimally-sized batch of accounts and persists a resume cursor (`LastProcessedAccount`, with O(1) `iter_from` resume), so the population is swept incrementally across blocks — no single block ever processes the entire user base.
|
||||
|
||||
Component scores are derived on read from their source data rather than stored as separate state: the education score is computed at query time from a citizen's completed course enrollments, and the referral score from accumulated referrer statistics. Only the composite trust score is cached. As a result, the trust system's persistent state grows with genuine activity, not with raw population. A dormant account produces no recurring *write* cost: the bounded sweep still visits it, but because its score is unchanged it triggers no state mutation — the update path writes to chain state only when `old_score != new_score`.
|
||||
|
||||
Large or content-heavy data is never placed on-chain. Course materials are referenced by IPFS content links (`content_link`); only the reference and minimal scoring metadata live in chain state. The citizenship layer is privacy-preserving by construction: no personal data is stored on-chain — only an `H256` commitment hash derived off-chain from a citizen's identity. Together, these keep the People-chain state footprint proportional to genuine network activity rather than to the total number of registered citizens.
|
||||
|
||||
|
||||
*Figure 2: TNPoS Consensus Flow*
|
||||
@@ -117,18 +163,20 @@ PezkuwiChain introduces an innovative dual-token economic model.
|
||||
*Figure 3: Dual-Token Economy Flow*
|
||||
|
||||
### 5.1. HEZ: The Currency of Security
|
||||
HEZ is the native, inflationary token used for staking and transaction fees. Its model perpetually incentivizes network participation.
|
||||
HEZ is the native token used for staking, transaction fees, and network security. It is inflationary: staking rewards are funded by era-based inflation bounded between **2.5% and 10%** per annum (`MinInflation` / `MaxInflation`), perpetually incentivizing staking participation.
|
||||
|
||||
### 5.2. PEZ: The Currency of Governance
|
||||
PEZ is a fixed-supply token (5 billion units) for governance and trust-based rewards, featuring a **synthetic halving schedule** every 48 months.
|
||||
PEZ is a fixed-supply token — **5,000,000,000 units**, fixed at genesis — used for trust-based rewards and as the backing of governance. Of total supply, **76% (3.8 billion PEZ)** forms the rewards pool, released on a **synthetic halving schedule** managed by `pezpallet-pez-treasury`: funds are released monthly to the incentive and government pots, and the monthly release amount halves at the start of every **48-month period** (`HALVING_PERIOD_BLOCKS` = 20,736,000 blocks, ~4 years at 6-second blocks).
|
||||
|
||||
Released incentive funds are distributed by `pezpallet-pez-rewards` on a per-epoch basis, **weighted by trust rather than holdings**: each citizen's share is `user_trust_score / total_active_trust_score × epoch_pool`, with 10% of each epoch's pool reserved for role-badge (NFT) holders and a one-week claim window after which unclaimed rewards are clawed back. Rewards therefore flow to verifiable contribution and trust, consistent with the TNPoS design.
|
||||
|
||||
|
||||
*Figure 4: PEZ Token Halving Schedule*
|
||||
|
||||
---
|
||||
## 6. Core Features & Custom Pallets
|
||||
## 6. Core Features & Custom Pezpallets
|
||||
|
||||
The true power of PezkuwiChain lies in the **Pezkuwi SDK**, a collection of **14 custom pallets** that provide the tools for digital nation-building.
|
||||
The true power of PezkuwiChain lies in the **Pezkuwi SDK**, a collection of **14 custom pezpallets** that provide the tools for digital nation-building.
|
||||
|
||||
- **Economic Pallets (on Asset Hub):** `pezpallet-pez-treasury`, `pezpallet-presale`, `pezpallet-token-wrapper`.
|
||||
- **Social & Identity Pallets (on People Chain):** `pezpallet-identity-kyc`, `pezpallet-trust`, `pezpallet-referral`, `pezpallet-perwerde`, `pezpallet-tiki`, `pezpallet-society`.
|
||||
@@ -137,21 +185,21 @@ The true power of PezkuwiChain lies in the **Pezkuwi SDK**, a collection of **14
|
||||
---
|
||||
|
||||
## 7. Technical Specifications & 8. Network Architecture
|
||||
PezkuwiChain is a decentralized system of nodes (Validators, Nominators, Full Nodes). It uses a hybrid consensus of BABE (for block production, ~6s block time) and GRANDPA (for finality). The runtime is a Wasm binary, allowing for forkless upgrades.
|
||||
PezkuwiChain is a decentralized network of validators, nominators, and full nodes, secured by **Nominated Proof-of-Stake (NPoS)** with validators elected through a Sequential Phragmén algorithm. It uses a hybrid consensus: **BABE** for block production — a fixed **6-second block time** (`MILLISECS_PER_BLOCK = 6000`) — and **GRANDPA** for deterministic, provable finality. The runtime is a Wasm binary, enabling forkless on-chain upgrades.
|
||||
|
||||
---
|
||||
|
||||
## 9. Governance Model & 10. Security
|
||||
Governance is managed on-chain via the `welati` pezpallet, allowing PEZ holders to propose, vote on, and enact changes. Security is multi-layered, leveraging Rust's memory safety, the battle-tested framework, forkless upgrades, and the economic and social disincentives for bad actors provided by TNPoS.
|
||||
Governance is conducted on-chain through the `welati` pezpallet as a **citizen-based electoral system — not a token-weighted vote**. Participation requires verified citizenship (a KYC-approved identity), and each citizen casts one vote per election. Major elections use strict **one-citizen-one-vote** (equal weight); for other ballots, vote weight is derived from trust score and **bounded to a 1–10× range** (`trust_score / 100`, clamped), so influence reflects reputation without being dominated — and is **never a function of token balance**. Candidacy is itself trust-gated: standing for an elected office requires a minimum trust score, and endorsements require endorsers to hold trust above a threshold. Citizens elect officeholders and representative bodies and vote on proposals; in keeping with the TNPoS principle, governance weight derives from citizenship and trust, never from capital. Security is multi-layered. At the implementation layer, the runtime is written in memory-safe Rust on the battle-tested Bizinikiwi framework, and forkless on-chain upgrades allow vulnerabilities to be patched without a hard fork. At the consensus layer, validator misbehaviour — equivocation and disputes — is penalized by **economic slashing** and **automatic validator disabling** (`AlwaysDisableForSlashGreaterThan`). At the social layer, TNPoS adds reputational disincentives: a bad actor forfeits the trust-weighted rewards and governance standing that the trust score confers.
|
||||
|
||||
---
|
||||
## 11. Roadmap & 12. Use Cases
|
||||
The project followed a phased rollout from Testnet to a live Mainnet. It now focuses on ecosystem growth, including a grants program and dApp developer onboarding. Use cases range from Digital Identity and Democratic Governance to Decentralized Finance and Education.
|
||||
PezkuwiChain advanced through a disciplined, phased rollout: Alpha and Beta testnets, the Zagros staging network, and a production Mainnet. With the base layer in production, development focus is on ecosystem growth — a treasury-funded grants program, developer onboarding, and the wallet, exchange, and citizenship applications. Target use cases span Digital Identity, on-chain Governance, Decentralized Finance, and Education, each served by dedicated pezpallets.
|
||||
|
||||
---
|
||||
|
||||
## 13. Team & 14. Ecosystem
|
||||
PezkuwiChain is an initiative led by the Kurdistan Tech Ministry, supported by a global community of over 156 contributors. The architecture is designed for interoperability within the broader blockchain ecosystem.
|
||||
PezkuwiChain is an initiative led by the Digital Kurdistan Tech Institute, supported by a global community of contributors. The architecture is designed for interoperability within the broader blockchain ecosystem.
|
||||
|
||||
---
|
||||
## 15. Legal & 16. Conclusion
|
||||
@@ -166,27 +214,27 @@ The project operates under the Kurdistan Talent Institute License. It is a utili
|
||||
3. **GRANDPA: A Byzantine Finality Gadget** - Web3 Foundation Research.
|
||||
4. **Nominated Proof-of-Stake (NPoS)** - Web3 Foundation Documentation.
|
||||
5. **XCM: The Cross-Consensus Message Format** - Polkadot Wiki.
|
||||
6. **Bizinikiwi: A Blockchain Framework for a Multichain Future** - Parity Technologies.
|
||||
6. **Substrate: A Blockchain Framework for a Multichain Future** — Parity Technologies. *(PezkuwiChain's Bizinikiwi framework is a renamed, independently-maintained derivative of Substrate; see the project `NOTICE` file.)*
|
||||
|
||||
### Project Resources
|
||||
1. **PezkuwiChain GitHub Repository** - `https://github.com/pezkuwichain/pezkuwi-sdk`
|
||||
2. **pezpallet-pez-treasury Source Code** - `.../pezkuwi/pallets/pez-treasury`
|
||||
3. **pezpallet-pez-rewards Source Code** - `.../pezkuwi/pallets/pez-rewards`
|
||||
4. **pezpallet-trust Source Code** - `.../pezkuwi/pallets/trust`
|
||||
1. **PezkuwiChain GitHub Repository** - `https://github.com/pezkuwichain/pezkuwi-DKS`
|
||||
2. **pezpallet-pez-treasury Source Code** - `pezcumulus/teyrchains/pezpallets/pez-treasury`
|
||||
3. **pezpallet-pez-rewards Source Code** - `pezcumulus/teyrchains/pezpallets/pez-rewards`
|
||||
4. **pezpallet-trust Source Code** - `pezcumulus/teyrchains/pezpallets/trust`
|
||||
|
||||
---
|
||||
## 18. Contact & Resources
|
||||
|
||||
### Official Channels
|
||||
* **Website:** `https://pezkuwichain.io`
|
||||
* **GitHub:** `https://github.com/pezkuwichain/pezkuwi-sdk`
|
||||
* **GitHub:** `https://github.com/pezkuwichain/pezkuwi-DKS`
|
||||
* **Documentation:** `https://docs.pezkuwichain.io`
|
||||
* **Block Explorer:** `https://explorer.pezkuwichain.io`
|
||||
|
||||
### Email Contacts
|
||||
* **General Inquiries:** `info@pezkuwichain.io`
|
||||
* **Technical Support:** `tech@pezkuwichain.io`
|
||||
* **Government Relations:** `tech@kurdistan.gov`, `admin@pezkuwichain.io`
|
||||
* **Institutional Relations:** `gov@pezkuwichain.io`, `admin@pezkuwichain.io`
|
||||
|
||||
### Developer Resources
|
||||
* **Developer Portal:** `https://developers.pezkuwichain.io`
|
||||
@@ -221,8 +269,8 @@ The project operates under the Kurdistan Talent Institute License. It is a utili
|
||||
**Node Setup:**
|
||||
```bash
|
||||
# Clone the repository
|
||||
git clone https://github.com/pezkuwichain/pezkuwi-sdk.git
|
||||
cd pezkuwi-sdk
|
||||
git clone https://github.com/pezkuwichain/pezkuwi-DKS.git
|
||||
cd pezkuwi-DKS
|
||||
# Compile the node
|
||||
cargo build --release
|
||||
# Run a development node
|
||||
|
||||
Reference in new issue
Block a user