Application Registry & Developer App Store

The Shamwari Application Registry (nxt.apps.Application) provides a protocol-native, decentralized developer directory and software provenance infrastructure built directly into the Shamwari core ledger runtime.

By anchoring software listings directly within nxt.apps—rather than relying on centralized app store gatekeepers, external web registries, or unverified smart contract registries—Shamwari delivers mathematically provable developer identity, tamper-proof version history, block-height-based listing expiration, and native integration with on-chain subscription gating across BetaChains.

---

Core Capabilities & Architecture

• Protocol-Native Application Registry: Executed directly within the core engine (nxt.apps.Application), eliminating virtual machine overhead, reentrancy vulnerabilities, and central gatekeeper fees.
• Post-Quantum Developer Provenance: Every registered application is linked directly to a developer account (developerId) backed by a hybrid post-quantum keypair (CRYSTALS-Kyber and CRYSTALS-Dilithium), ensuring signatures cannot be forged even in a post-quantum environment.
• Automatic Block-Height Delisting: Automated block-listener engine (AFTER_BLOCK_APPLY) evaluates listing expiration at every block height, automatically purging expired records from the active registry.
• Versioned Software Releases: Real-time updates to software releases (appRelease) trigger versioned ledger writes, preserving immutable audit trails across block heights.
• Full-Text & Structured Discovery: Metadata indexing for application name (appName), category (category), target platforms (platforms), repository link (repository), and web endpoint (appURL).
• Subscription-Gated Commercial Integration: Seamlessly couples with nxt.subscriptions.SubscriptionsHome to enable developers to gate software features behind block-height access entitlements.

---

Developer Identity & Post-Quantum Provenance

Unlike traditional mobile app stores or Web3 registries that rely on basic email verification or standard ECDSA keys, Shamwari binds every application listing to a quantum-resistant developer account identity.

       ┌────────────────────────────────────────────────────────┐
       │                Developer Account ID                    │
       ├───────────────────────────┬────────────────────────────┤
       │     KyberPublicKey        │    DilithiumPublicKey      │
       │  (Hybrid PQC Keypair)     │   (Digital Signatures)     │
       └─────────────┬─────────────┴──────────────┬─────────────┘
                     │                            │
                     └─────────────┬──────────────┘
                                   │
                                   ▼
                      Dilithium Transaction Signature
                                   │
                                   ▼
                   addApp() / Protocol-Native Listing
                                   │
                                   ▼
                   public.application Record Created

Each developer account (developerId) publishes a Dilithium public key on-chain. When a developer submits an APPLICATION_LISTING or APPLICATION_UPDATE transaction, the ledger verifies the post-quantum signature against the account's keypair. This guarantees that software listings cannot be hijacked, spoofed, or altered by malicious third parties or unauthorized platform operators.

---

Data Model & Relational Schema

Application metadata, versioning, software releases, and listing expiration heights are maintained in the versioned relational database table public.application.

1. Primary Application Entity (public.application)

Field	SQL Type	Entity Field	Description
id	BIGINT	id	Transaction ID of initial listing registration (globally unique handle).
developer_id	BIGINT	developerId	Account ID of the developer publishing the application.
app_name	VARCHAR	appName	Human-readable application title.
app_description	VARCHAR	appDescription	Detailed application summary and capabilities.
repository	VARCHAR	repository	Public or private source repository URL (e.g., Git repository).
app_url	VARCHAR	appURL	Official web application endpoint or project homepage.
category	VARCHAR	category	Industry categorization (e.g., "DeFi", "RegTech", "SaaS").
platforms	VARCHAR	platforms	Target operating environments (e.g., "Android, Web, Linux").
app_release	VARCHAR	appRelease	Active software version string (e.g., "v2.4.1").
timestamp	INT	timestamp	Blockchain timestamp (seconds since epoch) of last modification.
expiration_height	INT	expirationHeight	Target block height when the listing expires unless renewed.
height	INT	height	Block height of record entry creation/modification.
latest	BOOLEAN	latest	Versioning flag indicating current active record state.

---

Application Lifecycle & State Engine

Applications transition through lifecycle states managed by developer transactions and automated blockchain listeners.

                  ┌───────────────────────────────────────────────┐
                  │      addApp() / APPLICATION_LISTING           │
                  └───────────────────────┬───────────────────────┘
                                          │
                                          ▼
                      ┌───────────────────────────────────────┐
                      │            ACTIVE LISTING             │
                      │  expirationHeight = height + 2592000  │
                      └───────┬───────────────┬───────┬───────┘
                              │               │       │
        updateApp()           │               │       │   renewApp()
  (Updates appRelease)        │               │       │   (Extends Expiration)
                              ▼               │       ▼
                      ┌───────────────┐       │   ┌───────────────────────┐
                      │ Updated State │       │   │   Expiration Extended │
                      └───────────────┘       │   │  +2,628,000 blocks    │
                                              │   └───────────────────────┘
                                              │
                      Expiration Reached      │   deleteApp()
               (height > expirationHeight)    │   (Developer / System Delist)
                                              ▼
                      ┌───────────────────────────────────────┐
                      │           EXPIRED / DELETED           │
                      │    (Purged from Active Table)         │
                      └───────────────────────────────────────┘

---

Mathematical Formulas & Delisting Logic

1. Initial Expiration Height Calculation

