Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add rules/ethpandaops/spamoor/code_standardsgit clone --depth 1 https://github.com/ethpandaops/spamoorWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00007 | $0.02589 |
| Opus 5 | $0.00003 | $0.01295 |
| Sonnet 5 | $0.00001 | $0.00518 |
| Haiku 4.5 | $0.00001 | $0.00259 |
Grade A, and why
code_standards scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured yesterday.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 325 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Spamoor Code Standards
Critical Development Rules
🚨 NEVER use the root wallet directly in scenarios - it's shared across all running scenarios and direct usage will cause nonce conflicts.
🚨 NEVER use go-ethereum's bound contracts for transactions - they manage nonces independently and will conflict with Spamoor's nonce tracking. Always use BuildBoundTx pattern.
🚨 ALWAYS spread transactions across multiple wallets - Ethereum clients have limits on pending transactions per sender (typically 64-1000).
🚨 ALWAYS respect context cancellation - scenarios must stop all operations when context is cancelled.
🚨 ALWAYS call onComplete() in ProcessNextTxFn - required for scenario.RunTransactionScenario transaction counting.
🚨 NEVER assume receipt is non-nil in OnComplete - handle cancellation and replacement transaction scenarios properly.
Go Language Standards
Naming Conventions
- Package names: lowercase, no underscores (e.g.,
spamoor,txbuilder) - Types: PascalCase for exported, camelCase for unexported
- Functions/Methods: PascalCase for exported, camelCase for unexported
- Variables: camelCase for local, PascalCase for exported package-level
- Constants: PascalCase for exported, camelCase for unexported
- Scenario names: lowercase with hyphens (e.g.,
deploy-destruct) - Well-known wallets: lowercase with hyphens (e.g.,
deployer,token-owner)
File Organization
- One main type per file when possible
- Group related functionality in the same file
- Use descriptive filenames that match primary functionality
- Scenario directories:
scenarios/<scenario-name>/ - Each scenario has its own package named after the scenario
- Contract bindings in
contract/subdirectory
Code Structure Patterns
Scenario Implementation
// Standard scenario structure with all common options
type ScenarioOptions struct {
// Transaction Control
TotalCount uint64 `yaml:"total_count"` // Total transactions (0 = unlimited)
Throughput uint64 `yaml:"throughput"` // Transactions per slot
MaxPending uint64 `yaml:"max_pending"` // Maximum concurrent pending
MaxWallets uint64 `yaml:"max_wallets"` // Maximum child wallets
// Gas Configuration
BaseFee uint64 `yaml:"base_fee"` // Base fee in gwei
TipFee uint64 `yaml:"tip_fee"` // Priority fee in gwei
GasLimit uint64 `yaml:"gas_limit"` // Gas limit per transaction
// Client Control
ClientGroup string `yaml:"client_group"` // Preferred client group
// Logging
LogTxs bool `yaml:"log_txs"` // Log individual transactions
// Scenario-specific options...
}
type Scenario struct {
options ScenarioOptions
logger *logrus.Entry
walletPool *spamoor.WalletPool
}
var ScenarioName = "scenario-name"
var ScenarioDefaultOptions = ScenarioOptions{
TotalCount: 0,
Throughput: 10,
MaxPending: 0,
MaxWallets: 0,
BaseFee: 20,
TipFee: 2,
GasLimit: 21000,
ClientGroup: "",
LogTxs: false,
}
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- yesterday First seen · 325 lines · 7 tokens per session scan A 14153160bae0
code_standards is a cursor rule published in the GitHub repository ethpandaops/spamoor (79 stars, last pushed 3d ago), licensed MIT. It adds 7 tokens to every session and 2,589 once invoked, about $0.0000 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other cursor rules, from other repositories
mermaid-diagram-preset
Mermaid sequence diagram preset for all Markdown docs in this repo. Gives rectangles and notes enough breathing room that they don't overlap the arrows around them.
50-wallet-schema
This site deals with Ethereum wallets. The processing pipeline is as follows.
20-typescript
Cursor rule "20-typescript" from walletbeat/walletbeat, covering global typescript rules, the typechecker is your friend, eslint is your friend, respect code structure and do not bypass.
documentation
Documentation discovery index for Lineth monorepo.
pkg-or-internal
BTC Package Placement Rules.
repo-structure
Monorepo layout — which site each folder belongs to and where dev docs live.