feat(precompiles): implement TIP-1011 restrictions by legion2002 · Pull Request #3385 · tempoxyz/tempo

legion2002 · 2026-03-30T19:29:48Z

Stack Context

This is the middle PR in the TIP-1011 stack.

Parent: #3384 feat(primitives): add TIP-1011 wire format and ABI
Child: #3386 feat(node): enforce TIP-1011 restrictions

What This PR Does

This PR implements TIP-1011 inside the AccountKeychain precompile:

periodic spending-limit state and reset behavior
allowed-call target / selector / recipient scoping
precompile mutators and readers for the new restriction state
hardfork-gated dispatch and direct readers that depend on the new layout

This is the PR where the spec becomes concrete precompile and storage behavior. It intentionally stops short of handler and txpool runtime enforcement, which lands in PR3.

How To Review

Review this like a smart-contract PR.

Start in crates/precompiles/src/account_keychain/mod.rs and verify the storage model and invariants: uniqueness, rollover behavior, normalization, selector and recipient validation, and any assumptions about reads and writes.
Look for efficiency opportunities as you go: slot count, tight packing, unnecessary writes, and whether the chosen layout is the right tradeoff for expected access patterns.
Check access gating carefully for the important mutators, especially authorizeKey, setAllowedCalls, removeAllowedCalls, and updateSpendingLimit.
Review crates/precompiles/src/account_keychain/dispatch.rs for ABI routing and fork gating.
As a final pass, think ahead to how the handler will interact with these precompile functions and where they will be used in #3386.
Related context: #3370 is a draft PR that adds an enumerable map utility and makes the targets / target_scopes path more efficient. It is worth keeping in mind when evaluating this layout.

Note

If you want the full end-to-end diff in one place, see #3323. It is useful for seeing how the ideas interact across the stack, and Cyclops also runs there.

github-actions · 2026-03-30T19:30:48Z

⚠️ Changelog not found.

A changelog entry is required before merging. We've generated a suggested changelog based on your changes:

Preview

---
tempo-contracts: minor
tempo-precompiles: minor
---

Added TIP-1011 allowed call scoping to the AccountKeychain precompile with per-target and per-selector restriction support, periodic spending limits with automatic rollover, and T3 hardfork gating that rejects legacy `authorizeKey` selectors post-T3 while preserving backward compatibility pre-T3.

Add changelog to commit this to your branch.

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 476b865f8b

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

crates/alloy/src/provider/ext.rs

crates/transaction-pool/src/tempo_pool.rs

crates/precompiles/src/account_keychain/mod.rs

klkvr · 2026-03-30T23:20:56Z

crates/precompiles/src/account_keychain/mod.rs