When an application is first registered via addApp(), its initial expiration height ($\text{ExpirationHeight}_{\text{initial}}$) is set for $360 \text{ days}$ ($7,200 \text{ blocks/day}$ assuming a 12-second block time):

$\text{ExpirationHeight}_{\text{initial}} = \text{CurrentHeight} + (7,200 \times 360) = \text{CurrentHeight} + 2,592,000 \text{ blocks}$

---

2. Listing Renewal Formula

A developer can extend an active listing by submitting a renewal transaction (renewApp()), extending the expiration height ($\text{ExpirationHeight}_{\text{renewed}}$) by 1 full calendar year ($365 \text{ days}$):

$\text{ExpirationHeight}_{\text{renewed}} = \text{ExpirationHeight}_{\text{current}} + (7,200 \times 365) = \text{ExpirationHeight}_{\text{current}} + 2,628,000 \text{ blocks}$

---

3. Automated Block Listener & Delisting Query

At every block application (AFTER_BLOCK_APPLY), the ledger processor evaluates whether any listings expired between the previous block height ($\text{Height}_{\text{prev}}$) and the current block height ($\text{Height}_{\text{curr}}$):

$\text{IsExpired}(App) \iff \text{Height}_{\text{prev}} \le \text{expirationHeight} < \text{Height}_{\text{curr}}$

The system retrieves expired records using an atomic database clause and purges them:

// Logic from Application.getExpiredApplications(Block block)
final int height = block.getHeight();
final int previousHeight = Nxt.getBlockchain().getBlock(block.getPreviousBlockId()).getHeight();

DbClause dbClause = new DbClause.LongClause("expiration_height", DbClause.Op.LT, height)
        .and(new DbClause.LongClause("expiration_height", DbClause.Op.GTE, previousHeight));

try (DbIterator<Application> iterator = applicationTable.getManyBy(dbClause, 0, -1)) {
    while (iterator.hasNext()) {
        deleteApp(iterator.next().getId());
    }
}

---

Lifecycle Operations & Event Listener Matrix

The Application Registry exposes strongly-typed event listeners across all lifecycle transitions to support wallet UIs, discovery indexers, and compliance monitors:

Event Enum	Trigger Condition	Operational Action
APPLICATION_LISTING	Developer registers a new application listing or submits a major release.	Inserts record into public.application and computes initial $2,592,000 \text{ block}$ expiration.
APPLICATION_UPDATE	Developer updates appRelease version tag.	Updates software release version and refreshes timestamp in public.application.
APPLICATION_LISTING_RENEWAL	Developer extends listing duration.	Adds $+2,628,000 \text{ blocks}$ ($365 \text{ days}$) to expiration_height.
APPLICATION_DELETED	Developer manually removes listing or block listener purges expired app.	Deletes entity record from public.application.

// Example: Registering an application listener in a node module
Application.addListener(app -> {
    System.out.println("New Application Published: " + app.getAppName() 
        + " [Version: " + app.getAppRelease() + "]" 
        + " by Developer Account: " + app.getDeveloperId());
}, Application.Event.APPLICATION_LISTING);

---

Integration with Subscriptions Infrastructure

Developers listing software in the App Store can monetize their products natively without deploying custom payment processors or third-party license servers:

┌──────────────────────────┐         ┌──────────────────────────┐
│   Application Registry   │         │   Subscriptions System   │
│  (nxt.apps.Application)  │         │ (nxt.subscriptions.*)    │
├──────────────────────────┤         ├──────────────────────────┤
│ - appName: "ERP Connector"│ ──────> │ - serviceId              │
│ - developerId            │         │ - plans: JSON array      │
│ - appRelease: "v1.0"     │         │ - holdingId (ZWG/ZAR)    │
└──────────────────────────┘         └─────────────┬────────────┘
                                                   │
                                                   ▼
                                     ┌──────────────────────────┐
                                     │   AccountSubscription    │
                                     │ IsEntitlementActive() == │
                                     │ expirationHeight > height│
                                     └──────────────────────────┘

1. Service Registration: Developer registers a SubscriptionService linked to their developerId with defined pricing tiers (e.g., Free, Developer, Enterprise).
2. Payment & Entitlement: Users purchase access tiers using native platform coins, stablecoins, or custom totems via addSubscriptionPayment().
3. Runtime Verification: At software startup, the application verifies the client's AccountSubscription.getExpirationHeight() > currentHeight directly against the ledger state, unlocking functionality seamlessly.

---

Related APIs

API	Description
ListApplication	Register application
GetApplication	Get application
GetApplications	List applications
UpdateApplication	Update application
DeleteApplication	Delete application
RenewApplication	Renew application

Primary Institutional & Commercial Use Cases

• Verified dApp Discovery: Wallets and ecosystem portals index applications directly from public.application, ensuring users interact with authentic software signed by verified developer identities.
• Open-Source Tooling Registry: Developers publish libraries, SDKs, and developer tools with verified repository links (repository), establishing tamper-proof developer provenance.
• Enterprise Software Certification: Financial institutions publish ERP adapters, core-banking connectors, and regulatory reporting plugins signed by corporate post-quantum keypairs.
• RegTech & Compliance Adapters: Regulatory technology providers register AML screening modules and KYC gateways under the "RegTech" category, allowing institutions to verify audit histories.