DALP Contract Runtime: typed contract reads and writes

The Contract Runtime turns DALP operations into typed smart contract reads and writes. It validates target contracts, encodes calls from ABIs, routes writes through custody or local signing paths, waits for receipts when required, and normalises contract errors for API and workflow callers.

What the runtime does

The Contract Runtime is DALP's typed smart contract interaction layer. Application workflows pass an ABI, contract address, function name, typed arguments, and write options.

The runtime handles the blockchain mechanics that stay consistent across asset lifecycle operations.

It covers four jobs:

Validate that the target address has deployed contract code before a read or write.
Encode function calls from the supplied ABI and append DALP transaction attribution.
Route writes through the configured signing path and wait for a receipt when the caller requests confirmations.
Decode reverts into DALP contract error payloads when a catalog entry exists.

This keeps product workflows focused on the asset task, while the contract-call path stays consistent for nonce handling, custody approval waits, receipt checks, and error shaping.

How a write moves through the runtime

Rendering diagram...

Read calls

Read calls use the ABI passed by the caller and execute view or pure contract functions against the configured network public client. Before reading, DALP validates that contract code exists at the requested address.

Successful reads return the typed function result to the workflow step that requested it.

The read path is designed for deterministic workflow execution. Reads run inside a retryable workflow step, and the returned value is serialised so retries and replays can continue from the recorded result.

Write calls

Write calls use the same ABI-driven typing, then route the transaction through the configured signing path.

Runtime step	What DALP does
Contract validation	Checks cache, DALP's verified-contract store, and on-chain code before writing unless the caller explicitly skips validation after a known deployment receipt.
Function encoding	Encodes the function name and arguments from the ABI, then appends DALP attribution data.
Signer resolution	Resolves the configured wallet and tenant scope before a transaction is signed or broadcast.
Signing path	Uses provider-native broadcast when available. If custody policy requires approval, DALP uses sign-only approval handling. Local signing uses nonce-managed broadcast.
Receipt handling	Waits for the configured number of confirmations by default, verifies the returned receipt matches the broadcast hash, and returns the receipt to the caller.

The default write path waits for one confirmation. Callers can request a different confirmation count or skip waiting when they only need the transaction hash.

Custody approval and nonce handling

Some signing providers can require approval before a transaction leaves the wallet. When that happens, the Contract Runtime surfaces a custody-approval-pending response to the caller and starts the matching approval or quorum monitor so the workflow can resume after approval.

For sign-only and local signing paths, DALP serialises nonce use through the nonce manager. That prevents two writes from the same wallet and chain from racing to use the same nonce. If broadcast fails before a transaction is accepted, DALP releases the reservation so the wallet is not stuck behind a nonce that never reached the chain.

Contract validation

DALP validates target addresses before contract reads and writes. Validation checks:

a runtime cache for positive contract-exists results
DALP's verified-contract records for the current chain
on-chain bytecode with a getCode call when the address is not already known

Only positive contract-exists results are cached. A positive lookup is also stored as a verified-contract record, so DALP can keep recognising that address after the runtime cache eviction window. Negative results are not cached, because a contract can be deployed to an address after a previous lookup.

Error handling

Contract errors reach callers in a consistent shape.

Error source	Runtime behaviour
Gas estimation or broadcast revert	Extracts revert data from the signer or nonce-manager error. DALP decodes the data with the ABI when possible and maps known selectors to contract error payloads.
Receipt status is reverted	Replays the call at the receipt block to recover a decoded reason, then maps the result through the DALP contract error catalog when possible.
Unknown selector or undecoded revert	Returns a plain contract-function revert message instead of inventing a DALP-specific explanation.
Receipt hash mismatch	Rejects the receipt if the chain client returns a same-nonce replacement receipt for a different transaction hash.

The catalog mapping can include a DALP error code, message, suggested response, retryability flag, selector, Solidity error name, and decoded arguments.

When a selector is not in the catalog, the runtime keeps the fallback error bounded to the contract function and decoded reason it could verify.

What stays outside the runtime

The Contract Runtime owns the contract-call mechanics. Other DALP layers own business eligibility, compliance evidence, wallet policy, and network connectivity.

Boundary	Contract Runtime owns	The adjacent layer owns
Business rules	Executes the ABI function that the workflow requested and returns the result.	The product workflow decides whether an operation is allowed before requesting a contract call.
Compliance and transfer gates	Decodes contract reverts when the contract rejects a call.	Compliance modules, identity claims, transfer rules, and asset policy decide whether the requested operation should proceed.
Custody policy	Routes a write through the configured signing path and surfaces approval-pending responses.	The signing layer and custody provider enforce wallet policy, approval, quorum, and key access.
Network access	Uses the configured EVM client to read code, submit transactions, and wait for receipts.	The chain connectivity layer owns RPC endpoints, chain configuration, and upstream network availability.
Off-chain evidence	Returns the verified contract-call outcome.	The surrounding workflow attaches reserve backing, investor eligibility, custody approval, and other off-chain evidence.

The boundary above matches the adjacent public architecture pages: Transaction Signer covers signing and custody policy, Chain Gateway covers EVM network connectivity, and SMART Protocol integration (ERC-3643) covers the asset contract model.

Contract Runtime