Security audit
Security checks for vulnerabilities and agentic risk
This skill is a disclosed hot-wallet bounty operator with real transaction risk, but its artifacts align with that purpose and show scoped safeguards rather than hidden behavior.
Install only if you intend to run a low-balance Verdikta hot wallet. Review the sibling verdikta-discover package before using draft handoff, keep the wallet password in a secret store or mode-600 file outside the skill, keep spend-policy caps tight, use dry-runs first, and treat recovery state as sensitive because it can contain signed transaction bytes.
The declared description presents a full hot-wallet operator with blockchain, API, approval, and withdrawal functionality. The provided code chunk does none of that; it is only a generic helper for detecting whether a script is being run as the main module. This is a materially different actual behavior from the declared purpose, so it should be flagged as a mismatch.
The declared description is for a hot-wallet operator with sensitive blockchain and API capabilities. The supplied code chunk instead implements a hunter-side/work-order result validator: it parses a description, locates result.json in submitted files, reads the file from disk, parses JSON, and validates the result against a template/request. This is a materially different primary purpose and resource profile from the declared wallet operator behavior. While reading local files is benign, the mismatch is substantial because the code lacks the claimed wallet, network, approval, and transaction functionality and instead performs unrelated validation logic.
The supplied code does not implement the declared hot-wallet/operator behaviors such as key creation/import, keystore password handling, Base RPC interaction, transaction signing, spend-policy enforcement, bounty creation from approved drafts, or owner-only withdrawals. Instead, it performs a different task: registering a bot record with the Verdikta service and persisting the returned response/API key locally. While keeping an API key is mentioned in the description, the primary purpose and concrete behavior of this code chunk are materially different from the declared wallet-operator workflow, so this is a mismatch.
The declared description presents a powerful wallet-operating skill with signing, spending-policy enforcement, bounty creation, and withdrawal capabilities. The supplied code only performs a narrow, read-only API call to list open jobs using an API key. This is a materially different primary purpose and omits nearly all described capabilities. While the code does access the Verdikta API and use an API key, that alone does not make the description accurate for this chunk.
The declared description focuses on wallet/key management, API interactions, uploading bounty/work data, creating bounties from owner-approved drafts, and restricted withdrawals to the owner address. The supplied code instead implements a distinct operational action: resolving/claiming an existing bounty submission by inspecting escrow.nextAction(jobId, submissionId) and sending one of several contract calls (finalizeSubmission, failTimedOutSubmission, recoverLeftoverEth, or creatorApproveSubmission). That is a materially different primary purpose and includes capabilities not described in the declaration. Although use of Base RPC, a reviewed API origin, wallet loading, and spend-policy enforcement are consistent supporting elements, the core behavior here is post-submission payout/refund resolution, not bounty creation or owner-only withdrawal handling.
This is a clear description-behavior mismatch. The declared purpose describes a fully functional hot-wallet bounty operator with multiple sensitive capabilities, but the actual code chunk is only a stub that immediately terminates with an error. Its primary behavior is to prevent use of a retired script, not to perform any of the declared wallet, API, or blockchain actions. Therefore the description does not accurately represent what this code chunk actually does.
The declared description centers on a hot-wallet operator that creates/imports keys, uploads public bounty/work data, commissions a verdikta-discover work-order draft after explicit owner chat approval, creates the bounty under a spend policy, and withdraws funds only to the onboarded owner address. This code chunk instead implements a different workflow: submitting deliverables to an existing bounty as the hunter/supplier. It uploads files to /submit, validates work-order result structure, calls prepareSubmission and possibly startPreparedSubmission, confirms submissions via the API, checks nextAction, and stores submission recovery state. While it does use Verdikta API, Base RPC, a wallet, API key, and spend-policy transaction signing, those are supporting overlaps; the primary behavior is materially different from the declared owner-side bounty creation/withdrawal role. Therefore this is a clear description-behavior mismatch.
The declared description presents a full-featured hot-wallet/bounty operator with key storage, API interactions, approval-gated bounty creation, and withdrawals. The supplied code chunk does none of that; it immediately aborts and serves only as a retired placeholder for an old swap script. This is a materially different actual behavior from the declared purpose, so it should be flagged as a mismatch.
The declared description is for a high-privilege hot-wallet operator that manages keys, signs blockchain transactions, interacts with Verdikta and Base services, and enforces owner-approved spending workflows. The supplied code chunk does none of that. Its sole purpose is to validate that a locally configured escrow contract address matches the one published in remote agent documentation for the selected network. While this script may be a guardrail in the same project, the evaluation is for whether this code chunk matches the declared behavior, and it does not. The primary purpose, resources accessed, and trigger style are materially different.
The skill requests read access to ~/.config/verdikta-bounties/.env and secret-bearing wallet/API files. In this context, those files can contain owner address configuration, bot credentials, and sensitive wallet metadata; granting the skill broad read access to them increases the blast radius if the agent is prompt-injected or a companion script is compromised.
permissions:
filesystem:
read:
- "~/.config/verdikta-bounties/.env"
- "~/.config/verdikta-bounties/verdikta-bounties-bot.json"
- "~/.config/verdikta-bounties/verdikta-wallet.json"
- "scripts/*.json"
The skill also requests write access to ~/.config/verdikta-bounties/.env and persistent bot/wallet files. In a hot-wallet skill, write access to configuration and identity files is sensitive because a compromised or misdirected workflow could alter owner address records, endpoint settings, or credential material, enabling fund redirection or persistent tampering.
- "../verdikta-discover/node_modules/**"
- "operator-selected spend policy and approved work-order draft"
write:
- "~/.config/verdikta-bounties/.env"
- "~/.config/verdikta-bounties/verdikta-bounties-bot.json"
- "~/.config/verdikta-bounties/verdikta-wallet.json"
network:
Referenced artifact was not completely inspected
ce, read [operator setup](references/onboarding.md). The available helpers are `wallet_init.js`, `funding_instructions.js`, `funding_check.js`, `bot_register.js
Referenced artifact was not completely inspected
e helpers are `wallet_init.js`, `funding_instructions.js`, `funding_check.js`, `bot_register.js`, `preflight.js` and the read-only `bounty_worker_min.js`. Walle
Referenced artifact was not completely inspected
et_init.js`, `funding_instructions.js`, `funding_check.js`, `bot_register.js`, `preflight.js` and the read-only `bounty_worker_min.js`. Wallet creation/import,
Referenced artifact was not completely inspected
s.js`, `funding_check.js`, `bot_register.js`, `preflight.js` and the read-only `bounty_worker_min.js`. Wallet creation/import, registration and funding each req
Referenced artifact was not completely inspected
s.js`, `funding_check.js`, `bot_register.js`, `preflight.js` and the read-only `bounty_worker_min.js`. Wallet creation/import, registration and funding each req
Skill manipulates agent memory, state, or stored context. Memory corruption can alter personality, override safety rules, or cause unpredictable behavior.
`procurementMode` must be OPEN or TARGETED. TARGETED requires a valid nonzero `targetHunter`. Missing/invalid targets never become open bounties. Preview classification grants no funding authority.
State is saved beside the config as `.state.json`, exclusively created before any mutation. Keep it private and preserve it. Before broadcast, the signed bytes and their hash are saved atomically. `--resume state.json` verifies the saved transaction and reconciles its receipt; if the hash is absent from the RPC, it can resend only those identical signed bytes after review. An API_CREATED state can resume its first signing after fresh checks and approval, using its saved local creation time and a minimum five-minute usable submission window. Legacy BROADCAST_PENDING state without signed bytes/hash requires manual reconciliation. Never delete state merely to retry creation.
## Commission a verdikta-discover draft from a chat approval
Referenced artifact was not completely inspected
e authorization for `--yes` on that config and on nothing else, every check in `create_bounty.js` still applies (binder, rubric, jury against the live class, ch
The skill explicitly requests read access to local configuration, API key, and encrypted wallet files. Even though the metadata says the .env contains no wallet password, these files still contain sensitive operational data such as API credentials, keystore location, owner withdrawal address, and spend policy; compromise of the skill runtime or dependent code could expose or misuse them. Because this is a hot-wallet operator with signing ability, credential/file access materially increases blast radius.
},
"filesystem": {
"read": [
"~/.config/verdikta-bounties/.env",
"~/.config/verdikta-bounties/verdikta-bounties-bot.json",
"~/.config/verdikta-bounties/verdikta-wallet.json",
"scripts/*.json",
The skill requests write access to .env, bot credential storage, and wallet-related state. Write access to security-sensitive config can be abused to alter the recorded owner address, RPC endpoints, policy settings, or bot credentials, potentially redirecting funds or changing trust boundaries if the broader implementation is compromised. In a wallet-signing skill, modifying config is especially dangerous because it can affect future signed transactions.
"../verdikta-discover/references/fulfilment.md"
],
"write": [
"~/.config/verdikta-bounties/.env",
"~/.config/verdikta-bounties/verdikta-bounties-bot.json",
"~/.config/verdikta-bounties/verdikta-wallet.json",
"operator-selected commission/submission recovery state"
Declaring ~/.config/verdikta-bounties/.env and the bot credential file as required config paths confirms the skill depends on locally stored sensitive operational material. While this is not malicious, mandatory reliance on local files increases the attack surface and makes credential theft or tampering more plausible if the host or skill environment is compromised. The risk is elevated by the skill's ability to sign blockchain transactions.
"VERDIKTA_SPEND_POLICY"
],
"requiredConfigPaths": [
"~/.config/verdikta-bounties/.env",
"~/.config/verdikta-bounties/verdikta-bounties-bot.json"
],
"primaryCredential": {
Marking the primary credential as a file-backed .env path means the skill's trust model includes reading configuration from disk. The note says the .env should not contain the wallet password, which lowers severity, but the file still controls keystore path, network, and spend policy; manipulation of those values could influence which assets are used and how transactions are signed. In a hot-wallet context, even non-secret config can be security-critical.
],
"primaryCredential": {
"type": "file",
"path": "~/.config/verdikta-bounties/.env",
"fields": [
"VERDIKTA_NETWORK",
"VERDIKTA_KEYSTORE_PATH",
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
export const OWNER_ENV = 'OFFBOT_ADDRESS';
export const SET_OWNER = 'node onboard.js --set-owner';
// The file _env.js loads and onboarding writes.
export const ownerConfigFile = () => path.join(os.homedir(), '.config', 'verdikta-bounties', '.env');
function assigned(text) {
const values = String(text).split(/\r?\n/).map(line => dotenv.parse(line)[OWNER_ENV]).filter(v => v !== undefined).map(v => v.trim());
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
export const OWNER_ENV = 'OFFBOT_ADDRESS';
export const SET_OWNER = 'node onboard.js --set-owner';
// The file _env.js loads and onboarding writes.
export const ownerConfigFile = () => path.join(os.homedir(), '.config', 'verdikta-bounties', '.env');
function assigned(text) {
const values = String(text).split(/\r?\n/).map(line => dotenv.parse(line)[OWNER_ENV]).filter(v => v !== undefined).map(v => v.trim());
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
export const OWNER_ENV = 'OFFBOT_ADDRESS';
export const SET_OWNER = 'node onboard.js --set-owner';
// The file _env.js loads and onboarding writes.
export const ownerConfigFile = () => path.join(os.homedir(), '.config', 'verdikta-bounties', '.env');
function assigned(text) {
const values = String(text).split(/\r?\n/).map(line => dotenv.parse(line)[OWNER_ENV]).filter(v => v !== undefined).map(v => v.trim());
Detected: suspicious.env_credential_access, suspicious.exposed_secret_literal