Adding aptos service implementation

[yashnevatia]

TODO:
smartcontractkit/chainlink#21431

In general, to fix clear-text logging of sensitive information, you should avoid logging the sensitive value or, if logging is necessary, log only a redacted or truncated form that cannot be used maliciously (e.g., masking most characters, hashing, or omitting it entirely). The functional behavior of the code (business logic) should remain unchanged; only what is emitted to logs should be adjusted.

For this specific case, the problematic sink is the Warnw call in getAccountWithHighestBalance on line 308 of relayer/aptos_service.go:

s.logger.Warnw("failed to get balance for account, skipping", "account", account, "address", addr.String(), "error", err)

We can fix this by:

• Removing the "address", addr.String() field entirely (relying on "account", account for context), or
• Replacing it with a redacted form that does not expose the full address.

To preserve debuggability while aligning with the rule, the best minimal-impact change is to log only a truncated version of the address (e.g., first and last few characters) that cannot be used directly as an identifier but is still useful for correlating events. Since we cannot change imports beyond standard libraries and must not modify code outside the shown snippet, we will compute this redacted string inline in the log call.

Concretely:

• Edit relayer/aptos_service.go inside getAccountWithHighestBalance.
• Replace the Warnw invocation on line 308 with one that logs a redacted address using addr.String() locally, e.g., keeping only the first 6 and last 4 characters and replacing the middle with "...".
• No changes are needed in relayer/utils/address.go.

In general, to fix clear-text logging issues you either stop logging the sensitive value altogether or log only a redacted/obfuscated form (e.g., truncated, hashed) that is not directly usable as the original secret. For identifiers like account addresses, a common practice is to log only a shortened form (e.g., first 6 and last 4 characters) so operators can still correlate events without exposing the full value.

For this specific case, the problematic call is:

fromAddress := acc.String()
a.baseLogger.Infow("TestingAptosWriteCap: EnqueueCRE - resolved from address", "fromAddress", fromAddress)

We want to avoid emitting the full fromAddress string. The best minimal-impact fix is to log a redacted version. We can compute a shortened representation inline without changing behavior elsewhere: other code still uses the full fromAddress for parsing and transaction construction; only the log output changes. We do not need new imports or helpers.

Concretely, in relayer/txm/txm.go:

• Replace the Infow call on line 272 to log a redacted version, such as <redacted> or a truncated string ("0x1234…abcd").
• Keep all other uses of fromAddress unchanged.

No changes are needed in relayer/utils/address.go; the issue is purely at the logging sink.

---

To fix the problem, we should stop logging the potentially sensitive fromAddress value in clear text, especially in error logs that may be widely stored. The functional behavior of the code (deriving the address, parsing it, and constructing the transaction) can remain unchanged; only the logging needs adjustment.

The best minimal fix is to modify the two log statements that include fromAddress:

• The info log on line 272 that logs "resolved from address" with "fromAddress", fromAddress.
• The error log on line 277 that logs "failed to parse from address" with "fromAddress", fromAddress, "error", err.

Given that the main diagnostic value is knowing that parsing failed, not the specific address, we can:

• Remove the fromAddress field from both logs, and
• Optionally replace it with a non-sensitive placeholder such as a boolean flag ("hasFromAddress", fromAddress != "") or omit extra fields entirely.

This keeps the functionality and error handling identical while eliminating clear-text logging of the derived address.

Concretely, in relayer/txm/txm.go:

• Around existing lines 270–277, change the Infow call to not log fromAddress at all (or to log only a generic message).
• Change the Errorw call in the error branch to omit fromAddress and log only the error (and possibly transactionID, which is already in the logger context via ctxLogger if used, but we will leave the call as-is apart from removing fromAddress to avoid assumptions).

No new imports or helpers are needed; this is a pure log-parameter change.

General approach: Avoid logging the potentially sensitive fromAddress value in clear text. Either omit it from logs entirely or log only a redacted/hashed form that is not directly usable as an identifier, while preserving existing behavior otherwise.

Best concrete fix with minimal behavior change:

• In EnqueueCRE (relayer/txm/txm.go), remove or redact fromAddress from the two log statements:
  • The first info log after resolving the address:
    • Original: a.baseLogger.Infow("... resolved from address", "fromAddress", fromAddress)
    • Change to either omit the field, or log a redacted form (e.g., suffix or hash). To be conservative with respect to the alert, omit it entirely.
  • The info log when enqueueing the transaction:
    • Original: ctxLogger.Infow("... tx enqueued to broadcast channel", "fromAddr", fromAddress, "transactionID", transactionID)
    • Similarly, remove or redact fromAddr. Keeping transactionID is sufficient for traceability.

These changes happen only in relayer/txm/txm.go within the shown function; no imports or helper methods are needed because we’re just changing log arguments. The rest of the transaction handling and address derivation remain unchanged.

---