SettleMint
Reference

System addon factory registry API reference

List and read the system addon factories registered on the active DALP system through the Platform API, including type, kind, deployment, and implementation fields.

A system addon factory is an extension installed on a DALP system that adds capability beyond the core token contracts, such as XvP settlement, token sales, or fixed yield schedules. Each installed addon is registered under the system's addon registry, and these endpoints let an integration read that registry directly instead of through the Console.

Use them when you need to confirm which extensions a system runs, resolve an addon factory address before you call an addon workspace, or audit the implementation contracts an addon delegates to. For the operator workflow that installs and opens addons, see System addons.

Endpoints

EndpointUse it for
GET /api/v2/system/addon-factoriesList the addon factories registered on the active system.
GET /api/v2/system/addon-factories/{factoryAddress}Read one addon factory by its contract address.

The list response uses the DALP collection envelope with data, meta, and pagination links. The single read uses the single-resource envelope with data and links.self.

Both endpoints resolve the active system from the caller's organisation context. Set the participant and wallet context with the standard request headers before calling them. See Request headers.

Addon kinds

Every addon carries a kind that describes how it is implemented on chain.

  • singleton: one registry-level contract serves the whole system. The systemAddonImplementation field holds its implementation address.
  • factory: the addon deploys a separate proxy per instance, such as one contract per XvP settlement or token sale. The factoryImplementation field holds the factory implementation, and instanceImplementation holds the implementation each deployed proxy delegates to.
  • unknown: a legacy or unclassified registration whose kind the registry cannot resolve.

List addon factories

GET /api/v2/system/addon-factories returns the addon factories registered under the active system, with their type, kind, deployment transaction, and Directory implementation addresses. When the system has no registered addons, or before a system is bootstrapped, the list is empty.

The list supports pagination, global search across id and name, and sorting by id, name, or typeId. The default sort is name ascending. You can filter on these fields:

FilterMatches on
idAddon contract address, case-insensitive.
nameAddon name, partial text.
typeIdAddon type, exact value. Facetable.
accountDeployer address, exact value.
kindsingleton, factory, or unknown, exact value. Facetable.

Faceted counts are returned for typeId and kind, so a client can show how many addons of each type and implementation kind a system runs.

curl --globoff "https://your-platform.example.com/api/v2/system/addon-factories?filter[kind]=factory&sort=name" \
  -H "x-api-key: YOUR_API_KEY"
{
  "data": [
    {
      "id": "0x71C7656EC7ab88b098defB751B7401B5f6d8976F",
      "name": "XvP Settlement",
      "typeId": "xvp-settlement",
      "deployedInTransaction": "0xabcdef1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef12",
      "account": "0x2546BcD3c84621e976D8185a91A922aE77ECEc30",
      "kind": "factory",
      "systemAddonImplementation": null,
      "factoryImplementation": "0xCf7Ed3AccA5a467e9e704C703E8D87F634fB0Fc9",
      "instanceImplementation": "0xDc64a140Aa3E981100a9becA4E685f962f0cF6C9"
    }
  ],
  "meta": {
    "total": 1,
    "facets": {
      "typeId": [{ "value": "xvp-settlement", "count": 1 }],
      "kind": [{ "value": "factory", "count": 1 }]
    }
  },
  "links": {
    "self": "/v2/system/addon-factories?filter[kind]=factory&sort=name&page[offset]=0&page[limit]=50",
    "first": "/v2/system/addon-factories?filter[kind]=factory&sort=name&page[offset]=0&page[limit]=50",
    "prev": null,
    "next": null,
    "last": "/v2/system/addon-factories?filter[kind]=factory&sort=name&page[offset]=0&page[limit]=50"
  }
}

List fields

Each item in the list response carries these fields:

FieldTypeDescription
idstringThe addon contract address.
namestringThe addon name, such as XvP Settlement or Yield Schedule.
typeIdstringThe addon type, such as xvp-settlement or fixed-yield-schedule.
deployedInTransactionstringThe transaction hash where the addon was deployed.
accountstringThe account that deployed the addon.
kindstringHow the addon is implemented: singleton, factory, or unknown.
systemAddonImplementationstring or nullRegistry-level singleton implementation. Set for singleton kind only.
factoryImplementationstring or nullFactory implementation registered in the Directory.
instanceImplementationstring or nullImplementation that deployed addon proxies delegate to. Set for factory kind only.

Read one addon factory

GET /api/v2/system/addon-factories/{factoryAddress} reads a single addon factory by its contract address on the active network. The response carries the addon's identity, type, and detected contract version.

curl "https://your-platform.example.com/api/v2/system/addon-factories/0x71C7656EC7ab88b098defB751B7401B5f6d8976F" \
  -H "x-api-key: YOUR_API_KEY"
{
  "data": {
    "id": "0x71C7656EC7ab88b098defB751B7401B5f6d8976F",
    "name": "XvP Factory",
    "typeId": "xvp-settlement",
    "version": 2,
    "type": "xvp-settlement"
  },
  "links": {
    "self": "/v2/system/addon-factories/0x71C7656EC7ab88b098defB751B7401B5f6d8976F"
  }
}

Read fields

FieldTypeDescription
idstringThe addon contract address.
namestringThe addon factory name.
typeIdstringThe addon type, such as xvp-settlement or fixed-yield-schedule.
versionnumberContract version detected on chain. Defaults to 1 when no later version is found.
typestringThe addon type. Holds the same value as typeId.

When the address is not registered as an addon factory on the active system, the read returns 404 with error code DALP-0227. See the Platform API error reference.

On this page