Policy Scope Basics

Policy scope is simpler than it sounds.

When a script sends an action to Beav3r, three things need to line up:

• the API key must belong to the active project
• the policy rule must live in that same project
• the action name and field names must match the script payload

If those match, Beav3r applies the intended rule.

If the values do not match, Beav3r will not guess the intended rule.

The simple model

Think about it like this:

1. Create a project.
2. Create an API key from that project.
3. Add a rule in that project.
4. Send an action using that API key.

Beav3r uses the API key to figure out which project’s rules it should read.

So if the key belongs to Treasury, Beav3r will evaluate the rules saved in Treasury.

What needs to match

Here is a clear example.

If a script sends this:

{
  actionType: "payments.send_usdt",
  payload: {
    amount: 25,
    recipient: "0x1111111111111111111111111111111111111111"
  }
}

then the rule in the dashboard should use:

• action type: payments.send_usdt
• condition field: amount
• operator: is greater than
• value: 10

That means:

• 25 is greater than 10
• the request should go to approval

To keep the policy page understandable, use:

• technical action key: payments.send_usdt
• user-facing label: Send USDT
• condition field: amount
• operator: is greater than
• value: 10

That produces one technical matcher and one human label:

• the matcher decides when the rule applies
• the label is what people should recognize in the policy page and approval flow

If the rule instead says transfer, send_usdt, or uses a different field name, it will not match.

What users usually expect

Most people expect Beav3r to understand that these are “basically the same”:

• payments.send_usdt
• transfer
• send_usdt

Beav3r does not treat them as the same action.

It matches the exact action name in the request.

The same applies to fields:

• amount is not the same as value
• recipient is not the same as destination

What does not matter here

These do not decide which rule Beav3r will use:

• the local file name
• the script name
• the dashboard tab last viewed
• NODE_ENV

The main thing that decides project scope is the API key used for the request.

A practical checklist

Before testing a rule, check these:

1. Is this the API key from the project I am looking at in the dashboard?
2. Is the rule saved in that same project?
3. Does the rule use the exact same actionType as my script?
4. Do the condition fields use the exact same payload field names?
5. Does the rule include a user-facing label that matches the intended reviewer-facing action?
6. Did I save the rule after editing it?

Common mistakes

• Creating the rule in one project and using an API key from another.
• Sending payments.send_usdt while the rule still uses transfer.
• Using amount in the rule but a different field name in the payload.
• Assuming a project ID in a local script changes policy scope by itself.

What success looks like

When everything matches:

• Beav3r loads the rules from the correct project
• the action matches the rule
• the request is allowed, denied, or sent to approval exactly as the policy says
• the policy page stays readable because the action label is human, while the matcher stays exact

Example flow

Project: Treasury

API key:

• created from Treasury

Rule:

• action type: payments.send_usdt
• user-facing label: Send USDT
• condition: amount > 10
• effect: Require approval

Script:

await client.guardAndWait({
  actionType: "payments.send_usdt",
  payload: {
    amount: 25
  }
});

Expected result:

• the request appears in Inbox
• a signer approves or rejects it
• the SDK call resolves with the final result