A bridge integration has to connect message delivery with the state of the assets being transferred. In ICON Bridge’s NEAR implementation, that meant coordinating routing, token operations, asynchronous callbacks, and the storage costs attached to contract state.
Within ICON Bridge, a centralized bridge project, I worked on the NEAR integration from its early routing and service-management contracts through token transfers and storage accounting. That required following a transfer across contract boundaries: where it was routed, how its outcome returned, and which balances could change as a result.
Establish routing and service management
The early commits include link and route storage and service management, alongside work on BTP addresses, owner permissions, relays, and scenario tests.
These responsibilities sit in the message center: tracking connected networks, resolving destinations, and identifying the services that handle messages. The token service then implements the asset-specific behavior carried through those messages.
This separation lets routing and token accounting have distinct interfaces. Their integration still matters: an error returned through the messaging layer has to reach the service that owns the corresponding transfer state.
Account for asynchronous results
My token work included NEP-141 integration, minting and burning, deposits and withdrawals, and wrapped-token handling. The deposit and withdrawal implementation is one part of that progression.
On NEAR, a cross-contract operation returns through a promise callback. Submitting the operation does not establish that it succeeded. I added promise-result handling for mint, withdraw, and burn operations, with separate handling for successful and failed results.
Later BTP error-handling work connected errors across the message center and token service. This required error representations, callback handling, and tests to agree on how a failure moves through the system.
Make transfer controls and events explicit
I implemented account blacklisting, per-token limits, and transfer restriction checks. The associated message handling carries administrative changes through the service interface.
The work also included token metadata queries and event changes for transfers, registration, minting, burning, and withdrawals. Structured event logging gives consumers defined output to interpret alongside the contract state. These interfaces are part of making transfer behavior observable and operable.
Include storage in the accounting model
The storage-deposit implementation added balances associated with accounts and assets, storage-cost calculation, and deposit checks in transfer paths. It also connected mint callbacks with the costs reported by token operations and expanded the corresponding tests.
This makes storage a separate accounting concern. A token balance describes the asset held for an account; storage accounting records the cost of maintaining the related state. Transfer logic needs to account for both.
I also worked on contract storage organization, moving several structures to NEAR persistent collections, and a subsequent Rust contract refactoring. These changes sit alongside SDK and test-helper updates in the implementation history.
What shipped
The work merged into the NEAR integration includes routing and service-management foundations, token operations, asynchronous error handling, transfer controls, event and metadata interfaces, storage deposits, and contract tests.
The architectural concern throughout is consistency between layers: the message being handled, the outcome of the contract call, the asset balance, and the storage charged to maintain that state. Treating those as connected responsibilities shaped both the contract interfaces and their implementation.