feat(wallet): safely reuse ClawRouter signer and spend limits by A1igator · Pull Request #118 · BackTrackCo/tenjin-agent

A1igator · 2026-08-09T22:20:08Z

Summary

add explicit tenjin wallet connect clawrouter selection for users who already fund ClawRouter
follow ClawRouter's canonical EVM resolution contract: ~/.openclaw/blockrun/wallet.key first, BLOCKRUN_WALLET_KEY only when the file is absent
keep ClawRouter's source wallet outside Tenjin's mutation boundary across connect, reconnect, signing, installation, package upgrades, and uninstall
pin the connected address and refuse signer drift until an explicit --replace reconnect
support SIWX, publishing, and x402 message/typed-data signing while refusing raw transaction signing and therefore tenjin send
inherit ClawRouter's configured perRequest, rolling hourly, rolling daily, and session spend limits read-only by default
honor any explicit Tenjin read-spend setting as a separate Tenjin policy for Tenjin purchases

The integration contract was checked against BlockRunAI/ClawRouter at ba855b90103cde00b5d39023220e2f5aeab94b75 and the Hermes adapter at dfcc3009a422c539d31e7100a04c72348ae6b225.

Spend-policy contract

inherit only when the active provider is ClawRouter and none of maxAutoSpend, sessionBudget, confirm, or allowlistCreators is explicitly set in Tenjin
treat any explicit Tenjin read-spend key as selection of the separate Tenjin policy as a whole; never create a surprising inherited/explicit hybrid
parse only ClawRouter's standard limit fields from ~/.openclaw/blockrun/spending.json; never import, append to, or rewrite its history
round imported USD limits down to six-decimal USDC atomic units so conversion never loosens a limit
enforce per-request, rolling hourly, rolling daily, and session ceilings as hard denials before confirmation
reserve concurrent spends atomically and store committed event history in Tenjin's owner-only ledger
conservatively migrate Tenjin spend-ledger v2 into v3 history without discarding already-recorded spend
fall back to confirmation-only when the ClawRouter policy is missing, empty, malformed, unreadable, or unrepresentable
show inherited config provenance as clawrouter and disclose the source/limits in stacked install receipts

Tenjin and ClawRouter use separate ledgers. The configured limit values match, but spend across the two applications is not one aggregate budget. These are client-side guardrails, not signer-enforced controls.

Authority and custody model

The ClawRouter key belongs to the user. Tenjin selects it only after an explicit connect command (or the explicit --wallet-provider clawrouter choice in the stacked installer); mere discovery never selects it. The calling harness's configured execution policy decides whether that command prompts, is denied, or runs automatically. Tenjin does not add a second proof-of-humanity/TTY gate.

The key necessarily enters Tenjin process memory to derive the selected address and produce signatures. Tenjin does not copy it into Tenjin storage/configuration, persist it, log it, return it, transmit it, inspect the mnemonic, or request raw-transaction signing. Only provider/address metadata is stored.

If YOLO grants arbitrary shell access as the same OS user that can read the ClawRouter key or edit policy files, no Tenjin application-level prompt can reliably oppose it. Notices and receipts improve visibility but do not prove a human saw them. A meaningful restriction must be enforced outside that authority boundary, such as an OS sandbox, separate user, keychain user-presence check, hardware wallet, or independently constrained signer.

Implemented custody contract

give the connector only read/stat capabilities for the external source; it has no write, chmod, rename, archive, overwrite, or delete primitive
resolve the signer after acquiring Tenjin's wallet lock so a queued connect cannot pin a pre-lock observation
assert source byte/inode/mode/size/mtime stability across connect, idempotent reconnect, signing, rotation, drift refusal, diagnostics, and refused local replacement
keep consumer install/uninstall lifecycle scripts absent so package updates/removal cannot implicitly migrate a home-directory wallet
preserve/archive an outgoing local Tenjin wallet and passphrase before an explicit provider replacement
never silently create another wallet or move funds while connecting

Stack

This is stacked on #113. Merge #113 first. #119 consumes this PR's custody and spend-policy facts; #120 forwards them through the universal installer.

Verification

formatting, lint, typecheck, and build pass
243 focused free-read/buy/config/policy/ledger/provider/wallet tests pass on this PR head
full stacked suite passes apart from the loopback-restricted eval inside the sandbox; that eval passes outside the sandbox
source-protection suite and package lifecycle-script checks pass

A funded Base USDC purchase/publication smoke was not performed.

Priority

Critical (P0). This is the no-second-wallet safety and policy boundary used by the Hermes onboarding follow-up.

greptile-apps