Architecture

The Policy Engine is embedded in every Silent Network MPC node. It is not a separate, centralized service that approves a request before handing it to the signing network. Instead, every participating node authenticates the request, verifies the integrity of its locally stored records, and evaluates the key-bound policy before participating in MPC signing.

End-to-end signing and policy evaluation

A signing request can be authorized directly by the key owner or by a delegatee holding an ephemeral session key. The Wallet Provider authenticates the application request and sends it to a selected MPC node.

Each node independently performs the following checks inside its TEE:

1. Authenticate the request and derive its issuer.
2. Load the wallet records associated with key_id and verify their MAC integrity.
3. Decode the transaction and evaluate the policy rules matching the issuer and transaction type.
4. Participate in the MPC signing protocol only when the policy result is ALLOW.

A node that rejects the request does not participate in MPC signing. A signature is produced only if the required MPC participants independently authorize the request and successfully complete the signing protocol.

How a node determines the issuer

An issuer identifies which authenticated actor sent the request. The Policy Engine represents an issuer using <type>:<issuer_id>, for example:

UserId:alice_passkey
SessionKeyId:trading_agent_session

The issuer is needed to determine which policy rules apply to the request. A node first authenticates the supplied credential, derives its issuer, and considers only rules whose issuer field matches it. The matching rule's conditions then determine whether the requested transaction is allowed.

Each node maps the user credentials user_cred to an issuer as follows:

Request authentication	Derived issuer
EOA, Passkey, or JWT	UserId derived from user_cred
Ephemeral	SessionKeyId derived from user_cred
Missing or unsupported user_cred	UserId containing the Wallet Provider API key

The identifier is therefore selected from the authenticated credential, not from transaction data supplied to the policy.

Policy lifecycle and delegation

Delegation connects a registered session credential to policy rules through its SessionKeyId.

1. Establish the delegatee's session identity

Register an ephemeral credential and expiry for the wallet through an owner-authenticated request. In this example, session ID is trading_agent_session.

2. Construct a policy rule for the delegatee

Use the registered session ID as the rule issuer:

{
  "version": "1.0",
  "description": "Delegate trading-agent signing",
  "rules": [
    {
      "issuer": [{
        "type": "SessionKeyId",
        "id": "trading_agent_session"
      }],
      "action": "allow",
      "logic": "and",
      "chain_type": "ethereum",
      "conditions": [
        {
          "transaction_type": "nativeTransfer",
          "transaction_attr": "receiver",
          "operator": "in",
          "value": ["0xApprovedRecipient..."]
        },
        {
          "transaction_type": "nativeTransfer",
          "transaction_attr": "nativeValue",
          "operator": "lte",
          "value": "100000000000000000"
        }
      ]
    }
  ]
}

Only requests deriving the same issuer can match this rule.

3. Attach the policy to the wallet key

Attach the policy during wallet creation, or update the policy for an existing key_id. Each node authenticates the owner request, validates the policy, and stores it with its MAC.

4. Authorize a delegatee's signing request

The delegatee submits the transaction with user_cred.method = Ephemeral, the session credential ID, and its authentication signature. Each node authenticates the request and derives:

Issuer { issuer_type: IssuerType::SessionKeyId, id: "trading_agent_session" }

The node selects rules matching that issuer, evaluates their transaction conditions, and participates in MPC signing only when the result is ALLOW.

Flow summary

Loading Diagram...

For request formats and lifecycle operations, see Policy Management.