Skip to content

Conversation

@Jesse-Sawa
Copy link
Member

@Jesse-Sawa Jesse-Sawa commented Jan 6, 2026

Problem

Most teams using Predicate only need simple WHO-based access control (KYC, allowlists, time restrictions), but today they're forced to encode function signatures and handle parameters they don't actually use.

Solution

Split into two implementations:

  • BasicPredicateClient: For the majority of use cases that only validate WHO can call. No encoding onchain needed.
  • AdvancedPredicateClient: For complex policies that validate WHAT function, HOW MUCH value, or specific parameters.

Decision guide: "Do I need different rules based on WHAT users are doing, or just WHO is doing it?"

  • Just WHO → Basic
  • WHAT/HOW MUCH → Advanced

Note: to simplify the entire flow, we will need to modify the attestation API to ignore the data and msg_value fields


Note

Introduces a simplified client for common WHO-only policies and updates examples and docs to clarify integration choices.

  • Adds BasicPredicateClient mixin implementing WHO-based authorization only: ERC-7201 storage, PredicateRegistryUpdated/PredicatePolicyIDUpdated events, and _authorizeTransaction using canonical zero msgValue and empty encodedSigAndArgs
  • New inheritance examples: BasicVault (no encoding; sender-only validation) and AdvancedVault (function/value/parameter-aware validation using encoded data and optional msg.value)
  • README Quick Start overhaul: selection guide between BasicPredicateClient and PredicateClient, concise examples, and decision matrix; links to src/examples/inheritance/

Written by Cursor Bugbot for commit 2e71ceb. This will update automatically on new commits. Configure here.

- Created BasicPredicateClient for simple policies (no function/value validation)
- Created AdvancedPredicateClient for complex policies (full function/value support)
- Added BasicVault example demonstrating simplified integration
- Added AdvancedVault example showing function-specific and value-based rules
- Updated README with clear decision guide for choosing implementations
- Maintained existing PredicateClient unchanged (audited code preserved)
- All existing tests pass without modification
@openzeppelin-code
Copy link

openzeppelin-code bot commented Jan 6, 2026

Adds Basic and Advanced PredicateClient implementations

Generated at commit: 2e71ceb18397f37a577c9633fd1c4eb005728eaf

🚨 Report Summary

Severity Level Results
Contracts Critical
High
Medium
Low
Note
Total
1
0
0
4
23
28
Dependencies Critical
High
Medium
Low
Note
Total
0
0
0
0
0
0

For more details view the full report in OpenZeppelin Code Inspector

- Reduced both vault examples to minimal code needed to demonstrate concepts
- BasicVault: Shows simple WHO-based authorization with no encoding
- AdvancedVault: Shows function-specific and value-based authorization
- Added clear documentation about required setPolicyID/setRegistry implementations
- Noted that business logic contracts must implement access control for setters
- Clarified that getPolicyID/getRegistry are inherited and exposed
Added clear guidance: 'Do I need to enforce different rules based on WHAT users are doing, or just WHO is doing it?'
This helps developers quickly determine which PredicateClient implementation to use.
Copy link

@cursor cursor bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This PR is being reviewed by Cursor Bugbot

Details

Your team is on the Bugbot Free tier. On this plan, Bugbot will review limited PRs each billing cycle for each member of your team.

To receive Bugbot reviews on all of your PRs, visit the Cursor dashboard to activate Pro and start your 14-day free trial.

balances[msg.sender] += msg.value;
emit Deposit(msg.sender, msg.value);
// Lock logic would go here
}
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missing _executeLock call after authorization in depositAndLock

Low Severity

The depositAndLock function encodes and authorizes a call to _executeLock(address,uint256,uint256) but never actually calls _executeLock. After authorization, it only performs a regular deposit by updating balances and emitting a Deposit event. This breaks the pattern established by other functions like withdraw, withdrawTo, and transfer, which all call their corresponding internal execution functions after authorization. The _lockPeriod parameter is completely ignored in the actual execution, making the function misleading as example code for developers implementing lock functionality.

Fix in Cursor Fix in Web

- Added BasicPredicateClient for WHO-based authorization only
- Added BasicVault example in inheritance folder (simplified authorization)
- Added AdvancedVault example in inheritance folder (uses existing PredicateClient)
- Updated README with decision guide: 'Do I need different rules based on WHAT users are doing, or just WHO?'
- Removed duplicate AdvancedPredicateClient (use existing PredicateClient instead)
- All examples now in src/examples/inheritance/ folder
@Jesse-Sawa Jesse-Sawa changed the title Adds Basic and Advanced PredicateClient implementations Adds a Basic PredicateClient implementation Jan 17, 2026
@Jesse-Sawa
Copy link
Member Author

Wondering if we should rename PredicateClient to AdvancedPredicateClient

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants