NEP-641: Offchain Authorizations for Smart Contracts

[frol]

Rendered NEP Markdown

It is open for discussion and we collaborate with DefuseLabs team on this.

---

For painting the picture of how this all fits together, you can go to https://trezu.app and use EVM wallets sign in flow (the implementation there is based on the older draft of the NEP, but I still find it helpful to paint the overall picture).

Sign in to Trezu requires "sign message" from the account owner, but EVM wallet is represented by a wallet contract on NEAR, so it cannot use NEAR's NEP-413 to sign message, as there are no access keys.

Trezu uses the signed message to issue JWT token to access the backend APIs (e.g. get the address book and history of confidential transactions).

[Copilot]

Pull request overview

Adds a new standards-track NEP (NEP-641) specifying a w_auth_resolve view-function convention for on-chain verification of off-chain authorizations, including recursive resolution for composite wallets (e.g., multisigs) and a NEP-413 fallback for regular accounts.

Changes:

• Introduces the NEP-641 specification for off-chain authorization resolution via w_auth_resolve.
• Defines the wire types/JSON format, normative semantics (purpose/recipient binding, payload equality), and a caller-side recursive resolution algorithm.
• Documents reference flows and security considerations for replay/downgrade/state-drift scenarios.

---

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

[frol]

The use-cases that this NEP would enable are:

1. Sign in into a dApp with a proof of account ownership - e.g. Trezu allows to view the private address book (stored on Trezu backend) - PROVE_OWNERSHIP purpose
2. Approve confidential swap intents with passkey/metamask/... - sign off-chain message and submit it to the confidential API - APPROVE_OFFCHAIN_ACTION purpose

[frol]

This NEP is already implemented in the v0 of wallet contract for EIP-712 (Ethereum signMessage): near/intents#256 and on the client side it is integrated into NEAR Connect: azbang/near-connect#96, and it is live on https://trezu.org

[frol]

One more consideration that I want to bring up - will w_resolve_auth be compatible with NEAR MPC? I need to model it before concluding this NEP.

[frol]

This NEP is already implemented for Wallet Contracts and they are live in production on Trezu:

• feat(wallet): NEP-641 w_resolve_auth off-chain authorization resolution intents#319 (up-to-date implementation)
• feat(wallet): eip712 variant intents#256 (slightly outdated, so needs to be updated)

Thus, this NEP is now ready for review.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Suppressed comments (3)

neps/nep-0641.md:116

• The stale-state guarantee conflicts with the recommendation to backdate timestamps by about 60 seconds. A signature created now can still be resolved against a block from the preceding minute, so a key or member revoked during that window may remain valid. Either use the actual signing time and wait for a sufficiently recent block, or explicitly weaken the guarantee to “not before the declared timestamp” and document the exposure window.

Contracts reject messages whose `timestamp` is later than the current block timestamp. A freshly-signed authorization therefore cannot be resolved against chain state from *before* signing — where a revoked key, disabled extension, or removed member was still active — whether by a malicious caller pinning an old block or by a lagging RPC. Contracts MAY add a TTL. Clients set the timestamp ~60s early to absorb clock skew and block-time lag.

</details>

neps/nep-0641.md:384

• The sentence is truncated; “replay protecti” should be “replay protection.”

### Caller-side resolution algorithm

neps/nep-0641.md:309

• The cited near/intents reference implementation does not use this tagged representation: AccessKeySchema only has serde(rename_all = "snake_case"), so it serializes as {"nep413":{"callback_url":...}}, not the documented {"schema":"nep413","extra":...}. These formats are not interoperable; align the implementation or the normative wire format before presenting it as the reference.

    /// NEP-413 signing schema.
    Nep413 {

[mitinarseny]

Awesome! This NEP formalizes a unified and generic way for smart-contracts to resolve off-chain authorizations, paving a way for truly off-chain interactions, where keeping governance on-chain.

[frol]

As a Contract Standards working group member, I have a conflict of interest here, so I requested @mitinarseny to be the SME reviewer, and @graphite and @birchmd to act as working group approvers.

[graphite]

Thank you for the great NEP! between @frol's original work and @mitinarseny's review I literally have nothing to add here.

[birchmd]

I approve this NEP. Thanks for the great work @frol and @mitinarseny !

Defining an interface for off-chain services to authenticate users via their existing on-chain account abstractions makes it easier to develop such flows. And I like the design choices that are made in this proposal (e.g. opaque blobs, but with specific instances for common cases such as signatures).

The only downside from my perspective is that users will simply need to trust the off-chain service is implementing the standard correctly because there will not be any on-chain record of the authorization. But that is the nature of off-chain services, not really a flaw in the proposal itself.