walletbeat/wallet-update

You are helping a contributor populate or update feature data for a wallet in the Walletbeat project. The wallet they want to work on is: $ARGUMENTS (if blank, ask them which wallet before proceeding).

You have explicit permission to create and edit files inside data/contributors/ and data/ (including all subdirectories).

Your first actions

Before doing anything else:

1. If $ARGUMENTS is blank, ask: "Which wallet would you like to add feature data for?"
2. Identify the wallet type (software / hardware / embedded) if not obvious from the name.
3. Check that the wallet file already exists:
   • Software: data/software-wallets/[wallet-name].ts
   • Hardware: data/hardware-wallets/[wallet-name].ts
   • Embedded: data/embedded-wallets/[wallet-name].ts
   • If it does not exist, let the contributor know and suggest using /wallet-create first to register the wallet.
4. Ask: "What wallet data would you like to add or update?" (e.g., a specific feature, all null fields, a particular group of fields)
5. Ask: "What is your preferred display name or nickname?" and "Do you already have a contributor file in data/contributors/?"
   • If yes — confirm it exists. You only need to ensure they appear in the contributors: [] array of the wallet file.
   • If no — also ask for their affiliation (company / role, if any) and a URL to their profile. You will create the contributor file in Step A below.
6. Read the following files in parallel (skip files that don't exist):
   • The existing wallet file
   • The completed reference example: data/software-wallets/completed.tmpl.ts
   • The contributor guide: resources/docs/contribute/wallet-data.md
   • The example contributor file: data/contributors/example.ts (only if they need a new contributor file)

After reading these files, greet the contributor, summarize which wallet and fields you'll be working on, and begin.

---

Step A — Contributor file

Handle this before touching any feature data.

If the contributor already has a file

Confirm it exists and note the exported constant name. Make sure they appear in the wallet file's contributors: [] array. If not, add them.

If the contributor does not have a file yet

Create data/contributors/[their-nickname].ts using data/contributors/example.ts as the template.

Key rules:

• Affiliation must always be disclosed. If they work for or have equity in the wallet's company, set affiliation accordingly. If they have no affiliation, set affiliation: [].
• Import the entity constant if they have an affiliation (it must already exist in data/entities/).

Example for an affiliated contributor:

import type { Contributor } from '@/schema/wallet'
import { myWalletCorp } from '@/data/entities/my-wallet-corp'

export const chainMonkey: Contributor = {
	name: 'Chain Monkey',
	affiliation: [
		{
			developer: myWalletCorp,
			hasEquity: true,
			role: 'EMPLOYEE', // or 'FOUNDER', 'ADVISOR', 'CONTRACTOR'
		},
	],
}

Example for an unaffiliated contributor:

import type { Contributor } from '@/schema/wallet'

export const chainMonkey: Contributor = {
	name: 'Chain Monkey',
	affiliation: [],
}

Once the contributor file exists (confirmed or newly created), make sure they appear in the wallet file's contributors: [] array. Also update lastUpdated to today's date.

---

Step B — Populate feature fields

The goal is to replace every null field (or the specific fields the contributor identified) with real data gathered by testing the wallet and/or inspecting its source code.

General workflow for each field

For every null field:

1. Explain what the field measures (use TSDoc from the type definition — Ctrl+Click on the field name in the editor to navigate to the type)
2. Describe how to test or verify it
3. Show the completed example value from data/software-wallets/completed.tmpl.ts if applicable
4. Let the contributor fill it in with a ref

The type system — read this section carefully

null = unknown. Never use undefined. A null field means "we don't know yet." Leave fields as null rather than guessing.

VariantFeature<T> — Nearly every field is wrapped in this. It means you can either:

• Use a single value for all variants: multiAddress: featureSupported
• Use a per-variant object if the behavior differs: multiAddress: { [Variant.BROWSER]: featureSupported, [Variant.MOBILE]: notSupported }

Support / featureSupported / notSupported / supported({...}):

import { featureSupported, notSupported, supported } from '@/schema/features/support'

// Feature is supported, no extra data needed:
multiAddress: featureSupported

// Feature is not supported:
multiAddress: notSupported

// Feature is supported AND you need to provide additional structured data:
chainConfigurability: supported({
	ref: refTodo,
	l1: notSupported,
	nonL1: supported({ rpcEndpointConfiguration: RpcEndpointConfiguration.YES_BEFORE_ANY_REQUEST }),
	customChainRpcEndpoint: featureSupported,
})

WithRef<T> — Adds a ref field for sourcing. Always fill ref with evidence:

// Single URL (shorthand):
ref: 'https://github.com/example/wallet/blob/main/src/config.ts'

// Single reference object with label and explanation:
ref: {
  url: 'https://example.com/docs/chain-config',
  label: 'Chain configuration docs',
  explanation: 'This page documents how to configure RPC endpoints.',
}

// Multiple references (array):
ref: [
  { url: 'https://...', label: '...', explanation: '...' },
  { url: 'https://...', label: '...' },
]

// Placeholder — acceptable for initial PRs:
ref: refTodo

// Not necessary — use when the fact is self-evident:
ref: refNotNecessary

MustRef<T> — Like WithRef but you must provide a real ref. refTodo and refNotNecessary will not compile. Used for fields like publicSecurityAudits where the URL to the audit report is the primary piece of evidence.

Nullable<T> — Any subfield can be null if unknown. If any subfield is null, Walletbeat treats the entire field as unrated.

Type inference tip: If TypeScript complains about the supported({...}) call, explicitly annotate the type parameter:

supported<WithRef<ChainConfigurability>>({ ... })

Field-by-field guidance

Walk through each null field in the wallet file (or only the fields the contributor asked about). For each one, provide:

• What it measures (from the TSDoc comment at the type definition)
• How to test it (describe the testing method: try the wallet UI, inspect network traffic, read source code)
• Completed Passing wallet example (show the corresponding value from data/software-wallets/completed.tmpl.ts if applicable)
• Ref expectations (does it need WithRef? Is refTodo okay? Does it need MustRef?)

---

Final step — Verify everything

Once all desired fields are filled in, run:

pnpm fix          # Auto-fix formatting
pnpm check:all    # Must pass before opening a PR

Help the contributor fix any remaining TypeScript or lint errors before they open their pull request.

---

Key rules to remind the contributor throughout

• null = unknown — never use undefined; always prefer null over guessing.
• Every non-obvious value needs a ref — a URL pointing to source code, docs, or a public statement.
• refTodo is a valid placeholder for initial PRs; improve refs before the PR is merged if possible.
• refNotNecessary is only for self-evident facts (e.g., Safe Wallet supports Safe multisigs).
• MustRef fields require a real URL — refTodo won't compile there.
• Run pnpm fix before every commit to auto-fix formatting.
• Run pnpm check:all before opening the PR — it must pass.
• Affiliation must be disclosed — if the contributor is affiliated with the wallet's company, they must set the affiliation field in their contributor file.
• Ctrl+Click on any field in your editor to jump to its type definition — this is the fastest way to understand what a field expects.
• Look at completed.tmpl.ts for any field you're confused about — it's the most completely filled-in wallet example.