Skip to content

feat: trusted relayer#1

Open
frolvanya wants to merge 7 commits intomainfrom
feat/trusted-relayer
Open

feat: trusted relayer#1
frolvanya wants to merge 7 commits intomainfrom
feat/trusted-relayer

Conversation

@frolvanya
Copy link
Contributor

@frolvanya frolvanya commented Mar 15, 2026

This pull request introduces a new "trusted relayer" framework for NEAR smart contracts, providing a procedural macro and supporting runtime logic for managing relayer roles, staking, and access control. The main changes include the addition of a new #[trusted_relayer] macro, core runtime logic for relayer management, and integration points for both the derive and runtime crates.

Trusted relayer macro and runtime support:

  • Added a new #[trusted_relayer] procedural macro in omni-utils-derive, allowing easy injection of relayer access control and management methods into contract impl blocks and methods. This macro supports configuration of manager/bypass roles and custom logic, and injects guard checks automatically. [1] [2]
  • Implemented the core trusted relayer runtime logic in omni-utils/src/trusted_relayer.rs, including:
    • The TrustedRelayer trait with default and overridable logic for checking relayer status.
    • Relayer staking, application, resignation, rejection, and configuration update methods.
    • Persistent storage for relayer state/config, and event emission for relayer actions.
  • Updated the main library exports to re-export the new macro and include the new module. [1] [2]

Integration and API enhancements:

  • The macro and runtime provide a full suite of NEAR-callable methods (e.g. apply_for_trusted_relayer, resign_trusted_relayer, get_relayer_config) and internal helpers for managing relayer lifecycle and querying relayer state. [1] [2]
  • Access control for relayer management actions is enforced via the macro, supporting both role-based and staking-based authorization.

These changes provide a robust foundation for relayer-based access control and staking in NEAR contracts, with ergonomic macro-based integration and extensible runtime logic.

Copy link

Copilot AI left a comment

Choose a reason for hiding this comment

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

Pull request overview

This PR introduces a “trusted relayer” mechanism for NEAR smart contracts in this workspace, including on-chain staking state/config management and a proc-macro to generate NEAR-callable wrappers and relayer gating.

Changes:

  • Add omni-utils::trusted_relayer module implementing relayer stake/apply/resign/reject/config logic.
  • Add #[trusted_relayer] proc-macro attribute to generate wrapper methods and inject relayer guards.
  • Add near-plugins dependency to support access-control annotations in the generated methods.

Reviewed changes

Copilot reviewed 6 out of 7 changed files in this pull request and generated 6 comments.

Show a summary per file
File Description
omni-utils/src/trusted_relayer.rs New trusted relayer storage, config, events, and internal trait methods for staking lifecycle.
omni-utils/src/lib.rs Re-export macro crate as macros and expose the trusted_relayer module.
omni-utils/Cargo.toml Adds near-plugins dependency to the utils crate.
omni-utils-derive/src/trusted_relayer.rs New proc-macro implementing #[trusted_relayer] on impl blocks and methods.
omni-utils-derive/src/lib.rs Exposes the new trusted_relayer proc-macro attribute.
Cargo.toml Adds workspace dependency on near-plugins (git tag).

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

You can also share your feedback on Copilot code review. Take the survey.

)
}

#[::near_plugins::access_control_any(roles(#(#manager_roles),*))]
Copy link

@kiseln kiseln Mar 18, 2026

Choose a reason for hiding this comment

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

I wonder if we want to separate a role for setting config and for rejecting relayer applications. This makes manager to powerful - it is basically equivalent to bypass role since it can fast track any relayer instantly by setting a minimal delay.

The setup I have in mind is:

  • relayer manager can only reject applications
  • admin can do that plus any other management operation

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Agree, added in f1e99f1

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.

3 participants