diff --git a/.github/dependabot.yml b/.github/dependabot.yml
new file mode 100644
index 0000000..98e4454
--- /dev/null
+++ b/.github/dependabot.yml
@@ -0,0 +1,110 @@
+version: 2
+
+# Dependabot configuration.
+#
+# Shaped by GitHub's "Tame Dependabot: group your updates, slow the cadence,
+# keep security fast" guidance:
+# https://github.blog/security/supply-chain-security/tame-dependabot-group-your-updates-slow-the-cadence-keep-security-fast/
+#
+#   - GROUP routine churn, so a month of bumps arrives as ONE reviewable PR per
+#     ecosystem instead of thirty. Open PRs are not free: they rot into
+#     conflicts, and a wall of them trains reviewers to skim past the whole
+#     list, including the bumps that matter.
+#   - SLOW the cadence to monthly, so updates land on a rhythm you can plan
+#     around rather than "whenever anything upstream changes".
+#   - COOLDOWN of 7 days, so a release has been in the wild long enough for a
+#     bad one to be found and yanked before it is proposed here. Dependabot
+#     already applies 3 days by default; this raises it. Note the interaction
+#     with a monthly schedule: a release published just inside the window is
+#     skipped and waits for the NEXT monthly run, so the practical delay from
+#     publish to PR can approach five weeks, not seven days.
+#
+# ONE PLACE THIS DELIBERATELY DEPARTS FROM THE ARTICLE.
+#
+# The article says to delete `open-pull-requests-limit`. Do not. Omitting the
+# key does not mean "unlimited" -- the documented default is FIVE, and once five
+# version-update PRs are open Dependabot raises no more until some are closed.
+# That is silent withholding, the exact failure the article is arguing against,
+# so the limit is set EXPLICITLY and set high enough never to bind in practice.
+# Grouping, not the limit, is what controls the noise. (Security PRs are exempt
+# from the limit and do not count toward it.)
+#
+# TWO THINGS THIS DELIBERATELY DOES NOT DO. Both are one config key away, and
+# both would be worse than the noise this file exists to reduce:
+#
+# 1. It does not group MAJOR bumps. Every group below matches only `minor` and
+#    `patch`, so a major arrives as its own PR with its own review. A major can
+#    change behaviour, and must never land buried in a large diff that reads as
+#    routine.
+#
+#    Know how Dependabot classifies, because it differs by ecosystem. For CARGO
+#    it applies Cargo's own semver rules, where for a 0.y.z crate a bump in y is
+#    BREAKING: `0.8 -> 0.9` is treated as a MAJOR, falls out of the group, and
+#    arrives as its own PR. That is right for Rust, and it is why the cargo
+#    limit below is generous -- a repo with many 0.x dependencies produces a
+#    real queue of individual PRs alongside the single grouped one. For every
+#    other ecosystem here (npm, pip, docker, gradle, github-actions) Dependabot
+#    compares raw version segments instead, so an npm `0.8 -> 0.9` is classified
+#    `minor` and WILL be grouped, even though npm convention treats 0.x minors
+#    as breaking. The "majors are always reviewed alone" guarantee is therefore
+#    strong for cargo and weaker for the rest.
+#
+# 2. It does not touch SECURITY updates. `applies-to` defaults to
+#    `version-updates`, so Dependabot's security PRs ignore the grouping, the
+#    monthly schedule, the cooldown and the PR limit entirely, and keep arriving
+#    one per advisory, immediately. Do NOT "finish the job" by adding
+#    `applies-to: security-updates` -- slowing security fixes down is precisely
+#    the outcome this configuration avoids.
+
+updates:
+  - package-ecosystem: "cargo"
+    directory: "/"
+    schedule:
+      interval: "monthly"
+    cooldown:
+      default-days: 7
+    # Set explicitly: omitting this caps at 5 and silently withholds the rest.
+    open-pull-requests-limit: 50
+    # This workspace reaches a contract/delegate crate: a bump here can move a
+    # contract address. Labelled so that shows on the PR, not just in this file.
+    labels:
+      - "dependencies"
+      - "contract-rekey-risk"
+    groups:
+      cargo-minor-and-patch:
+        patterns:
+          - "*"
+        update-types:
+          - "minor"
+          - "patch"
+
+  - package-ecosystem: "github-actions"
+    directory: "/"
+    schedule:
+      interval: "monthly"
+    cooldown:
+      default-days: 7
+    # Set explicitly: omitting this caps at 5 and silently withholds the rest.
+    open-pull-requests-limit: 20
+    groups:
+      github-actions-minor-and-patch:
+        patterns:
+          - "*"
+        update-types:
+          - "minor"
+          - "patch"
+
+# WARNING -- this workspace contains contract and/or delegate crates whose
+# COMPILED WASM IS THE CONTRACT ADDRESS. A cargo workspace shares one Cargo.lock,
+# so a grouped dependency bump merged here can silently re-key a deployed
+# contract and strand existing user data. ANY wasm change moves the address: a
+# direct bump, a transitive bump, or a rustc upgrade.
+#
+# This repo has NO migration or wasm-hash guard workflow, so nothing here will
+# turn red when that happens. Before merging a cargo PR, rebuild and compare the
+# contract key, and ship a migration if it moved. See the `freenet-app-migration`
+# skill and `.claude/rules/` in the freenet tree.
+#
+# Dependabot does not create this hazard -- a hand-run `cargo update` does the
+# same thing -- but it does deliver a steady stream of routine-LOOKING PRs, and
+# that is exactly the context in which a re-key gets merged unnoticed.