chore: migrate rust/icp_transfer to icp-cli (#1412)

Author: marc0olo

.github/workflows/icp_transfer.yml

@@ -6,6 +6,7 @@ on:
   pull_request:
     paths:
       - motoko/icp_transfer/**
+      - rust/icp_transfer/**
       - .github/workflows/icp_transfer.yml
 
 concurrency:
@@ -26,3 +27,17 @@ jobs:
           icp network start -d
           icp deploy
           make test
+
+  rust-icp_transfer:
+    runs-on: ubuntu-24.04
+    container: ghcr.io/dfinity/icp-dev-env-rust:1.0.1
+    env:
+      ICP_CLI_GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+    steps:
+      - uses: actions/checkout@34e114876b0b11c390a56381ad16ebd13914f8d5 # v4.3.1
+      - name: Deploy and test
+        working-directory: rust/icp_transfer
+        run: |
+          icp network start -d
+          icp deploy
+          make test

.github/workflows/rust-icp-transfer-example.yml

@@ -46,12 +46,11 @@ test:
 	  echo "  PASS"; \
 	  \
 	  echo "=== Test 3: transferToAccountId — same recipient, same deduction ==="; \
-	  account_id_vec="vec { $$(echo "$$cli_hex" | fold -w2 | while read b; do printf '%d : nat8; ' "0x$$b"; done | sed 's/; $$//') }"; \
-	  echo "  AccountIdentifier: $$account_id_vec"; \
+	  echo "  AccountIdentifier hex: $$cli_hex"; \
 	  backend_before=$$(get_balance "$$backend"); \
 	  recipient_before=$$(get_balance "$$recipient"); \
 	  result=$$(icp canister call backend transferToAccountId \
-	    "(record { e8s = 99_990_000 : nat64 }, $$account_id_vec)"); \
+	    "(record { e8s = 99_990_000 : nat64 }, \"$$cli_hex\")"); \
 	  echo "  result: $$result"; \
 	  echo "$$result" | grep -q 'ok' || (echo "FAIL: transfer rejected" && exit 1); \
 	  backend_after=$$(get_balance "$$backend"); \
@@ -60,4 +59,4 @@ test:
 	  echo "  recipient: $$recipient_before → $$recipient_after  (delta $$((recipient_after - recipient_before)))"; \
 	  [ "$$((backend_after - backend_before))" -eq -100000000 ] || (echo "FAIL: expected backend delta -100000000 e8s" && exit 1); \
 	  [ "$$((recipient_after - recipient_before))" -eq 99990000 ] || (echo "FAIL: expected recipient delta +99990000 e8s" && exit 1); \
-	  echo "  PASS — same recipient reached via AccountIdentifier blob as via principal"
+	  echo "  PASS — same recipient reached via AccountIdentifier hex as via principal"

motoko/icp_transfer/Makefile

@@ -10,7 +10,7 @@ The example exposes three functions to make this concrete:
 
 - **`toAccountIdHex(principal, subaccount)`** — query returning the AccountIdentifier as a 64-char lowercase hex string, the format shown in block explorers and CEX deposit screens.
 - **`transferToPrincipal(amount, principal, subaccount)`** — calls `toLedgerAccount` internally. Use this when you have a principal.
-- **`transferToAccountId(amount, accountId)`** — accepts the raw blob directly. Use this when an exchange or external service gives you the destination as an AccountIdentifier rather than as a principal.
+- **`transferToAccountId(amount, accountIdHex)`** — accepts the AccountIdentifier as a 64-char hex string (the format CEXs and block explorers provide).
 
 > The ICP ledger also supports the [ICRC-1](https://github.com/dfinity/ICRC-1) standard via `icrc1_transfer`. For new token integrations that don't require AccountIdentifier compatibility, ICRC-1 is the recommended interface. A comprehensive ICRC ledger example is planned.
 
@@ -34,11 +34,11 @@ icp network stop
 `make test` funds the backend with 2 ICP, then:
 1. Compares `icp identity account-id --format ledger` with `toAccountIdHex` to verify the CLI and the backend compute the same AccountIdentifier.
 2. Calls `transferToPrincipal` — transfers 99_990_000 e8s (amount) + 10_000 e8s (fee) = exactly 1 ICP deducted from the backend; confirms both sides via `icp token balance`.
-3. Calls `transferToAccountId` with the AccountIdentifier as `vec nat8` — same 1 ICP deduction, confirming both transfer paths reach the same account and the backend balance reaches zero.
+3. Calls `transferToAccountId` with the hex string from step 1 — same 1 ICP deduction, confirming both transfer paths reach the same account and the backend balance reaches zero.
 
 ## Security considerations and best practices
 
 Refer to the [security best practices](https://docs.internetcomputer.org/guides/security/overview) for information on security and best practices for your ICP app. For this example the following aspects are particularly relevant:
 
-- [Inter-canister calls and rollbacks](https://docs.internetcomputer.org/guides/security/overview): issues around inter-canister calls (here the ledger) can lead to time-of-check time-of-use or double-spending bugs.
-- [Certify query responses if they are relevant for security](https://docs.internetcomputer.org/guides/security/overview): essential when displaying financial data that users act on.
+- [Securely handle traps in callbacks](https://docs.internetcomputer.org/guides/security/inter-canister-calls/#securely-handle-traps-in-callbacks): issues around inter-canister calls (here the ledger) can lead to time-of-check time-of-use or double-spending bugs.
+- [Certified variables](https://docs.internetcomputer.org/guides/security/data-integrity-and-authenticity/#certified-variables): essential when displaying financial data that users act on.

motoko/icp_transfer/README.md

@@ -1,4 +1,5 @@
 import Array "mo:core/Array";
+import Blob "mo:core/Blob";
 import Debug "mo:core/Debug";
 import Hex "mo:hex";
 import Result "mo:core/Result";
@@ -82,11 +83,23 @@ actor IcpTransfer {
     await doTransfer(amount, toPrincipal.toLedgerAccount(toSubaccount));
   };
 
-  // Transfer ICP to a recipient identified by an AccountIdentifier blob.
-  // Use this when an exchange or external service gives you the destination
-  // as a raw blob rather than as a principal.
-  public shared func transferToAccountId(amount : Tokens, toAccountId : AccountIdentifier) : async Result.Result<BlockIndex, Text> {
-    Debug.print("Transferring " # debug_show amount # " to account id " # debug_show toAccountId);
-    await doTransfer(amount, toAccountId);
+  // Transfer ICP to a recipient identified by an AccountIdentifier hex string.
+  // Use this when an exchange or block explorer gives you the destination as a
+  // 64-char hex string rather than as a principal.
+  //
+  // Note: CRC32 checksum validation is not performed here — the ICP ledger
+  // validates it and returns a clear error on mismatch. A fromHex helper with
+  // CRC32 validation (equivalent to AccountIdentifier::from_hex in ic-ledger-types)
+  // would be a valuable addition to a Motoko ICP library.
+  public shared func transferToAccountId(amount : Tokens, toAccountIdHex : Text) : async Result.Result<BlockIndex, Text> {
+    switch (Hex.toArray(toAccountIdHex)) {
+      case (#err(e)) #err("invalid hex: " # e);
+      case (#ok(bytes)) {
+        if (bytes.size() != 32) {
+          return #err("AccountIdentifier must be 32 bytes (64 hex chars), got " # debug_show(bytes.size()));
+        };
+        await doTransfer(amount, Blob.fromArray(bytes));
+      };
+    };
   };
 };

motoko/icp_transfer/backend/app.mo

@@ -7,9 +7,6 @@
 .DS_Store
 **/.DS_Store
 
-# dfx temporary files
-.dfx/
-
 # generated files
 **/declarations/