+        Ok(())
+    }
+
+    fn validate_selector_rules(


it seems that this check is entirely stateless and is something that we would want to do in the pool so ideally we have it as a helper on CallScope

crates/precompiles/src/account_keychain/mod.rs

crates/transaction-pool/src/tempo_pool.rs

crates/precompiles/src/account_keychain/mod.rs

0xKitsune · 2026-03-31T14:35:02Z

crates/precompiles/src/account_keychain/mod.rs

+        let mut limit_state = self.spending_limits[limit_key][token].read()?;
+        limit_state.remaining = limit_state.remaining.saturating_add(amount);


Currently, if a period rolls over resetting remaining to max and then a fee refund arrives for a transaction charged in the previous period, remaining gets pushed above max because saturating_add has no upper bound. We should clamp remaining to min(remaining, amount) after the add when period > 0 so that refunds never grant more budget than the owner originally authorized per period.

yeah I had thought about this, but don't think we can ever reach this path.
the refund is an atomic operation, so period rollover cannot happen in the middle of a tx, and the refund can never be more than the initial spending limit.

But I can add a min() clamp as a defense-in-depth improvement if you want, because it should be cheap to do the check.

crates/transaction-pool/src/tempo_pool.rs

klkvr · 2026-03-31T23:56:29Z

crates/precompiles/src/account_keychain/mod.rs

+/// Key-level call scope.
+#[derive(Debug, Clone, Storable, Default)]
+pub struct KeyScope {
+    pub is_scoped: bool,


I understand that we need this flag for KeyScope to distinguish between the key not allowing any calls and the key allowing all calls

however, for TargetScope and SelectorScope this flag seems redundant? given that we track Set of keys that actually exist it should not be possible to confuse a non-existing selector/target scope with an existing one because we would always perform the inclusion check via the Set?

my intuition here was to keep things symmetrical, and explicit to understand.
If we remove the flag from TargetScope/SelectorScope. An empty array in these scopes means "allow-all", but an empty array in "KeyScope" would mean deny-all.

Having thought about it more, I am changing my mental model to -

it doesn't make logical sense to keep a scope around if all the selectors/entries in that scope are blocked. So in this case the default meaning of an empty list is "allow-all"

But we have an exception in call scope, because it is the topmost level, so we can't just remove the entry, for the deny-all case.
In this case we add an explicit bool for "allow-all", and the default empty list value is "deny-all"

I think this is still slightly confusing in the implementation, but people would not be interacting with storage slots directly in most cases.
And I have also added explicit scoping bools to the get_allowed_calls return value to make this more clear.

addressed in 72809e7

crates/transaction-pool/src/tempo_pool.rs

0xKitsune · 2026-04-01T04:33:01Z

crates/precompiles/src/account_keychain/mod.rs

+        let target = scope.target;
+
+        if !scope.selectorRules.is_empty() {
+            self.validate_selector_rules(target, &scope.selectorRules)?;
+        }
+
+        if !self.key_scopes[account_key].targets.contains(&target)? {
+            let count = self.key_scopes[account_key].targets.len()?;
+            if count >= MAX_CALL_SCOPES as usize {
+                return Err(AccountKeychainError::scope_limit_exceeded().into());
+            }


upsert_target_scope doesn't reject Address::ZERO as target. IIUC Address::ZERO is used as the sentinel value in get_allowed_calls to represent "scoped but no targets".

If a user calls setAllowedCalls with target = address(0), it'll be inserted into the targets set, corrupting the sentinel distinction, get_allowed_calls would return it as a real target, and validate_call_scope_for_transaction would allow calls to address(0).

addressed in 72809e7 and 66421f5

crates/precompiles/src/account_keychain/mod.rs

fgimenez

lgtm, a couple suggestions

crates/precompiles/src/account_keychain/mod.rs

klkvr · 2026-04-01T11:04:41Z

crates/precompiles/src/account_keychain/mod.rs

+        if scopes.is_empty() {
+            return Ok(());
+        }


hmm i don't think it's expected that we'd just ignore this call if scopes are empty?

we have a separate endpoint "removeAllowedCalls", if people want to remove scopes.
do you mean we should revert here instead?

We can't iterate over the scopes and remove them ourselves, because we don't have an enumerable map for this onchain. We expect that people will call removeAllowedCalls with the scopes instead. Or disable the key altogether.

then empty scopes should probably make the key unrestricted?

crates/precompiles/src/account_keychain/mod.rs

klkvr · 2026-04-01T11:22:55Z

crates/precompiles/src/account_keychain/mod.rs

+        // Check key is valid (exists and not revoked)
+        let current_timestamp = self.storage.timestamp().saturating_to::<u64>();
+        let key = self.load_active_key(account, key_id, current_timestamp)?;


couldn't load_active_key fetch timestamp internally?

there are a couple of places where the timestamp is already available, so we don't have to fetch it again, like the validate_keychain_authorization fn

it's not expensive to fetch it at all, we carry it around as a u64

Amp-Thread-ID: https://ampcode.com/threads/T-019d4307-f847-7661-82ac-a8e22e140693

Amp-Thread-ID: https://ampcode.com/threads/T-019d43c1-3d1f-701f-8475-5c0be39a765d

Amp-Thread-ID: https://ampcode.com/threads/T-019d453b-5da2-76ec-b058-840ce67c1350

Amp-Thread-ID: https://ampcode.com/threads/T-019d4572-ffe2-73dc-b971-0323631b9260

Amp-Thread-ID: https://ampcode.com/threads/T-019d43c1-3d1f-701f-8475-5c0be39a765d

Amp-Thread-ID: https://ampcode.com/threads/T-019d47f8-a4c0-71af-8427-68314207dfed

Amp-Thread-ID: https://ampcode.com/threads/T-019d47f4-6e44-703e-b211-925ca1c63fd6

Amp-Thread-ID: https://ampcode.com/threads/T-019d47f8-a4c0-71af-8427-68314207dfed

Amp-Thread-ID: https://ampcode.com/threads/T-019d486b-4380-776b-b8c1-c658270e0655

Amp-Thread-ID: https://ampcode.com/threads/T-019d48d0-100a-75df-a9ba-6836b811180e

## Stack Context This is the top PR in the TIP-1011 stack. - Parent: [#3385](#3385) `feat(precompiles): implement TIP-1011 restrictions` - Child: none ## What This PR Does This PR enforces TIP-1011 at runtime: - handler-side validation and intrinsic gas accounting for `key_authorization` - execution-time enforcement of periodic limits and call scopes - rejection of invalid access-key contract-creation or scoped calls before execution - txpool validation so invalid transactions are filtered before propagation This is the integration layer where the protocol shape from PR1 and the precompile semantics from PR2 are actually enforced by the node. ## How To Review 1. Start with `crates/revm/src/handler.rs`. This is the core of the PR: hardfork gating, intrinsic gas, same-transaction authorization behavior, and per-call enforcement. 2. Then review `crates/transaction-pool/src/validator.rs` and confirm txpool admission matches the runtime rules closely enough to reject bad transactions early without diverging from execution. 3. Review the remaining runtime tests and regressions after that. 4. Think about the stack as a whole while reviewing this PR: how the signed payload from [#3384](#3384) feeds the precompile state from [#3385](#3385), and how this handler and validator layer consumes both. ## Note If you want the full end-to-end diff in one place, see [#3323](#3323). It is useful for seeing how the ideas interact across the stack, and Cyclops also runs there.

legion2002 requested review from 0xKitsune, 0xrusowsky, fgimenez, howydev, klkvr, mattsse and onbjerg as code owners March 30, 2026 19:29

chatgpt-codex-connector bot reviewed Mar 30, 2026

View reviewed changes

crates/alloy/src/provider/ext.rs Outdated Show resolved Hide resolved

crates/transaction-pool/src/tempo_pool.rs Outdated Show resolved Hide resolved

This was referenced Mar 30, 2026

feat(primitives): add TIP-1011 wire format and ABI #3384

Open

feat(node): enforce TIP-1011 restrictions #3386

Merged

klkvr reviewed Mar 30, 2026

View reviewed changes

0xrusowsky reviewed Mar 31, 2026

View reviewed changes

crates/precompiles/src/account_keychain/mod.rs Outdated Show resolved Hide resolved

legion2002 mentioned this pull request Mar 31, 2026

feat(account-keychain): implement TIP-1011 T3 semantics #3323

Closed

0xrusowsky reviewed Mar 31, 2026

View reviewed changes

crates/transaction-pool/src/tempo_pool.rs Outdated Show resolved Hide resolved

0xrusowsky reviewed Mar 31, 2026

View reviewed changes

crates/precompiles/src/account_keychain/mod.rs Outdated Show resolved Hide resolved

0xrusowsky reviewed Mar 31, 2026

View reviewed changes

crates/precompiles/src/account_keychain/mod.rs Outdated Show resolved Hide resolved

0xrusowsky reviewed Mar 31, 2026

View reviewed changes

crates/precompiles/src/account_keychain/mod.rs Show resolved Hide resolved

0xrusowsky reviewed Mar 31, 2026

View reviewed changes

crates/precompiles/src/account_keychain/mod.rs Show resolved Hide resolved

legion2002 force-pushed the tanishk/tip-1011-precompiles-exact branch 2 times, most recently from 9f1ed91 to 5434753 Compare March 31, 2026 10:10

0xrusowsky reviewed Mar 31, 2026

View reviewed changes

crates/precompiles/src/account_keychain/mod.rs Outdated Show resolved Hide resolved

0xrusowsky reviewed Mar 31, 2026

View reviewed changes

crates/precompiles/src/account_keychain/mod.rs Outdated Show resolved Hide resolved

fgimenez reviewed Mar 31, 2026

View reviewed changes

crates/precompiles/src/account_keychain/mod.rs Outdated Show resolved Hide resolved

crates/precompiles/src/account_keychain/mod.rs Outdated Show resolved Hide resolved

0xKitsune reviewed Mar 31, 2026

View reviewed changes

legion2002 force-pushed the tanishk/tip-1011-precompiles-exact branch from 5434753 to 42d8683 Compare March 31, 2026 19:04

legion2002 requested review from dankrad and danrobinson as code owners March 31, 2026 19:04

klkvr reviewed Apr 1, 2026

View reviewed changes

0xKitsune reviewed Apr 1, 2026

View reviewed changes

fgimenez approved these changes Apr 1, 2026

View reviewed changes

crates/precompiles/src/account_keychain/mod.rs Outdated Show resolved Hide resolved

crates/precompiles/src/account_keychain/mod.rs Show resolved Hide resolved

0xrusowsky reviewed Apr 1, 2026

View reviewed changes

crates/precompiles/src/account_keychain/mod.rs Outdated Show resolved Hide resolved

0xrusowsky reviewed Apr 1, 2026

View reviewed changes

crates/precompiles/src/account_keychain/mod.rs Show resolved Hide resolved

klkvr reviewed Apr 1, 2026

View reviewed changes

legion2002 added 19 commits April 1, 2026 18:28

feat(precompiles): implement TIP-1011 restrictions

a58291c

Amp-Thread-ID: https://ampcode.com/threads/T-019d4307-f847-7661-82ac-a8e22e140693

fix(precompiles): reject duplicate T3 token limits

6856273

Amp-Thread-ID: https://ampcode.com/threads/T-019d4307-f847-7661-82ac-a8e22e140693

refactor(precompiles): simplify keychain scope state

a40d868

Amp-Thread-ID: https://ampcode.com/threads/T-019d43c1-3d1f-701f-8475-5c0be39a765d

fix(precompiles): address simple keychain review nits

68250c1

Amp-Thread-ID: https://ampcode.com/threads/T-019d453b-5da2-76ec-b058-840ce67c1350

fix(precompiles): clarify legacy authorizeKey upgrade

bac50c1

Amp-Thread-ID: https://ampcode.com/threads/T-019d453b-5da2-76ec-b058-840ce67c1350

fix(tx-pool): use effective periodic key limits

9c2a81a

Amp-Thread-ID: https://ampcode.com/threads/T-019d453b-5da2-76ec-b058-840ce67c1350

fix(precompiles): preserve legacy key limit slot access

1e2d814

Amp-Thread-ID: https://ampcode.com/threads/T-019d453b-5da2-76ec-b058-840ce67c1350

refactor(precompiles): simplify account keychain call scopes

bdbf834

Amp-Thread-ID: https://ampcode.com/threads/T-019d4572-ffe2-73dc-b971-0323631b9260

perf(precompiles): narrow keychain limit reads

dbcc34e

Amp-Thread-ID: https://ampcode.com/threads/T-019d4572-ffe2-73dc-b971-0323631b9260

refactor(precompiles): simplify keychain scope updates

9cb6715

Amp-Thread-ID: https://ampcode.com/threads/T-019d4572-ffe2-73dc-b971-0323631b9260

docs(precompiles): clarify spending limit state layout

d201441

Amp-Thread-ID: https://ampcode.com/threads/T-019d43c1-3d1f-701f-8475-5c0be39a765d

style(precompiles): reorder account keychain storage types

7c3cdc1

Amp-Thread-ID: https://ampcode.com/threads/T-019d43c1-3d1f-701f-8475-5c0be39a765d

docs(precompiles): clarify account keychain scope helpers

06005af

Amp-Thread-ID: https://ampcode.com/threads/T-019d47f8-a4c0-71af-8427-68314207dfed

fix(precompiles): make getAllowedCalls mode explicit

09a3e02

Amp-Thread-ID: https://ampcode.com/threads/T-019d47f4-6e44-703e-b211-925ca1c63fd6

refactor(precompiles): simplify call scope storage

474ef9a

Amp-Thread-ID: https://ampcode.com/threads/T-019d47f4-6e44-703e-b211-925ca1c63fd6

fix(precompiles): zero remaining for inactive keys

1b48182

Amp-Thread-ID: https://ampcode.com/threads/T-019d47f8-a4c0-71af-8427-68314207dfed

refactor(account-keychain): address review cleanup

b6119a1

Amp-Thread-ID: https://ampcode.com/threads/T-019d486b-4380-776b-b8c1-c658270e0655

fix(precompiles): preserve keychain limit semantics

87485fe

Amp-Thread-ID: https://ampcode.com/threads/T-019d48d0-100a-75df-a9ba-6836b811180e

refactor(precompiles): simplify keychain scope checks

e51b9cf

Amp-Thread-ID: https://ampcode.com/threads/T-019d48d0-100a-75df-a9ba-6836b811180e

legion2002 force-pushed the tanishk/tip-1011-precompiles-exact branch from a29e4af to e51b9cf Compare April 1, 2026 13:01

legion2002 requested a review from rakita as a code owner April 1, 2026 13:11

legion2002 merged commit d604c15 into tanishk/tip-1011-primitives-exact Apr 1, 2026
17 of 28 checks passed

legion2002 deleted the tanishk/tip-1011-precompiles-exact branch April 1, 2026 13:12

		let mut limit_state = self.spending_limits[limit_key][token].read()?;
		limit_state.remaining = limit_state.remaining.saturating_add(amount);

Conversation

legion2002 commented Mar 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Stack Context

What This PR Does

How To Review

Note

Uh oh!

github-actions bot commented Mar 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

⚠️ Changelog not found.

Uh oh!

chatgpt-codex-connector bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

legion2002 Mar 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

fgimenez left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

legion2002 commented Mar 30, 2026 •

edited

Loading

github-actions bot commented Mar 30, 2026 •

edited

Loading

legion2002 Mar 31, 2026 •

edited

Loading