Vault Issuance SDK

Overview¶

The AXC Vault Issuance SDK provides tokenisation infrastructure for creating and administering both open end and closed end investment funds, with or without maturity sddates. It connects issuer-facing applications with backend workflow services, transaction-signing infrastructure and on-chain asset contracts.

The toolkit covers three operational areas:

• Issuance: Configure investment products and deploy asset contracts through predefined factories.

• Administration: Manage platform users, submit valuation inputs and initiate token issuance.

• Execution: Translate authorised business instructions into blockchain transactions using an internal signing service.

1: Architecture¶

• High Level workflow: The issuer or administrator authenticates with a wallet and submits an operation request through the frontend management interface. The request passes through the NGINX reverse proxy to the middleware, which coordinates the workflow and invokes data system for calculations and internal approvals. Once approved, the token engine prepares the blockchain transaction, obtains a signature from the MPC signing service using the internal execution account, and submits it to the target blockchain. Depending on the operation, the transaction interacts with a contract factory to deploy an asset contract or with an existing asset contract to manage ownership, permissions or template-specific product logic.

• Authentication, authorisation and signing: Authentication: Establish who is interacting with the application. Authorisation: Determine whether that user may request a particular operation. Transaction signing: Authorise execution through the internal blockchain account. On-chain enforcement: Validate the transaction against contract-level permissions and rules. In the described implementation, users authenticate with their own wallets, while administrative transactions are submitted through an internal execution account.

2: Backend Components¶

• Token Engine: The token engine is the blockchain execution component. It receives instructions from middleware and submits the corresponding operations to the selected network. Described responsibilities: Receive instructions for contract deployment and asset administration. Translate instructions into blockchain-specific calls. Coordinate signing through the internal execution account. Submit transactions that update on-chain state.

• Smart Contract Templates and Factories: Factory contracts to create asse contracts and connect them to the wider infrastructure. A template defines the behaviour of a supported product type. A factory creates instances of that template. An asset contract represents an individual issued product.

• Multi-Party Computation Security Module: The security module manages signing authority for the internal execution account. Under the described model: A user authenticates through the frontend. The application determines whether the requested operation is permitted. The backend prepares the blockchain transaction. The signing service authorises that transaction. The token engine submits it to the network. This arrangement allows application-user access to change without necessarily changing the internal execution address.

3: Data System¶

• Data system: Provides calculations and internal approval decisions for infrastructure operations. Perform calculations used by product workflows. Approve or reject operations internally.

• Responsibility boundary: The supplied description assigns calculations to both DRDS and smart contracts. Documentation must specify which component is authoritative for: Fund valuation, NAV per share. Subscription quantities. Redemption proceeds. Distribution amounts. Input data and its source. Effective valuation time. Calculation methodology and version. Approval identity and timestamp. Applicable asset, network and operation. Expiry or validity period.

4: Smart Contracts and Deployment

• Asset Configuration: Asset configuration includes the asset name, tag, description and image; custodian information; links to fund or asset documents; a fixed-term or perpetual duration; product type; financing structure ; blockchain network (BNB or Base); distribution frequency (monthly, quarterly or yearly); an adjustable vault-allocation fraction; public or private access; subscription and redemption windows; and, for the described fund workflow, monthly pricing and quarterly redemptions. Access and transfer policies.

• Subscription and Redemption: Applicable NAV and valuation timestamp. Subscription and redemption cut-off times. Fees, precision and rounding. Request acceptance and cancellation rules. Minting, burning or escrow behaviour. Partial fulfilment and insufficient-liquidity handling. Settlement status and reconciliation.

5: Management Interface

• User Administration: The management interface allows authorised operators to add and remove users.Platform administrators. Issuance operators. Valuation submitters. Approval authorities. Investors and eligible wallets.

• NAV Input and Calculation: Input underlying fund-value, such as monthly asset holdings, and calculates pricing on-chain. Asset identifier. Valuation date and effective period. Valuation currency. Relevant fund values and share count. Calculated or approved NAV per share. Methodology version. Supporting evidence. Approval status. Reference to any superseded record.

6: Supporting Infrastructure¶

• NGINX Reverse Proxy: The infrastructure includes NGINX configuration for routing external requests to internal modules. NGINX supports this through its reverse-proxy functionality. (nginx.org)

• Deployment documentation should identify: Public routes and their upstream services. TLS configuration. Request-size and timeout limits. Rate limits.Trusted proxy-header handling. Logging and sensitive-data redaction. Routing through NGINX should not be treated as a substitute for application-level authorisation.

• Deployment Scripts: Deployment scripts are included, but their commands and supported environments were not supplied. Runtime and infrastructure prerequisites. Required environment variables. Database initialisation and migrations.RPC and network configuration. Signer provisioning.Factory deployment and address registration.Service startup order and health checks. Upgrade, rollback and recovery procedures.