Profiles
Open questions
What is not settled yet in the profile spec and its EVM binding, and who owns each question.
This page mirrors profile/docs/open-questions.md
and the open items of the EVM binding, spec
§15.8 and, for
EIP-712 messages, §15.9. Ids and
owners are as written there. An owner is one of the project's workstreams (W0, W1, …); "Blocks" says what waits on
the answer. When a question is answered it moves to the answered list with its date and evidence, and a decision is
recorded when the answer changes the spec. Some questions name files of the project's working repository that are not
in this public copy (the eval's task review, status logs, proposals).
Open in the profile spec#
| ID | Question | Owner | Blocks |
|---|---|---|---|
| OQ-3 | open Quoted Candid method names ("foo-bar") in addresses. Proposed: "foo-bar"(0).x. Until then, method names must be identifier-shaped (Addresses). |
W1 | Rare interfaces |
| OQ-5 | open Doc-annotation namespace. Bare @amount(...) (readable) or a prefix such as @ca.amount(...) (no collisions with other conventions)? See Annotate a .did file. |
W0 | Doc-annotation compiler |
| OQ-6 | open Cross-canister refs, for example a DEX record holding amount plus the token's ledger principal in a sibling field. Planned for v1. Partly answered for EVM (spec §15.9, D-055): amount.token names the token by an address field of the same argument, and the consumer passes that token's decimals and symbol per address (An amount in the token a field names). A Candid amount whose ledger a field names, and refs to a contract no field names, stay open (EE_TOKEN_PATH on a Candid service). |
W0 | DeFi coverage |
| OQ-7 | open Third-party attestations for profiles (ERC-8176-like) and where a registry lives. Planned for v1. ERC-8176 itself attests ERC-7730 files, and its schema UID is reserved for them; the export of D-054 gives a reviewer the hash and the unsigned attestation of such a file. A profile attestation needs its own schema (phase 3 of the EVM proposal). | W0/W6 | Trust beyond the author's claim |
| OQ-8 | open Spending policies and budgets that let agents commit without per-call confirmation. Product layer (B3Pay?). | W6 | Unattended agents |
| OQ-9 | open ERC-7730 import for EVM ABIs. The export half is answered (spec §15.7, D-054): a profile of an EVM contract gives its ERC-7730 file and ERC-8176 descriptorHash. Import, as display-only profiles checked against ERC-8176 attestations, is phase 2. See EVM contracts. |
W6 | Cross-chain story |
| OQ-10 | open Should the resolved form carry resolved dynamic values with provenance (certified or not)? Today they stay as { "from": … } (Profile and resolved form). |
W1/W3 | Consent and tool rendering |
| OQ-11 | open Upstream: would imcp2 allow transfers through profile-typed, previewed calls? | W6 | Distribution |
| OQ-12 | open ICRC-21 for 18-decimal tokens: TokenAmount.amount is nat64. Propose a nat variant upstream, or always fall back to Text? |
W4/W6 | ckETH-class tokens |
| OQ-13 | open The practice-ledger symbols TKA, TKB and TKC are one letter apart and confuse device-class models: in the E4B probe, E4B chose ledger TKA for an approval on TKB three times in three. Renaming them would change the eval's tasks, a shared contract, and so needs the independent reviewer. W0 recommends renaming before the pilot. | W0 | The freeze (M2): independent reviewer, owner Behrad |
| OQ-14 | open Several phrasings per intent for device-class models. Each task has one phrasing, and the E4B probe shows that the ledger choice depends on the phrasing. Adding phrasings (for example a seeded list per task) changes the tasks and the scorer's expectations, and needs the independent reviewer. W0 recommends one phrasing in v0.6, with sensitivity as a later exploratory study. | W0 | The freeze (M2): independent reviewer, owner Behrad |
| OQ-16 | open How is Gemini 3.5 Flash-Lite pinned, and what does it think by default? Google publishes no dated snapshot for the stable code gemini-3.5-flash-lite. The preregistration needs an exact pin, so the plan is the stable code plus the modelVersion field of every response, recorded per run; to verify that the field is returned and stays constant across the pilot. Also to record the model's default thinking behavior (the thoughtsTokenCount of its replies when nothing is sent). Needs a key and one or two calls; no eval task. |
W2 | §13 pins; the first P-F runs of the model |
Answered#
| ID | Answer | Date | Evidence |
|---|---|---|---|
| OQ-1 | A public custom section, icp:public candid:profile, read with candid:service in one certified read_state (spec §8.1, D-048). The section holds the profile as UTF-8 JSON, an author canister profile bound to the interface the canister serves. A path the certificate shows absent means nothing is served; a path it neither holds nor rules out is an error, never absent. A query method is not proposed: its reply is not certified. See Serve a profile. |
2026-10-27 | The IC interface specification and its HTTPS interface; the resource limits (16 icp: sections, 1 MiB). fact Observed on PocketIC 16.0.0: a module given the section serves it byte for byte through @icp-sdk/core 6.1.0 readState, with the certificate verified; a canister without it shows the path absent; a private section is refused to a non-controller. |
| OQ-15 | Yes, the whole prompt. prompt_eval_count is the full prompt token count on every turn, cached or not. Above num_ctx, Ollama drops the oldest messages silently and reports the size of what is left, so the eval's gate G3 also counts a run whose per-turn count stopped growing as over the line. |
2026-10-10 | Ollama 0.40.2 with three gemma4 models, a three-turn conversation run cold, warm and on a fully cached repeat. |
| OQ-4 | An occurrence path is a sequence of steps from type:<Decl> or actor.methods[i], then .function.args[j] / .function.results[j], then .type, .fields[k], .inner and .args[j] / .results[j] steps. To map a doc on an inline actor field to a method address: match the path's method prefix, let the next step pick (j) or ->(j), then walk the Contract writing .label per field step, nothing for opt, [] for vec. |
2026-10-09 | Real output of the native compiler built from candid-core main (acabe0f). At the time, @candid-core/cli 0.2.0 built SourceInfo and dropped it; the resolver now reads doc attributes through didToDocAttributes of @candid-core/cli 0.4.0. |
| OQ-2 | Yes. Result variants may be wider than the pack fragment; extra cases fall back to outcome.default, else fail. Spec §7, D-019. |
2026-10-08 | Candid subtyping: a variant with more cases is a supertype, so a ledger that adds an error case would stop matching. Both ICRC packs set default: "fail". |
| OQ-0 | @candid-core/schema 0.3.0 loads Contract documents (./contract export), and @candid-core/cli 0.2.0 compiles .did to a Contract envelope in wasm, including field names. |
2026-10-08 | npm package metadata; the envelope observed by the validator. |
Open items of the EVM binding#
Spec §15.8, for the experimental EVM binding (EVM contracts), and §15.9 for its EIP-712 messages (O9 to O14). These have no owner column in the spec.
| Item | Status | Question |
|---|---|---|
| O1 | open | Overloaded function names (ERC-721 safeTransferFrom). Candidate: name@0x<selector>. Until then an overloaded name is EE_ABI. |
| O2 | open | The native value of a payable call as a position, with the chain's native decimals and symbol. Until then consent text refuses a payable function. |
| O3 | open | Whether a transfer recipient typed in one case (no checksum) is accepted everywhere. |
| O4 | open | Whether EVM packs should apply only to deployments a consumer lists. Meanwhile the consent text shows the contract's address (spec §11 item 9). |
| O5 | settled | The resolved form carries abi beside candid, with a top-level chain (§15.5). |
| O6 | settled | The export refuses what it cannot express (§15.7, EE_EXPORT). |
| O7 | open | fact (ERC-7730): a wallet that finds no ticker "SHOULD display the raw value instead with an 'Unknown token' warning", where spec §12 rule 10 produces no message. An exported file cannot make a wallet refuse. |
| O8 | assumption | A wallet reads metadata.token as the token at @.to. ERC-7730 calls it the token "exported by this format"; the export writes it only when the caller says the contract is that token. |
| O9 | open | Permit2 witness messages (PermitWitnessTransferFrom with a protocol's own witness type). Each needs its own profile; until then a request with a witness matches nothing and gets no text. |
| O10 | open | Permit2's deployments beyond chains 1 and 42161: its address is the same on many chains, and each is added after checking Uniswap's list, never assumed. |
| O11 | open | Domains with a salt, and contracts whose domain name or version changes after deployment: refused for now (EE_DOMAIN for a salt). |
| O12 | open | DAI's allowed bool reads through its template ("to all of it if allowed is true, to none if false"); a case-like reading of true and false would need D-053 for bool. |
| O13 | open | The signer against an owner or holder member: whether the text should say so, or refuse, when they differ. The consent function does not take the signer yet. |
| O14 | open | Permits that differ from EIP-2612 by a member match nothing and get no text; a pack per variant is added only when one is seen. |
Assumptions the spec states#
Spec §14 lists three assumptions next to its open questions:
- assumption Typed tools built from these tags reduce agent value errors. This is what the preregistered eval tests.
- assumption Doc-annotation ergonomics are good enough for authors.
- assumption Candid subtyping, relaxed for result variants, is the right pack-match rule.