System Factory

DALP creates one system per organization through a System Factory contract. Token reads then use the active system's token factory registry to keep assets isolated across organizations on the same network.

Prerequisites

• You have an onboarded organization with signing available for system creation.
• The directory exposes the current System Factory address for the target network, or you pass an explicit factory contract address.
• Your API credential can call system routes for the organization.

Quickstart

Create the organization's system by calling the system creation endpoint. Omit contract when you want DALP to use the System Factory address from the indexed directory.

curl -X POST "https://your-platform.example.com/api/v2/systems" \
  -H "X-Api-Key: $DALP_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "walletVerification": {
      "verificationType": "PINCODE",
      "secretVerificationCode": "123456"
    }
  }'

A synchronous success returns the deployed system address inside the mutation envelope.

{
  "data": {
    "systemAddress": "0x71C7656EC7ab88b098defB751B7401B5f6d8976F"
  },
  "meta": {
    "txHashes": ["0x4f3d5e9b2a9f6d2f0b6b4d8a3e1c5f7a9b0c2d4e6f8a1b3c5d7e9f0a2b4c6d8e"]
  },
  "links": {
    "self": "/v2/systems"
  }
}

When the request is accepted asynchronously, DALP returns a transaction status response instead of the data envelope. Persist the returned status URL and poll it before retrying the business operation.

The request is idempotent per organization while the deployment workflow runs. If the organization already has a stored system address, DALP rejects a second create request instead of deploying another system.

What the system factory creates

The System Factory deploys a new system access manager and a new system proxy. The new system receives the directory reference during initialization and resolves implementation addresses from that directory. This keeps the factory responsible for system creation while the directory remains the source of implementation addresses.

The initial caller becomes the first system administrator. During bootstrap, the factory temporarily holds the permissions it needs to grant roles. After it grants the administrator and system roles, the factory renounces its temporary administrator role for that system.

The factory records every system it creates. Indexers can use the emitted creation event and the factory's stored system list to connect systems, access managers, and directory versions.

Asset isolation model

A system is the organization-level boundary for assets, identities, registries, and factory-scoped reads. Assets are isolated in two ways:

1. The deployed token stores the system address resolved by the indexer.
2. The active system stores a token factory registry with the token factories that belong to that system.

Read handlers use both signals. A token is in scope when its resolved system address matches the active system or when its factory address appears in the active system's token factory registry. This covers assets whose system address is available directly and assets that need to be resolved through their creating factory.

If the active system has no token factories in its registry, scoped reads fail closed and return no rows for that predicate. This prevents a stale or incomplete system context from disclosing assets from another organization.

Multi-tenant read behavior

DALP applies the system factory scope to user asset lists, token search, and related indexer-backed token views. The rule is the same across those surfaces: the active system controls the factory set used to filter rows.

This design lets DALP run multiple organizations on one indexed network without relying only on user identity or wallet address. Wallets can appear in more than one system, but token visibility still follows the active system context.

Idempotency and failure behavior

System creation runs through a durable workflow keyed by the organization id. A retry, double-click, or duplicate client submission joins the same workflow instance while creation is in progress.

The settings table is the durable source for the organization system address after deployment. DALP checks that stored value before it submits a new workflow.

Production notes

• Treat one system as the administrative boundary for one organization on a network.
• Keep the token factory registry current before relying on aggregate asset or user-asset reads.
• Do not use wallet address alone as an isolation boundary. Use the active system context and token factory registry.
• Monitor system creation as an asynchronous deployment. The HTTP request can time out before the workflow has reached a terminal state.
• Verify the directory address set for the network before creating systems in a new environment.

Related primitives

• System context explains where systems sit in the DALP architecture.
• Asset issuance flow shows how asset creation depends on the active system.
• Unified API describes the API surface that exposes system operations.
• Contract runtime explains how DALP executes contract operations.