Skip to main content

Grammar

The grammar has been designed for flexibility and expressiveness. We currently support the following operations:

Keywords

Keywords are reserved words that are dynamically interchanged for real values at evaluation time. Each field supports a different set of keywords.

Consensus

Condition

Types

The language is strongly typed which makes policies easy to author and maintain.

Primitive

Struct

**NOTE: The ContractArgument type, used in documentation for ABI an IDL arguments represents an enum indicating this type could be any one of the string, number, array or struct types listed in our Primitives section.

Nested Structs

Activity Breakdown

Appendix

Root quorum activities

There are a select few activities that are not governed by policies, but rather by an organization’s root quorum. These activities are: ACTIVITY\_TYPE\_UPDATE\_ROOT\_QUORUM, ACTIVITY\_TYPE\_SET\_ORGANIZATION\_FEATURE, ACTIVITY\_TYPE\_REMOVE\_ORGANIZATION\_FEATURE. For example, if a policy is added that allows a specific non-root user to perform ACTIVITY\_TYPE\_SET\_ORGANIZATION\_FEATURE activities, these requests will still fail as they are subject specifically to root quorum.

Ethereum

Our Ethereum policy language (accessible via eth.tx) allows for the granular governance of signing Ethereum (EVM-compatible) transactions. Our policy engine exposes a fairly standard set of properties belonging to a transaction. See the Ethereum policy examples for sample scenarios.

Solana

Similarly, our Solana policy language (accessible via solana.tx) allows for control over signing Solana transactions. Note that there are some fundamental differences between the architecture of the two types of transactions, hence the resulting differences in policy structure. Notably, within our policy engine, a Solana transaction contains a list of Transfers, currently corresponding to native SOL transfers. Each transfer within a transaction is considered a separate entity. Here are some approaches you might take to govern native SOL transfers:
  • All transfers need to match the policy condition. Useful for allowlists (example)
  • Just one transfer needs to match the policy condition. Useful for blocklists (example)
  • Only match if there is a single transfer in the transaction, and that transfer meets the criteria (example). This is the most secure approach, and thus most restrictive.
See the Solana policy examples for sample scenarios.

Tron

Our Tron policy language (accessible via tron.tx) allows for policy control over signing Tron transactions. Our policy language supports the standard fields in a Tron transaction: https://developers.tron.network/docs/tron-protocol-transaction. To reference a Contract within a Transaction you should use tron.tx.contract[0].field_name in your policy where field_name is some field of the contract used in your transaction. While Tron only currently supports 1 contract per transaction this could change in the future, and were ready for it if it does! The policy engine currently supports the following Tron contract types:
  • TransferContract (TRX transfers)
  • TriggerSmartContract (Smart contract, including, but not limited to TRC-20, invocations)
See the Tron policy examples for sample scenarios.