Profiles

Tags

All 18 tags: where each applies, its arguments, and whether it is core or experimental.

A tag gives one position of an interface a meaning. Twelve tags are core: the preregistered eval depends on them, so they are stable within v0. Six are experimental and may change. The tables below are checked against spec §5, the JSON Schema (profile/spec/profile-v0.schema.json, the args_* definitions) and the resolver's applicability checks (checks.mjs). Each tag links to the concept page that explains it.

A tag is one annotation: an address, the tag's name and its arguments. This one is from the ICRC-1 pack:

at

icrc1_transfer(0).amount

tag

amount

args

• decimals: { "from": "query:icrc1_decimals" }
• symbol: { "from": "query:icrc1_symbol" }

Value tags#

A value tag sits at a value address (method(i).path, method->(i).path or, in a canister profile, type:Decl.path; see Addresses). opt is transparent: a tag on fee : opt nat applies to the nat. A tag on a type it does not fit is EE_TAG_NOT_APPLICABLE; a value tag at a bare method name is EE_TAG_TARGET.

Dynamic values#

Integers that can exceed 2⁵³ (amounts, bounds) are decimal strings, such as "100000000". The resolver leaves dynamic values unresolved in the resolved form: resolving them needs the network, so it is the consumer's job (Profile and resolved form).

Words for extreme values#

threshold, message and labels change what a value displays as, never what it is: input is unchanged, a number at the threshold still parses to that number, and a word is never parsed back (spec §5.3, D-054 for amount, D-055 for timestamp). On a timestamp a label is checked first, then the threshold, then the time. A timestamp shown as words is never read as a time: it is not localized, and in an ICRC-21 fields message it is Text, never TimestampSeconds; an amount at or above its threshold is Text, never a TokenAmount. The words exist for deadlines whose extreme values are not dates: uint256 max for "never", which is otherwise out of range, and Permit2's expiration 0 for "this block only", which otherwise reads as 1970. From the Permit2 profile:

at

PermitSingle(0).details.expiration

tag

timestamp

args

• unit: "s"
• epoch: "unix"
• threshold: "281474976710655"
• message: "Never"
• labels: { "0": "Only in the block it is used" }

An amount in the token a field names#

experimental EVM only (spec §15.9). amount.token is a relative path from the argument to an address field of the same argument whose path up to its last [] is the amount's own: the token is in the same array element as the amount, or outside every array ("token": "details[].token" for details[].amount). decimals and symbol are not given (the schema refuses them): they are that token's decimals() and symbol(), which the consumer reads and passes per token address (tokens: { "0xA0b8…eB48": { "decimals": 6, "symbol": "USDC" } }); the libraries do no I/O. Without an entry there is no text (EE_REF_UNRESOLVED; §12 rule 10), never a number read in the wrong decimals. A token's symbol() is its own claim, so its address is always shown beside it. A path that breaks these rules is EE_TOKEN_PATH, and so is token on a Candid service, whose ledger a field cannot name yet (open OQ-6, on Open questions). token works on functions too.

at

PermitBatch(0).details[].amount

tag

amount

args

• token: "details[].token"
• threshold: "1461501637330902918203684832716283019655932542975"

Method tags#

A method tag sits at a bare method name. intent and effect may also sit at a case address, an argument address whose last step selects a case of a variant (propose(0).Transfer, D-053); a result address, a type: address or a path through [] is EE_TAG_TARGET, and two tagged cases one value can take both are EE_CASE_OVERLAP.

Defaults and bounds#

What a call grants#

Spec §5.3, D-056. An effect of kind transfer or approve may carry grant: who may take tokens because of the call or the signature, which token, how many and until when, so that a consumer can compare a request with terms the person confirmed (Confirm terms for a task). Its values are relpaths into the method's arguments, written as an intent template's placeholders are (§6). From the ICRC-2 pack:

at

icrc2_approve

tag

effect

args

• kind: "approve"
• irreversible: false
• grant: { "spender": "spender", "amount": "amount", "ends": ["expires_at"] }

• spender, to and amount are in every call: neither optional nor inside a case of a variant, and no position of a grant is inside one.
• No position steps into []: a grant covers one token, so a request that grants several (Permit2's PermitBatch) has none in v0.
• The token is the one the amount tag names (token, §15.9), else the contract or canister the call is for.
• A deadline that bounds only when a signature may be used is not an end of what it grants: EIP-2612's deadline and DAI's expiry set allowances that never end, so neither is in ends.
• The amount, timestamp and account tags a grant needs may come from another profile of the merge: the resolver checks the grant against the merged tags.

A grant on another kind, on a case effect (§5.2), or whose positions break these rules is EE_GRANT. A pack applied to a service where its grant does not hold keeps its effect and loses the grant (II_PACK_ANNOTATION_SKIPPED): dropping the effect would leave a transfer or approve with the default effect. A grant is the author's claim, like any effect (§11.1). The grants the standard packs carry are on Standard packs.

Tags on an EVM contract#

An ABI is read as the graph a .did compiles to, so the same tags apply, with these types (spec §15.4):

The native value a payable function receives has no position yet (open O2, on Open questions).

Tags on EIP-712 messages#

experimental Spec §15.9, D-055. A contract profile or an EVM pack may bind EIP-712 struct types in binds.eip712.types (Profile and resolved form). A message is a type the same document tags with intent at its bare name; its struct is argument 0, as a function's parameters are, so its members are addressed like a function's:

at

PermitSingle

tag

intent

args

• title: "Permit2: allow token spending"
• template: "Let {spender} spend up to {details.amount}. Allowance expires: {details.expiration}. Signature expires: {sigDeadline}."

A message may not share its name with a function, and two profiles may not give one type name different members (the later profile is invalid): each is EE_EIP712. A signing request matches a message by its type hash, never by its name: DAI's Permit and EIP-2612's share a name and not a hash. The standard messages are on Standard packs.

A message's grant#

Spec §15.9, D-056. A message's grant names its positions as its template does, from the struct. Permit2's PermitSingle:

at

PermitSingle

tag

effect

args

• kind: "approve"
• irreversible: false
• grant: { "spender": "spender", "amount": "details.amount", "ends": ["details.expiration", "sigDeadline"] }

fact (Uniswap permit2 at main, read 2026-10-30, src/libraries/Allowance.sol, as spec §15.9 records) An expiration of 0 is stored as the time of the block the permit is used in, and that block may come as late as sigDeadline; the latest of the two is the end, so 0 needs no rule of its own. The token is the one amount.token names (details.token), not the verifying contract.

Where to read more#

Edit this page on GitHub