Separate the legal agreement from executable code
A smart contract automates the formal portion of a process, but it does not express every legal exception or dispute mechanism. Link each code revision to the governing agreement, data model and approved operating procedure. For every automated decision, identify the triggering fact and the party accountable for that fact.
Begin with a business-object state machine: created, approved, shipped, accepted, paid, disputed and cancelled. Explicit transitions are easier to test and map to ERP records than a collection of unrelated functions.
Draw the onchain and offchain boundary
Put only the evidence several parties must verify onchain: an identifier, state, evidence hash, signatures and time. Product data, personal information, scans, calculation models and large documents remain in enterprise systems. Bind their exact revision to a transaction with a stable identifier and hash.
This reduces transaction cost and disclosure risk, but makes external storage availability part of the design. Archives, backups and retention must preserve the evidence needed for verification years later.
Use an integration adapter instead of connecting ERP directly to a node
A dedicated service converts business events into contract commands, signs them with an authorized service key, tracks confirmation and returns the outcome. It also owns schema validation, limits, deduplication, retry queues and audit records.
Assign an idempotency key to every operation. A retry after a timeout must not create a second shipment or payment. Distinguish submitted, included in a block, sufficiently confirmed and rejected states; ERP must not mark work complete merely because a transaction was sent.
Give oracles their own trust model
A contract cannot independently verify an API response, exchange rate, sensor reading or delivery event. An oracle moves the fact onchain and introduces a new trust boundary. Define accepted sources, data signatures, maximum age, confirmation count, aggregation rules and safe behavior when sources disagree.
In an enterprise process, an oracle may be a set of signing organizations or a protected gateway rather than a public feed. The contract must validate origin and freshness, while operators need visibility into delay and channel failure.
Treat keys and identities as a separate service
Separate user identity, service account and blockchain address. The policy should explain who may initiate an operation, who technically signs it and how the business action maps back to an employee. Critical keys belong in protected custody or hardware, not inside integration code.
Support rotation without process outage, revocation after departure or incident, multi-party approval for administrative actions and an auditable mapping between corporate roles and addresses.
Handle reorganization, delay and failure
Networks provide different finality guarantees. The adapter must wait for the agreed confirmation level or an explicit finality event, tolerate temporary chain divergence and reconcile state again. Its durable queue records the original command, transaction identifier, current stage and latest error.
If the network or oracle is unavailable, the business process enters a visible pending state instead of proceeding on an assumption. Emergency manual decisions require a role, rationale, dual approval and later reconciliation.
Observability must join both worlds
One correlation ID should connect the ERP document, integration message, transaction, contract event and monitoring record. The operational view reports submission and confirmation latency, queue depth, error rate, transaction cost, stale oracle data and state mismatches.
Logs must not contain private keys or unnecessary personal data, yet they must preserve enough evidence to reconstruct which code, input and authority produced an outcome.
Acceptance tests the complete path
Exercise the normal flow, duplicate command, timeout, unavailable node, bad oracle value, key rotation, ERP rollback, contract upgrade and manual recovery. Reconcile every participant's record after each scenario.
The service is production-ready only when business users see an unambiguous status, engineers can retry safely, security teams control keys and a dispute can be traced through linked evidence from the source document to the ledger transaction.