A parent chain anchors sovereign child chains. Each chain is an isolated financial environment with its own schema, currency, permission policy, and embedded regulatory authorities. Every financial primitive from payments, lending, insurance, commerce and identity reside within the consensus layer, not in smart contracts.
The two-tier model separates infrastructure from application. FxtChain handles global settlement finality and houses the infrastructure-only transaction set. BetaChains are sovereign financial environments where each has its own schema, currency, permission policy, and embedded regulatory authority accounts.
| Property | FxtChain (Parent) | BetaChain (Child) |
|---|---|---|
| Chain id | 1 (fixed singleton) | 2, 3, 4… sequential at creation |
| Database schema | PUBLIC | Chain name e.g. ZIMBABWE, CAPITAL |
| Native currency | WEALTH (SHAMWARI) | Per-chain ZWG, ZAR, CAPITAL… |
| Total supply | 1,000,000,000,000 QNT | Immutable configuration at genesis |
| Transaction scope | Core type infrastructure-wide transactions only | Full financial primitive set (application types) |
| Permission policy | N/A for root authority | NONE → BETA_CHAIN at a pre-committed block height |
| Regulatory authorities | N/A | 3 hardcoded at genesis: CB + SEC + INS |
| Disabled API tags | Chain-control subset | Configurable per chain via disabledAPITags |
| Instantiation pattern | Static singleton (JVM init) | Builder pattern which is immutable after build() |
| Cross-chain settlement | Provides finality anchor | References FxtChain for global settlement events |
Each chain writes exclusively to its own named schema in the database. Account balances, totem ownership, insurance policies, and all financial state are schema-scoped and one chain cannot read or write another's tables. This is not application-level isolation; it is enforced at the database layer.
// BetaChainBuilder for key genesis params
BetaChain.newBuilder()
.id(2)
.schema("ZIMBABWE")
.currency("ZWG")
.name("Zimbabwe Gold Chain")
.description("Central Bank regulated chain")
.totalAmount(100_000_000_000L * Constants.ONE_COIN)
.permissionPolicyType(PermissionPolicyType.NONE)
.permissionSwitchHeight(10_000L) // NONE → BETA_CHAIN at block 10K
.centralBankAccountId(RESERVE_BANK_ACCOUNT_ID) // hardcoded at genesis
.securitiesRegulatorId(SEC_ACCOUNT_ID)
.insuranceAuthorityId(IPEC_ACCOUNT_ID)
.disabledAPITags() // no restrictions
.build();BetaChains launch with the NONE permission policy with permissionless bootstrapping for community adoption. At a pre-committed block height set at genesis, the policy transitions automatically to BETA_CHAIN: all future transactions require CHAIN_USER permission or above. The transition is protocol-enforced and requires no chain upgrade.
permissionPolicyType = NONEblocks 0 → permissionSwitchHeightblock == permissionSwitchHeight → BETA_CHAINpermissionPolicyType = BETA_CHAIN| Transaction | AI Allowed | Method |
|---|---|---|
| CURRENCY_PAYMENT (P2P) | ✓ Yes | isAIAllowed() → true |
| SUBSCRIBE / UNSUBSCRIBE | ✓ Yes | isAIAllowed() → true |
| PURCHASES | ✓ Yes | isAIAllowed() → true |
| EXCHANGE_BUY / SELL | ✓ Yes | isAIAllowed() → true |
| ISSUE_CERTIFICATE | ✗ Blocked | default → false |
| INSURANCE_APPROVAL | ✗ Blocked | default → false |
| GRANT_PERMISSION | ✗ Blocked | default → false |
| TOTEM_APPROVAL | ✗ Blocked | default → false |
Every transaction passes through the same ordered validation pipeline on every node. Each gate is deterministic and identical input always produces identical output. This is what produces consensus: not a voting mechanism, but a shared computation over the same validation logic.
TransactionImpl.verify() → Crypto.verify(signature, txBytes, publicKey)Chain.isAllowed(tx.getType()) → booleanPermissionPolicy.check(sender, txType) → PASS | REJECTAccountType.isAllowed(Transaction tx, Account sender)TransactionType.validateAttachment(Transaction tx)BalanceHome.addToBalance(accountId, -amount) → overflow-safeBlockchainProcessorImpl.apply(block) → atomic DB transactionAfter every successfully applied block, the AFTER_BLOCK_APPLY event fires. Multiple systems register listeners that execute automatic protocol operations without any user transaction subscriptions unsubscribe themselves after lapses, insurance products cancel on expiry, expired purchases refund buyers, and Totem freeze heights activate without any human trigger.
Every financial operation is a typed, protocol-enforced transaction and not a smart contract call. The type byte determines chain routing, permission requirements, account type eligibility, and the validation logic applied.
interface TransactionType {
// Chain routing: does this type run here?
boolean isAllowed(TransactionType type);
// AI gate: secure by default
default boolean isAIAllowed() {
return false; // override to permit AI agents
}
// Business logic: type-specific rules
void validateAttachment(Transaction tx)
throws ValidationException;
// Admin gate: does this need CHAIN_ADMIN?
default boolean isAdministrative() {
return false;
}
}The decision to implement every financial primitive at the consensus layer rather than as smart contract overlays is not a limitation but a core architectural thesis. Every security property, compliance guarantee, and operational cost advantage flows directly from this design choice.
On existing platforms, every new dApp deployment is a new attack surface. Shamwari's financial logic is audited once in the protocol codebase and deployed everywhere. $3.8B+ in DeFi has been lost to smart contract exploits that are structurally impossible here.
Regulatory controls like TotemApproval, account type restrictions, and insurance authority actions are enforced by the consensus engine. No application-layer code can override them such that a suspended Totem stays suspended regardless of what any front-end tells users.
All five financial systems share the same protocol, so cross-system operations are atomic by construction. A purchase that triggers a loyalty reward, a loan repayment that releases collateral can all execute in one block, one database transaction. No bridge risk. No cross-contract call failure.
Gas models create unpredictable transaction costs, making them unusable for high-frequency, low-value operations like subscription billing, insurance premium collection, and microfinance repayments. Shamwari's transaction fee model is fixed and predictable per transaction type.
| Property | Shamwari (Protocol-native) | Ethereum (Smart contract) | Solana (Programme-based) |
|---|---|---|---|
| Financial logic location | Consensus layer | Smart contract (EVM bytecode) | On-chain programme (SBF) |
| Compliance enforcement | Protocol-enforced, ungovernable by apps | Application-layer only, bypassable | Application-layer only, bypassable |
| Transaction cost model | Fixed per-type fee | Variable gas fees spike unpredictably | Low but not zero and SOL denominated |
| Security audit surface | One codebase, one audit | Every contract is a new surface | Every programme is a new surface |
| Re-entrancy risk | None with no external calls | Structural risk (DAO hack, $60M) | Structural risk exists |
| Post-quantum signatures | ML-DSA Dilithium from genesis | ECDSA migration TBD | Ed25519 is quantum vulnerable |
| Regulatory authority | Hardcoded at genesis, immutable | No native concept | No native concept |
Shamwari transforms each BetaChain from an open blockchain into a regulated financial network where participation is a privilege that must be explicitly granted, can be revoked, and is permanently recorded. This is not application-layer access control but enforced logic at the transaction validation layer.
When a CHAIN_ADMIN is removed, the system automatically revokes every CHAIN_USER and BLOCKED_CHAIN_USER permission they granted from the specified height onwards. No orphaned permissions persist after an admin is compromised or removed.
| Capability | Shamwari Chain Control | Traditional KYC System | Smart Contract Access Control |
|---|---|---|---|
| Permission enforcement | Protocol layer is robust and structurally impossible to bypass | Application layers can be circumvented | Application layer depends on smart contract logic |
| Cascading revocation | Automatic on admin removal | Manual multi-system update | Not available |
| Blocker mechanism | Positive denial with full history | Delete-only and loses audit trail | Not available |
| KYC data attachment | Encrypted on-chain per grant | Separate database | Not available |
| Policy upgrade | In-protocol at configured block height | Requires redeployment | Requires contract upgrade |
| Audit trail | Versioned blockchain table that is immutable | External database which is modifiable | Event logs only |
Shamwari's Taxation System is the most comprehensive on-chain tax infrastructure deployed on any blockchain. Every taxable transaction automatically computes applicable taxes, withholds them from relevant parties, and credits the chain's designated Tax Collector account all atomically within the same block.
Tax calculation: taxAmount = (transactionAmount × rateBps) / 10,000. Each type supports independent min/max taxable thresholds. Amounts below minimum are untaxed; amounts above maximum are capped.
The SetTaxRatesAttachment allows up to 13 rate entries in a single transaction. All entries apply at the same block height via atomic database transaction ensuring partial updates are structurally impossible.
The Binder Protocol removes the requirement for end users to hold native blockchain tokens to pay transaction fees. A Binder holds WEALTH (FXT) tokens and pays FxtChain fees on behalf of BetaChain users, who pay BetaChain fees in their local currency. Users only ever need ZWG, ZAR, or CAPITAL to transact.
Each Rule combines three elements: minimum rate (minRateMTAPerFXT), overpay factor (overpayFQTPerFXT), and an ordered list of Filters. Filters determine which transactions the Rule applies to.
MIN_FEE charges exactly the required FXT fee. PROPORTIONAL_FEE scales with the BetaChain fee paid by the user. Custom calculators can be loaded via nxt.customBindingFeeCalculators for institutional-specific structures.
Binders advertise rates via BinderRate broadcast to the peer-to-peer network. Wallets query getBinderRates() and select the most favourable binder. Competitive binder pricing is incentivised as the binder offering the lowest fee wins contested transactions.
Every Shamwari block is signed with ML-DSA-2 (Dilithium Level 2, NIST FIPS 204). The balance-weighted forging algorithm determines block generation rights without energy expenditure. Dynamic base target adjustment maintains ~60-second block times.
For each candidate forger, a hit value is computed from SHA-256(previousBlock.generationSignature || forgerPublicKey.combinedPublicKey). The forger with the earliest hitTime generates the next block.
Adjusts every 2 blocks to maintain target time. If average block time exceeds target, baseTarget increases (easier forging). If below, it decreases. Bounded by MIN/MAX_BLOCKTIME_DELTA to prevent sudden swings.
The Generator module prevents block generation when CPU or RAM is insufficient for current transaction volume. Required resources scale linearly with mempool size to prevent node crashes under extreme load.
The genesis block establishes the entire initial network state from JSON data files. All mutable state is stored in versioned entity tables and every state change at every block height is preserved, enabling point-in-time queries without transaction replay.
A single Shamwari node simultaneously serves a fully open global asset market (CAPITAL chain), a regulated ZWG monetary system with Central Bank oversight (ZIMBABWE chain), and a South African rand-denominated financial platform (SOUTH AFRICA chain) all isolated, each under its own regulatory framework, sharing the same proof-of-stake consensus.
| Chain | Currency | Code | Decimals | Total Supply | Key Restriction |
|---|---|---|---|---|---|
| FxtChain | SHAMWARI | WEALTH | 3 | 1,000,000,000,000 | Settlement only |
| CAPITAL | CAPITAL | CAPITAL | 4 | 1,000,000,000,000 | Open permission policy |
| ZIMBABWE | Zimbabwe Gold | ZWG | 1 | 100,000,000,000 | Permissioned from configured height |
| SOUTH AFRICA | South African Rand | ZAR | 1 | 100,000,000,000 | Permissioned from configured height |
Shamwari's architectural decisions from a dual-chain design to protocol-native financial primitives, post-quantum security, and embedded regulatory governance create structural advantages that application-layer solutions cannot replicate.
| Architectural Property | Shamwari | Ethereum | Hyperledger Fabric |
|---|---|---|---|
| Block signatures | Post-quantum Dilithium (FIPS 204) | ECDSA (quantum-vulnerable) | RSA/ECDSA (quantum-vulnerable) |
| Account keys | ML-KEM-512 + ML-DSA-2 hybrid | ECDSA secp256k1 | RSA/ECDSA |
| Consensus | Balance-weighted PoS (no energy waste) | PoS (ETH 2.0) | PBFT / Raft (permissioned) |
| Multi-jurisdiction | Native BetaChain model | Manual sharding | Channels (limited) |
| Regulatory accounts | Protocol-embedded authority accounts | Application layer only | Application layer only |
| Fee abstraction | Native Binder Protocol | ERC-4337 (complex) | Orderer pays (limited) |
| Financial product depth | 70+ native transaction types | ERC standards + contracts | Custom chaincode |
| KYC/permission | Protocol-native PermissionPolicy | Application layer only | MSP (member services) |
| Tax integration | Automatic on-chain withholding | None | None |
| Permission upgrade | Block-height-triggered in-protocol | Governance contracts | MSP configuration |
All five volumes of the Shamwari Technical Papers are available in the documentation covering every system, every transaction type, every cryptographic decision, and the full database schema.