# AssetAZ Documentation

## 1. Introduction and Purpose

AssetAZ is not a finance application – it is a platform. Just like Windows is not Notepad or Word, AssetAZ is not a budgeting app or a wallet. AssetAZ is the foundation upon which other applications and plugins are built.

Each user (human or AI) runs their own “AssetHub” – the central system that manages all their financial plugins and data. This means that all interaction with assets happens locally and under full user or AI control. AssetAZ is designed as a new standard for building financial software – open, decentralized, and flexible.

## 2. Hubs and Terminals

An AssetHub runs in a single place – locally or in the cloud – and has one owner. Terminals are the devices that access the hub: this could be mobile apps, API clients, smartwatches, or even automated agents such as AIs. Some terminals have graphical UIs, others are completely invisible and operate only through messages or events.

There is only one user per AssetAZHub. It is not a multi-user system, but a personal system. Access to external systems (such as API keys) is managed in Nenjim, not inside AssetAZ.

## 3. Plugins and Interfaces

AssetAZ itself can do almost nothing. All functionality comes from plugins. A plugin can be, for example, a wallet, a budgeting tool, or a plugin that connects to an exchange.

Plugins communicate via API modules (interfaces), which can have many different implementations. This ensures that various components can be swapped out without breaking the whole system. A key feature of the AssetAZ ecosystem is that interfaces survive, but implementations can die.

## 4. Interaction with Nenjim

Nenjim is responsible for fetching, configuring, and delivering instances of components. AssetAZ simply asks Nenjim: “Give me a Bitcoin wallet.” Nenjim returns an instance that already works, because it’s configured with, for example, the correct private key.

All configuration – such as access to external APIs – happens in Nenjim. Plugins in AssetAZ communicate with Nenjim via lazy-loaded and versioned components. This enables side-by-side execution of old and new versions of the same objects.

## 5. Observables and Subscribers

Observables are plugins that provide information or events to others interested in receiving that information. Those who listen to the information are called 'Subscribers'. When everything flows through AssetAZ, it becomes possible to do centralized logging, analysis, and, for example, correct tax calculation (FIFO, etc.).

A plugin acting as an Observable can also be a system that registers external events (such as water temperature). Observables can also be subscribed to over P2P – an AssetAZHub can subscribe to an observable from another hub and receive events as if they were local.

## 6. AssetAZ Token and Incentives

The AssetAZ token is used to pay developers, vote on decisions, and provide access to plugins and services. When a task needs to be solved, the price is estimated in tokens. The developer is then paid in tokens and can choose to keep them as an investment or sell them.

Tokens can also be used by users who wish to have features developed, or as a reward for contributing knowledge, code, or data.

The token’s price is determined indirectly through the “anchors” that users set themselves – one user may expect one token to equal one krone, while another may value it more highly. These differences create trade and speculation on a decentralized exchange, but can also easily be traded “over the counter” (OTC).

## 7. Peer-to-peer and Oracles

All AssetAZHubs run in a P2P network. This makes it possible to share services – for example, access to wallets, sensor data, or plugins – without giving access to the actual code. You can sell oracle services, such as measuring sea temperature every morning and making it available as an observable to other AssetAZHubs.

This makes it possible to earn tokens on other types of assets than just financial – knowledge and data also become assets.

## 8. User Experience

The user experience in AssetAZ depends 100% on the terminal and plugins you use. An AI will never use a UI, while a human user may only use a smartwatch.

A plugin can choose to render information in many ways – it’s similar to installing a graphics card in a computer. It translates data into something the user understands. It’s up to the terminal to present it.

## 9. Transparency, Trust and Signed Builds

All plugins are open source. The user can compile them themselves or trust builds that others have published and cryptographically signed.

The user defines their own prioritized list of whom they trust. When a plugin needs to be installed, Nenjim tries to find a build that matches from one of the trusted signatures.

It’s also possible to charge for signed builds, e.g., via the AssetAZ token, but this requires actively adding a payment plugin – Nenjim has no dependency on AssetAZ unless you want it.

## 10. Distribution and Installation

To make AssetAZ easy to install, it can be delivered as a ready-made image with Lightwale – a minimalist, immutable Linux system with Docker. There is only one container: Nenjim. It is configured to automatically start AssetAZ and the relevant plugins via a single configuration file.

This makes it possible to deliver an entire hub with everything preconfigured – you just power it up.

## 11. Future Topics (TODO)

- Backup and restore via IPFS and encryption
- Security and privacy section
- AI as users and agents
- Governance and community
- User scenarios and fictional cases
- Semver-enforcer tool and build validation
- Further development of the observable concept
- Fluid trust and signature replacement
- Payment services for signed builds