Share Logs
API Name: Kira2
Model: gpt-4.1-2025-04-142025-09-17 05:25:01
Context:
[
{
"role": "user",
"content": "\\item \\emph{Access follows provenance.} A unit of value is usable by $u$ only if there exists a custody chain in $\\mathcal{H}$ from an external deposit to $u$. Informally, $\\textsf{Allow}(u,\\alpha,x)\\quad\\text{means balance } x \\text{ is reachable for } u \\text{ via provenance in } \\mathcal{H}$. This implies \\emph{consistency}: for every $\\alpha$, the total internal balance equals the on-chain balance at $\\pk$, i.e., $\\sum_{u\\in\\mathcal{U}}\\mathcal{L}[u][\\alpha]=B_{\\mathrm{on}}(\\alpha)$. Incoming deposits $(\\alpha,x,m)\\in\\mathcal{I}$ are ``wrapped'' and must be explicitly claimed before use by the sender address.\n\n这边Allow之后太长了 能重写了一下让它能正常换行吗"
},
{
"role": "assistant",
"content": "当然可以！你可以把 `\\textsf{Allow}(u,\\alpha,x)\\quad\\text{means balance } x \\text{ is reachable for } u \\text{ via provenance in } \\mathcal{H}.` 这句话重写成便于换行的形式。这里有几种 LaTeX 的写法，推荐用 `\\parbox`，`\\begin{tabular}` 或 `align` 环境来控制换行。\n\n### 方案1：用 `\\parbox` 控制宽度自动换行\n\n```latex\n\\item \\emph{Access follows provenance.} A unit of value is usable by $u$ only if there exists a custody chain in $\\mathcal{H}$ from an external deposit to $u$. Informally,\n\\[\n\\textsf{Allow}(u,\\alpha,x)\\quad\n\\parbox[t]{.7\\linewidth}{means balance $x$ is reachable for $u$ via provenance in $\\mathcal{H}$.}\n\\]\nThis implies \\emph{consistency}: for every $\\alpha$, the total internal balance equals the on-chain balance at $\\pk$, i.e., $\\sum_{u\\in\\mathcal{U}}\\mathcal{L}[u][\\alpha]=B_{\\mathrm{on}}(\\alpha)$. Incoming deposits $(\\alpha,x,m)\\in\\mathcal{I}$ are ``wrapped'' and must be explicitly claimed before use by the sender address.\n```\n\n### 方案2：用 `align` 环境让公式自动换行\n\n```latex\n\\item \\emph{Access follows provenance.} A unit of value is usable by $u$ only if there exists a custody chain in $\\mathcal{H}$ from an external deposit to $u$. Informally,\n\\begin{align*}\n\\textsf{Allow}(u,\\alpha,x)\\quad &\\text{means balance $x$ is reachable for $u$} \\\\\n&\\text{via provenance in } \\mathcal{H}.\n\\end{align*}\nThis implies \\emph{consistency}: for every $\\alpha$, the total internal balance equals the on-chain balance at $\\pk$, i.e., $\\sum_{u\\in\\mathcal{U}}\\mathcal{L}[u][\\alpha]=B_{\\mathrm{on}}(\\alpha)$. Incoming deposits $(\\alpha,x,m)\\in\\mathcal{I}$ are ``wrapped'' and must be explicitly claimed before use by the sender address.\n```\n\n### 方案3：用 `tabular` 环境\n\n```latex\n\\item \\emph{Access follows provenance.} A unit of value is usable by $u$ only if there exists a custody chain in $\\mathcal{H}$ from an external deposit to $u$. Informally,\n\\[\n\\begin{tabular}{@{}l}\n $\\textsf{Allow}(u,\\alpha,x)$ \\quad means balance $x$ is reachable for $u$ \\\\\n via provenance in $\\mathcal{H}$.\n\\end{tabular}\n\\]\nThis implies \\emph{consistency}: for every $\\alpha$, the total internal balance equals the on-chain balance at $\\pk$, i.e., $\\sum_{u\\in\\mathcal{U}}\\mathcal{L}[u][\\alpha]=B_{\\mathrm{on}}(\\alpha)$. Incoming deposits $(\\alpha,x,m)\\in\\mathcal{I}$ are ``wrapped'' and must be explicitly claimed before use by the sender address.\n```\n\n---\n\n**推荐**：如果你想让公式和正文排版更美观，建议用 **方案2** 的 `align*` 环境。这样数学环境会自动对齐，长句也不会溢出。\n\n---\n\n**效果图**（方案2）：\n\n```latex\n\\item \\emph{Access follows provenance.} A unit of value is usable by $u$ only if there exists a custody chain in $\\mathcal{H}$ from an external deposit to $u$. Informally,\n\\begin{align*}\n\\textsf{Allow}(u,\\alpha,x)\\quad &\\text{means balance $x$ is reachable for $u$} \\\\\n&\\text{via provenance in } \\mathcal{H}.\n\\end{align*}\nThis implies \\emph{consistency}: for every $\\alpha$, the total internal balance equals the on-chain balance at $\\pk$, i.e., $\\sum_{u\\in\\mathcal{U}}\\mathcal{L}[u][\\alpha]=B_{\\mathrm{on}}(\\alpha)$. Incoming deposits $(\\alpha,x,m)\\in\\mathcal{I}$ are ``wrapped'' and must be explicitly claimed before use by the sender address.\n```\n\n这样就能正常换行了！"
},
{
"role": "user",
"content": "论文怎么用vspace压缩篇幅"
},
{
"role": "assistant",
"content": "在写论文时，`\\vspace` 可以用来**手动调整段落或环境之间的垂直间距**，以压缩（或扩展）篇幅。不过，**过度使用 `\\vspace` 可能影响论文的排版美观和可读性**，所以建议谨慎使用，必要时结合其他方法一起优化篇幅。\n\n下面是一些常见的压缩篇幅方法，供你参考：\n\n---\n\n## 1. 用 `\\vspace` 压缩间距\n\n- **减少段前/段后间距** \n 例如在两段之间减少距离：\n ```latex\n 段落一。\n \\vspace{-0.8em}\n 段落二。\n ```\n- **减少公式上下间距** \n 在公式环境上下加负间距：\n ```latex\n \\vspace{-1em}\n \\begin{equation}\n E = mc^2\n \\end{equation}\n \\vspace{-1em}\n ```\n\n---\n\n## 2. 压缩列表项间距\n\n- **压缩 itemize/enumerate 列表的间距** \n ```latex\n \\usepackage{enumitem}\n % 在导言区加上\n \\setlist{nosep} % 或 \\setlist{itemsep=0pt, topsep=0pt}\n ```\n\n---\n\n## 3. 调整段落间距\n\n- **减少段落间距** \n 修改段落参数，例如：\n ```latex\n \\setlength{\\parskip}{0pt}\n \\setlength{\\parindent}{1em}\n ```\n\n---\n\n## 4. 压缩标题与正文之间的间距\n\n- **调整 section/subsection 等标题间距** \n ```latex\n \\usepackage[compact]{titlesec}\n \\titlespacing*{\\section}{0pt}{1.2ex plus .2ex minus .2ex}{0.8ex plus .1ex}\n \\titlespacing*{\\subsection}{0pt}{1ex plus .2ex minus .2ex}{0.7ex plus .1ex}\n ```\n 或\n ```latex\n \\usepackage{titlesec}\n \\titlespacing{\\section}{0pt}{*0.8}{*0.5}\n ```\n\n---\n\n## 5. 压缩图表与正文之间的间距\n\n- **减少图表上下间距**\n ```latex\n \\setlength{\\abovecaptionskip}{2pt}\n \\setlength{\\belowcaptionskip}{2pt}\n ```\n\n---\n\n## 6. 注意事项\n\n- **负间距（如 `\\vspace{-1em}`）容易导致版面不美观，建议小心使用。**\n- **如果是会议/期刊模板，优先遵循模板原有的格式要求。**\n\n---\n\n## 示例\n\n```latex\n\\documentclass{article}\n\\usepackage{enumitem}\n\\usepackage{titlesec}\n\\setlist{nosep}\n\\titlespacing*{\\section}{0pt}{1.2ex plus .2ex}{0.8ex plus .1ex}\n\\titlespacing*{\\subsection}{0pt}{1ex plus .2ex}{0.7ex plus .1ex}\n\\setlength{\\parskip}{0pt}\n\\setlength{\\abovecaptionskip}{2pt}\n\\setlength{\\belowcaptionskip}{2pt}\n\n\\begin{document}\n\n\\section{Introduction}\n文本段落一。\n\\vspace{-0.5em}\n文本段落二。\n\n\\begin{itemize}\n \\item 第一项\n \\item 第二项\n\\end{itemize}\n\n\\end{document}\n```\n\n---\n\n**总结** \n`\\vspace` 主要用于临时、局部调整，压缩全局篇幅建议结合 `enumitem`、`titlesec`、`\\setlength` 等参数一起用，效果更好、更规范。如需更详细帮助，可贴出具体格式要求或模板。"
},
{
"role": "user",
"content": "能怎么重定义一下\\begin{proposition} 吗 让它的上下间距近一些"
}
]Response:
当然可以！你可以通过 `\newtheoremstyle`（来自 `amsthm` 宏包）或 `\theoremstyle` 配合 `enumitem`/`titlesec` 等方法来重定义 `proposition` 环境的上下间距。下面给出最推荐的几种方式：
---
## 方法1：用 `amsthm` 的 `\newtheoremstyle` 自定义间距（推荐）
```latex
\usepackage{amsthm}
% 新定义一个theorem style，设置上下间距
\newtheoremstyle{tightprop}% <name>
{2pt}% <Space above>
{2pt}% <Space below>
{\itshape}% <Body font>
{}% <Indent amount>
{\bfseries}% <Theorem head font>
{.}% <Punctuation after theorem head>
{.5em}% <Space after theorem head>
{}% <Theorem head spec>
\theoremstyle{tightprop}
\newtheorem{proposition}{Proposition}
```
说明：
- `{2pt}` 是上下的间距（可以改成 `1pt`、`0pt` 或负值如 `-2pt` 以进一步压缩）。
- 这样定义后，`\begin{proposition}` 的上下间距就会变得很小。
---
## 方法2：用 `etoolbox` 给环境前后加负的 `\vspace`
有时你用的不是 `amsthm`，可以用 `etoolbox` 给环境加手动负间距：
```latex
\usepackage{amsthm}
\usepackage{etoolbox}
\newtheorem{proposition}{Proposition}
% 环境前后加负间距
\AtBeginEnvironment{proposition}{\vspace{-0.8em}}
\AtEndEnvironment{proposition}{\vspace{-0.8em}}
```
说明：
- 你可以调整 `-0.8em` 的数值为你需要的压缩程度。
---
## 方法3：用 `mdframed` 自定义环境（可选）
如果你喜欢盒子样式，也可以用 `mdframed`，它支持 `skipabove` 和 `skipbelow`：
```latex
\usepackage{amsthm}
\usepackage[framemethod=default]{mdframed}
\newmdenv[
skipabove=2pt,
skipbelow=2pt,
linewidth=0pt
]{proposition}
```
---
## 实例
```latex
\documentclass{article}
\usepackage{amsthm}
\newtheoremstyle{tightprop}
{2pt}{2pt} % 上下间距都设为2pt
{\itshape}{}{\bfseries}{.}{.5em}{}
\theoremstyle{tightprop}
\newtheorem{proposition}{Proposition}
\begin{document}
\begin{proposition}
这是一个命题，间距很紧。
\end{proposition}
正文内容。
\begin{proposition}
另一个命题，间距依然很紧。
\end{proposition}
\end{document}
```
---
## 总结
- 推荐用 `amsthm` 的 `\newtheoremstyle`，最优雅且兼容性好。
- 极端压缩可以用 `etoolbox` 增加更大的负间距，但影响美观需谨慎。
- 若需要自定义盒子样式可用 `mdframed`。
如需进一步个性化格式，请补充你的期刊/会议模板或具体样式要求！
Model: gpt-4.1-2025-04-142025-09-17 05:21:39
Context:
[
{
"role": "user",
"content": "\\item \\emph{Access follows provenance.} A unit of value is usable by $u$ only if there exists a custody chain in $\\mathcal{H}$ from an external deposit to $u$. Informally, $\\textsf{Allow}(u,\\alpha,x)\\quad\\text{means balance } x \\text{ is reachable for } u \\text{ via provenance in } \\mathcal{H}$. This implies \\emph{consistency}: for every $\\alpha$, the total internal balance equals the on-chain balance at $\\pk$, i.e., $\\sum_{u\\in\\mathcal{U}}\\mathcal{L}[u][\\alpha]=B_{\\mathrm{on}}(\\alpha)$. Incoming deposits $(\\alpha,x,m)\\in\\mathcal{I}$ are ``wrapped'' and must be explicitly claimed before use by the sender address.\n\n这边Allow之后太长了 能重写了一下让它能正常换行吗"
},
{
"role": "assistant",
"content": "当然可以！你可以把 `\\textsf{Allow}(u,\\alpha,x)\\quad\\text{means balance } x \\text{ is reachable for } u \\text{ via provenance in } \\mathcal{H}.` 这句话重写成便于换行的形式。这里有几种 LaTeX 的写法，推荐用 `\\parbox`，`\\begin{tabular}` 或 `align` 环境来控制换行。\n\n### 方案1：用 `\\parbox` 控制宽度自动换行\n\n```latex\n\\item \\emph{Access follows provenance.} A unit of value is usable by $u$ only if there exists a custody chain in $\\mathcal{H}$ from an external deposit to $u$. Informally,\n\\[\n\\textsf{Allow}(u,\\alpha,x)\\quad\n\\parbox[t]{.7\\linewidth}{means balance $x$ is reachable for $u$ via provenance in $\\mathcal{H}$.}\n\\]\nThis implies \\emph{consistency}: for every $\\alpha$, the total internal balance equals the on-chain balance at $\\pk$, i.e., $\\sum_{u\\in\\mathcal{U}}\\mathcal{L}[u][\\alpha]=B_{\\mathrm{on}}(\\alpha)$. Incoming deposits $(\\alpha,x,m)\\in\\mathcal{I}$ are ``wrapped'' and must be explicitly claimed before use by the sender address.\n```\n\n### 方案2：用 `align` 环境让公式自动换行\n\n```latex\n\\item \\emph{Access follows provenance.} A unit of value is usable by $u$ only if there exists a custody chain in $\\mathcal{H}$ from an external deposit to $u$. Informally,\n\\begin{align*}\n\\textsf{Allow}(u,\\alpha,x)\\quad &\\text{means balance $x$ is reachable for $u$} \\\\\n&\\text{via provenance in } \\mathcal{H}.\n\\end{align*}\nThis implies \\emph{consistency}: for every $\\alpha$, the total internal balance equals the on-chain balance at $\\pk$, i.e., $\\sum_{u\\in\\mathcal{U}}\\mathcal{L}[u][\\alpha]=B_{\\mathrm{on}}(\\alpha)$. Incoming deposits $(\\alpha,x,m)\\in\\mathcal{I}$ are ``wrapped'' and must be explicitly claimed before use by the sender address.\n```\n\n### 方案3：用 `tabular` 环境\n\n```latex\n\\item \\emph{Access follows provenance.} A unit of value is usable by $u$ only if there exists a custody chain in $\\mathcal{H}$ from an external deposit to $u$. Informally,\n\\[\n\\begin{tabular}{@{}l}\n $\\textsf{Allow}(u,\\alpha,x)$ \\quad means balance $x$ is reachable for $u$ \\\\\n via provenance in $\\mathcal{H}$.\n\\end{tabular}\n\\]\nThis implies \\emph{consistency}: for every $\\alpha$, the total internal balance equals the on-chain balance at $\\pk$, i.e., $\\sum_{u\\in\\mathcal{U}}\\mathcal{L}[u][\\alpha]=B_{\\mathrm{on}}(\\alpha)$. Incoming deposits $(\\alpha,x,m)\\in\\mathcal{I}$ are ``wrapped'' and must be explicitly claimed before use by the sender address.\n```\n\n---\n\n**推荐**：如果你想让公式和正文排版更美观，建议用 **方案2** 的 `align*` 环境。这样数学环境会自动对齐，长句也不会溢出。\n\n---\n\n**效果图**（方案2）：\n\n```latex\n\\item \\emph{Access follows provenance.} A unit of value is usable by $u$ only if there exists a custody chain in $\\mathcal{H}$ from an external deposit to $u$. Informally,\n\\begin{align*}\n\\textsf{Allow}(u,\\alpha,x)\\quad &\\text{means balance $x$ is reachable for $u$} \\\\\n&\\text{via provenance in } \\mathcal{H}.\n\\end{align*}\nThis implies \\emph{consistency}: for every $\\alpha$, the total internal balance equals the on-chain balance at $\\pk$, i.e., $\\sum_{u\\in\\mathcal{U}}\\mathcal{L}[u][\\alpha]=B_{\\mathrm{on}}(\\alpha)$. Incoming deposits $(\\alpha,x,m)\\in\\mathcal{I}$ are ``wrapped'' and must be explicitly claimed before use by the sender address.\n```\n\n这样就能正常换行了！"
},
{
"role": "user",
"content": "论文怎么用vspace压缩篇幅"
}
]Response:
在写论文时，`\vspace` 可以用来**手动调整段落或环境之间的垂直间距**，以压缩（或扩展）篇幅。不过，**过度使用 `\vspace` 可能影响论文的排版美观和可读性**，所以建议谨慎使用，必要时结合其他方法一起优化篇幅。
下面是一些常见的压缩篇幅方法，供你参考：
---
## 1. 用 `\vspace` 压缩间距
- **减少段前/段后间距**
例如在两段之间减少距离：
```latex
段落一。
\vspace{-0.8em}
段落二。
```
- **减少公式上下间距**
在公式环境上下加负间距：
```latex
\vspace{-1em}
\begin{equation}
E = mc^2
\end{equation}
\vspace{-1em}
```
---
## 2. 压缩列表项间距
- **压缩 itemize/enumerate 列表的间距**
```latex
\usepackage{enumitem}
% 在导言区加上
\setlist{nosep} % 或 \setlist{itemsep=0pt, topsep=0pt}
```
---
## 3. 调整段落间距
- **减少段落间距**
修改段落参数，例如：
```latex
\setlength{\parskip}{0pt}
\setlength{\parindent}{1em}
```
---
## 4. 压缩标题与正文之间的间距
- **调整 section/subsection 等标题间距**
```latex
\usepackage[compact]{titlesec}
\titlespacing*{\section}{0pt}{1.2ex plus .2ex minus .2ex}{0.8ex plus .1ex}
\titlespacing*{\subsection}{0pt}{1ex plus .2ex minus .2ex}{0.7ex plus .1ex}
```
或
```latex
\usepackage{titlesec}
\titlespacing{\section}{0pt}{*0.8}{*0.5}
```
---
## 5. 压缩图表与正文之间的间距
- **减少图表上下间距**
```latex
\setlength{\abovecaptionskip}{2pt}
\setlength{\belowcaptionskip}{2pt}
```
---
## 6. 注意事项
- **负间距（如 `\vspace{-1em}`）容易导致版面不美观，建议小心使用。**
- **如果是会议/期刊模板，优先遵循模板原有的格式要求。**
---
## 示例
```latex
\documentclass{article}
\usepackage{enumitem}
\usepackage{titlesec}
\setlist{nosep}
\titlespacing*{\section}{0pt}{1.2ex plus .2ex}{0.8ex plus .1ex}
\titlespacing*{\subsection}{0pt}{1ex plus .2ex}{0.7ex plus .1ex}
\setlength{\parskip}{0pt}
\setlength{\abovecaptionskip}{2pt}
\setlength{\belowcaptionskip}{2pt}
\begin{document}
\section{Introduction}
文本段落一。
\vspace{-0.5em}
文本段落二。
\begin{itemize}
\item 第一项
\item 第二项
\end{itemize}
\end{document}
```
---
**总结**
`\vspace` 主要用于临时、局部调整，压缩全局篇幅建议结合 `enumitem`、`titlesec`、`\setlength` 等参数一起用，效果更好、更规范。如需更详细帮助，可贴出具体格式要求或模板。
Model: gpt-4.1-nano-2025-04-142025-09-17 05:16:51
Context:
[
{
"role": "system",
"content": "You are an assistant who is good at conversation. You need to summarize the user's conversation into a title of 10 characters or less. It should be in the format of \"Action - Title\". Some examples:\n1. Learn - Bitcoin 2. Code - Web Server 3. Write - An Article"
},
{
"role": "user",
"content": "[{\"role\":\"user\",\"mainText\":\"\\\\item \\\\emph{Access follows provenance.} A unit of value is usable by $u$ only if there exists a custody chain in $\\\\mathcal{H}$ from an external deposit to $u$. Informally, $\\\\textsf{Allow}(u,\\\\alpha,x)\\\\quad\\\\text{means balance } x \\\\text{ is reachable for } u \\\\text{ via provenance in } \\\\mathcal{H}$. This implies \\\\emph{consistency}: for every $\\\\alpha$, the total internal balance equals the on-chain balance at $\\\\pk$, i.e., $\\\\sum_{u\\\\in\\\\mathcal{U}}\\\\mathcal{L}[u][\\\\alpha]=B_{\\\\mathrm{on}}(\\\\alpha)$. Incoming deposits $(\\\\alpha,x,m)\\\\in\\\\mathcal{I}$ are ``wrapped'' and must be explicitly claimed before use by the sender address.\\n\\n这边Allow之后太长了 能重写了一下让它能正常换行吗\"},{\"role\":\"assistant\",\"mainText\":\"当然可以！你可以把 `\\\\textsf{Allow}(u,\\\\alpha,x)\\\\quad\\\\text{means balance } x \\\\text{ is reachable for } u \\\\text{ via provenance in } \\\\mathcal{H}.` 这句话重写成便于换行的形式。这里有几种 LaTeX 的写法，推荐用 `\\\\parbox`，`\\\\begin{tabular}` 或 `align` 环境来控制换行。\\n\\n### 方案1：用 `\\\\parbox` 控制宽度自动换行\\n\\n```latex\\n\\\\item \\\\emph{Access follows provenance.} A unit of value is usable by $u$ only if there exists a custody chain in $\\\\mathcal{H}$ from an external deposit to $u$. Informally,\\n\\\\[\\n\\\\textsf{Allow}(u,\\\\alpha,x)\\\\quad\\n\\\\parbox[t]{.7\\\\linewidth}{means balance $x$ is reachable for $u$ via provenance in $\\\\mathcal{H}$.}\\n\\\\]\\nThis implies \\\\emph{consistency}: for every $\\\\alpha$, the total internal balance equals the on-chain balance at $\\\\pk$, i.e., $\\\\sum_{u\\\\in\\\\mathcal{U}}\\\\mathcal{L}[u][\\\\alpha]=B_{\\\\mathrm{on}}(\\\\alpha)$. Incoming deposits $(\\\\alpha,x,m)\\\\in\\\\mathcal{I}$ are ``wrapped'' and must be explicitly claimed before use by the sender address.\\n```\\n\\n### 方案2：用 `align` 环境让公式自动换行\\n\\n```latex\\n\\\\item \\\\emph{Access follows provenance.} A unit of value is usable by $u$ only if there exists a custody chain in $\\\\mathcal{H}$ from an external deposit to $u$. Informally,\\n\\\\begin{align*}\\n\\\\textsf{Allow}(u,\\\\alpha,x)\\\\quad &\\\\text{means balance $x$ is reachable for $u$} \\\\\\\\\\n&\\\\text{via provenance in } \\\\mathcal{H}.\\n\\\\end{align*}\\nThis implies \\\\emph{consistency}: for every $\\\\alpha$, the total internal balance equals the on-chain balance at $\\\\pk$, i.e., $\\\\sum_{u\\\\in\\\\mathcal{U}}\\\\mathcal{L}[u][\\\\alpha]=B_{\\\\mathrm{on}}(\\\\alpha)$. Incoming deposits $(\\\\alpha,x,m)\\\\in\\\\mathcal{I}$ are ``wrapped'' and must be explicitly claimed before use by the sender address.\\n```\\n\\n### 方案3：用 `tabular` 环境\\n\\n```latex\\n\\\\item \\\\emph{Access follows provenance.} A unit of value is usable by $u$ only if there exists a custody chain in $\\\\mathcal{H}$ from an external deposit to $u$. Informally,\\n\\\\[\\n\\\\begin{tabular}{@{}l}\\n $\\\\textsf{Allow}(u,\\\\alpha,x)$ \\\\quad means balance $x$ is reachable for $u$ \\\\\\\\\\n via provenance in $\\\\mathcal{H}$.\\n\\\\end{tabular}\\n\\\\]\\nThis implies \\\\emph{consistency}: for every $\\\\alpha$, the total internal balance equals the on-chain balance at $\\\\pk$, i.e., $\\\\sum_{u\\\\in\\\\mathcal{U}}\\\\mathcal{L}[u][\\\\alpha]=B_{\\\\mathrm{on}}(\\\\alpha)$. Incoming deposits $(\\\\alpha,x,m)\\\\in\\\\mathcal{I}$ are ``wrapped'' and must be explicitly claimed before use by the sender address.\\n```\\n\\n---\\n\\n**推荐**：如果你想让公式和正文排版更美观，建议用 **方案2** 的 `align*` 环境。这样数学环境会自动对齐，长句也不会溢出。\\n\\n---\\n\\n**效果图**（方案2）：\\n\\n```latex\\n\\\\item \\\\emph{Access follows provenance.} A unit of value is usable by $u$ only if there exists a custody chain in $\\\\mathcal{H}$ from an external deposit to $u$. Informally,\\n\\\\begin{align*}\\n\\\\textsf{Allow}(u,\\\\alpha,x)\\\\quad &\\\\text{means balance $x$ is reachable for $u$} \\\\\\\\\\n&\\\\text{via provenance in } \\\\mathcal{H}.\\n\\\\end{align*}\\nThis implies \\\\emph{consistency}: for every $\\\\alpha$, the total internal balance equals the on-chain balance at $\\\\pk$, i.e., $\\\\sum_{u\\\\in\\\\mathcal{U}}\\\\mathcal{L}[u][\\\\alpha]=B_{\\\\mathrm{on}}(\\\\alpha)$. Incoming deposits $(\\\\alpha,x,m)\\\\in\\\\mathcal{I}$ are ``wrapped'' and must be explicitly claimed before use by the sender address.\\n```\\n\\n这样就能正常换行了！\"}]"
}
]Response:
Rewrite - LaTeX换行技巧
Model: gpt-4.1-2025-04-142025-09-17 05:16:49
Context:
[
{
"role": "user",
"content": "\\item \\emph{Access follows provenance.} A unit of value is usable by $u$ only if there exists a custody chain in $\\mathcal{H}$ from an external deposit to $u$. Informally, $\\textsf{Allow}(u,\\alpha,x)\\quad\\text{means balance } x \\text{ is reachable for } u \\text{ via provenance in } \\mathcal{H}$. This implies \\emph{consistency}: for every $\\alpha$, the total internal balance equals the on-chain balance at $\\pk$, i.e., $\\sum_{u\\in\\mathcal{U}}\\mathcal{L}[u][\\alpha]=B_{\\mathrm{on}}(\\alpha)$. Incoming deposits $(\\alpha,x,m)\\in\\mathcal{I}$ are ``wrapped'' and must be explicitly claimed before use by the sender address.\n\n这边Allow之后太长了 能重写了一下让它能正常换行吗"
}
]Response:
当然可以！你可以把 `\textsf{Allow}(u,\alpha,x)\quad\text{means balance } x \text{ is reachable for } u \text{ via provenance in } \mathcal{H}.` 这句话重写成便于换行的形式。这里有几种 LaTeX 的写法，推荐用 `\parbox`，`\begin{tabular}` 或 `align` 环境来控制换行。
### 方案1：用 `\parbox` 控制宽度自动换行
```latex
\item \emph{Access follows provenance.} A unit of value is usable by $u$ only if there exists a custody chain in $\mathcal{H}$ from an external deposit to $u$. Informally,
\[
\textsf{Allow}(u,\alpha,x)\quad
\parbox[t]{.7\linewidth}{means balance $x$ is reachable for $u$ via provenance in $\mathcal{H}$.}
\]
This implies \emph{consistency}: for every $\alpha$, the total internal balance equals the on-chain balance at $\pk$, i.e., $\sum_{u\in\mathcal{U}}\mathcal{L}[u][\alpha]=B_{\mathrm{on}}(\alpha)$. Incoming deposits $(\alpha,x,m)\in\mathcal{I}$ are ``wrapped'' and must be explicitly claimed before use by the sender address.
```
### 方案2：用 `align` 环境让公式自动换行
```latex
\item \emph{Access follows provenance.} A unit of value is usable by $u$ only if there exists a custody chain in $\mathcal{H}$ from an external deposit to $u$. Informally,
\begin{align*}
\textsf{Allow}(u,\alpha,x)\quad &\text{means balance $x$ is reachable for $u$} \\
&\text{via provenance in } \mathcal{H}.
\end{align*}
This implies \emph{consistency}: for every $\alpha$, the total internal balance equals the on-chain balance at $\pk$, i.e., $\sum_{u\in\mathcal{U}}\mathcal{L}[u][\alpha]=B_{\mathrm{on}}(\alpha)$. Incoming deposits $(\alpha,x,m)\in\mathcal{I}$ are ``wrapped'' and must be explicitly claimed before use by the sender address.
```
### 方案3：用 `tabular` 环境
```latex
\item \emph{Access follows provenance.} A unit of value is usable by $u$ only if there exists a custody chain in $\mathcal{H}$ from an external deposit to $u$. Informally,
\[
\begin{tabular}{@{}l}
$\textsf{Allow}(u,\alpha,x)$ \quad means balance $x$ is reachable for $u$ \\
via provenance in $\mathcal{H}$.
\end{tabular}
\]
This implies \emph{consistency}: for every $\alpha$, the total internal balance equals the on-chain balance at $\pk$, i.e., $\sum_{u\in\mathcal{U}}\mathcal{L}[u][\alpha]=B_{\mathrm{on}}(\alpha)$. Incoming deposits $(\alpha,x,m)\in\mathcal{I}$ are ``wrapped'' and must be explicitly claimed before use by the sender address.
```
---
**推荐**：如果你想让公式和正文排版更美观，建议用 **方案2** 的 `align*` 环境。这样数学环境会自动对齐，长句也不会溢出。
---
**效果图**（方案2）：
```latex
\item \emph{Access follows provenance.} A unit of value is usable by $u$ only if there exists a custody chain in $\mathcal{H}$ from an external deposit to $u$. Informally,
\begin{align*}
\textsf{Allow}(u,\alpha,x)\quad &\text{means balance $x$ is reachable for $u$} \\
&\text{via provenance in } \mathcal{H}.
\end{align*}
This implies \emph{consistency}: for every $\alpha$, the total internal balance equals the on-chain balance at $\pk$, i.e., $\sum_{u\in\mathcal{U}}\mathcal{L}[u][\alpha]=B_{\mathrm{on}}(\alpha)$. Incoming deposits $(\alpha,x,m)\in\mathcal{I}$ are ``wrapped'' and must be explicitly claimed before use by the sender address.
```
这样就能正常换行了！
Model: gpt-4.1-2025-04-142025-09-17 05:09:36
Context:
[
{
"role": "user",
"content": "这样一个latex宏能同时支持数字列表和普通列表吗？\n\\newenvironment{icompact}{\n \\begin{list}{$\\bullet$}{\n \\parsep 0pt plus 1pt\n \\partopsep 0pt plus 1pt\n \\topsep 2pt plus 1pt minus 1pt\n \\itemsep 0pt plus 0pt\n \\parskip 0pt plus 2pt\n \\leftmargin 0.15in}}\n {\\normalsize\\end{list}}"
}
]Response:
你的 `icompact` 环境定义如下：
```latex
\newenvironment{icompact}{
\begin{list}{$\bullet$}{
\parsep 0pt plus 1pt
\partopsep 0pt plus 1pt
\topsep 2pt plus 1pt minus 1pt
\itemsep 0pt plus 0pt
\parskip 0pt plus 2pt
\leftmargin 0.15in}}
{\normalsize\end{list}}
```
**答案：**
这个宏**只能用来实现紧凑的无序（即带圆点的）列表**，**不能直接支持有序（数字）列表**。
### 原因分析
- `\begin{list}{$\bullet$}{...}` 明确指定了每个条目前的标记是 `$\bullet$`，所以所有项都是“圆点”样式。
- 如果你想做数字列表，通常需要用 `enumerate` 环境或类似的参数 (`\begin{list}{1.}{...}` 并不能自动递增数字)。
### 怎么同时支持？
你可以定义两个不同的环境，一个用于无序，一个用于有序。例如：
```latex
\newenvironment{icompact}{
\begin{list}{$\bullet$}{
\parsep 0pt plus 1pt
\partopsep 0pt plus 1pt
\topsep 2pt plus 1pt minus 1pt
\itemsep 0pt plus 0pt
\parskip 0pt plus 2pt
\leftmargin 0.15in}}
{\end{list}}
\newenvironment{ncompact}{
\begin{list}{\arabic{enumi}.}{
\usecounter{enumi}
\parsep 0pt plus 1pt
\partopsep 0pt plus 1pt
\topsep 2pt plus 1pt minus 1pt
\itemsep 0pt plus 0pt
\parskip 0pt plus 2pt
\leftmargin 0.15in}}
{\end{list}}
```
- `icompact` 是紧凑的无序列表。
- `ncompact` 是紧凑的有序（数字）列表。
**用法示例：**
```latex
\begin{icompact}
\item Apple
\item Banana
\end{icompact}
\begin{ncompact}
\item First
\item Second
\end{ncompact}
```
---
### 更简单的做法
你也可以用 `enumitem` 宏包来定制 `itemize` 和 `enumerate` 的间距：
```latex
\usepackage{enumitem}
\setlist[itemize]{nosep, left=0.15in}
\setlist[enumerate]{nosep, left=0.15in}
```
这样你就可以直接用 `itemize` 和 `enumerate`，而拥有紧凑的效果。
---
**总结：**
你的这个宏**只支持一种列表**（带圆点的普通列表），要想支持数字列表，需要另写一个环境，或用 `enumitem` 宏包统一设置。
Model: gpt-4.1-nano-2025-04-142025-09-17 05:01:21
Context:
[
{
"role": "system",
"content": "You are an assistant who is good at conversation. You need to summarize the user's conversation into a title of 10 characters or less. It should be in the format of \"Action - Title\". Some examples:\n1. Learn - Bitcoin 2. Code - Web Server 3. Write - An Article"
},
{
"role": "user",
"content": "[{\"role\":\"user\",\"mainText\":\"我的apple account是大陆的 但是apple music显示的歌名都是繁体怎们办\"},{\"role\":\"assistant\",\"mainText\":\"你的 Apple Music 歌名显示为繁体中文，通常是因为以下原因之一：\\n\\n1. **Apple ID 地区设置** \\n虽然你的 Apple ID 是大陆的，但 Apple Music 的内容语言显示，主要受设备的「语言与地区」设置影响。\\n\\n2. **设备语言设置** \\n请按照以下步骤检查和修改：\\n\\n**iPhone/iPad 操作：**\\n1. 打开【设置】>【通用】>【语言与地区】。\\n2. 确认「iPhone 语言」选择的是「简体中文」。\\n3. 「地区」请选择「中国大陆」。\\n4. 重启设备。\\n\\n**Mac 操作：**\\n1. 打开「系统设置」>「通用」>「语言与地区」。\\n2. 将首选语言设置为「简体中文」。\\n3. 地区选择「中国大陆」。\\n4. 重新启动 Apple Music 应用。\\n\\n3. **Apple Music 应用设置** \\n部分 Apple Music 版本支持自定义显示语言，确认 App 语言设置为简体中文。\\n\\n4. **缓存问题** \\n有时语言切换后需要清理缓存或重新登录 Apple Music。\\n\\n**尝试方法：**\\n- 退出 Apple Music 账号，再重新登录。\\n- 卸载并重装 Apple Music 应用。\\n\\n5. **部分歌曲元数据本身为繁体** \\n极少数情况下，版权方提交的曲库信息本身用的是繁体，这种情况用户无法更改。\\n\\n---\\n\\n### 总结\\n大多数情况下，调整设备的「语言与地区」到「简体中文」和「中国大陆」即可解决。如果问题依旧，建议联系 Apple 官方客服反馈。\\n\\n如有其他疑问，欢迎随时追问！\"}]"
}
]Response:
Music - 繁体显示
Model: gpt-4.1-2025-04-142025-09-17 05:01:20
Context:
[
{
"role": "user",
"content": "我的apple account是大陆的 但是apple music显示的歌名都是繁体怎们办"
}
]Response:
你的 Apple Music 歌名显示为繁体中文，通常是因为以下原因之一：
1. **Apple ID 地区设置**
虽然你的 Apple ID 是大陆的，但 Apple Music 的内容语言显示，主要受设备的「语言与地区」设置影响。
2. **设备语言设置**
请按照以下步骤检查和修改：
**iPhone/iPad 操作：**
1. 打开【设置】>【通用】>【语言与地区】。
2. 确认「iPhone 语言」选择的是「简体中文」。
3. 「地区」请选择「中国大陆」。
4. 重启设备。
**Mac 操作：**
1. 打开「系统设置」>「通用」>「语言与地区」。
2. 将首选语言设置为「简体中文」。
3. 地区选择「中国大陆」。
4. 重新启动 Apple Music 应用。
3. **Apple Music 应用设置**
部分 Apple Music 版本支持自定义显示语言，确认 App 语言设置为简体中文。
4. **缓存问题**
有时语言切换后需要清理缓存或重新登录 Apple Music。
**尝试方法：**
- 退出 Apple Music 账号，再重新登录。
- 卸载并重装 Apple Music 应用。
5. **部分歌曲元数据本身为繁体**
极少数情况下，版权方提交的曲库信息本身用的是繁体，这种情况用户无法更改。
---
### 总结
大多数情况下，调整设备的「语言与地区」到「简体中文」和「中国大陆」即可解决。如果问题依旧，建议联系 Apple 官方客服反馈。
如有其他疑问，欢迎随时追问！
Model: gpt-4.1-nano-2025-04-142025-09-16 09:07:15
Context:
[
{
"role": "system",
"content": "You are an assistant who is good at conversation. You need to summarize the user's conversation into a title of 10 characters or less. It should be in the format of \"Action - Title\". Some examples:\n1. Learn - Bitcoin 2. Code - Web Server 3. Write - An Article"
},
{
"role": "user",
"content": "[{\"role\":\"user\",\"mainText\":\"how can i reset the mail.app in macos\"},{\"role\":\"assistant\",\"mainText\":\"If you want to \\\"reset\\\" the Mail app on macOS, you might mean one or more of the following:\\n\\n- **Remove all accounts and data from Mail**\\n- **Delete cached data and preferences**\\n- **Start Mail as if it's never been used**\\n\\n**IMPORTANT:** Resetting Mail will delete your account settings, downloaded messages, and customizations. If you use POP accounts, make sure you have backups of your mail, as messages may be stored *locally* and could be lost.\\n\\n---\\n\\n## Step-by-Step: Reset Mail.app on macOS\\n\\n### 1. Quit Mail\\nFully quit the Mail app (`Mail` > `Quit Mail`).\\n\\n---\\n\\n### 2. Remove Mail Preferences\\n\\nOpen **Finder**, then from the menu bar select `Go` > `Go to Folder…`, and enter:\\n\\n```\\n~/Library/Preferences/\\n```\\n\\nFind and delete these files (if present):\\n\\n- `com.apple.mail.plist`\\n- `com.apple.mail-shared.plist`\\n\\n---\\n\\n### 3. Remove Mail Data\\n\\nStill in Finder, use `Go to Folder…` again and enter:\\n\\n```\\n~/Library/Mail/\\n```\\n\\nMove the entire `Mail` folder to the Trash.\\n\\n---\\n\\n### 4. Remove Mail Accounts (Optional, for complete reset)\\n\\nGo to:\\n\\n```\\n~/Library/Containers/\\n```\\n\\nFind and delete:\\n\\n- `com.apple.mail`\\n- `com.apple.MailServiceAgent`\\n\\n---\\n\\n### 5. Remove Saved Application State (Optional)\\n\\nGo to:\\n\\n```\\n~/Library/Saved Application State/\\n```\\n\\nDelete:\\n\\n- `com.apple.mail.savedState`\\n\\n---\\n\\n### 6. Remove Internet Accounts (Optional)\\n\\nIf you want to remove mail accounts from your Mac entirely, go to **System Settings > Internet Accounts** (or **System Preferences > Internet Accounts** on older macOS) and remove mail accounts there.\\n\\n---\\n\\n### 7. Restart Mail\\n\\nOpen Mail. You'll be prompted to set up your accounts as if Mail is being launched for the first time.\\n\\n---\\n\\n## **Cautions**\\n- **Back up important emails** before deleting anything.\\n- If you use **iCloud, Gmail, or IMAP**, your mail will resync after re-adding the account.\\n- If you use **POP**, ensure you have backups of your local mail.\\n- This process does **not** uninstall Mail; it only resets its data and preferences.\\n\\n---\\n\\n### **Summary Table**\\n\\n| Step | What to Remove | Path |\\n|------|---------------------------------------------|--------------------------------------|\\n| 1 | Preferences | `~/Library/Preferences/` |\\n| 2 | Mail Data | `~/Library/Mail/` |\\n| 3 | Containers | `~/Library/Containers/` |\\n| 4 | Saved State | `~/Library/Saved Application State/` |\\n\\n---\\n\\nIf you need more detailed help or want to target specific issues, let me know!\"}]"
}
]Response:
Reset - Mail
Model: gpt-4.1-2025-04-142025-09-16 09:07:14
Context:
[
{
"role": "user",
"content": "how can i reset the mail.app in macos"
}
]Response:
If you want to "reset" the Mail app on macOS, you might mean one or more of the following:
- **Remove all accounts and data from Mail**
- **Delete cached data and preferences**
- **Start Mail as if it's never been used**
**IMPORTANT:** Resetting Mail will delete your account settings, downloaded messages, and customizations. If you use POP accounts, make sure you have backups of your mail, as messages may be stored *locally* and could be lost.
---
## Step-by-Step: Reset Mail.app on macOS
### 1. Quit Mail
Fully quit the Mail app (`Mail` > `Quit Mail`).
---
### 2. Remove Mail Preferences
Open **Finder**, then from the menu bar select `Go` > `Go to Folder…`, and enter:
```
~/Library/Preferences/
```
Find and delete these files (if present):
- `com.apple.mail.plist`
- `com.apple.mail-shared.plist`
---
### 3. Remove Mail Data
Still in Finder, use `Go to Folder…` again and enter:
```
~/Library/Mail/
```
Move the entire `Mail` folder to the Trash.
---
### 4. Remove Mail Accounts (Optional, for complete reset)
Go to:
```
~/Library/Containers/
```
Find and delete:
- `com.apple.mail`
- `com.apple.MailServiceAgent`
---
### 5. Remove Saved Application State (Optional)
Go to:
```
~/Library/Saved Application State/
```
Delete:
- `com.apple.mail.savedState`
---
### 6. Remove Internet Accounts (Optional)
If you want to remove mail accounts from your Mac entirely, go to **System Settings > Internet Accounts** (or **System Preferences > Internet Accounts** on older macOS) and remove mail accounts there.
---
### 7. Restart Mail
Open Mail. You'll be prompted to set up your accounts as if Mail is being launched for the first time.
---
## **Cautions**
- **Back up important emails** before deleting anything.
- If you use **iCloud, Gmail, or IMAP**, your mail will resync after re-adding the account.
- If you use **POP**, ensure you have backups of your local mail.
- This process does **not** uninstall Mail; it only resets its data and preferences.
---
### **Summary Table**
| Step | What to Remove | Path |
|------|---------------------------------------------|--------------------------------------|
| 1 | Preferences | `~/Library/Preferences/` |
| 2 | Mail Data | `~/Library/Mail/` |
| 3 | Containers | `~/Library/Containers/` |
| 4 | Saved State | `~/Library/Saved Application State/` |
---
If you need more detailed help or want to target specific issues, let me know!
Model: gpt-4.1-nano-2025-04-142025-09-16 09:01:26
Context:
[
{
"role": "system",
"content": "You are an assistant who is good at conversation. You need to summarize the user's conversation into a title of 10 characters or less. It should be in the format of \"Action - Title\". Some examples:\n1. Learn - Bitcoin 2. Code - Web Server 3. Write - An Article"
},
{
"role": "user",
"content": "[{\"role\":\"user\",\"mainText\":\"翻译成中文：\\nThanks Shelven! \\n\\nSo at least in some threat models it would be conceivable for the KMS host to censor an event (eg key restore) for an application hash/digest? \\n\\nFor example, if the application is known to the adversary, who then bribes the KMS host to prevent key recovery.\\n\\nI suppose the question is whether this is a threat model that matters in practice.\"},{\"role\":\"assistant\",\"mainText\":\"谢谢 Shelven！\\n\\n那么，至少在某些威胁模型下，KMS 主机有可能对某个应用哈希/摘要的事件（例如密钥恢复）进行审查，对吧？\\n\\n比如，如果攻击者已经知道了这个应用程序，并且收买了 KMS 主机来阻止密钥恢复。\\n\\n我想我的问题是，这样的威胁模型在实际中是否值得关注。\"}]"
}
]Response:
Discuss - KMS Threat
Model: gpt-4.1-2025-04-142025-09-16 09:01:25
Context:
[
{
"role": "user",
"content": "翻译成中文：\nThanks Shelven! \n\nSo at least in some threat models it would be conceivable for the KMS host to censor an event (eg key restore) for an application hash/digest? \n\nFor example, if the application is known to the adversary, who then bribes the KMS host to prevent key recovery.\n\nI suppose the question is whether this is a threat model that matters in practice."
}
]Response:
谢谢 Shelven！
那么，至少在某些威胁模型下，KMS 主机有可能对某个应用哈希/摘要的事件（例如密钥恢复）进行审查，对吧？
比如，如果攻击者已经知道了这个应用程序，并且收买了 KMS 主机来阻止密钥恢复。
我想我的问题是，这样的威胁模型在实际中是否值得关注。
Model: gpt-4.1-nano-2025-04-142025-09-16 08:24:54
Context:
[
{
"role": "system",
"content": "You are an assistant who is good at conversation. You need to summarize the user's conversation into a title of 10 characters or less. It should be in the format of \"Action - Title\". Some examples:\n1. Learn - Bitcoin 2. Code - Web Server 3. Write - An Article"
},
{
"role": "user",
"content": "[{\"role\":\"user\",\"mainText\":\"prf是什么 密码学背景\"},{\"role\":\"assistant\",\"mainText\":\"在密码学中，**PRF** 是 **Pseudorandom Function** 的缩写，中文通常称为**伪随机函数**。\\n\\n## PRF（伪随机函数）定义\\n\\n### 基本概念\\n- PRF 是一种函数族，通常记作 \\\\( \\\\{ f_k : \\\\{0,1\\\\}^n \\\\rightarrow \\\\{0,1\\\\}^m \\\\}_{k \\\\in K} \\\\)，其中 \\\\( k \\\\) 是密钥。\\n- 给定密钥 \\\\( k \\\\)，\\\\( f_k \\\\) 就是一个具体的函数。\\n- 其核心性质是：对于不知道密钥 \\\\( k \\\\) 的多项式时间的对手，\\\\( f_k \\\\) 的输出与真正的随机函数无法区分。\\n\\n### 形式化定义\\n- 设 \\\\( F: K \\\\times X \\\\rightarrow Y \\\\) 是一个函数族。\\n- 对于所有有效（多项式时间）的攻击者 \\\\(\\\\mathcal{A}\\\\)，其区分 \\\\( F_k(\\\\cdot) \\\\)（随机选取密钥的函数）和真正的随机函数 \\\\( R(\\\\cdot) \\\\) 的概率非常接近（具体来说，差值为可忽略函数）。\\n\\n### 作用\\n- PRF 是许多对称密码学算法的基础组件，比如消息认证码（MAC）、密钥派生函数（KDF）、分组密码的模式（如CTR模式）等。\\n- 实用中的分组密码（如AES）可以在一定条件下被证明为PRF。\\n\\n### 相关概念\\n- **PRG（Pseudorandom Generator, 伪随机生成器）**：生成长的伪随机串。\\n- **PRP（Pseudorandom Permutation, 伪随机置换）**：是可逆的PRF，常用于分组密码。\\n\\n---\\n\\n**总结：**\\n> 在密码学中，PRF（伪随机函数）是一类输出与真正随机函数无法区分的函数族，是对称加密、消息认证等构建的基础原语。\"}]"
}
]Response:
Learn - PRF
Model: gpt-4.1-2025-04-142025-09-16 08:24:53
Context:
[
{
"role": "user",
"content": "prf是什么 密码学背景"
}
]Response:
在密码学中，**PRF** 是 **Pseudorandom Function** 的缩写，中文通常称为**伪随机函数**。
## PRF（伪随机函数）定义
### 基本概念
- PRF 是一种函数族，通常记作 \( \{ f_k : \{0,1\}^n \rightarrow \{0,1\}^m \}_{k \in K} \)，其中 \( k \) 是密钥。
- 给定密钥 \( k \)，\( f_k \) 就是一个具体的函数。
- 其核心性质是：对于不知道密钥 \( k \) 的多项式时间的对手，\( f_k \) 的输出与真正的随机函数无法区分。
### 形式化定义
- 设 \( F: K \times X \rightarrow Y \) 是一个函数族。
- 对于所有有效（多项式时间）的攻击者 \(\mathcal{A}\)，其区分 \( F_k(\cdot) \)（随机选取密钥的函数）和真正的随机函数 \( R(\cdot) \) 的概率非常接近（具体来说，差值为可忽略函数）。
### 作用
- PRF 是许多对称密码学算法的基础组件，比如消息认证码（MAC）、密钥派生函数（KDF）、分组密码的模式（如CTR模式）等。
- 实用中的分组密码（如AES）可以在一定条件下被证明为PRF。
### 相关概念
- **PRG（Pseudorandom Generator, 伪随机生成器）**：生成长的伪随机串。
- **PRP（Pseudorandom Permutation, 伪随机置换）**：是可逆的PRF，常用于分组密码。
---
**总结：**
> 在密码学中，PRF（伪随机函数）是一类输出与真正随机函数无法区分的函数族，是对称加密、消息认证等构建的基础原语。
Model: gpt-4.1-nano-2025-04-142025-09-16 06:31:39
Context:
[
{
"role": "system",
"content": "You are an assistant who is good at conversation. You need to summarize the user's conversation into a title of 10 characters or less. It should be in the format of \"Action - Title\". Some examples:\n1. Learn - Bitcoin 2. Code - Web Server 3. Write - An Article"
},
{
"role": "user",
"content": "[{\"role\":\"user\",\"mainText\":\"mac里怎么设置隐私允许一个app获取wifi ssid\"},{\"role\":\"assistant\",\"mainText\":\"在 macOS 系统中，如果一个 App 想要获取 Wi-Fi SSID（即当前连接的 Wi-Fi 名称），通常需要获得“定位服务”权限。因为自 macOS 10.15 (Catalina) 及更高版本，为了保护用户隐私，系统将 Wi-Fi 信息的访问权限和定位服务绑定在一起。\\n\\n### 步骤如下：\\n\\n1. **打开“系统设置”/“系统偏好设置”：**\\n - macOS Ventura 及更高版本：点击左上角苹果菜单 > 选择“系统设置”。\\n - macOS Monterey 及更早版本：点击左上角苹果菜单 > 选择“系统偏好设置”。\\n\\n2. **进入“隐私与安全性”/“安全性与隐私”：**\\n - 找到左侧的“隐私”或“隐私与安全性”标签，点击进入。\\n\\n3. **找到“定位服务”：**\\n - 在列表中找到“定位服务”（Location Services），点击它。\\n\\n4. **解锁设置：**\\n - 如果设置是灰色的，点击左下角的锁形按钮，输入你的管理员密码进行解锁。\\n\\n5. **找到你的 App 并授权：**\\n - 在右侧应用列表中，找到你希望允许获取 Wi-Fi SSID 的 App，勾选它前面的复选框，允许其使用定位服务。\\n\\n6. **重启 App：**\\n - 关闭并重新打开该 App，以确保设置生效。\\n\\n---\\n\\n### 注意事项\\n\\n- **并非所有 App 都会自动出现在定位服务列表中**，只有那些请求过此权限的 App 才会显示。如果没有看到你要授权的 App，请先打开该 App 并尝试相关操作，系统会弹窗询问是否授权定位服务。\\n- **没有看到 App？** \\n 有些 App 并不是通过标准方式请求权限，可能无法直接在这里授权。建议联系 App 开发者，确认他们是否正确实现了定位权限请求。\\n- **安全性考虑：** \\n 只允许你信任的 App 获取此权限，因为它们可以间接获取你的位置。\\n\\n---\\n\\n### 总结\\n\\n**macOS 允许 App 获取 Wi-Fi SSID 的前提是该 App 有定位服务权限。** \\n路径为： \\n`系统设置/系统偏好设置 > 隐私(与安全性) > 定位服务 > 勾选对应 App`\\n\\n如有更多具体需求或遇到问题，欢迎补充说明！\"}]"
}
]Response:
Privacy - Wi-Fi Access
Model: gpt-4.1-2025-04-142025-09-16 06:31:38
Context:
[
{
"role": "user",
"content": "mac里怎么设置隐私允许一个app获取wifi ssid"
}
]Response:
在 macOS 系统中，如果一个 App 想要获取 Wi-Fi SSID（即当前连接的 Wi-Fi 名称），通常需要获得“定位服务”权限。因为自 macOS 10.15 (Catalina) 及更高版本，为了保护用户隐私，系统将 Wi-Fi 信息的访问权限和定位服务绑定在一起。
### 步骤如下：
1. **打开“系统设置”/“系统偏好设置”：**
- macOS Ventura 及更高版本：点击左上角苹果菜单 > 选择“系统设置”。
- macOS Monterey 及更早版本：点击左上角苹果菜单 > 选择“系统偏好设置”。
2. **进入“隐私与安全性”/“安全性与隐私”：**
- 找到左侧的“隐私”或“隐私与安全性”标签，点击进入。
3. **找到“定位服务”：**
- 在列表中找到“定位服务”（Location Services），点击它。
4. **解锁设置：**
- 如果设置是灰色的，点击左下角的锁形按钮，输入你的管理员密码进行解锁。
5. **找到你的 App 并授权：**
- 在右侧应用列表中，找到你希望允许获取 Wi-Fi SSID 的 App，勾选它前面的复选框，允许其使用定位服务。
6. **重启 App：**
- 关闭并重新打开该 App，以确保设置生效。
---
### 注意事项
- **并非所有 App 都会自动出现在定位服务列表中**，只有那些请求过此权限的 App 才会显示。如果没有看到你要授权的 App，请先打开该 App 并尝试相关操作，系统会弹窗询问是否授权定位服务。
- **没有看到 App？**
有些 App 并不是通过标准方式请求权限，可能无法直接在这里授权。建议联系 App 开发者，确认他们是否正确实现了定位权限请求。
- **安全性考虑：**
只允许你信任的 App 获取此权限，因为它们可以间接获取你的位置。
---
### 总结
**macOS 允许 App 获取 Wi-Fi SSID 的前提是该 App 有定位服务权限。**
路径为：
`系统设置/系统偏好设置 > 隐私(与安全性) > 定位服务 > 勾选对应 App`
如有更多具体需求或遇到问题，欢迎补充说明！
Model: gpt-4.1-nano-2025-04-142025-09-16 06:31:00
Context:
[
{
"role": "system",
"content": "You are an assistant who is good at conversation. You need to summarize the user's conversation into a title of 10 characters or less. It should be in the format of \"Action - Title\". Some examples:\n1. Learn - Bitcoin 2. Code - Web Server 3. Write - An Article"
},
{
"role": "user",
"content": "[{\"role\":\"user\",\"mainText\":\"I just updated to macOS Tahoe 26 and my application doesn't launch. It complains \\\"origin config has been renamed\\\". And this is the crash report. Check it and debug what's wrong.\\n\\n```\\n-------------------------------------\\nTranslated Report (Full Report Below)\\n-------------------------------------\\nProcess: ClashX Pro [4380]\\nPath: /Applications/ClashX Pro.app/Contents/MacOS/ClashX Pro\\nIdentifier: com.west2online.ClashXPro\\nVersion: 1.118.1.1 (1.118.1.1)\\nCode Type: ARM-64 (Native)\\nRole: Default\\nParent Process: launchd [1]\\nCoalition: com.west2online.ClashXPro [1781]\\nUser ID: 501\\n\\nDate/Time: 2025-09-16 14:29:59.8794 +0800\\nLaunch Time: 2025-09-16 14:29:59.7105 +0800\\nHardware Model: Mac16,10\\nOS Version: macOS 26.0 (25A354)\\nRelease Type: User\\n\\nCrash Reporter Key: 1542C1AD-5B7A-094E-6414-2D0080ED3E3B\\nIncident Identifier: 693C641C-16AE-4644-B652-2AC8EFC9ECB1\\n\\nTime Awake Since Boot: 1300 seconds\\n\\nSystem Integrity Protection: enabled\\n\\nTriggered by Thread: 0\\n\\nException Type: EXC_CRASH (SIGABRT)\\nException Codes: 0x0000000000000000, 0x0000000000000000\\n\\nTermination Reason: Namespace SIGNAL, Code 6, Abort trap: 6\\nTerminating Process: ClashX Pro [4380]\\n\\n\\nApplication Specific Information:\\nabort() called\\n\\n\\nLast Exception Backtrace:\\n0 CoreFoundation \\t 0x190998764 __exceptionPreprocess + 164\\n1 libobjc.A.dylib \\t 0x190476418 objc_exception_throw + 88\\n2 Foundation \\t 0x192bba85c -[NSConcreteTask launchWithDictionary:error:] + 3976\\n3 ClashX Pro \\t 0x1046a4680 0x104648000 + 378496\\n4 ClashX Pro \\t 0x1046a7a54 0x104648000 + 391764\\n5 ClashX Pro \\t 0x1046a7790 0x104648000 + 391056\\n6 ClashX Pro \\t 0x1046a7094 0x104648000 + 389268\\n7 ClashX Pro \\t 0x10466b368 0x104648000 + 144232\\n8 ClashX Pro \\t 0x1046698e4 0x104648000 + 137444\\n9 ClashX Pro \\t 0x104677828 0x104648000 + 194600\\n10 ClashX Pro \\t 0x104694ee4 0x104648000 + 315108\\n11 libdispatch.dylib \\t 0x1906ecb5c _dispatch_call_block_and_release + 32\\n12 libdispatch.dylib \\t 0x190706ac4 _dispatch_client_callout + 16\\n13 libdispatch.dylib \\t 0x1907240e4 _dispatch_main_queue_drain.cold.5 + 812\\n14 libdispatch.dylib \\t 0x1906fbf48 _dispatch_main_queue_drain + 180\\n15 libdispatch.dylib \\t 0x1906fbe84 _dispatch_main_queue_callback_4CF + 44\\n16 CoreFoundation \\t 0x190974098 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 16\\n17 CoreFoundation \\t 0x1909468cc __CFRunLoopRun + 1944\\n18 CoreFoundation \\t 0x190a04898 _CFRunLoopRunSpecificWithOptions + 532\\n19 HIToolbox \\t 0x19d343730 RunCurrentEventLoopInMode + 316\\n20 HIToolbox \\t 0x19d3469d0 ReceiveNextEventCommon + 488\\n21 HIToolbox \\t 0x19d4d01f4 _BlockUntilNextEventMatchingListInMode + 48\\n22 AppKit \\t 0x19521e308 _DPSBlockUntilNextEventMatchingListInMode + 236\\n23 AppKit \\t 0x194d34edc _DPSNextEvent + 588\\n24 AppKit \\t 0x195787a04 -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 688\\n25 AppKit \\t 0x195787710 -[NSApplication(NSEventRouting) nextEventMatchingMask:untilDate:inMode:dequeue:] + 72\\n26 AppKit \\t 0x194d2d720 -[NSApplication run] + 368\\n27 AppKit \\t 0x194d19694 NSApplicationMain + 880\\n28 ClashX Pro \\t 0x1046734e8 0x104648000 + 177384\\n29 dyld \\t 0x1904e9d54 start + 7184\\n\\nThread 0 Crashed:\\n0 libsystem_kernel.dylib \\t 0x19086e5b0 __pthread_kill + 8\\n1 libsystem_pthread.dylib \\t 0x1908a8888 pthread_kill + 296\\n2 libsystem_c.dylib \\t 0x1907ae808 abort + 124\\n3 libc++abi.dylib \\t 0x19085c858 __abort_message + 132\\n4 libc++abi.dylib \\t 0x19084b4d4 demangling_terminate_handler() + 304\\n5 libobjc.A.dylib \\t 0x190480464 _objc_terminate() + 156\\n6 libc++abi.dylib \\t 0x19085bc2c std::__terminate(void (*)()) + 16\\n7 libc++abi.dylib \\t 0x19085f394 __cxxabiv1::failed_throw(__cxxabiv1::__cxa_exception*) + 88\\n8 libc++abi.dylib \\t 0x19085f33c __cxa_throw + 92\\n9 libobjc.A.dylib \\t 0x190476580 objc_exception_throw + 448\\n10 Foundation \\t 0x192bba85c -[NSConcreteTask launchWithDictionary:error:] + 3976\\n11 ClashX Pro \\t 0x1046a4680 0x104648000 + 378496\\n12 ClashX Pro \\t 0x1046a7a54 0x104648000 + 391764\\n13 ClashX Pro \\t 0x1046a7790 0x104648000 + 391056\\n14 ClashX Pro \\t 0x1046a7094 0x104648000 + 389268\\n15 ClashX Pro \\t 0x10466b368 0x104648000 + 144232\\n16 ClashX Pro \\t 0x1046698e4 0x104648000 + 137444\\n17 ClashX Pro \\t 0x104677828 0x104648000 + 194600\\n18 ClashX Pro \\t 0x104694ee4 0x104648000 + 315108\\n19 libdispatch.dylib \\t 0x1906ecb5c _dispatch_call_block_and_release + 32\\n20 libdispatch.dylib \\t 0x190706ac4 _dispatch_client_callout + 16\\n21 libdispatch.dylib \\t 0x1907240e4 _dispatch_main_queue_drain.cold.5 + 812\\n22 libdispatch.dylib \\t 0x1906fbf48 _dispatch_main_queue_drain + 180\\n23 libdispatch.dylib \\t 0x1906fbe84 _dispatch_main_queue_callback_4CF + 44\\n24 CoreFoundation \\t 0x190974098 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 16\\n25 CoreFoundation \\t 0x1909468cc __CFRunLoopRun + 1944\\n26 CoreFoundation \\t 0x190a04898 _CFRunLoopRunSpecificWithOptions + 532\\n27 HIToolbox \\t 0x19d343730 RunCurrentEventLoopInMode + 316\\n28 HIToolbox \\t 0x19d3469d0 ReceiveNextEventCommon + 488\\n29 HIToolbox \\t 0x19d4d01f4 _BlockUntilNextEventMatchingListInMode + 48\\n30 AppKit \\t 0x19521e308 _DPSBlockUntilNextEventMatchingListInMode + 236\\n31 AppKit \\t 0x194d34edc _DPSNextEvent + 588\\n32 AppKit \\t 0x195787a04 -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 688\\n33 AppKit \\t 0x195787710 -[NSApplication(NSEventRouting) nextEventMatchingMask:untilDate:inMode:dequeue:] + 72\\n34 AppKit \\t 0x194d2d720 -[NSApplication run] + 368\\n35 AppKit \\t 0x194d19694 NSApplicationMain + 880\\n36 ClashX Pro \\t 0x1046734e8 0x104648000 + 177384\\n37 dyld \\t 0x1904e9d54 start + 7184\\n\\nThread 1:\\n\\nThread 2:\\n0 libsystem_kernel.dylib \\t 0x190867ae4 __ulock_wait + 8\\n1 libdispatch.dylib \\t 0x1906eecec _dlock_wait + 56\\n2 libdispatch.dylib \\t 0x1906eeb0c _dispatch_thread_event_wait_slow + 56\\n3 libdispatch.dylib \\t 0x1906fcc20 __DISPATCH_WAIT_FOR_QUEUE__ + 368\\n4 libdispatch.dylib \\t 0x1906fc7d8 _dispatch_sync_f_slow + 148\\n5 libsystem_trace.dylib \\t 0x1905dd1a8 ___os_state_request_for_self_block_invoke + 372\\n6 libdispatch.dylib \\t 0x1906ecb5c _dispatch_call_block_and_release + 32\\n7 libdispatch.dylib \\t 0x190706ac4 _dispatch_client_callout + 16\\n8 libdispatch.dylib \\t 0x1906f54e8 _dispatch_lane_serial_drain + 740\\n9 libdispatch.dylib \\t 0x1906f5ff8 _dispatch_lane_invoke + 440\\n10 libdispatch.dylib \\t 0x190700474 _dispatch_root_queue_drain_deferred_wlh + 292\\n11 libdispatch.dylib \\t 0x1906ffd6c _dispatch_workloop_worker_thread + 692\\n12 libsystem_pthread.dylib \\t 0x1908a4e4c _pthread_wqthread + 292\\n13 libsystem_pthread.dylib \\t 0x1908a3b9c start_wqthread + 8\\n\\nThread 3:\\n0 libsystem_kernel.dylib \\t 0x1908694f8 __psynch_cvwait + 8\\n1 libsystem_pthread.dylib \\t 0x1908a90dc _pthread_cond_wait + 984\\n2 ClashX Pro \\t 0x1049df168 0x104648000 + 3764584\\n3 ClashX Pro \\t 0x1049dda78 0x104648000 + 3758712\\n4 ??? \\t 0xd65f03c0 ???\\n\\nThread 4:\\n0 libsystem_kernel.dylib \\t 0x1908692f4 __semwait_signal + 8\\n1 libsystem_c.dylib \\t 0x190742d6c nanosleep + 220\\n2 libsystem_c.dylib \\t 0x190742c84 usleep + 68\\n3 ClashX Pro \\t 0x1049dede4 0x104648000 + 3763684\\n4 ClashX Pro \\t 0x1049dda78 0x104648000 + 3758712\\n\\nThread 5:\\n0 libsystem_kernel.dylib \\t 0x19086bf30 kevent + 8\\n1 ClashX Pro \\t 0x1049deea8 0x104648000 + 3763880\\n\\nThread 6:\\n0 libsystem_kernel.dylib \\t 0x1908694f8 __psynch_cvwait + 8\\n1 libsystem_pthread.dylib \\t 0x1908a90dc _pthread_cond_wait + 984\\n2 ClashX Pro \\t 0x1049df168 0x104648000 + 3764584\\n3 ClashX Pro \\t 0x1049dda78 0x104648000 + 3758712\\n4 ??? \\t 0xd65f03c0 ???\\n\\nThread 7:\\n0 libsystem_kernel.dylib \\t 0x1908694f8 __psynch_cvwait + 8\\n1 libsystem_pthread.dylib \\t 0x1908a90dc _pthread_cond_wait + 984\\n2 ClashX Pro \\t 0x1049df168 0x104648000 + 3764584\\n3 ClashX Pro \\t 0x1049dda78 0x104648000 + 3758712\\n4 ??? \\t 0xd65f03c0 ???\\n\\nThread 8:\\n0 libsystem_kernel.dylib \\t 0x1908694f8 __psynch_cvwait + 8\\n1 libsystem_pthread.dylib \\t 0x1908a90dc _pthread_cond_wait + 984\\n2 ClashX Pro \\t 0x1049df168 0x104648000 + 3764584\\n3 ClashX Pro \\t 0x1049dda78 0x104648000 + 3758712\\n4 ??? \\t 0xd65f03c0 ???\\n\\nThread 9:\\n\\nThread 10:\\n0 libsystem_kernel.dylib \\t 0x1908694f8 __psynch_cvwait + 8\\n1 libsystem_pthread.dylib \\t 0x1908a90dc _pthread_cond_wait + 984\\n2 ClashX Pro \\t 0x1049df168 0x104648000 + 3764584\\n3 ClashX Pro \\t 0x1049dda78 0x104648000 + 3758712\\n4 ??? \\t 0xd65f03c0 ???\\n\\nThread 11:\\n\\nThread 12:: com.apple.NSEventThread\\n0 libsystem_kernel.dylib \\t 0x190865c34 mach_msg2_trap + 8\\n1 libsystem_kernel.dylib \\t 0x190878028 mach_msg2_internal + 76\\n2 libsystem_kernel.dylib \\t 0x19086e98c mach_msg_overwrite + 484\\n3 libsystem_kernel.dylib \\t 0x190865fb4 mach_msg + 24\\n4 CoreFoundation \\t 0x190947c80 __CFRunLoopServiceMachPort + 160\\n5 CoreFoundation \\t 0x1909465d8 __CFRunLoopRun + 1188\\n6 CoreFoundation \\t 0x190a04898 _CFRunLoopRunSpecificWithOptions + 532\\n7 AppKit \\t 0x194dc4a68 _NSEventThread + 184\\n8 libsystem_pthread.dylib \\t 0x1908a8c08 _pthread_start + 136\\n9 libsystem_pthread.dylib \\t 0x1908a3ba8 thread_start + 8\\n\\nThread 13:: HIE: M_ e0f345a8106056e2 2025-09-16 14:29:59.876\\n0 libsystem_kernel.dylib \\t 0x190865c34 mach_msg2_trap + 8\\n1 libsystem_kernel.dylib \\t 0x190878028 mach_msg2_internal + 76\\n2 libsystem_kernel.dylib \\t 0x1908957bc thread_suspend + 108\\n3 HIServices \\t 0x197ef344c SOME_OTHER_THREAD_SWALLOWED_AT_LEAST_ONE_EXCEPTION + 20\\n4 Foundation \\t 0x192154750 __NSThread__start__ + 732\\n5 libsystem_pthread.dylib \\t 0x1908a8c08 _pthread_start + 136\\n6 libsystem_pthread.dylib \\t 0x1908a3ba8 thread_start + 8\\n\\n\\nThread 0 crashed with ARM Thread State (64-bit):\\n x0: 0x0000000000000000 x1: 0x0000000000000000 x2: 0x0000000000000000 x3: 0x0000000000000000\\n x4: 0x0000000190861007 x5: 0x000000016b7b4240 x6: 0x000000000000006e x7: 0xfffff0003ffff800\\n x8: 0x6465def6fd57567a x9: 0x6465def700721e7a x10: 0x0000000000000051 x11: 0x000000000000000b\\n x12: 0x000000000000000b x13: 0x0000000190d6f0d4 x14: 0x00000001064cc9b8 x15: 0x0000000bea020000\\n x16: 0x0000000000000148 x17: 0x00000001fe88a008 x18: 0x0000000000000000 x19: 0x0000000000000006\\n x20: 0x0000000000000103 x21: 0x00000001fd2548e0 x22: 0x00000001fb14c000 x23: 0x00000008cb4a0d00\\n x24: 0x00000008cb4a0d00 x25: 0x00000008cb696800 x26: 0x0000000105b1b000 x27: 0x0000000000000000\\n x28: 0x00000001feaa9678 fp: 0x000000016b7b41b0 lr: 0x00000001908a8888\\n sp: 0x000000016b7b4190 pc: 0x000000019086e5b0 cpsr: 0x40000000\\n far: 0x0000000000000000 esr: 0x56000080 (Syscall)\\n\\nBinary Images:\\n 0x104648000 - 0x105343fff com.west2online.ClashXPro (1.118.1.1) <4ae041a8-d9a2-337b-92f7-5083d605f8a9> /Applications/ClashX Pro.app/Contents/MacOS/ClashX Pro\\n 0x105da4000 - 0x105de7fff org.sparkle-project.Sparkle (2.5.1) <f6d9e0bb-3dec-34d5-8524-32b314d93248> /Applications/ClashX Pro.app/Contents/Frameworks/Sparkle.framework/Versions/B/Sparkle\\n 0x155068000 - 0x155073fff libobjc-trampolines.dylib (*) <580e4b29-8304-342d-a21c-2a869364dc35> /usr/lib/libobjc-trampolines.dylib\\n 0x1570e0000 - 0x157903fff com.apple.AGXMetalG16G-B0 (340.26.3) <2170a88b-3de9-3ecc-927d-9690438526d0> /System/Library/Extensions/AGXMetalG16G_B0.bundle/Contents/MacOS/AGXMetalG16G_B0\\n 0x190865000 - 0x1908a145f libsystem_kernel.dylib (*) <2eb73bf1-8c71-3e1f-a160-6da83dc82606> /usr/lib/system/libsystem_kernel.dylib\\n 0x1908a2000 - 0x1908aeabb libsystem_pthread.dylib (*) <5d31d65c-2ecf-36da-84f5-ba4caab06adb> /usr/lib/system/libsystem_pthread.dylib\\n 0x190735000 - 0x1907b6ff7 libsystem_c.dylib (*) <1e2fc910-e211-3a48-90c1-402c82129ea8> /usr/lib/system/libsystem_c.dylib\\n 0x19084a000 - 0x19086492f libc++abi.dylib (*) <1db24a4f-6a19-3415-b7c4-79c43340ec7b> /usr/lib/libc++abi.dylib\\n 0x19045c000 - 0x1904af4eb libobjc.A.dylib (*) <7443a268-c9f9-3d65-b497-4f8081799514> /usr/lib/libobjc.A.dylib\\n 0x19212e000 - 0x1930ba31f com.apple.Foundation (6.9) <f61e71c3-480f-3691-b656-e1281f60a3e3> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation\\n 0x1906eb000 - 0x190731e9f libdispatch.dylib (*) <17d849c6-a785-3dbb-bfb5-8321706c4b8d> /usr/lib/system/libdispatch.dylib\\n 0x1908e8000 - 0x190e34f7f com.apple.CoreFoundation (6.9) <edb39786-80b1-3bff-b6c3-e33f2e3ca867> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation\\n 0x19d282000 - 0x19d5846ff com.apple.HIToolbox (2.1.1) <f369023f-1a24-3f3f-9056-6f5248071e8c> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox\\n 0x194d15000 - 0x196410d9f com.apple.AppKit (6.9) <6d84c7a3-ee98-3daf-ac66-cd95a902ba84> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit\\n 0x1904e1000 - 0x19057ff73 dyld (*) <abfd3247-50ac-3c8e-b72a-83710166e982> /usr/lib/dyld\\n 0x0 - 0xffffffffffffffff ??? (*) <00000000-0000-0000-0000-000000000000> ???\\n 0x1905d1000 - 0x1905f17df libsystem_trace.dylib (*) <28139651-ffe2-3795-95ac-1c7cb27a3a9b> /usr/lib/system/libsystem_trace.dylib\\n 0x197ebd000 - 0x197f291ff com.apple.HIServices (1.22) <fd66e806-cfa4-3e6f-81bd-eefb21be31fe> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices\\n\\nExternal Modification Summary:\\n Calls made by other processes targeting this process:\\n task_for_pid: 0\\n thread_create: 0\\n thread_set_state: 0\\n Calls made by this process:\\n task_for_pid: 0\\n thread_create: 0\\n thread_set_state: 0\\n Calls made by all processes on this machine:\\n task_for_pid: 0\\n thread_create: 0\\n thread_set_state: 0\\n\\nVM Region Summary:\\nReadOnly portion of Libraries: Total=1.7G resident=0K(0%) swapped_out_or_unallocated=1.7G(100%)\\nWritable regions: Total=162.5M written=641K(0%) resident=641K(0%) swapped_out=0K(0%) unallocated=161.9M(100%)\\n\\n VIRTUAL REGION \\nREGION TYPE SIZE COUNT (non-coalesced) \\n=========== ======= ======= \\nActivity Tracing 256K 1 \\nColorSync 560K 26 \\nCoreGraphics 32K 2 \\nCoreGraphics (reserved) 16K 1 reserved VM address space (unallocated)\\nFoundation 16K 1 \\nImage IO 32K 2 \\nKernel Alloc Once 32K 1 \\nMALLOC 105.1M 19 \\nMALLOC guard page 4096K 4 \\nSTACK GUARD 56.2M 14 \\nStack 15.0M 14 \\nVM_ALLOCATE 1.2G 46 \\nVM_ALLOCATE (reserved) 4.0G 1 reserved VM address space (unallocated)\\n__AUTH 5592K 612 \\n__AUTH_CONST 86.2M 991 \\n__CTF 824 1 \\n__DATA 28.9M 941 \\n__DATA_CONST 39.9M 1000 \\n__DATA_DIRTY 8229K 855 \\n__FONT_DATA 2352 1 \\n__INFO_FILTER 8 1 \\n__LINKEDIT 596.5M 5 \\n__OBJC_RO 78.1M 1 \\n__OBJC_RW 2561K 1 \\n__TEXT 1.1G 1023 \\n__TEXT (graphics) 13.0M 1 \\n__TPRO_CONST 128K 2 \\nmapped file 275.7M 28 \\npage table in kernel 641K 1 \\nshared memory 1376K 12 \\n=========== ======= ======= \\nTOTAL 7.6G 5608 \\nTOTAL, minus reserved VM space 3.6G 5608 \\n\\n\\n-----------\\nFull Report\\n-----------\\n\\n{\\\"app_name\\\":\\\"ClashX Pro\\\",\\\"timestamp\\\":\\\"2025-09-16 14:30:02.00 +0800\\\",\\\"app_version\\\":\\\"1.118.1.1\\\",\\\"slice_uuid\\\":\\\"4ae041a8-d9a2-337b-92f7-5083d605f8a9\\\",\\\"build_version\\\":\\\"1.118.1.1\\\",\\\"platform\\\":1,\\\"bundleID\\\":\\\"com.west2online.ClashXPro\\\",\\\"share_with_app_devs\\\":0,\\\"is_first_party\\\":0,\\\"bug_type\\\":\\\"309\\\",\\\"os_version\\\":\\\"macOS 26.0 (25A354)\\\",\\\"roots_installed\\\":0,\\\"name\\\":\\\"ClashX Pro\\\",\\\"incident_id\\\":\\\"693C641C-16AE-4644-B652-2AC8EFC9ECB1\\\"}\\n{\\n \\\"uptime\\\" : 1300,\\n \\\"procRole\\\" : \\\"Default\\\",\\n \\\"version\\\" : 2,\\n \\\"userID\\\" : 501,\\n \\\"deployVersion\\\" : 210,\\n \\\"modelCode\\\" : \\\"Mac16,10\\\",\\n \\\"coalitionID\\\" : 1781,\\n \\\"osVersion\\\" : {\\n \\\"train\\\" : \\\"macOS 26.0\\\",\\n \\\"build\\\" : \\\"25A354\\\",\\n \\\"releaseType\\\" : \\\"User\\\"\\n },\\n \\\"captureTime\\\" : \\\"2025-09-16 14:29:59.8794 +0800\\\",\\n \\\"codeSigningMonitor\\\" : 2,\\n \\\"incident\\\" : \\\"693C641C-16AE-4644-B652-2AC8EFC9ECB1\\\",\\n \\\"pid\\\" : 4380,\\n \\\"translated\\\" : false,\\n \\\"cpuType\\\" : \\\"ARM-64\\\",\\n \\\"roots_installed\\\" : 0,\\n \\\"bug_type\\\" : \\\"309\\\",\\n \\\"procLaunch\\\" : \\\"2025-09-16 14:29:59.7105 +0800\\\",\\n \\\"procStartAbsTime\\\" : 33241957097,\\n \\\"procExitAbsTime\\\" : 33245934410,\\n \\\"procName\\\" : \\\"ClashX Pro\\\",\\n \\\"procPath\\\" : \\\"\\\\/Applications\\\\/ClashX Pro.app\\\\/Contents\\\\/MacOS\\\\/ClashX Pro\\\",\\n \\\"bundleInfo\\\" : {\\\"CFBundleShortVersionString\\\":\\\"1.118.1.1\\\",\\\"CFBundleVersion\\\":\\\"1.118.1.1\\\",\\\"CFBundleIdentifier\\\":\\\"com.west2online.ClashXPro\\\"},\\n \\\"storeInfo\\\" : {\\\"deviceIdentifierForVendor\\\":\\\"29FF4C35-601E-50B0-B559-8650866A58C8\\\",\\\"thirdParty\\\":true},\\n \\\"parentProc\\\" : \\\"launchd\\\",\\n \\\"parentPid\\\" : 1,\\n \\\"coalitionName\\\" : \\\"com.west2online.ClashXPro\\\",\\n \\\"crashReporterKey\\\" : \\\"1542C1AD-5B7A-094E-6414-2D0080ED3E3B\\\",\\n \\\"developerMode\\\" : 1,\\n \\\"codeSigningID\\\" : \\\"com.west2online.ClashXPro\\\",\\n \\\"codeSigningTeamID\\\" : \\\"MEWHFZ92DY\\\",\\n \\\"codeSigningFlags\\\" : 570503953,\\n \\\"codeSigningValidationCategory\\\" : 6,\\n \\\"codeSigningTrustLevel\\\" : 4294967295,\\n \\\"codeSigningAuxiliaryInfo\\\" : 0,\\n \\\"instructionByteStream\\\" : {\\\"beforePC\\\":\\\"fyMD1f17v6n9AwCRFOD\\\\/l78DAJH9e8Go\\\\/w9f1sADX9YQKYDSARAA1A==\\\",\\\"atPC\\\":\\\"AwEAVH8jA9X9e7+p\\\\/QMAkQng\\\\/5e\\\\/AwCR\\\\/XvBqP8PX9bAA1\\\\/WcAqA0g==\\\"},\\n \\\"bootSessionUUID\\\" : \\\"F0C74C20-70CC-43D6-A83A-E9AEDD62422B\\\",\\n \\\"sip\\\" : \\\"enabled\\\",\\n \\\"exception\\\" : {\\\"codes\\\":\\\"0x0000000000000000, 0x0000000000000000\\\",\\\"rawCodes\\\":[0,0],\\\"type\\\":\\\"EXC_CRASH\\\",\\\"signal\\\":\\\"SIGABRT\\\"},\\n \\\"termination\\\" : {\\\"flags\\\":0,\\\"code\\\":6,\\\"namespace\\\":\\\"SIGNAL\\\",\\\"indicator\\\":\\\"Abort trap: 6\\\",\\\"byProc\\\":\\\"ClashX Pro\\\",\\\"byPid\\\":4380},\\n \\\"asi\\\" : {\\\"libsystem_c.dylib\\\":[\\\"abort() called\\\"]},\\n \\\"extMods\\\" : {\\\"caller\\\":{\\\"thread_create\\\":0,\\\"thread_set_state\\\":0,\\\"task_for_pid\\\":0},\\\"system\\\":{\\\"thread_create\\\":0,\\\"thread_set_state\\\":0,\\\"task_for_pid\\\":0},\\\"targeted\\\":{\\\"thread_create\\\":0,\\\"thread_set_state\\\":0,\\\"task_for_pid\\\":0},\\\"warnings\\\":0},\\n \\\"lastExceptionBacktrace\\\" : [{\\\"imageOffset\\\":722788,\\\"symbol\\\":\\\"__exceptionPreprocess\\\",\\\"symbolLocation\\\":164,\\\"imageIndex\\\":11},{\\\"imageOffset\\\":107544,\\\"symbol\\\":\\\"objc_exception_throw\\\",\\\"symbolLocation\\\":88,\\\"imageIndex\\\":8},{\\\"imageOffset\\\":11061340,\\\"symbol\\\":\\\"-[NSConcreteTask launchWithDictionary:error:]\\\",\\\"symbolLocation\\\":3976,\\\"imageIndex\\\":9},{\\\"imageOffset\\\":378496,\\\"imageIndex\\\":0},{\\\"imageOffset\\\":391764,\\\"imageIndex\\\":0},{\\\"imageOffset\\\":391056,\\\"imageIndex\\\":0},{\\\"imageOffset\\\":389268,\\\"imageIndex\\\":0},{\\\"imageOffset\\\":144232,\\\"imageIndex\\\":0},{\\\"imageOffset\\\":137444,\\\"imageIndex\\\":0},{\\\"imageOffset\\\":194600,\\\"imageIndex\\\":0},{\\\"imageOffset\\\":315108,\\\"imageIndex\\\":0},{\\\"imageOffset\\\":7004,\\\"symbol\\\":\\\"_dispatch_call_block_and_release\\\",\\\"symbolLocation\\\":32,\\\"imageIndex\\\":10},{\\\"imageOffset\\\":113348,\\\"symbol\\\":\\\"_dispatch_client_callout\\\",\\\"symbolLocation\\\":16,\\\"imageIndex\\\":10},{\\\"imageOffset\\\":233700,\\\"symbol\\\":\\\"_dispatch_main_queue_drain.cold.5\\\",\\\"symbolLocation\\\":812,\\\"imageIndex\\\":10},{\\\"imageOffset\\\":69448,\\\"symbol\\\":\\\"_dispatch_main_queue_drain\\\",\\\"symbolLocation\\\":180,\\\"imageIndex\\\":10},{\\\"imageOffset\\\":69252,\\\"symbol\\\":\\\"_dispatch_main_queue_callback_4CF\\\",\\\"symbolLocation\\\":44,\\\"imageIndex\\\":10},{\\\"imageOffset\\\":573592,\\\"symbol\\\":\\\"__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__\\\",\\\"symbolLocation\\\":16,\\\"imageIndex\\\":11},{\\\"imageOffset\\\":387276,\\\"symbol\\\":\\\"__CFRunLoopRun\\\",\\\"symbolLocation\\\":1944,\\\"imageIndex\\\":11},{\\\"imageOffset\\\":1165464,\\\"symbol\\\":\\\"_CFRunLoopRunSpecificWithOptions\\\",\\\"symbolLocation\\\":532,\\\"imageIndex\\\":11},{\\\"imageOffset\\\":792368,\\\"symbol\\\":\\\"RunCurrentEventLoopInMode\\\",\\\"symbolLocation\\\":316,\\\"imageIndex\\\":12},{\\\"imageOffset\\\":805328,\\\"symbol\\\":\\\"ReceiveNextEventCommon\\\",\\\"symbolLocation\\\":488,\\\"imageIndex\\\":12},{\\\"imageOffset\\\":2417140,\\\"symbol\\\":\\\"_BlockUntilNextEventMatchingListInMode\\\",\\\"symbolLocation\\\":48,\\\"imageIndex\\\":12},{\\\"imageOffset\\\":5280520,\\\"symbol\\\":\\\"_DPSBlockUntilNextEventMatchingListInMode\\\",\\\"symbolLocation\\\":236,\\\"imageIndex\\\":13},{\\\"imageOffset\\\":130780,\\\"symbol\\\":\\\"_DPSNextEvent\\\",\\\"symbolLocation\\\":588,\\\"imageIndex\\\":13},{\\\"imageOffset\\\":10955268,\\\"symbol\\\":\\\"-[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:]\\\",\\\"symbolLocation\\\":688,\\\"imageIndex\\\":13},{\\\"imageOffset\\\":10954512,\\\"symbol\\\":\\\"-[NSApplication(NSEventRouting) nextEventMatchingMask:untilDate:inMode:dequeue:]\\\",\\\"symbolLocation\\\":72,\\\"imageIndex\\\":13},{\\\"imageOffset\\\":100128,\\\"symbol\\\":\\\"-[NSApplication run]\\\",\\\"symbolLocation\\\":368,\\\"imageIndex\\\":13},{\\\"imageOffset\\\":18068,\\\"symbol\\\":\\\"NSApplicationMain\\\",\\\"symbolLocation\\\":880,\\\"imageIndex\\\":13},{\\\"imageOffset\\\":177384,\\\"imageIndex\\\":0},{\\\"imageOffset\\\":36180,\\\"symbol\\\":\\\"start\\\",\\\"symbolLocation\\\":7184,\\\"imageIndex\\\":14}],\\n \\\"faultingThread\\\" : 0,\\n \\\"threads\\\" : [{\\\"triggered\\\":true,\\\"id\\\":43465,\\\"threadState\\\":{\\\"x\\\":[{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":6719672327},{\\\"value\\\":6098207296},{\\\"value\\\":110},{\\\"value\\\":18446726482597246976},{\\\"value\\\":7234433528834250362},{\\\"value\\\":7234433528886337146},{\\\"value\\\":81},{\\\"value\\\":11},{\\\"value\\\":11},{\\\"value\\\":6724972756},{\\\"value\\\":4400662968},{\\\"value\\\":51170639872},{\\\"value\\\":328},{\\\"value\\\":8565334024},{\\\"value\\\":0},{\\\"value\\\":6},{\\\"value\\\":259},{\\\"value\\\":8542046432,\\\"symbolLocation\\\":224,\\\"symbol\\\":\\\"_main_thread\\\"},{\\\"value\\\":8507408384,\\\"symbolLocation\\\":0,\\\"symbol\\\":\\\"OBJC_IVAR_$_Object.isa\\\"},{\\\"value\\\":37770366208},{\\\"value\\\":37770366208},{\\\"value\\\":37772421120},{\\\"value\\\":4390498304},{\\\"value\\\":0},{\\\"value\\\":8567559800,\\\"symbolLocation\\\":0,\\\"symbol\\\":\\\"value witness table for CharacterSet\\\"}],\\\"flavor\\\":\\\"ARM_THREAD_STATE64\\\",\\\"lr\\\":{\\\"value\\\":6719965320},\\\"cpsr\\\":{\\\"value\\\":1073741824},\\\"fp\\\":{\\\"value\\\":6098207152},\\\"sp\\\":{\\\"value\\\":6098207120},\\\"esr\\\":{\\\"value\\\":1442840704,\\\"description\\\":\\\"(Syscall)\\\"},\\\"pc\\\":{\\\"value\\\":6719727024,\\\"matchesCrashFrame\\\":1},\\\"far\\\":{\\\"value\\\":0}},\\\"frames\\\":[{\\\"imageOffset\\\":38320,\\\"symbol\\\":\\\"__pthread_kill\\\",\\\"symbolLocation\\\":8,\\\"imageIndex\\\":4},{\\\"imageOffset\\\":26760,\\\"symbol\\\":\\\"pthread_kill\\\",\\\"symbolLocation\\\":296,\\\"imageIndex\\\":5},{\\\"imageOffset\\\":497672,\\\"symbol\\\":\\\"abort\\\",\\\"symbolLocation\\\":124,\\\"imageIndex\\\":6},{\\\"imageOffset\\\":75864,\\\"symbol\\\":\\\"__abort_message\\\",\\\"symbolLocation\\\":132,\\\"imageIndex\\\":7},{\\\"imageOffset\\\":5332,\\\"symbol\\\":\\\"demangling_terminate_handler()\\\",\\\"symbolLocation\\\":304,\\\"imageIndex\\\":7},{\\\"imageOffset\\\":148580,\\\"symbol\\\":\\\"_objc_terminate()\\\",\\\"symbolLocation\\\":156,\\\"imageIndex\\\":8},{\\\"imageOffset\\\":72748,\\\"symbol\\\":\\\"std::__terminate(void (*)())\\\",\\\"symbolLocation\\\":16,\\\"imageIndex\\\":7},{\\\"imageOffset\\\":86932,\\\"symbol\\\":\\\"__cxxabiv1::failed_throw(__cxxabiv1::__cxa_exception*)\\\",\\\"symbolLocation\\\":88,\\\"imageIndex\\\":7},{\\\"imageOffset\\\":86844,\\\"symbol\\\":\\\"__cxa_throw\\\",\\\"symbolLocation\\\":92,\\\"imageIndex\\\":7},{\\\"imageOffset\\\":107904,\\\"symbol\\\":\\\"objc_exception_throw\\\",\\\"symbolLocation\\\":448,\\\"imageIndex\\\":8},{\\\"imageOffset\\\":11061340,\\\"symbol\\\":\\\"-[NSConcreteTask launchWithDictionary:error:]\\\",\\\"symbolLocation\\\":3976,\\\"imageIndex\\\":9},{\\\"imageOffset\\\":378496,\\\"imageIndex\\\":0},{\\\"imageOffset\\\":391764,\\\"imageIndex\\\":0},{\\\"imageOffset\\\":391056,\\\"imageIndex\\\":0},{\\\"imageOffset\\\":389268,\\\"imageIndex\\\":0},{\\\"imageOffset\\\":144232,\\\"imageIndex\\\":0},{\\\"imageOffset\\\":137444,\\\"imageIndex\\\":0},{\\\"imageOffset\\\":194600,\\\"imageIndex\\\":0},{\\\"imageOffset\\\":315108,\\\"imageIndex\\\":0},{\\\"imageOffset\\\":7004,\\\"symbol\\\":\\\"_dispatch_call_block_and_release\\\",\\\"symbolLocation\\\":32,\\\"imageIndex\\\":10},{\\\"imageOffset\\\":113348,\\\"symbol\\\":\\\"_dispatch_client_callout\\\",\\\"symbolLocation\\\":16,\\\"imageIndex\\\":10},{\\\"imageOffset\\\":233700,\\\"symbol\\\":\\\"_dispatch_main_queue_drain.cold.5\\\",\\\"symbolLocation\\\":812,\\\"imageIndex\\\":10},{\\\"imageOffset\\\":69448,\\\"symbol\\\":\\\"_dispatch_main_queue_drain\\\",\\\"symbolLocation\\\":180,\\\"imageIndex\\\":10},{\\\"imageOffset\\\":69252,\\\"symbol\\\":\\\"_dispatch_main_queue_callback_4CF\\\",\\\"symbolLocation\\\":44,\\\"imageIndex\\\":10},{\\\"imageOffset\\\":573592,\\\"symbol\\\":\\\"__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__\\\",\\\"symbolLocation\\\":16,\\\"imageIndex\\\":11},{\\\"imageOffset\\\":387276,\\\"symbol\\\":\\\"__CFRunLoopRun\\\",\\\"symbolLocation\\\":1944,\\\"imageIndex\\\":11},{\\\"imageOffset\\\":1165464,\\\"symbol\\\":\\\"_CFRunLoopRunSpecificWithOptions\\\",\\\"symbolLocation\\\":532,\\\"imageIndex\\\":11},{\\\"imageOffset\\\":792368,\\\"symbol\\\":\\\"RunCurrentEventLoopInMode\\\",\\\"symbolLocation\\\":316,\\\"imageIndex\\\":12},{\\\"imageOffset\\\":805328,\\\"symbol\\\":\\\"ReceiveNextEventCommon\\\",\\\"symbolLocation\\\":488,\\\"imageIndex\\\":12},{\\\"imageOffset\\\":2417140,\\\"symbol\\\":\\\"_BlockUntilNextEventMatchingListInMode\\\",\\\"symbolLocation\\\":48,\\\"imageIndex\\\":12},{\\\"imageOffset\\\":5280520,\\\"symbol\\\":\\\"_DPSBlockUntilNextEventMatchingListInMode\\\",\\\"symbolLocation\\\":236,\\\"imageIndex\\\":13},{\\\"imageOffset\\\":130780,\\\"symbol\\\":\\\"_DPSNextEvent\\\",\\\"symbolLocation\\\":588,\\\"imageIndex\\\":13},{\\\"imageOffset\\\":10955268,\\\"symbol\\\":\\\"-[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:]\\\",\\\"symbolLocation\\\":688,\\\"imageIndex\\\":13},{\\\"imageOffset\\\":10954512,\\\"symbol\\\":\\\"-[NSApplication(NSEventRouting) nextEventMatchingMask:untilDate:inMode:dequeue:]\\\",\\\"symbolLocation\\\":72,\\\"imageIndex\\\":13},{\\\"imageOffset\\\":100128,\\\"symbol\\\":\\\"-[NSApplication run]\\\",\\\"symbolLocation\\\":368,\\\"imageIndex\\\":13},{\\\"imageOffset\\\":18068,\\\"symbol\\\":\\\"NSApplicationMain\\\",\\\"symbolLocation\\\":880,\\\"imageIndex\\\":13},{\\\"imageOffset\\\":177384,\\\"imageIndex\\\":0},{\\\"imageOffset\\\":36180,\\\"symbol\\\":\\\"start\\\",\\\"symbolLocation\\\":7184,\\\"imageIndex\\\":14}]},{\\\"id\\\":43479,\\\"frames\\\":[],\\\"threadState\\\":{\\\"x\\\":[{\\\"value\\\":6098776064},{\\\"value\\\":5891},{\\\"value\\\":6098239488},{\\\"value\\\":0},{\\\"value\\\":409604},{\\\"value\\\":18446744073709551615},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0}],\\\"flavor\\\":\\\"ARM_THREAD_STATE64\\\",\\\"lr\\\":{\\\"value\\\":0},\\\"cpsr\\\":{\\\"value\\\":0},\\\"fp\\\":{\\\"value\\\":0},\\\"sp\\\":{\\\"value\\\":6098776064},\\\"esr\\\":{\\\"value\\\":1442840704,\\\"description\\\":\\\"(Syscall)\\\"},\\\"pc\\\":{\\\"value\\\":6719945620},\\\"far\\\":{\\\"value\\\":0}}},{\\\"id\\\":43480,\\\"frames\\\":[{\\\"imageOffset\\\":10980,\\\"symbol\\\":\\\"__ulock_wait\\\",\\\"symbolLocation\\\":8,\\\"imageIndex\\\":4},{\\\"imageOffset\\\":15596,\\\"symbol\\\":\\\"_dlock_wait\\\",\\\"symbolLocation\\\":56,\\\"imageIndex\\\":10},{\\\"imageOffset\\\":15116,\\\"symbol\\\":\\\"_dispatch_thread_event_wait_slow\\\",\\\"symbolLocation\\\":56,\\\"imageIndex\\\":10},{\\\"imageOffset\\\":72736,\\\"symbol\\\":\\\"__DISPATCH_WAIT_FOR_QUEUE__\\\",\\\"symbolLocation\\\":368,\\\"imageIndex\\\":10},{\\\"imageOffset\\\":71640,\\\"symbol\\\":\\\"_dispatch_sync_f_slow\\\",\\\"symbolLocation\\\":148,\\\"imageIndex\\\":10},{\\\"imageOffset\\\":49576,\\\"symbol\\\":\\\"___os_state_request_for_self_block_invoke\\\",\\\"symbolLocation\\\":372,\\\"imageIndex\\\":16},{\\\"imageOffset\\\":7004,\\\"symbol\\\":\\\"_dispatch_call_block_and_release\\\",\\\"symbolLocation\\\":32,\\\"imageIndex\\\":10},{\\\"imageOffset\\\":113348,\\\"symbol\\\":\\\"_dispatch_client_callout\\\",\\\"symbolLocation\\\":16,\\\"imageIndex\\\":10},{\\\"imageOffset\\\":42216,\\\"symbol\\\":\\\"_dispatch_lane_serial_drain\\\",\\\"symbolLocation\\\":740,\\\"imageIndex\\\":10},{\\\"imageOffset\\\":45048,\\\"symbol\\\":\\\"_dispatch_lane_invoke\\\",\\\"symbolLocation\\\":440,\\\"imageIndex\\\":10},{\\\"imageOffset\\\":87156,\\\"symbol\\\":\\\"_dispatch_root_queue_drain_deferred_wlh\\\",\\\"symbolLocation\\\":292,\\\"imageIndex\\\":10},{\\\"imageOffset\\\":85356,\\\"symbol\\\":\\\"_dispatch_workloop_worker_thread\\\",\\\"symbolLocation\\\":692,\\\"imageIndex\\\":10},{\\\"imageOffset\\\":11852,\\\"symbol\\\":\\\"_pthread_wqthread\\\",\\\"symbolLocation\\\":292,\\\"imageIndex\\\":5},{\\\"imageOffset\\\":7068,\\\"symbol\\\":\\\"start_wqthread\\\",\\\"symbolLocation\\\":8,\\\"imageIndex\\\":5}],\\\"threadState\\\":{\\\"x\\\":[{\\\"value\\\":18446744073709551612},{\\\"value\\\":0},{\\\"value\\\":4294967295},{\\\"value\\\":0},{\\\"value\\\":8542064960,\\\"symbolLocation\\\":0,\\\"symbol\\\":\\\"_dispatch_main_q\\\"},{\\\"value\\\":18},{\\\"value\\\":18446744072631617535},{\\\"value\\\":18446726482597246976},{\\\"value\\\":0},{\\\"value\\\":37759983760},{\\\"value\\\":8542065064,\\\"symbolLocation\\\":104,\\\"symbol\\\":\\\"_dispatch_main_q\\\"},{\\\"value\\\":5},{\\\"value\\\":37759983750},{\\\"value\\\":8542065008,\\\"symbolLocation\\\":48,\\\"symbol\\\":\\\"_dispatch_main_q\\\"},{\\\"value\\\":0},{\\\"value\\\":37759983750},{\\\"value\\\":515},{\\\"value\\\":8565334184},{\\\"value\\\":0},{\\\"value\\\":4294967295},{\\\"value\\\":1},{\\\"value\\\":0},{\\\"value\\\":6099347264},{\\\"value\\\":6099347424},{\\\"value\\\":37759988096},{\\\"value\\\":6843781120},{\\\"value\\\":0},{\\\"value\\\":37769818168},{\\\"value\\\":9223372036855026582}],\\\"flavor\\\":\\\"ARM_THREAD_STATE64\\\",\\\"lr\\\":{\\\"value\\\":6718156012},\\\"cpsr\\\":{\\\"value\\\":1073741824},\\\"fp\\\":{\\\"value\\\":6099347072},\\\"sp\\\":{\\\"value\\\":6099347040},\\\"esr\\\":{\\\"value\\\":1442840704,\\\"description\\\":\\\"(Syscall)\\\"},\\\"pc\\\":{\\\"value\\\":6719699684},\\\"far\\\":{\\\"value\\\":0}}},{\\\"id\\\":43482,\\\"frames\\\":[{\\\"imageOffset\\\":17656,\\\"symbol\\\":\\\"__psynch_cvwait\\\",\\\"symbolLocation\\\":8,\\\"imageIndex\\\":4},{\\\"imageOffset\\\":28892,\\\"symbol\\\":\\\"_pthread_cond_wait\\\",\\\"symbolLocation\\\":984,\\\"imageIndex\\\":5},{\\\"imageOffset\\\":3764584,\\\"imageIndex\\\":0},{\\\"imageOffset\\\":3758712,\\\"imageIndex\\\":0},{\\\"imageOffset\\\":3596551104,\\\"imageIndex\\\":15}],\\\"threadState\\\":{\\\"x\\\":[{\\\"value\\\":260},{\\\"value\\\":0},{\\\"value\\\":1280},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":160},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":6099921880},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":2},{\\\"value\\\":2},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":305},{\\\"value\\\":8565333952},{\\\"value\\\":0},{\\\"value\\\":4391161800},{\\\"value\\\":4391161864},{\\\"value\\\":6099923168},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":1280},{\\\"value\\\":1281},{\\\"value\\\":1536},{\\\"value\\\":18446744073709551488},{\\\"value\\\":4391158912}],\\\"flavor\\\":\\\"ARM_THREAD_STATE64\\\",\\\"lr\\\":{\\\"value\\\":6719967452},\\\"cpsr\\\":{\\\"value\\\":1610612736},\\\"fp\\\":{\\\"value\\\":6099922000},\\\"sp\\\":{\\\"value\\\":6099921856},\\\"esr\\\":{\\\"value\\\":1442840704,\\\"description\\\":\\\"(Syscall)\\\"},\\\"pc\\\":{\\\"value\\\":6719706360},\\\"far\\\":{\\\"value\\\":0}}},{\\\"id\\\":43485,\\\"frames\\\":[{\\\"imageOffset\\\":17140,\\\"symbol\\\":\\\"__semwait_signal\\\",\\\"symbolLocation\\\":8,\\\"imageIndex\\\":4},{\\\"imageOffset\\\":56684,\\\"symbol\\\":\\\"nanosleep\\\",\\\"symbolLocation\\\":220,\\\"imageIndex\\\":6},{\\\"imageOffset\\\":56452,\\\"symbol\\\":\\\"usleep\\\",\\\"symbolLocation\\\":68,\\\"imageIndex\\\":6},{\\\"imageOffset\\\":3763684,\\\"imageIndex\\\":0},{\\\"imageOffset\\\":3758712,\\\"imageIndex\\\":0}],\\\"threadState\\\":{\\\"x\\\":[{\\\"value\\\":4},{\\\"value\\\":0},{\\\"value\\\":1},{\\\"value\\\":1},{\\\"value\\\":0},{\\\"value\\\":10000000},{\\\"value\\\":6},{\\\"value\\\":0},{\\\"value\\\":8542087968,\\\"symbolLocation\\\":0,\\\"symbol\\\":\\\"clock_sem\\\"},{\\\"value\\\":3},{\\\"value\\\":17},{\\\"value\\\":2},{\\\"value\\\":0},{\\\"value\\\":6100512240},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":334},{\\\"value\\\":8565334072},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":6100512192},{\\\"value\\\":3},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":4384491688},{\\\"value\\\":1},{\\\"value\\\":1374389545408}],\\\"flavor\\\":\\\"ARM_THREAD_STATE64\\\",\\\"lr\\\":{\\\"value\\\":6718500204},\\\"cpsr\\\":{\\\"value\\\":2684354560},\\\"fp\\\":{\\\"value\\\":6100512176},\\\"sp\\\":{\\\"value\\\":6100512128},\\\"esr\\\":{\\\"value\\\":1442840704,\\\"description\\\":\\\"(Syscall)\\\"},\\\"pc\\\":{\\\"value\\\":6719705844},\\\"far\\\":{\\\"value\\\":0}}},{\\\"id\\\":43486,\\\"frames\\\":[{\\\"imageOffset\\\":28464,\\\"symbol\\\":\\\"kevent\\\",\\\"symbolLocation\\\":8,\\\"imageIndex\\\":4},{\\\"imageOffset\\\":3763880,\\\"imageIndex\\\":0}],\\\"threadState\\\":{\\\"x\\\":[{\\\"value\\\":4},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":6101099864},{\\\"value\\\":64},{\\\"value\\\":6101099816},{\\\"value\\\":0},{\\\"value\\\":1385164689166},{\\\"value\\\":1374389954816},{\\\"value\\\":1},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":1},{\\\"value\\\":6101099600},{\\\"value\\\":2},{\\\"value\\\":37769773056},{\\\"value\\\":363},{\\\"value\\\":6101099840},{\\\"value\\\":0},{\\\"value\\\":6101101704},{\\\"value\\\":6101099712},{\\\"value\\\":3},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":4384490744},{\\\"value\\\":4390768640},{\\\"value\\\":1374389546240}],\\\"flavor\\\":\\\"ARM_THREAD_STATE64\\\",\\\"lr\\\":{\\\"value\\\":4372426408},\\\"cpsr\\\":{\\\"value\\\":1610612736},\\\"fp\\\":{\\\"value\\\":6101099576},\\\"sp\\\":{\\\"value\\\":6101099584},\\\"esr\\\":{\\\"value\\\":1442840704,\\\"description\\\":\\\"(Syscall)\\\"},\\\"pc\\\":{\\\"value\\\":6719717168},\\\"far\\\":{\\\"value\\\":0}}},{\\\"id\\\":43487,\\\"frames\\\":[{\\\"imageOffset\\\":17656,\\\"symbol\\\":\\\"__psynch_cvwait\\\",\\\"symbolLocation\\\":8,\\\"imageIndex\\\":4},{\\\"imageOffset\\\":28892,\\\"symbol\\\":\\\"_pthread_cond_wait\\\",\\\"symbolLocation\\\":984,\\\"imageIndex\\\":5},{\\\"imageOffset\\\":3764584,\\\"imageIndex\\\":0},{\\\"imageOffset\\\":3758712,\\\"imageIndex\\\":0},{\\\"imageOffset\\\":3596551104,\\\"imageIndex\\\":15}],\\\"threadState\\\":{\\\"x\\\":[{\\\"value\\\":260},{\\\"value\\\":0},{\\\"value\\\":1536},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":160},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":6101691256},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":2},{\\\"value\\\":2},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":305},{\\\"value\\\":8565333952},{\\\"value\\\":0},{\\\"value\\\":1374389956808},{\\\"value\\\":1374389956872},{\\\"value\\\":6101692640},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":1536},{\\\"value\\\":1537},{\\\"value\\\":1792},{\\\"value\\\":32},{\\\"value\\\":1374389548320}],\\\"flavor\\\":\\\"ARM_THREAD_STATE64\\\",\\\"lr\\\":{\\\"value\\\":6719967452},\\\"cpsr\\\":{\\\"value\\\":1610612736},\\\"fp\\\":{\\\"value\\\":6101691376},\\\"sp\\\":{\\\"value\\\":6101691232},\\\"esr\\\":{\\\"value\\\":1442840704,\\\"description\\\":\\\"(Syscall)\\\"},\\\"pc\\\":{\\\"value\\\":6719706360},\\\"far\\\":{\\\"value\\\":0}}},{\\\"id\\\":43488,\\\"frames\\\":[{\\\"imageOffset\\\":17656,\\\"symbol\\\":\\\"__psynch_cvwait\\\",\\\"symbolLocation\\\":8,\\\"imageIndex\\\":4},{\\\"imageOffset\\\":28892,\\\"symbol\\\":\\\"_pthread_cond_wait\\\",\\\"symbolLocation\\\":984,\\\"imageIndex\\\":5},{\\\"imageOffset\\\":3764584,\\\"imageIndex\\\":0},{\\\"imageOffset\\\":3758712,\\\"imageIndex\\\":0},{\\\"imageOffset\\\":3596551104,\\\"imageIndex\\\":15}],\\\"threadState\\\":{\\\"x\\\":[{\\\"value\\\":260},{\\\"value\\\":0},{\\\"value\\\":1536},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":160},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":6102297464},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":2},{\\\"value\\\":2},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":305},{\\\"value\\\":8565333952},{\\\"value\\\":0},{\\\"value\\\":1374390584136},{\\\"value\\\":1374390584200},{\\\"value\\\":6102298848},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":1536},{\\\"value\\\":1537},{\\\"value\\\":1792},{\\\"value\\\":18446744073709551520},{\\\"value\\\":1374390591904}],\\\"flavor\\\":\\\"ARM_THREAD_STATE64\\\",\\\"lr\\\":{\\\"value\\\":6719967452},\\\"cpsr\\\":{\\\"value\\\":1610612736},\\\"fp\\\":{\\\"value\\\":6102297584},\\\"sp\\\":{\\\"value\\\":6102297440},\\\"esr\\\":{\\\"value\\\":1442840704,\\\"description\\\":\\\"(Syscall)\\\"},\\\"pc\\\":{\\\"value\\\":6719706360},\\\"far\\\":{\\\"value\\\":0}}},{\\\"id\\\":43489,\\\"frames\\\":[{\\\"imageOffset\\\":17656,\\\"symbol\\\":\\\"__psynch_cvwait\\\",\\\"symbolLocation\\\":8,\\\"imageIndex\\\":4},{\\\"imageOffset\\\":28892,\\\"symbol\\\":\\\"_pthread_cond_wait\\\",\\\"symbolLocation\\\":984,\\\"imageIndex\\\":5},{\\\"imageOffset\\\":3764584,\\\"imageIndex\\\":0},{\\\"imageOffset\\\":3758712,\\\"imageIndex\\\":0},{\\\"imageOffset\\\":3596551104,\\\"imageIndex\\\":15}],\\\"threadState\\\":{\\\"x\\\":[{\\\"value\\\":260},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":160},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":6102887672},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":2},{\\\"value\\\":2},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":305},{\\\"value\\\":8565333952},{\\\"value\\\":0},{\\\"value\\\":1374389957960},{\\\"value\\\":1374389958024},{\\\"value\\\":6102888672},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":1},{\\\"value\\\":256},{\\\"value\\\":96},{\\\"value\\\":1374389549152}],\\\"flavor\\\":\\\"ARM_THREAD_STATE64\\\",\\\"lr\\\":{\\\"value\\\":6719967452},\\\"cpsr\\\":{\\\"value\\\":1610612736},\\\"fp\\\":{\\\"value\\\":6102887792},\\\"sp\\\":{\\\"value\\\":6102887648},\\\"esr\\\":{\\\"value\\\":1442840704,\\\"description\\\":\\\"(Syscall)\\\"},\\\"pc\\\":{\\\"value\\\":6719706360},\\\"far\\\":{\\\"value\\\":0}}},{\\\"id\\\":43499,\\\"frames\\\":[],\\\"threadState\\\":{\\\"x\\\":[{\\\"value\\\":6103461888},{\\\"value\\\":18947},{\\\"value\\\":6102925312},{\\\"value\\\":0},{\\\"value\\\":409604},{\\\"value\\\":18446744073709551615},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0}],\\\"flavor\\\":\\\"ARM_THREAD_STATE64\\\",\\\"lr\\\":{\\\"value\\\":0},\\\"cpsr\\\":{\\\"value\\\":0},\\\"fp\\\":{\\\"value\\\":0},\\\"sp\\\":{\\\"value\\\":6103461888},\\\"esr\\\":{\\\"value\\\":1442840704,\\\"description\\\":\\\"(Syscall)\\\"},\\\"pc\\\":{\\\"value\\\":6719945620},\\\"far\\\":{\\\"value\\\":0}}},{\\\"id\\\":43500,\\\"frames\\\":[{\\\"imageOffset\\\":17656,\\\"symbol\\\":\\\"__psynch_cvwait\\\",\\\"symbolLocation\\\":8,\\\"imageIndex\\\":4},{\\\"imageOffset\\\":28892,\\\"symbol\\\":\\\"_pthread_cond_wait\\\",\\\"symbolLocation\\\":984,\\\"imageIndex\\\":5},{\\\"imageOffset\\\":3764584,\\\"imageIndex\\\":0},{\\\"imageOffset\\\":3758712,\\\"imageIndex\\\":0},{\\\"imageOffset\\\":3596551104,\\\"imageIndex\\\":15}],\\\"threadState\\\":{\\\"x\\\":[{\\\"value\\\":260},{\\\"value\\\":0},{\\\"value\\\":512},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":160},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":6104066984},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":2},{\\\"value\\\":2},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":305},{\\\"value\\\":8565333952},{\\\"value\\\":0},{\\\"value\\\":1374391632712},{\\\"value\\\":1374391632776},{\\\"value\\\":6104068320},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":512},{\\\"value\\\":513},{\\\"value\\\":768},{\\\"value\\\":18446744073709551520},{\\\"value\\\":1374391640480}],\\\"flavor\\\":\\\"ARM_THREAD_STATE64\\\",\\\"lr\\\":{\\\"value\\\":6719967452},\\\"cpsr\\\":{\\\"value\\\":1610612736},\\\"fp\\\":{\\\"value\\\":6104067104},\\\"sp\\\":{\\\"value\\\":6104066960},\\\"esr\\\":{\\\"value\\\":1442840704,\\\"description\\\":\\\"(Syscall)\\\"},\\\"pc\\\":{\\\"value\\\":6719706360},\\\"far\\\":{\\\"value\\\":0}}},{\\\"id\\\":43501,\\\"frames\\\":[],\\\"threadState\\\":{\\\"x\\\":[{\\\"value\\\":6104641536},{\\\"value\\\":23331},{\\\"value\\\":6104104960},{\\\"value\\\":0},{\\\"value\\\":409604},{\\\"value\\\":18446744073709551615},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":0}],\\\"flavor\\\":\\\"ARM_THREAD_STATE64\\\",\\\"lr\\\":{\\\"value\\\":0},\\\"cpsr\\\":{\\\"value\\\":0},\\\"fp\\\":{\\\"value\\\":0},\\\"sp\\\":{\\\"value\\\":6104641536},\\\"esr\\\":{\\\"value\\\":1442840704,\\\"description\\\":\\\"(Syscall)\\\"},\\\"pc\\\":{\\\"value\\\":6719945620},\\\"far\\\":{\\\"value\\\":0}}},{\\\"id\\\":43504,\\\"name\\\":\\\"com.apple.NSEventThread\\\",\\\"threadState\\\":{\\\"x\\\":[{\\\"value\\\":268451845},{\\\"value\\\":21592279046},{\\\"value\\\":8589934592},{\\\"value\\\":123158187212800},{\\\"value\\\":0},{\\\"value\\\":123158187212800},{\\\"value\\\":2},{\\\"value\\\":4294967295},{\\\"value\\\":0},{\\\"value\\\":17179869184},{\\\"value\\\":0},{\\\"value\\\":2},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":28675},{\\\"value\\\":0},{\\\"value\\\":18446744073709551569},{\\\"value\\\":8565335824},{\\\"value\\\":0},{\\\"value\\\":4294967295},{\\\"value\\\":2},{\\\"value\\\":123158187212800},{\\\"value\\\":0},{\\\"value\\\":123158187212800},{\\\"value\\\":6105211016},{\\\"value\\\":8589934592},{\\\"value\\\":21592279046},{\\\"value\\\":18446744073709550527},{\\\"value\\\":4412409862}],\\\"flavor\\\":\\\"ARM_THREAD_STATE64\\\",\\\"lr\\\":{\\\"value\\\":6719766568},\\\"cpsr\\\":{\\\"value\\\":0},\\\"fp\\\":{\\\"value\\\":6105210864},\\\"sp\\\":{\\\"value\\\":6105210784},\\\"esr\\\":{\\\"value\\\":1442840704,\\\"description\\\":\\\"(Syscall)\\\"},\\\"pc\\\":{\\\"value\\\":6719691828},\\\"far\\\":{\\\"value\\\":0}},\\\"frames\\\":[{\\\"imageOffset\\\":3124,\\\"symbol\\\":\\\"mach_msg2_trap\\\",\\\"symbolLocation\\\":8,\\\"imageIndex\\\":4},{\\\"imageOffset\\\":77864,\\\"symbol\\\":\\\"mach_msg2_internal\\\",\\\"symbolLocation\\\":76,\\\"imageIndex\\\":4},{\\\"imageOffset\\\":39308,\\\"symbol\\\":\\\"mach_msg_overwrite\\\",\\\"symbolLocation\\\":484,\\\"imageIndex\\\":4},{\\\"imageOffset\\\":4020,\\\"symbol\\\":\\\"mach_msg\\\",\\\"symbolLocation\\\":24,\\\"imageIndex\\\":4},{\\\"imageOffset\\\":392320,\\\"symbol\\\":\\\"__CFRunLoopServiceMachPort\\\",\\\"symbolLocation\\\":160,\\\"imageIndex\\\":11},{\\\"imageOffset\\\":386520,\\\"symbol\\\":\\\"__CFRunLoopRun\\\",\\\"symbolLocation\\\":1188,\\\"imageIndex\\\":11},{\\\"imageOffset\\\":1165464,\\\"symbol\\\":\\\"_CFRunLoopRunSpecificWithOptions\\\",\\\"symbolLocation\\\":532,\\\"imageIndex\\\":11},{\\\"imageOffset\\\":719464,\\\"symbol\\\":\\\"_NSEventThread\\\",\\\"symbolLocation\\\":184,\\\"imageIndex\\\":13},{\\\"imageOffset\\\":27656,\\\"symbol\\\":\\\"_pthread_start\\\",\\\"symbolLocation\\\":136,\\\"imageIndex\\\":5},{\\\"imageOffset\\\":7080,\\\"symbol\\\":\\\"thread_start\\\",\\\"symbolLocation\\\":8,\\\"imageIndex\\\":5}]},{\\\"id\\\":43526,\\\"name\\\":\\\"HIE: M_ e0f345a8106056e2 2025-09-16 14:29:59.876\\\",\\\"threadState\\\":{\\\"x\\\":[{\\\"value\\\":0},{\\\"value\\\":8589934595},{\\\"value\\\":103079220499},{\\\"value\\\":243004954691075},{\\\"value\\\":15483357102080},{\\\"value\\\":243004954640384},{\\\"value\\\":44},{\\\"value\\\":0},{\\\"value\\\":6719901696,\\\"symbolLocation\\\":472,\\\"symbol\\\":\\\"mach_voucher_extract_all_attr_recipes\\\"},{\\\"value\\\":1},{\\\"value\\\":48260678783},{\\\"value\\\":7},{\\\"value\\\":7},{\\\"value\\\":37769993952},{\\\"value\\\":8542053000,\\\"symbolLocation\\\":0,\\\"symbol\\\":\\\"_NSConcreteMallocBlock\\\"},{\\\"value\\\":8542053000,\\\"symbolLocation\\\":0,\\\"symbol\\\":\\\"_NSConcreteMallocBlock\\\"},{\\\"value\\\":18446744073709551569},{\\\"value\\\":8565339000},{\\\"value\\\":0},{\\\"value\\\":0},{\\\"value\\\":44},{\\\"value\\\":243004954640384},{\\\"value\\\":15483357102080},{\\\"value\\\":243004954691075},{\\\"value\\\":6105787664},{\\\"value\\\":103079220499},{\\\"value\\\":8589934595},{\\\"value\\\":18446744073709550527},{\\\"value\\\":0}],\\\"flavor\\\":\\\"ARM_THREAD_STATE64\\\",\\\"lr\\\":{\\\"value\\\":6719766568},\\\"cpsr\\\":{\\\"value\\\":2147483648},\\\"fp\\\":{\\\"value\\\":6105787648},\\\"sp\\\":{\\\"value\\\":6105787568},\\\"esr\\\":{\\\"value\\\":1442840704,\\\"description\\\":\\\"(Syscall)\\\"},\\\"pc\\\":{\\\"value\\\":6719691828},\\\"far\\\":{\\\"value\\\":0}},\\\"frames\\\":[{\\\"imageOffset\\\":3124,\\\"symbol\\\":\\\"mach_msg2_trap\\\",\\\"symbolLocation\\\":8,\\\"imageIndex\\\":4},{\\\"imageOffset\\\":77864,\\\"symbol\\\":\\\"mach_msg2_internal\\\",\\\"symbolLocation\\\":76,\\\"imageIndex\\\":4},{\\\"imageOffset\\\":198588,\\\"symbol\\\":\\\"thread_suspend\\\",\\\"symbolLocation\\\":108,\\\"imageIndex\\\":4},{\\\"imageOffset\\\":222284,\\\"symbol\\\":\\\"SOME_OTHER_THREAD_SWALLOWED_AT_LEAST_ONE_EXCEPTION\\\",\\\"symbolLocation\\\":20,\\\"imageIndex\\\":17},{\\\"imageOffset\\\":157520,\\\"symbol\\\":\\\"__NSThread__start__\\\",\\\"symbolLocation\\\":732,\\\"imageIndex\\\":9},{\\\"imageOffset\\\":27656,\\\"symbol\\\":\\\"_pthread_start\\\",\\\"symbolLocation\\\":136,\\\"imageIndex\\\":5},{\\\"imageOffset\\\":7080,\\\"symbol\\\":\\\"thread_start\\\",\\\"symbolLocation\\\":8,\\\"imageIndex\\\":5}]}],\\n \\\"usedImages\\\" : [\\n {\\n \\\"source\\\" : \\\"P\\\",\\n \\\"arch\\\" : \\\"arm64\\\",\\n \\\"base\\\" : 4368662528,\\n \\\"CFBundleShortVersionString\\\" : \\\"1.118.1.1\\\",\\n \\\"CFBundleIdentifier\\\" : \\\"com.west2online.ClashXPro\\\",\\n \\\"size\\\" : 13615104,\\n \\\"uuid\\\" : \\\"4ae041a8-d9a2-337b-92f7-5083d605f8a9\\\",\\n \\\"path\\\" : \\\"\\\\/Applications\\\\/ClashX Pro.app\\\\/Contents\\\\/MacOS\\\\/ClashX Pro\\\",\\n \\\"name\\\" : \\\"ClashX Pro\\\",\\n \\\"CFBundleVersion\\\" : \\\"1.118.1.1\\\"\\n },\\n {\\n \\\"source\\\" : \\\"P\\\",\\n \\\"arch\\\" : \\\"arm64\\\",\\n \\\"base\\\" : 4393156608,\\n \\\"CFBundleShortVersionString\\\" : \\\"2.5.1\\\",\\n \\\"CFBundleIdentifier\\\" : \\\"org.sparkle-project.Sparkle\\\",\\n \\\"size\\\" : 278528,\\n \\\"uuid\\\" : \\\"f6d9e0bb-3dec-34d5-8524-32b314d93248\\\",\\n \\\"path\\\" : \\\"\\\\/Applications\\\\/ClashX Pro.app\\\\/Contents\\\\/Frameworks\\\\/Sparkle.framework\\\\/Versions\\\\/B\\\\/Sparkle\\\",\\n \\\"name\\\" : \\\"Sparkle\\\",\\n \\\"CFBundleVersion\\\" : \\\"2032\\\"\\n },\\n {\\n \\\"source\\\" : \\\"P\\\",\\n \\\"arch\\\" : \\\"arm64e\\\",\\n \\\"base\\\" : 5721456640,\\n \\\"size\\\" : 49152,\\n \\\"uuid\\\" : \\\"580e4b29-8304-342d-a21c-2a869364dc35\\\",\\n \\\"path\\\" : \\\"\\\\/usr\\\\/lib\\\\/libobjc-trampolines.dylib\\\",\\n \\\"name\\\" : \\\"libobjc-trampolines.dylib\\\"\\n },\\n {\\n \\\"source\\\" : \\\"P\\\",\\n \\\"arch\\\" : \\\"arm64e\\\",\\n \\\"base\\\" : 5755502592,\\n \\\"CFBundleShortVersionString\\\" : \\\"340.26.3\\\",\\n \\\"CFBundleIdentifier\\\" : \\\"com.apple.AGXMetalG16G-B0\\\",\\n \\\"size\\\" : 8536064,\\n \\\"uuid\\\" : \\\"2170a88b-3de9-3ecc-927d-9690438526d0\\\",\\n \\\"path\\\" : \\\"\\\\/System\\\\/Library\\\\/Extensions\\\\/AGXMetalG16G_B0.bundle\\\\/Contents\\\\/MacOS\\\\/AGXMetalG16G_B0\\\",\\n \\\"name\\\" : \\\"AGXMetalG16G_B0\\\",\\n \\\"CFBundleVersion\\\" : \\\"340.26.3\\\"\\n },\\n {\\n \\\"source\\\" : \\\"P\\\",\\n \\\"arch\\\" : \\\"arm64e\\\",\\n \\\"base\\\" : 6719688704,\\n \\\"size\\\" : 246880,\\n \\\"uuid\\\" : \\\"2eb73bf1-8c71-3e1f-a160-6da83dc82606\\\",\\n \\\"path\\\" : \\\"\\\\/usr\\\\/lib\\\\/system\\\\/libsystem_kernel.dylib\\\",\\n \\\"name\\\" : \\\"libsystem_kernel.dylib\\\"\\n },\\n {\\n \\\"source\\\" : \\\"P\\\",\\n \\\"arch\\\" : \\\"arm64e\\\",\\n \\\"base\\\" : 6719938560,\\n \\\"size\\\" : 51900,\\n \\\"uuid\\\" : \\\"5d31d65c-2ecf-36da-84f5-ba4caab06adb\\\",\\n \\\"path\\\" : \\\"\\\\/usr\\\\/lib\\\\/system\\\\/libsystem_pthread.dylib\\\",\\n \\\"name\\\" : \\\"libsystem_pthread.dylib\\\"\\n },\\n {\\n \\\"source\\\" : \\\"P\\\",\\n \\\"arch\\\" : \\\"arm64e\\\",\\n \\\"base\\\" : 6718443520,\\n \\\"size\\\" : 532472,\\n \\\"uuid\\\" : \\\"1e2fc910-e211-3a48-90c1-402c82129ea8\\\",\\n \\\"path\\\" : \\\"\\\\/usr\\\\/lib\\\\/system\\\\/libsystem_c.dylib\\\",\\n \\\"name\\\" : \\\"libsystem_c.dylib\\\"\\n },\\n {\\n \\\"source\\\" : \\\"P\\\",\\n \\\"arch\\\" : \\\"arm64e\\\",\\n \\\"base\\\" : 6719578112,\\n \\\"size\\\" : 108848,\\n \\\"uuid\\\" : \\\"1db24a4f-6a19-3415-b7c4-79c43340ec7b\\\",\\n \\\"path\\\" : \\\"\\\\/usr\\\\/lib\\\\/libc++abi.dylib\\\",\\n \\\"name\\\" : \\\"libc++abi.dylib\\\"\\n },\\n {\\n \\\"source\\\" : \\\"P\\\",\\n \\\"arch\\\" : \\\"arm64e\\\",\\n \\\"base\\\" : 6715457536,\\n \\\"size\\\" : 341228,\\n \\\"uuid\\\" : \\\"7443a268-c9f9-3d65-b497-4f8081799514\\\",\\n \\\"path\\\" : \\\"\\\\/usr\\\\/lib\\\\/libobjc.A.dylib\\\",\\n \\\"name\\\" : \\\"libobjc.A.dylib\\\"\\n },\\n {\\n \\\"source\\\" : \\\"P\\\",\\n \\\"arch\\\" : \\\"arm64e\\\",\\n \\\"base\\\" : 6745677824,\\n \\\"CFBundleShortVersionString\\\" : \\\"6.9\\\",\\n \\\"CFBundleIdentifier\\\" : \\\"com.apple.Foundation\\\",\\n \\\"size\\\" : 16302880,\\n \\\"uuid\\\" : \\\"f61e71c3-480f-3691-b656-e1281f60a3e3\\\",\\n \\\"path\\\" : \\\"\\\\/System\\\\/Library\\\\/Frameworks\\\\/Foundation.framework\\\\/Versions\\\\/C\\\\/Foundation\\\",\\n \\\"name\\\" : \\\"Foundation\\\",\\n \\\"CFBundleVersion\\\" : \\\"4040.1.401\\\"\\n },\\n {\\n \\\"source\\\" : \\\"P\\\",\\n \\\"arch\\\" : \\\"arm64e\\\",\\n \\\"base\\\" : 6718140416,\\n \\\"size\\\" : 290464,\\n \\\"uuid\\\" : \\\"17d849c6-a785-3dbb-bfb5-8321706c4b8d\\\",\\n \\\"path\\\" : \\\"\\\\/usr\\\\/lib\\\\/system\\\\/libdispatch.dylib\\\",\\n \\\"name\\\" : \\\"libdispatch.dylib\\\"\\n },\\n {\\n \\\"source\\\" : \\\"P\\\",\\n \\\"arch\\\" : \\\"arm64e\\\",\\n \\\"base\\\" : 6720225280,\\n \\\"CFBundleShortVersionString\\\" : \\\"6.9\\\",\\n \\\"CFBundleIdentifier\\\" : \\\"com.apple.CoreFoundation\\\",\\n \\\"size\\\" : 5558144,\\n \\\"uuid\\\" : \\\"edb39786-80b1-3bff-b6c3-e33f2e3ca867\\\",\\n \\\"path\\\" : \\\"\\\\/System\\\\/Library\\\\/Frameworks\\\\/CoreFoundation.framework\\\\/Versions\\\\/A\\\\/CoreFoundation\\\",\\n \\\"name\\\" : \\\"CoreFoundation\\\",\\n \\\"CFBundleVersion\\\" : \\\"4040.1.401\\\"\\n },\\n {\\n \\\"source\\\" : \\\"P\\\",\\n \\\"arch\\\" : \\\"arm64e\\\",\\n \\\"base\\\" : 6931619840,\\n \\\"CFBundleShortVersionString\\\" : \\\"2.1.1\\\",\\n \\\"CFBundleIdentifier\\\" : \\\"com.apple.HIToolbox\\\",\\n \\\"size\\\" : 3155712,\\n \\\"uuid\\\" : \\\"f369023f-1a24-3f3f-9056-6f5248071e8c\\\",\\n \\\"path\\\" : \\\"\\\\/System\\\\/Library\\\\/Frameworks\\\\/Carbon.framework\\\\/Versions\\\\/A\\\\/Frameworks\\\\/HIToolbox.framework\\\\/Versions\\\\/A\\\\/HIToolbox\\\",\\n \\\"name\\\" : \\\"HIToolbox\\\"\\n },\\n {\\n \\\"source\\\" : \\\"P\\\",\\n \\\"arch\\\" : \\\"arm64e\\\",\\n \\\"base\\\" : 6791712768,\\n \\\"CFBundleShortVersionString\\\" : \\\"6.9\\\",\\n \\\"CFBundleIdentifier\\\" : \\\"com.apple.AppKit\\\",\\n \\\"size\\\" : 24100256,\\n \\\"uuid\\\" : \\\"6d84c7a3-ee98-3daf-ac66-cd95a902ba84\\\",\\n \\\"path\\\" : \\\"\\\\/System\\\\/Library\\\\/Frameworks\\\\/AppKit.framework\\\\/Versions\\\\/C\\\\/AppKit\\\",\\n \\\"name\\\" : \\\"AppKit\\\",\\n \\\"CFBundleVersion\\\" : \\\"2685.10.108\\\"\\n },\\n {\\n \\\"source\\\" : \\\"P\\\",\\n \\\"arch\\\" : \\\"arm64e\\\",\\n \\\"base\\\" : 6716002304,\\n \\\"size\\\" : 651124,\\n \\\"uuid\\\" : \\\"abfd3247-50ac-3c8e-b72a-83710166e982\\\",\\n \\\"path\\\" : \\\"\\\\/usr\\\\/lib\\\\/dyld\\\",\\n \\\"name\\\" : \\\"dyld\\\"\\n },\\n {\\n \\\"size\\\" : 0,\\n \\\"source\\\" : \\\"A\\\",\\n \\\"base\\\" : 0,\\n \\\"uuid\\\" : \\\"00000000-0000-0000-0000-000000000000\\\"\\n },\\n {\\n \\\"source\\\" : \\\"P\\\",\\n \\\"arch\\\" : \\\"arm64e\\\",\\n \\\"base\\\" : 6716985344,\\n \\\"size\\\" : 133088,\\n \\\"uuid\\\" : \\\"28139651-ffe2-3795-95ac-1c7cb27a3a9b\\\",\\n \\\"path\\\" : \\\"\\\\/usr\\\\/lib\\\\/system\\\\/libsystem_trace.dylib\\\",\\n \\\"name\\\" : \\\"libsystem_trace.dylib\\\"\\n },\\n {\\n \\\"source\\\" : \\\"P\\\",\\n \\\"arch\\\" : \\\"arm64e\\\",\\n \\\"base\\\" : 6843781120,\\n \\\"CFBundleShortVersionString\\\" : \\\"1.22\\\",\\n \\\"CFBundleIdentifier\\\" : \\\"com.apple.HIServices\\\",\\n \\\"size\\\" : 442880,\\n \\\"uuid\\\" : \\\"fd66e806-cfa4-3e6f-81bd-eefb21be31fe\\\",\\n \\\"path\\\" : \\\"\\\\/System\\\\/Library\\\\/Frameworks\\\\/ApplicationServices.framework\\\\/Versions\\\\/A\\\\/Frameworks\\\\/HIServices.framework\\\\/Versions\\\\/A\\\\/HIServices\\\",\\n \\\"name\\\" : \\\"HIServices\\\"\\n }\\n],\\n \\\"sharedCache\\\" : {\\n \\\"base\\\" : 6714933248,\\n \\\"size\\\" : 5557583872,\\n \\\"uuid\\\" : \\\"52e4eec0-379e-31c7-ac62-bfed14d90f52\\\"\\n},\\n \\\"vmSummary\\\" : \\\"ReadOnly portion of Libraries: Total=1.7G resident=0K(0%) swapped_out_or_unallocated=1.7G(100%)\\\\nWritable regions: Total=162.5M written=641K(0%) resident=641K(0%) swapped_out=0K(0%) unallocated=161.9M(100%)\\\\n\\\\n VIRTUAL REGION \\\\nREGION TYPE SIZE COUNT (non-coalesced) \\\\n=========== ======= ======= \\\\nActivity Tracing 256K 1 \\\\nColorSync 560K 26 \\\\nCoreGraphics 32K 2 \\\\nCoreGraphics (reserved) 16K 1 reserved VM address space (unallocated)\\\\nFoundation 16K 1 \\\\nImage IO 32K 2 \\\\nKernel Alloc Once 32K 1 \\\\nMALLOC 105.1M 19 \\\\nMALLOC guard page 4096K 4 \\\\nSTACK GUARD 56.2M 14 \\\\nStack 15.0M 14 \\\\nVM_ALLOCATE 1.2G 46 \\\\nVM_ALLOCATE (reserved) 4.0G 1 reserved VM address space (unallocated)\\\\n__AUTH 5592K 612 \\\\n__AUTH_CONST 86.2M 991 \\\\n__CTF 824 1 \\\\n__DATA 28.9M 941 \\\\n__DATA_CONST 39.9M 1000 \\\\n__DATA_DIRTY 8229K 855 \\\\n__FONT_DATA 2352 1 \\\\n__INFO_FILTER 8 1 \\\\n__LINKEDIT 596.5M 5 \\\\n__OBJC_RO 78.1M 1 \\\\n__OBJC_RW 2561K 1 \\\\n__TEXT 1.1G 1023 \\\\n__TEXT (graphics) 13.0M 1 \\\\n__TPRO_CONST 128K 2 \\\\nmapped file 275.7M 28 \\\\npage table in kernel 641K 1 \\\\nshared memory 1376K 12 \\\\n=========== ======= ======= \\\\nTOTAL 7.6G 5608 \\\\nTOTAL, minus reserved VM space 3.6G 5608 \\\\n\\\",\\n \\\"legacyInfo\\\" : {\\n \\\"threadTriggered\\\" : {\\n\\n }\\n},\\n \\\"logWritingSignature\\\" : \\\"202451bcbcb8837efde73c96a0364db57df74c52\\\",\\n \\\"trialInfo\\\" : {\\n \\\"rollouts\\\" : [\\n {\\n \\\"rolloutId\\\" : \\\"64c17a9925d75a7281053d4c\\\",\\n \\\"factorPackIds\\\" : [\\n \\\"64d29746ad29a465b3bbeace\\\"\\n ],\\n \\\"deploymentId\\\" : 240000002\\n },\\n {\\n \\\"rolloutId\\\" : \\\"60f8ddccefea4203d95cbeef\\\",\\n \\\"factorPackIds\\\" : [\\n\\n ],\\n \\\"deploymentId\\\" : 240000025\\n }\\n ],\\n \\\"experiments\\\" : [\\n {\\n \\\"treatmentId\\\" : \\\"f18344bb-554f-48ae-8449-e108a8813a55\\\",\\n \\\"experimentId\\\" : \\\"6685b5584477001000e8c6c9\\\",\\n \\\"deploymentId\\\" : 400000009\\n }\\n ]\\n}\\n}\\n```\"},{\"role\":\"assistant\",\"mainText\":\"Let's break this down and debug the root cause. \\nYour main clues:\\n\\n- **App:** ClashX Pro 1.118.1.1\\n- **macOS:** 26.0 (Tahoe, build 25A354)\\n- **Crash Reason:** \\n - The app doesn't launch.\\n - Error message: `\\\"origin config has been renamed\\\"`\\n - Crash: `abort() called` from Foundation's `-[NSConcreteTask launchWithDictionary:error:]`\\n - The exception stack: \\n ```\\n 2 Foundation -[NSConcreteTask launchWithDictionary:error:] + 3976\\n 3 ClashX Pro 0x1046a4680 ...\\n ```\\n - `objc_exception_throw` is called.\\n\\n---\\n\\n## What does this mean?\\n\\n### 1. **\\\"origin config has been renamed\\\"**\\n\\n- This is almost certainly a message from ClashX Pro or (more likely) the underlying [Clash](https://github.com/Dreamacro/clash) core it uses.\\n- In recent versions of Clash, the `-f`/`--config` argument has been renamed from `origin config` to just `config`.\\n- Some wrappers or launchers that shell out to the Clash binary (or expect a certain config path) may break if they hardcode the old argument name.\\n- On macOS 26, it's possible Apple has updated some Foundation APIs or changed how tasks/arguments are parsed, making previously ignored errors now fatal.\\n\\n### 2. **The exception is thrown from `-[NSConcreteTask launchWithDictionary:error:]`**\\n\\n- This is the Objective-C API for launching subprocesses.\\n- If you give it an invalid path or an argument that isn't accepted by the binary, it throws.\\n- The error is not handled by ClashX Pro, so it aborts.\\n\\n### 3. **Crash context**\\n\\n- The crash is at app startup, before any UI appears.\\n- This means ClashX Pro is likely trying to start the `clash` core binary with a config file, and is using an argument or config key that is now invalid.\\n\\n---\\n\\n## What changed?\\n\\n### **macOS 26 and Foundation**\\n\\n- Foundation and process spawning is stricter.\\n- Errors in argument parsing or file paths that previously may have been ignored/warned are now fatal.\\n\\n### **Clash core**\\n\\n- The core binary changed its config argument name.\\n- If ClashX Pro is outdated (or has a hardcoded argument), it breaks.\\n\\n---\\n\\n## **What to do?**\\n\\n### **For End Users:**\\n\\n#### 1. **Update ClashX Pro**\\n- **Check for a new version**: \\n Go to [ClashX Pro releases](https://github.com/yichengchen/clashX/releases) and download the latest version. \\n - macOS 26 is very new; the developer may have released an update to fix this compatibility issue.\\n\\n#### 2. **Workaround (Advanced Users):**\\n- If you can't update, you can try to patch the Clash core binary or the config file, but this is not recommended for most users.\\n\\n### **For Developers:**\\n\\n#### 1. **Update Your Code**\\n- **Find where you launch the Clash core binary** (usually via `NSTask` or `Process`).\\n- **Check the arguments:** \\n - If you use `--origin-config` or similar, **change it to the new argument name** (likely `--config`).\\n - If you pass a config dictionary or file, **make sure the key is now `config`, not `origin config`**.\\n\\n#### 2. **Handle Errors Gracefully**\\n- Catch exceptions when launching tasks, and show a clear error to the user.\\n\\n#### 3. **Test on macOS 26**\\n- Foundation may now throw for things that used to be warnings.\\n\\n---\\n\\n## **Summary Table**\\n\\n| Problem | Cause | Solution |\\n|---------|-------|----------|\\n| \\\"origin config has been renamed\\\" error | Clash core/config argument changed; app uses old name | Update ClashX Pro or patch argument to `config` |\\n| Crash in `-[NSConcreteTask launchWithDictionary:error:]` | Bad argument or config path; unhandled exception | Update code to use correct argument and handle errors |\\n\\n---\\n\\n## **References**\\n\\n- [Clash core v1.18.0+ changelog](https://github.com/Dreamacro/clash/releases) — config argument changes\\n- [ClashX Pro issues](https://github.com/yichengchen/clashX/issues) — search for \\\"origin config\\\"\\n- [NSTask launchWithDictionary:error:](https://developer.apple.com/documentation/foundation/nstask/3131931-launchwithdictionary) — stricter in new Foundation\\n\\n---\\n\\n## **TL;DR**\\n\\n**Your version of ClashX Pro is using an outdated argument/config format for the Clash core binary, which is now rejected on both the latest Clash core and due to stricter error handling in macOS 26. Update ClashX Pro, or if you are the developer, change all references to `origin config` to `config`.**\\n\\n---\\n\\nIf you need help patching the code or finding where to change this in an open-source fork, let me know!\"}]"
}
]Response:
Debug - ConfigRename
Model: gpt-4.1-2025-04-142025-09-16 06:30:58
Context:
[
{
"role": "user",
"content": "I just updated to macOS Tahoe 26 and my application doesn't launch. It complains \"origin config has been renamed\". And this is the crash report. Check it and debug what's wrong.\n\n```\n-------------------------------------\nTranslated Report (Full Report Below)\n-------------------------------------\nProcess: ClashX Pro [4380]\nPath: /Applications/ClashX Pro.app/Contents/MacOS/ClashX Pro\nIdentifier: com.west2online.ClashXPro\nVersion: 1.118.1.1 (1.118.1.1)\nCode Type: ARM-64 (Native)\nRole: Default\nParent Process: launchd [1]\nCoalition: com.west2online.ClashXPro [1781]\nUser ID: 501\n\nDate/Time: 2025-09-16 14:29:59.8794 +0800\nLaunch Time: 2025-09-16 14:29:59.7105 +0800\nHardware Model: Mac16,10\nOS Version: macOS 26.0 (25A354)\nRelease Type: User\n\nCrash Reporter Key: 1542C1AD-5B7A-094E-6414-2D0080ED3E3B\nIncident Identifier: 693C641C-16AE-4644-B652-2AC8EFC9ECB1\n\nTime Awake Since Boot: 1300 seconds\n\nSystem Integrity Protection: enabled\n\nTriggered by Thread: 0\n\nException Type: EXC_CRASH (SIGABRT)\nException Codes: 0x0000000000000000, 0x0000000000000000\n\nTermination Reason: Namespace SIGNAL, Code 6, Abort trap: 6\nTerminating Process: ClashX Pro [4380]\n\n\nApplication Specific Information:\nabort() called\n\n\nLast Exception Backtrace:\n0 CoreFoundation \t 0x190998764 __exceptionPreprocess + 164\n1 libobjc.A.dylib \t 0x190476418 objc_exception_throw + 88\n2 Foundation \t 0x192bba85c -[NSConcreteTask launchWithDictionary:error:] + 3976\n3 ClashX Pro \t 0x1046a4680 0x104648000 + 378496\n4 ClashX Pro \t 0x1046a7a54 0x104648000 + 391764\n5 ClashX Pro \t 0x1046a7790 0x104648000 + 391056\n6 ClashX Pro \t 0x1046a7094 0x104648000 + 389268\n7 ClashX Pro \t 0x10466b368 0x104648000 + 144232\n8 ClashX Pro \t 0x1046698e4 0x104648000 + 137444\n9 ClashX Pro \t 0x104677828 0x104648000 + 194600\n10 ClashX Pro \t 0x104694ee4 0x104648000 + 315108\n11 libdispatch.dylib \t 0x1906ecb5c _dispatch_call_block_and_release + 32\n12 libdispatch.dylib \t 0x190706ac4 _dispatch_client_callout + 16\n13 libdispatch.dylib \t 0x1907240e4 _dispatch_main_queue_drain.cold.5 + 812\n14 libdispatch.dylib \t 0x1906fbf48 _dispatch_main_queue_drain + 180\n15 libdispatch.dylib \t 0x1906fbe84 _dispatch_main_queue_callback_4CF + 44\n16 CoreFoundation \t 0x190974098 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 16\n17 CoreFoundation \t 0x1909468cc __CFRunLoopRun + 1944\n18 CoreFoundation \t 0x190a04898 _CFRunLoopRunSpecificWithOptions + 532\n19 HIToolbox \t 0x19d343730 RunCurrentEventLoopInMode + 316\n20 HIToolbox \t 0x19d3469d0 ReceiveNextEventCommon + 488\n21 HIToolbox \t 0x19d4d01f4 _BlockUntilNextEventMatchingListInMode + 48\n22 AppKit \t 0x19521e308 _DPSBlockUntilNextEventMatchingListInMode + 236\n23 AppKit \t 0x194d34edc _DPSNextEvent + 588\n24 AppKit \t 0x195787a04 -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 688\n25 AppKit \t 0x195787710 -[NSApplication(NSEventRouting) nextEventMatchingMask:untilDate:inMode:dequeue:] + 72\n26 AppKit \t 0x194d2d720 -[NSApplication run] + 368\n27 AppKit \t 0x194d19694 NSApplicationMain + 880\n28 ClashX Pro \t 0x1046734e8 0x104648000 + 177384\n29 dyld \t 0x1904e9d54 start + 7184\n\nThread 0 Crashed:\n0 libsystem_kernel.dylib \t 0x19086e5b0 __pthread_kill + 8\n1 libsystem_pthread.dylib \t 0x1908a8888 pthread_kill + 296\n2 libsystem_c.dylib \t 0x1907ae808 abort + 124\n3 libc++abi.dylib \t 0x19085c858 __abort_message + 132\n4 libc++abi.dylib \t 0x19084b4d4 demangling_terminate_handler() + 304\n5 libobjc.A.dylib \t 0x190480464 _objc_terminate() + 156\n6 libc++abi.dylib \t 0x19085bc2c std::__terminate(void (*)()) + 16\n7 libc++abi.dylib \t 0x19085f394 __cxxabiv1::failed_throw(__cxxabiv1::__cxa_exception*) + 88\n8 libc++abi.dylib \t 0x19085f33c __cxa_throw + 92\n9 libobjc.A.dylib \t 0x190476580 objc_exception_throw + 448\n10 Foundation \t 0x192bba85c -[NSConcreteTask launchWithDictionary:error:] + 3976\n11 ClashX Pro \t 0x1046a4680 0x104648000 + 378496\n12 ClashX Pro \t 0x1046a7a54 0x104648000 + 391764\n13 ClashX Pro \t 0x1046a7790 0x104648000 + 391056\n14 ClashX Pro \t 0x1046a7094 0x104648000 + 389268\n15 ClashX Pro \t 0x10466b368 0x104648000 + 144232\n16 ClashX Pro \t 0x1046698e4 0x104648000 + 137444\n17 ClashX Pro \t 0x104677828 0x104648000 + 194600\n18 ClashX Pro \t 0x104694ee4 0x104648000 + 315108\n19 libdispatch.dylib \t 0x1906ecb5c _dispatch_call_block_and_release + 32\n20 libdispatch.dylib \t 0x190706ac4 _dispatch_client_callout + 16\n21 libdispatch.dylib \t 0x1907240e4 _dispatch_main_queue_drain.cold.5 + 812\n22 libdispatch.dylib \t 0x1906fbf48 _dispatch_main_queue_drain + 180\n23 libdispatch.dylib \t 0x1906fbe84 _dispatch_main_queue_callback_4CF + 44\n24 CoreFoundation \t 0x190974098 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 16\n25 CoreFoundation \t 0x1909468cc __CFRunLoopRun + 1944\n26 CoreFoundation \t 0x190a04898 _CFRunLoopRunSpecificWithOptions + 532\n27 HIToolbox \t 0x19d343730 RunCurrentEventLoopInMode + 316\n28 HIToolbox \t 0x19d3469d0 ReceiveNextEventCommon + 488\n29 HIToolbox \t 0x19d4d01f4 _BlockUntilNextEventMatchingListInMode + 48\n30 AppKit \t 0x19521e308 _DPSBlockUntilNextEventMatchingListInMode + 236\n31 AppKit \t 0x194d34edc _DPSNextEvent + 588\n32 AppKit \t 0x195787a04 -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 688\n33 AppKit \t 0x195787710 -[NSApplication(NSEventRouting) nextEventMatchingMask:untilDate:inMode:dequeue:] + 72\n34 AppKit \t 0x194d2d720 -[NSApplication run] + 368\n35 AppKit \t 0x194d19694 NSApplicationMain + 880\n36 ClashX Pro \t 0x1046734e8 0x104648000 + 177384\n37 dyld \t 0x1904e9d54 start + 7184\n\nThread 1:\n\nThread 2:\n0 libsystem_kernel.dylib \t 0x190867ae4 __ulock_wait + 8\n1 libdispatch.dylib \t 0x1906eecec _dlock_wait + 56\n2 libdispatch.dylib \t 0x1906eeb0c _dispatch_thread_event_wait_slow + 56\n3 libdispatch.dylib \t 0x1906fcc20 __DISPATCH_WAIT_FOR_QUEUE__ + 368\n4 libdispatch.dylib \t 0x1906fc7d8 _dispatch_sync_f_slow + 148\n5 libsystem_trace.dylib \t 0x1905dd1a8 ___os_state_request_for_self_block_invoke + 372\n6 libdispatch.dylib \t 0x1906ecb5c _dispatch_call_block_and_release + 32\n7 libdispatch.dylib \t 0x190706ac4 _dispatch_client_callout + 16\n8 libdispatch.dylib \t 0x1906f54e8 _dispatch_lane_serial_drain + 740\n9 libdispatch.dylib \t 0x1906f5ff8 _dispatch_lane_invoke + 440\n10 libdispatch.dylib \t 0x190700474 _dispatch_root_queue_drain_deferred_wlh + 292\n11 libdispatch.dylib \t 0x1906ffd6c _dispatch_workloop_worker_thread + 692\n12 libsystem_pthread.dylib \t 0x1908a4e4c _pthread_wqthread + 292\n13 libsystem_pthread.dylib \t 0x1908a3b9c start_wqthread + 8\n\nThread 3:\n0 libsystem_kernel.dylib \t 0x1908694f8 __psynch_cvwait + 8\n1 libsystem_pthread.dylib \t 0x1908a90dc _pthread_cond_wait + 984\n2 ClashX Pro \t 0x1049df168 0x104648000 + 3764584\n3 ClashX Pro \t 0x1049dda78 0x104648000 + 3758712\n4 ??? \t 0xd65f03c0 ???\n\nThread 4:\n0 libsystem_kernel.dylib \t 0x1908692f4 __semwait_signal + 8\n1 libsystem_c.dylib \t 0x190742d6c nanosleep + 220\n2 libsystem_c.dylib \t 0x190742c84 usleep + 68\n3 ClashX Pro \t 0x1049dede4 0x104648000 + 3763684\n4 ClashX Pro \t 0x1049dda78 0x104648000 + 3758712\n\nThread 5:\n0 libsystem_kernel.dylib \t 0x19086bf30 kevent + 8\n1 ClashX Pro \t 0x1049deea8 0x104648000 + 3763880\n\nThread 6:\n0 libsystem_kernel.dylib \t 0x1908694f8 __psynch_cvwait + 8\n1 libsystem_pthread.dylib \t 0x1908a90dc _pthread_cond_wait + 984\n2 ClashX Pro \t 0x1049df168 0x104648000 + 3764584\n3 ClashX Pro \t 0x1049dda78 0x104648000 + 3758712\n4 ??? \t 0xd65f03c0 ???\n\nThread 7:\n0 libsystem_kernel.dylib \t 0x1908694f8 __psynch_cvwait + 8\n1 libsystem_pthread.dylib \t 0x1908a90dc _pthread_cond_wait + 984\n2 ClashX Pro \t 0x1049df168 0x104648000 + 3764584\n3 ClashX Pro \t 0x1049dda78 0x104648000 + 3758712\n4 ??? \t 0xd65f03c0 ???\n\nThread 8:\n0 libsystem_kernel.dylib \t 0x1908694f8 __psynch_cvwait + 8\n1 libsystem_pthread.dylib \t 0x1908a90dc _pthread_cond_wait + 984\n2 ClashX Pro \t 0x1049df168 0x104648000 + 3764584\n3 ClashX Pro \t 0x1049dda78 0x104648000 + 3758712\n4 ??? \t 0xd65f03c0 ???\n\nThread 9:\n\nThread 10:\n0 libsystem_kernel.dylib \t 0x1908694f8 __psynch_cvwait + 8\n1 libsystem_pthread.dylib \t 0x1908a90dc _pthread_cond_wait + 984\n2 ClashX Pro \t 0x1049df168 0x104648000 + 3764584\n3 ClashX Pro \t 0x1049dda78 0x104648000 + 3758712\n4 ??? \t 0xd65f03c0 ???\n\nThread 11:\n\nThread 12:: com.apple.NSEventThread\n0 libsystem_kernel.dylib \t 0x190865c34 mach_msg2_trap + 8\n1 libsystem_kernel.dylib \t 0x190878028 mach_msg2_internal + 76\n2 libsystem_kernel.dylib \t 0x19086e98c mach_msg_overwrite + 484\n3 libsystem_kernel.dylib \t 0x190865fb4 mach_msg + 24\n4 CoreFoundation \t 0x190947c80 __CFRunLoopServiceMachPort + 160\n5 CoreFoundation \t 0x1909465d8 __CFRunLoopRun + 1188\n6 CoreFoundation \t 0x190a04898 _CFRunLoopRunSpecificWithOptions + 532\n7 AppKit \t 0x194dc4a68 _NSEventThread + 184\n8 libsystem_pthread.dylib \t 0x1908a8c08 _pthread_start + 136\n9 libsystem_pthread.dylib \t 0x1908a3ba8 thread_start + 8\n\nThread 13:: HIE: M_ e0f345a8106056e2 2025-09-16 14:29:59.876\n0 libsystem_kernel.dylib \t 0x190865c34 mach_msg2_trap + 8\n1 libsystem_kernel.dylib \t 0x190878028 mach_msg2_internal + 76\n2 libsystem_kernel.dylib \t 0x1908957bc thread_suspend + 108\n3 HIServices \t 0x197ef344c SOME_OTHER_THREAD_SWALLOWED_AT_LEAST_ONE_EXCEPTION + 20\n4 Foundation \t 0x192154750 __NSThread__start__ + 732\n5 libsystem_pthread.dylib \t 0x1908a8c08 _pthread_start + 136\n6 libsystem_pthread.dylib \t 0x1908a3ba8 thread_start + 8\n\n\nThread 0 crashed with ARM Thread State (64-bit):\n x0: 0x0000000000000000 x1: 0x0000000000000000 x2: 0x0000000000000000 x3: 0x0000000000000000\n x4: 0x0000000190861007 x5: 0x000000016b7b4240 x6: 0x000000000000006e x7: 0xfffff0003ffff800\n x8: 0x6465def6fd57567a x9: 0x6465def700721e7a x10: 0x0000000000000051 x11: 0x000000000000000b\n x12: 0x000000000000000b x13: 0x0000000190d6f0d4 x14: 0x00000001064cc9b8 x15: 0x0000000bea020000\n x16: 0x0000000000000148 x17: 0x00000001fe88a008 x18: 0x0000000000000000 x19: 0x0000000000000006\n x20: 0x0000000000000103 x21: 0x00000001fd2548e0 x22: 0x00000001fb14c000 x23: 0x00000008cb4a0d00\n x24: 0x00000008cb4a0d00 x25: 0x00000008cb696800 x26: 0x0000000105b1b000 x27: 0x0000000000000000\n x28: 0x00000001feaa9678 fp: 0x000000016b7b41b0 lr: 0x00000001908a8888\n sp: 0x000000016b7b4190 pc: 0x000000019086e5b0 cpsr: 0x40000000\n far: 0x0000000000000000 esr: 0x56000080 (Syscall)\n\nBinary Images:\n 0x104648000 - 0x105343fff com.west2online.ClashXPro (1.118.1.1) <4ae041a8-d9a2-337b-92f7-5083d605f8a9> /Applications/ClashX Pro.app/Contents/MacOS/ClashX Pro\n 0x105da4000 - 0x105de7fff org.sparkle-project.Sparkle (2.5.1) <f6d9e0bb-3dec-34d5-8524-32b314d93248> /Applications/ClashX Pro.app/Contents/Frameworks/Sparkle.framework/Versions/B/Sparkle\n 0x155068000 - 0x155073fff libobjc-trampolines.dylib (*) <580e4b29-8304-342d-a21c-2a869364dc35> /usr/lib/libobjc-trampolines.dylib\n 0x1570e0000 - 0x157903fff com.apple.AGXMetalG16G-B0 (340.26.3) <2170a88b-3de9-3ecc-927d-9690438526d0> /System/Library/Extensions/AGXMetalG16G_B0.bundle/Contents/MacOS/AGXMetalG16G_B0\n 0x190865000 - 0x1908a145f libsystem_kernel.dylib (*) <2eb73bf1-8c71-3e1f-a160-6da83dc82606> /usr/lib/system/libsystem_kernel.dylib\n 0x1908a2000 - 0x1908aeabb libsystem_pthread.dylib (*) <5d31d65c-2ecf-36da-84f5-ba4caab06adb> /usr/lib/system/libsystem_pthread.dylib\n 0x190735000 - 0x1907b6ff7 libsystem_c.dylib (*) <1e2fc910-e211-3a48-90c1-402c82129ea8> /usr/lib/system/libsystem_c.dylib\n 0x19084a000 - 0x19086492f libc++abi.dylib (*) <1db24a4f-6a19-3415-b7c4-79c43340ec7b> /usr/lib/libc++abi.dylib\n 0x19045c000 - 0x1904af4eb libobjc.A.dylib (*) <7443a268-c9f9-3d65-b497-4f8081799514> /usr/lib/libobjc.A.dylib\n 0x19212e000 - 0x1930ba31f com.apple.Foundation (6.9) <f61e71c3-480f-3691-b656-e1281f60a3e3> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation\n 0x1906eb000 - 0x190731e9f libdispatch.dylib (*) <17d849c6-a785-3dbb-bfb5-8321706c4b8d> /usr/lib/system/libdispatch.dylib\n 0x1908e8000 - 0x190e34f7f com.apple.CoreFoundation (6.9) <edb39786-80b1-3bff-b6c3-e33f2e3ca867> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation\n 0x19d282000 - 0x19d5846ff com.apple.HIToolbox (2.1.1) <f369023f-1a24-3f3f-9056-6f5248071e8c> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox\n 0x194d15000 - 0x196410d9f com.apple.AppKit (6.9) <6d84c7a3-ee98-3daf-ac66-cd95a902ba84> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit\n 0x1904e1000 - 0x19057ff73 dyld (*) <abfd3247-50ac-3c8e-b72a-83710166e982> /usr/lib/dyld\n 0x0 - 0xffffffffffffffff ??? (*) <00000000-0000-0000-0000-000000000000> ???\n 0x1905d1000 - 0x1905f17df libsystem_trace.dylib (*) <28139651-ffe2-3795-95ac-1c7cb27a3a9b> /usr/lib/system/libsystem_trace.dylib\n 0x197ebd000 - 0x197f291ff com.apple.HIServices (1.22) <fd66e806-cfa4-3e6f-81bd-eefb21be31fe> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices\n\nExternal Modification Summary:\n Calls made by other processes targeting this process:\n task_for_pid: 0\n thread_create: 0\n thread_set_state: 0\n Calls made by this process:\n task_for_pid: 0\n thread_create: 0\n thread_set_state: 0\n Calls made by all processes on this machine:\n task_for_pid: 0\n thread_create: 0\n thread_set_state: 0\n\nVM Region Summary:\nReadOnly portion of Libraries: Total=1.7G resident=0K(0%) swapped_out_or_unallocated=1.7G(100%)\nWritable regions: Total=162.5M written=641K(0%) resident=641K(0%) swapped_out=0K(0%) unallocated=161.9M(100%)\n\n VIRTUAL REGION \nREGION TYPE SIZE COUNT (non-coalesced) \n=========== ======= ======= \nActivity Tracing 256K 1 \nColorSync 560K 26 \nCoreGraphics 32K 2 \nCoreGraphics (reserved) 16K 1 reserved VM address space (unallocated)\nFoundation 16K 1 \nImage IO 32K 2 \nKernel Alloc Once 32K 1 \nMALLOC 105.1M 19 \nMALLOC guard page 4096K 4 \nSTACK GUARD 56.2M 14 \nStack 15.0M 14 \nVM_ALLOCATE 1.2G 46 \nVM_ALLOCATE (reserved) 4.0G 1 reserved VM address space (unallocated)\n__AUTH 5592K 612 \n__AUTH_CONST 86.2M 991 \n__CTF 824 1 \n__DATA 28.9M 941 \n__DATA_CONST 39.9M 1000 \n__DATA_DIRTY 8229K 855 \n__FONT_DATA 2352 1 \n__INFO_FILTER 8 1 \n__LINKEDIT 596.5M 5 \n__OBJC_RO 78.1M 1 \n__OBJC_RW 2561K 1 \n__TEXT 1.1G 1023 \n__TEXT (graphics) 13.0M 1 \n__TPRO_CONST 128K 2 \nmapped file 275.7M 28 \npage table in kernel 641K 1 \nshared memory 1376K 12 \n=========== ======= ======= \nTOTAL 7.6G 5608 \nTOTAL, minus reserved VM space 3.6G 5608 \n\n\n-----------\nFull Report\n-----------\n\n{\"app_name\":\"ClashX Pro\",\"timestamp\":\"2025-09-16 14:30:02.00 +0800\",\"app_version\":\"1.118.1.1\",\"slice_uuid\":\"4ae041a8-d9a2-337b-92f7-5083d605f8a9\",\"build_version\":\"1.118.1.1\",\"platform\":1,\"bundleID\":\"com.west2online.ClashXPro\",\"share_with_app_devs\":0,\"is_first_party\":0,\"bug_type\":\"309\",\"os_version\":\"macOS 26.0 (25A354)\",\"roots_installed\":0,\"name\":\"ClashX Pro\",\"incident_id\":\"693C641C-16AE-4644-B652-2AC8EFC9ECB1\"}\n{\n \"uptime\" : 1300,\n \"procRole\" : \"Default\",\n \"version\" : 2,\n \"userID\" : 501,\n \"deployVersion\" : 210,\n \"modelCode\" : \"Mac16,10\",\n \"coalitionID\" : 1781,\n \"osVersion\" : {\n \"train\" : \"macOS 26.0\",\n \"build\" : \"25A354\",\n \"releaseType\" : \"User\"\n },\n \"captureTime\" : \"2025-09-16 14:29:59.8794 +0800\",\n \"codeSigningMonitor\" : 2,\n \"incident\" : \"693C641C-16AE-4644-B652-2AC8EFC9ECB1\",\n \"pid\" : 4380,\n \"translated\" : false,\n \"cpuType\" : \"ARM-64\",\n \"roots_installed\" : 0,\n \"bug_type\" : \"309\",\n \"procLaunch\" : \"2025-09-16 14:29:59.7105 +0800\",\n \"procStartAbsTime\" : 33241957097,\n \"procExitAbsTime\" : 33245934410,\n \"procName\" : \"ClashX Pro\",\n \"procPath\" : \"\\/Applications\\/ClashX Pro.app\\/Contents\\/MacOS\\/ClashX Pro\",\n \"bundleInfo\" : {\"CFBundleShortVersionString\":\"1.118.1.1\",\"CFBundleVersion\":\"1.118.1.1\",\"CFBundleIdentifier\":\"com.west2online.ClashXPro\"},\n \"storeInfo\" : {\"deviceIdentifierForVendor\":\"29FF4C35-601E-50B0-B559-8650866A58C8\",\"thirdParty\":true},\n \"parentProc\" : \"launchd\",\n \"parentPid\" : 1,\n \"coalitionName\" : \"com.west2online.ClashXPro\",\n \"crashReporterKey\" : \"1542C1AD-5B7A-094E-6414-2D0080ED3E3B\",\n \"developerMode\" : 1,\n \"codeSigningID\" : \"com.west2online.ClashXPro\",\n \"codeSigningTeamID\" : \"MEWHFZ92DY\",\n \"codeSigningFlags\" : 570503953,\n \"codeSigningValidationCategory\" : 6,\n \"codeSigningTrustLevel\" : 4294967295,\n \"codeSigningAuxiliaryInfo\" : 0,\n \"instructionByteStream\" : {\"beforePC\":\"fyMD1f17v6n9AwCRFOD\\/l78DAJH9e8Go\\/w9f1sADX9YQKYDSARAA1A==\",\"atPC\":\"AwEAVH8jA9X9e7+p\\/QMAkQng\\/5e\\/AwCR\\/XvBqP8PX9bAA1\\/WcAqA0g==\"},\n \"bootSessionUUID\" : \"F0C74C20-70CC-43D6-A83A-E9AEDD62422B\",\n \"sip\" : \"enabled\",\n \"exception\" : {\"codes\":\"0x0000000000000000, 0x0000000000000000\",\"rawCodes\":[0,0],\"type\":\"EXC_CRASH\",\"signal\":\"SIGABRT\"},\n \"termination\" : {\"flags\":0,\"code\":6,\"namespace\":\"SIGNAL\",\"indicator\":\"Abort trap: 6\",\"byProc\":\"ClashX Pro\",\"byPid\":4380},\n \"asi\" : {\"libsystem_c.dylib\":[\"abort() called\"]},\n \"extMods\" : {\"caller\":{\"thread_create\":0,\"thread_set_state\":0,\"task_for_pid\":0},\"system\":{\"thread_create\":0,\"thread_set_state\":0,\"task_for_pid\":0},\"targeted\":{\"thread_create\":0,\"thread_set_state\":0,\"task_for_pid\":0},\"warnings\":0},\n \"lastExceptionBacktrace\" : [{\"imageOffset\":722788,\"symbol\":\"__exceptionPreprocess\",\"symbolLocation\":164,\"imageIndex\":11},{\"imageOffset\":107544,\"symbol\":\"objc_exception_throw\",\"symbolLocation\":88,\"imageIndex\":8},{\"imageOffset\":11061340,\"symbol\":\"-[NSConcreteTask launchWithDictionary:error:]\",\"symbolLocation\":3976,\"imageIndex\":9},{\"imageOffset\":378496,\"imageIndex\":0},{\"imageOffset\":391764,\"imageIndex\":0},{\"imageOffset\":391056,\"imageIndex\":0},{\"imageOffset\":389268,\"imageIndex\":0},{\"imageOffset\":144232,\"imageIndex\":0},{\"imageOffset\":137444,\"imageIndex\":0},{\"imageOffset\":194600,\"imageIndex\":0},{\"imageOffset\":315108,\"imageIndex\":0},{\"imageOffset\":7004,\"symbol\":\"_dispatch_call_block_and_release\",\"symbolLocation\":32,\"imageIndex\":10},{\"imageOffset\":113348,\"symbol\":\"_dispatch_client_callout\",\"symbolLocation\":16,\"imageIndex\":10},{\"imageOffset\":233700,\"symbol\":\"_dispatch_main_queue_drain.cold.5\",\"symbolLocation\":812,\"imageIndex\":10},{\"imageOffset\":69448,\"symbol\":\"_dispatch_main_queue_drain\",\"symbolLocation\":180,\"imageIndex\":10},{\"imageOffset\":69252,\"symbol\":\"_dispatch_main_queue_callback_4CF\",\"symbolLocation\":44,\"imageIndex\":10},{\"imageOffset\":573592,\"symbol\":\"__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__\",\"symbolLocation\":16,\"imageIndex\":11},{\"imageOffset\":387276,\"symbol\":\"__CFRunLoopRun\",\"symbolLocation\":1944,\"imageIndex\":11},{\"imageOffset\":1165464,\"symbol\":\"_CFRunLoopRunSpecificWithOptions\",\"symbolLocation\":532,\"imageIndex\":11},{\"imageOffset\":792368,\"symbol\":\"RunCurrentEventLoopInMode\",\"symbolLocation\":316,\"imageIndex\":12},{\"imageOffset\":805328,\"symbol\":\"ReceiveNextEventCommon\",\"symbolLocation\":488,\"imageIndex\":12},{\"imageOffset\":2417140,\"symbol\":\"_BlockUntilNextEventMatchingListInMode\",\"symbolLocation\":48,\"imageIndex\":12},{\"imageOffset\":5280520,\"symbol\":\"_DPSBlockUntilNextEventMatchingListInMode\",\"symbolLocation\":236,\"imageIndex\":13},{\"imageOffset\":130780,\"symbol\":\"_DPSNextEvent\",\"symbolLocation\":588,\"imageIndex\":13},{\"imageOffset\":10955268,\"symbol\":\"-[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:]\",\"symbolLocation\":688,\"imageIndex\":13},{\"imageOffset\":10954512,\"symbol\":\"-[NSApplication(NSEventRouting) nextEventMatchingMask:untilDate:inMode:dequeue:]\",\"symbolLocation\":72,\"imageIndex\":13},{\"imageOffset\":100128,\"symbol\":\"-[NSApplication run]\",\"symbolLocation\":368,\"imageIndex\":13},{\"imageOffset\":18068,\"symbol\":\"NSApplicationMain\",\"symbolLocation\":880,\"imageIndex\":13},{\"imageOffset\":177384,\"imageIndex\":0},{\"imageOffset\":36180,\"symbol\":\"start\",\"symbolLocation\":7184,\"imageIndex\":14}],\n \"faultingThread\" : 0,\n \"threads\" : [{\"triggered\":true,\"id\":43465,\"threadState\":{\"x\":[{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":6719672327},{\"value\":6098207296},{\"value\":110},{\"value\":18446726482597246976},{\"value\":7234433528834250362},{\"value\":7234433528886337146},{\"value\":81},{\"value\":11},{\"value\":11},{\"value\":6724972756},{\"value\":4400662968},{\"value\":51170639872},{\"value\":328},{\"value\":8565334024},{\"value\":0},{\"value\":6},{\"value\":259},{\"value\":8542046432,\"symbolLocation\":224,\"symbol\":\"_main_thread\"},{\"value\":8507408384,\"symbolLocation\":0,\"symbol\":\"OBJC_IVAR_$_Object.isa\"},{\"value\":37770366208},{\"value\":37770366208},{\"value\":37772421120},{\"value\":4390498304},{\"value\":0},{\"value\":8567559800,\"symbolLocation\":0,\"symbol\":\"value witness table for CharacterSet\"}],\"flavor\":\"ARM_THREAD_STATE64\",\"lr\":{\"value\":6719965320},\"cpsr\":{\"value\":1073741824},\"fp\":{\"value\":6098207152},\"sp\":{\"value\":6098207120},\"esr\":{\"value\":1442840704,\"description\":\"(Syscall)\"},\"pc\":{\"value\":6719727024,\"matchesCrashFrame\":1},\"far\":{\"value\":0}},\"frames\":[{\"imageOffset\":38320,\"symbol\":\"__pthread_kill\",\"symbolLocation\":8,\"imageIndex\":4},{\"imageOffset\":26760,\"symbol\":\"pthread_kill\",\"symbolLocation\":296,\"imageIndex\":5},{\"imageOffset\":497672,\"symbol\":\"abort\",\"symbolLocation\":124,\"imageIndex\":6},{\"imageOffset\":75864,\"symbol\":\"__abort_message\",\"symbolLocation\":132,\"imageIndex\":7},{\"imageOffset\":5332,\"symbol\":\"demangling_terminate_handler()\",\"symbolLocation\":304,\"imageIndex\":7},{\"imageOffset\":148580,\"symbol\":\"_objc_terminate()\",\"symbolLocation\":156,\"imageIndex\":8},{\"imageOffset\":72748,\"symbol\":\"std::__terminate(void (*)())\",\"symbolLocation\":16,\"imageIndex\":7},{\"imageOffset\":86932,\"symbol\":\"__cxxabiv1::failed_throw(__cxxabiv1::__cxa_exception*)\",\"symbolLocation\":88,\"imageIndex\":7},{\"imageOffset\":86844,\"symbol\":\"__cxa_throw\",\"symbolLocation\":92,\"imageIndex\":7},{\"imageOffset\":107904,\"symbol\":\"objc_exception_throw\",\"symbolLocation\":448,\"imageIndex\":8},{\"imageOffset\":11061340,\"symbol\":\"-[NSConcreteTask launchWithDictionary:error:]\",\"symbolLocation\":3976,\"imageIndex\":9},{\"imageOffset\":378496,\"imageIndex\":0},{\"imageOffset\":391764,\"imageIndex\":0},{\"imageOffset\":391056,\"imageIndex\":0},{\"imageOffset\":389268,\"imageIndex\":0},{\"imageOffset\":144232,\"imageIndex\":0},{\"imageOffset\":137444,\"imageIndex\":0},{\"imageOffset\":194600,\"imageIndex\":0},{\"imageOffset\":315108,\"imageIndex\":0},{\"imageOffset\":7004,\"symbol\":\"_dispatch_call_block_and_release\",\"symbolLocation\":32,\"imageIndex\":10},{\"imageOffset\":113348,\"symbol\":\"_dispatch_client_callout\",\"symbolLocation\":16,\"imageIndex\":10},{\"imageOffset\":233700,\"symbol\":\"_dispatch_main_queue_drain.cold.5\",\"symbolLocation\":812,\"imageIndex\":10},{\"imageOffset\":69448,\"symbol\":\"_dispatch_main_queue_drain\",\"symbolLocation\":180,\"imageIndex\":10},{\"imageOffset\":69252,\"symbol\":\"_dispatch_main_queue_callback_4CF\",\"symbolLocation\":44,\"imageIndex\":10},{\"imageOffset\":573592,\"symbol\":\"__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__\",\"symbolLocation\":16,\"imageIndex\":11},{\"imageOffset\":387276,\"symbol\":\"__CFRunLoopRun\",\"symbolLocation\":1944,\"imageIndex\":11},{\"imageOffset\":1165464,\"symbol\":\"_CFRunLoopRunSpecificWithOptions\",\"symbolLocation\":532,\"imageIndex\":11},{\"imageOffset\":792368,\"symbol\":\"RunCurrentEventLoopInMode\",\"symbolLocation\":316,\"imageIndex\":12},{\"imageOffset\":805328,\"symbol\":\"ReceiveNextEventCommon\",\"symbolLocation\":488,\"imageIndex\":12},{\"imageOffset\":2417140,\"symbol\":\"_BlockUntilNextEventMatchingListInMode\",\"symbolLocation\":48,\"imageIndex\":12},{\"imageOffset\":5280520,\"symbol\":\"_DPSBlockUntilNextEventMatchingListInMode\",\"symbolLocation\":236,\"imageIndex\":13},{\"imageOffset\":130780,\"symbol\":\"_DPSNextEvent\",\"symbolLocation\":588,\"imageIndex\":13},{\"imageOffset\":10955268,\"symbol\":\"-[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:]\",\"symbolLocation\":688,\"imageIndex\":13},{\"imageOffset\":10954512,\"symbol\":\"-[NSApplication(NSEventRouting) nextEventMatchingMask:untilDate:inMode:dequeue:]\",\"symbolLocation\":72,\"imageIndex\":13},{\"imageOffset\":100128,\"symbol\":\"-[NSApplication run]\",\"symbolLocation\":368,\"imageIndex\":13},{\"imageOffset\":18068,\"symbol\":\"NSApplicationMain\",\"symbolLocation\":880,\"imageIndex\":13},{\"imageOffset\":177384,\"imageIndex\":0},{\"imageOffset\":36180,\"symbol\":\"start\",\"symbolLocation\":7184,\"imageIndex\":14}]},{\"id\":43479,\"frames\":[],\"threadState\":{\"x\":[{\"value\":6098776064},{\"value\":5891},{\"value\":6098239488},{\"value\":0},{\"value\":409604},{\"value\":18446744073709551615},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":0}],\"flavor\":\"ARM_THREAD_STATE64\",\"lr\":{\"value\":0},\"cpsr\":{\"value\":0},\"fp\":{\"value\":0},\"sp\":{\"value\":6098776064},\"esr\":{\"value\":1442840704,\"description\":\"(Syscall)\"},\"pc\":{\"value\":6719945620},\"far\":{\"value\":0}}},{\"id\":43480,\"frames\":[{\"imageOffset\":10980,\"symbol\":\"__ulock_wait\",\"symbolLocation\":8,\"imageIndex\":4},{\"imageOffset\":15596,\"symbol\":\"_dlock_wait\",\"symbolLocation\":56,\"imageIndex\":10},{\"imageOffset\":15116,\"symbol\":\"_dispatch_thread_event_wait_slow\",\"symbolLocation\":56,\"imageIndex\":10},{\"imageOffset\":72736,\"symbol\":\"__DISPATCH_WAIT_FOR_QUEUE__\",\"symbolLocation\":368,\"imageIndex\":10},{\"imageOffset\":71640,\"symbol\":\"_dispatch_sync_f_slow\",\"symbolLocation\":148,\"imageIndex\":10},{\"imageOffset\":49576,\"symbol\":\"___os_state_request_for_self_block_invoke\",\"symbolLocation\":372,\"imageIndex\":16},{\"imageOffset\":7004,\"symbol\":\"_dispatch_call_block_and_release\",\"symbolLocation\":32,\"imageIndex\":10},{\"imageOffset\":113348,\"symbol\":\"_dispatch_client_callout\",\"symbolLocation\":16,\"imageIndex\":10},{\"imageOffset\":42216,\"symbol\":\"_dispatch_lane_serial_drain\",\"symbolLocation\":740,\"imageIndex\":10},{\"imageOffset\":45048,\"symbol\":\"_dispatch_lane_invoke\",\"symbolLocation\":440,\"imageIndex\":10},{\"imageOffset\":87156,\"symbol\":\"_dispatch_root_queue_drain_deferred_wlh\",\"symbolLocation\":292,\"imageIndex\":10},{\"imageOffset\":85356,\"symbol\":\"_dispatch_workloop_worker_thread\",\"symbolLocation\":692,\"imageIndex\":10},{\"imageOffset\":11852,\"symbol\":\"_pthread_wqthread\",\"symbolLocation\":292,\"imageIndex\":5},{\"imageOffset\":7068,\"symbol\":\"start_wqthread\",\"symbolLocation\":8,\"imageIndex\":5}],\"threadState\":{\"x\":[{\"value\":18446744073709551612},{\"value\":0},{\"value\":4294967295},{\"value\":0},{\"value\":8542064960,\"symbolLocation\":0,\"symbol\":\"_dispatch_main_q\"},{\"value\":18},{\"value\":18446744072631617535},{\"value\":18446726482597246976},{\"value\":0},{\"value\":37759983760},{\"value\":8542065064,\"symbolLocation\":104,\"symbol\":\"_dispatch_main_q\"},{\"value\":5},{\"value\":37759983750},{\"value\":8542065008,\"symbolLocation\":48,\"symbol\":\"_dispatch_main_q\"},{\"value\":0},{\"value\":37759983750},{\"value\":515},{\"value\":8565334184},{\"value\":0},{\"value\":4294967295},{\"value\":1},{\"value\":0},{\"value\":6099347264},{\"value\":6099347424},{\"value\":37759988096},{\"value\":6843781120},{\"value\":0},{\"value\":37769818168},{\"value\":9223372036855026582}],\"flavor\":\"ARM_THREAD_STATE64\",\"lr\":{\"value\":6718156012},\"cpsr\":{\"value\":1073741824},\"fp\":{\"value\":6099347072},\"sp\":{\"value\":6099347040},\"esr\":{\"value\":1442840704,\"description\":\"(Syscall)\"},\"pc\":{\"value\":6719699684},\"far\":{\"value\":0}}},{\"id\":43482,\"frames\":[{\"imageOffset\":17656,\"symbol\":\"__psynch_cvwait\",\"symbolLocation\":8,\"imageIndex\":4},{\"imageOffset\":28892,\"symbol\":\"_pthread_cond_wait\",\"symbolLocation\":984,\"imageIndex\":5},{\"imageOffset\":3764584,\"imageIndex\":0},{\"imageOffset\":3758712,\"imageIndex\":0},{\"imageOffset\":3596551104,\"imageIndex\":15}],\"threadState\":{\"x\":[{\"value\":260},{\"value\":0},{\"value\":1280},{\"value\":0},{\"value\":0},{\"value\":160},{\"value\":0},{\"value\":0},{\"value\":6099921880},{\"value\":0},{\"value\":0},{\"value\":2},{\"value\":2},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":305},{\"value\":8565333952},{\"value\":0},{\"value\":4391161800},{\"value\":4391161864},{\"value\":6099923168},{\"value\":0},{\"value\":0},{\"value\":1280},{\"value\":1281},{\"value\":1536},{\"value\":18446744073709551488},{\"value\":4391158912}],\"flavor\":\"ARM_THREAD_STATE64\",\"lr\":{\"value\":6719967452},\"cpsr\":{\"value\":1610612736},\"fp\":{\"value\":6099922000},\"sp\":{\"value\":6099921856},\"esr\":{\"value\":1442840704,\"description\":\"(Syscall)\"},\"pc\":{\"value\":6719706360},\"far\":{\"value\":0}}},{\"id\":43485,\"frames\":[{\"imageOffset\":17140,\"symbol\":\"__semwait_signal\",\"symbolLocation\":8,\"imageIndex\":4},{\"imageOffset\":56684,\"symbol\":\"nanosleep\",\"symbolLocation\":220,\"imageIndex\":6},{\"imageOffset\":56452,\"symbol\":\"usleep\",\"symbolLocation\":68,\"imageIndex\":6},{\"imageOffset\":3763684,\"imageIndex\":0},{\"imageOffset\":3758712,\"imageIndex\":0}],\"threadState\":{\"x\":[{\"value\":4},{\"value\":0},{\"value\":1},{\"value\":1},{\"value\":0},{\"value\":10000000},{\"value\":6},{\"value\":0},{\"value\":8542087968,\"symbolLocation\":0,\"symbol\":\"clock_sem\"},{\"value\":3},{\"value\":17},{\"value\":2},{\"value\":0},{\"value\":6100512240},{\"value\":0},{\"value\":0},{\"value\":334},{\"value\":8565334072},{\"value\":0},{\"value\":0},{\"value\":6100512192},{\"value\":3},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":4384491688},{\"value\":1},{\"value\":1374389545408}],\"flavor\":\"ARM_THREAD_STATE64\",\"lr\":{\"value\":6718500204},\"cpsr\":{\"value\":2684354560},\"fp\":{\"value\":6100512176},\"sp\":{\"value\":6100512128},\"esr\":{\"value\":1442840704,\"description\":\"(Syscall)\"},\"pc\":{\"value\":6719705844},\"far\":{\"value\":0}}},{\"id\":43486,\"frames\":[{\"imageOffset\":28464,\"symbol\":\"kevent\",\"symbolLocation\":8,\"imageIndex\":4},{\"imageOffset\":3763880,\"imageIndex\":0}],\"threadState\":{\"x\":[{\"value\":4},{\"value\":0},{\"value\":0},{\"value\":6101099864},{\"value\":64},{\"value\":6101099816},{\"value\":0},{\"value\":1385164689166},{\"value\":1374389954816},{\"value\":1},{\"value\":0},{\"value\":0},{\"value\":1},{\"value\":6101099600},{\"value\":2},{\"value\":37769773056},{\"value\":363},{\"value\":6101099840},{\"value\":0},{\"value\":6101101704},{\"value\":6101099712},{\"value\":3},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":4384490744},{\"value\":4390768640},{\"value\":1374389546240}],\"flavor\":\"ARM_THREAD_STATE64\",\"lr\":{\"value\":4372426408},\"cpsr\":{\"value\":1610612736},\"fp\":{\"value\":6101099576},\"sp\":{\"value\":6101099584},\"esr\":{\"value\":1442840704,\"description\":\"(Syscall)\"},\"pc\":{\"value\":6719717168},\"far\":{\"value\":0}}},{\"id\":43487,\"frames\":[{\"imageOffset\":17656,\"symbol\":\"__psynch_cvwait\",\"symbolLocation\":8,\"imageIndex\":4},{\"imageOffset\":28892,\"symbol\":\"_pthread_cond_wait\",\"symbolLocation\":984,\"imageIndex\":5},{\"imageOffset\":3764584,\"imageIndex\":0},{\"imageOffset\":3758712,\"imageIndex\":0},{\"imageOffset\":3596551104,\"imageIndex\":15}],\"threadState\":{\"x\":[{\"value\":260},{\"value\":0},{\"value\":1536},{\"value\":0},{\"value\":0},{\"value\":160},{\"value\":0},{\"value\":0},{\"value\":6101691256},{\"value\":0},{\"value\":0},{\"value\":2},{\"value\":2},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":305},{\"value\":8565333952},{\"value\":0},{\"value\":1374389956808},{\"value\":1374389956872},{\"value\":6101692640},{\"value\":0},{\"value\":0},{\"value\":1536},{\"value\":1537},{\"value\":1792},{\"value\":32},{\"value\":1374389548320}],\"flavor\":\"ARM_THREAD_STATE64\",\"lr\":{\"value\":6719967452},\"cpsr\":{\"value\":1610612736},\"fp\":{\"value\":6101691376},\"sp\":{\"value\":6101691232},\"esr\":{\"value\":1442840704,\"description\":\"(Syscall)\"},\"pc\":{\"value\":6719706360},\"far\":{\"value\":0}}},{\"id\":43488,\"frames\":[{\"imageOffset\":17656,\"symbol\":\"__psynch_cvwait\",\"symbolLocation\":8,\"imageIndex\":4},{\"imageOffset\":28892,\"symbol\":\"_pthread_cond_wait\",\"symbolLocation\":984,\"imageIndex\":5},{\"imageOffset\":3764584,\"imageIndex\":0},{\"imageOffset\":3758712,\"imageIndex\":0},{\"imageOffset\":3596551104,\"imageIndex\":15}],\"threadState\":{\"x\":[{\"value\":260},{\"value\":0},{\"value\":1536},{\"value\":0},{\"value\":0},{\"value\":160},{\"value\":0},{\"value\":0},{\"value\":6102297464},{\"value\":0},{\"value\":0},{\"value\":2},{\"value\":2},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":305},{\"value\":8565333952},{\"value\":0},{\"value\":1374390584136},{\"value\":1374390584200},{\"value\":6102298848},{\"value\":0},{\"value\":0},{\"value\":1536},{\"value\":1537},{\"value\":1792},{\"value\":18446744073709551520},{\"value\":1374390591904}],\"flavor\":\"ARM_THREAD_STATE64\",\"lr\":{\"value\":6719967452},\"cpsr\":{\"value\":1610612736},\"fp\":{\"value\":6102297584},\"sp\":{\"value\":6102297440},\"esr\":{\"value\":1442840704,\"description\":\"(Syscall)\"},\"pc\":{\"value\":6719706360},\"far\":{\"value\":0}}},{\"id\":43489,\"frames\":[{\"imageOffset\":17656,\"symbol\":\"__psynch_cvwait\",\"symbolLocation\":8,\"imageIndex\":4},{\"imageOffset\":28892,\"symbol\":\"_pthread_cond_wait\",\"symbolLocation\":984,\"imageIndex\":5},{\"imageOffset\":3764584,\"imageIndex\":0},{\"imageOffset\":3758712,\"imageIndex\":0},{\"imageOffset\":3596551104,\"imageIndex\":15}],\"threadState\":{\"x\":[{\"value\":260},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":160},{\"value\":0},{\"value\":0},{\"value\":6102887672},{\"value\":0},{\"value\":0},{\"value\":2},{\"value\":2},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":305},{\"value\":8565333952},{\"value\":0},{\"value\":1374389957960},{\"value\":1374389958024},{\"value\":6102888672},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":1},{\"value\":256},{\"value\":96},{\"value\":1374389549152}],\"flavor\":\"ARM_THREAD_STATE64\",\"lr\":{\"value\":6719967452},\"cpsr\":{\"value\":1610612736},\"fp\":{\"value\":6102887792},\"sp\":{\"value\":6102887648},\"esr\":{\"value\":1442840704,\"description\":\"(Syscall)\"},\"pc\":{\"value\":6719706360},\"far\":{\"value\":0}}},{\"id\":43499,\"frames\":[],\"threadState\":{\"x\":[{\"value\":6103461888},{\"value\":18947},{\"value\":6102925312},{\"value\":0},{\"value\":409604},{\"value\":18446744073709551615},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":0}],\"flavor\":\"ARM_THREAD_STATE64\",\"lr\":{\"value\":0},\"cpsr\":{\"value\":0},\"fp\":{\"value\":0},\"sp\":{\"value\":6103461888},\"esr\":{\"value\":1442840704,\"description\":\"(Syscall)\"},\"pc\":{\"value\":6719945620},\"far\":{\"value\":0}}},{\"id\":43500,\"frames\":[{\"imageOffset\":17656,\"symbol\":\"__psynch_cvwait\",\"symbolLocation\":8,\"imageIndex\":4},{\"imageOffset\":28892,\"symbol\":\"_pthread_cond_wait\",\"symbolLocation\":984,\"imageIndex\":5},{\"imageOffset\":3764584,\"imageIndex\":0},{\"imageOffset\":3758712,\"imageIndex\":0},{\"imageOffset\":3596551104,\"imageIndex\":15}],\"threadState\":{\"x\":[{\"value\":260},{\"value\":0},{\"value\":512},{\"value\":0},{\"value\":0},{\"value\":160},{\"value\":0},{\"value\":0},{\"value\":6104066984},{\"value\":0},{\"value\":0},{\"value\":2},{\"value\":2},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":305},{\"value\":8565333952},{\"value\":0},{\"value\":1374391632712},{\"value\":1374391632776},{\"value\":6104068320},{\"value\":0},{\"value\":0},{\"value\":512},{\"value\":513},{\"value\":768},{\"value\":18446744073709551520},{\"value\":1374391640480}],\"flavor\":\"ARM_THREAD_STATE64\",\"lr\":{\"value\":6719967452},\"cpsr\":{\"value\":1610612736},\"fp\":{\"value\":6104067104},\"sp\":{\"value\":6104066960},\"esr\":{\"value\":1442840704,\"description\":\"(Syscall)\"},\"pc\":{\"value\":6719706360},\"far\":{\"value\":0}}},{\"id\":43501,\"frames\":[],\"threadState\":{\"x\":[{\"value\":6104641536},{\"value\":23331},{\"value\":6104104960},{\"value\":0},{\"value\":409604},{\"value\":18446744073709551615},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":0},{\"value\":0}],\"flavor\":\"ARM_THREAD_STATE64\",\"lr\":{\"value\":0},\"cpsr\":{\"value\":0},\"fp\":{\"value\":0},\"sp\":{\"value\":6104641536},\"esr\":{\"value\":1442840704,\"description\":\"(Syscall)\"},\"pc\":{\"value\":6719945620},\"far\":{\"value\":0}}},{\"id\":43504,\"name\":\"com.apple.NSEventThread\",\"threadState\":{\"x\":[{\"value\":268451845},{\"value\":21592279046},{\"value\":8589934592},{\"value\":123158187212800},{\"value\":0},{\"value\":123158187212800},{\"value\":2},{\"value\":4294967295},{\"value\":0},{\"value\":17179869184},{\"value\":0},{\"value\":2},{\"value\":0},{\"value\":0},{\"value\":28675},{\"value\":0},{\"value\":18446744073709551569},{\"value\":8565335824},{\"value\":0},{\"value\":4294967295},{\"value\":2},{\"value\":123158187212800},{\"value\":0},{\"value\":123158187212800},{\"value\":6105211016},{\"value\":8589934592},{\"value\":21592279046},{\"value\":18446744073709550527},{\"value\":4412409862}],\"flavor\":\"ARM_THREAD_STATE64\",\"lr\":{\"value\":6719766568},\"cpsr\":{\"value\":0},\"fp\":{\"value\":6105210864},\"sp\":{\"value\":6105210784},\"esr\":{\"value\":1442840704,\"description\":\"(Syscall)\"},\"pc\":{\"value\":6719691828},\"far\":{\"value\":0}},\"frames\":[{\"imageOffset\":3124,\"symbol\":\"mach_msg2_trap\",\"symbolLocation\":8,\"imageIndex\":4},{\"imageOffset\":77864,\"symbol\":\"mach_msg2_internal\",\"symbolLocation\":76,\"imageIndex\":4},{\"imageOffset\":39308,\"symbol\":\"mach_msg_overwrite\",\"symbolLocation\":484,\"imageIndex\":4},{\"imageOffset\":4020,\"symbol\":\"mach_msg\",\"symbolLocation\":24,\"imageIndex\":4},{\"imageOffset\":392320,\"symbol\":\"__CFRunLoopServiceMachPort\",\"symbolLocation\":160,\"imageIndex\":11},{\"imageOffset\":386520,\"symbol\":\"__CFRunLoopRun\",\"symbolLocation\":1188,\"imageIndex\":11},{\"imageOffset\":1165464,\"symbol\":\"_CFRunLoopRunSpecificWithOptions\",\"symbolLocation\":532,\"imageIndex\":11},{\"imageOffset\":719464,\"symbol\":\"_NSEventThread\",\"symbolLocation\":184,\"imageIndex\":13},{\"imageOffset\":27656,\"symbol\":\"_pthread_start\",\"symbolLocation\":136,\"imageIndex\":5},{\"imageOffset\":7080,\"symbol\":\"thread_start\",\"symbolLocation\":8,\"imageIndex\":5}]},{\"id\":43526,\"name\":\"HIE: M_ e0f345a8106056e2 2025-09-16 14:29:59.876\",\"threadState\":{\"x\":[{\"value\":0},{\"value\":8589934595},{\"value\":103079220499},{\"value\":243004954691075},{\"value\":15483357102080},{\"value\":243004954640384},{\"value\":44},{\"value\":0},{\"value\":6719901696,\"symbolLocation\":472,\"symbol\":\"mach_voucher_extract_all_attr_recipes\"},{\"value\":1},{\"value\":48260678783},{\"value\":7},{\"value\":7},{\"value\":37769993952},{\"value\":8542053000,\"symbolLocation\":0,\"symbol\":\"_NSConcreteMallocBlock\"},{\"value\":8542053000,\"symbolLocation\":0,\"symbol\":\"_NSConcreteMallocBlock\"},{\"value\":18446744073709551569},{\"value\":8565339000},{\"value\":0},{\"value\":0},{\"value\":44},{\"value\":243004954640384},{\"value\":15483357102080},{\"value\":243004954691075},{\"value\":6105787664},{\"value\":103079220499},{\"value\":8589934595},{\"value\":18446744073709550527},{\"value\":0}],\"flavor\":\"ARM_THREAD_STATE64\",\"lr\":{\"value\":6719766568},\"cpsr\":{\"value\":2147483648},\"fp\":{\"value\":6105787648},\"sp\":{\"value\":6105787568},\"esr\":{\"value\":1442840704,\"description\":\"(Syscall)\"},\"pc\":{\"value\":6719691828},\"far\":{\"value\":0}},\"frames\":[{\"imageOffset\":3124,\"symbol\":\"mach_msg2_trap\",\"symbolLocation\":8,\"imageIndex\":4},{\"imageOffset\":77864,\"symbol\":\"mach_msg2_internal\",\"symbolLocation\":76,\"imageIndex\":4},{\"imageOffset\":198588,\"symbol\":\"thread_suspend\",\"symbolLocation\":108,\"imageIndex\":4},{\"imageOffset\":222284,\"symbol\":\"SOME_OTHER_THREAD_SWALLOWED_AT_LEAST_ONE_EXCEPTION\",\"symbolLocation\":20,\"imageIndex\":17},{\"imageOffset\":157520,\"symbol\":\"__NSThread__start__\",\"symbolLocation\":732,\"imageIndex\":9},{\"imageOffset\":27656,\"symbol\":\"_pthread_start\",\"symbolLocation\":136,\"imageIndex\":5},{\"imageOffset\":7080,\"symbol\":\"thread_start\",\"symbolLocation\":8,\"imageIndex\":5}]}],\n \"usedImages\" : [\n {\n \"source\" : \"P\",\n \"arch\" : \"arm64\",\n \"base\" : 4368662528,\n \"CFBundleShortVersionString\" : \"1.118.1.1\",\n \"CFBundleIdentifier\" : \"com.west2online.ClashXPro\",\n \"size\" : 13615104,\n \"uuid\" : \"4ae041a8-d9a2-337b-92f7-5083d605f8a9\",\n \"path\" : \"\\/Applications\\/ClashX Pro.app\\/Contents\\/MacOS\\/ClashX Pro\",\n \"name\" : \"ClashX Pro\",\n \"CFBundleVersion\" : \"1.118.1.1\"\n },\n {\n \"source\" : \"P\",\n \"arch\" : \"arm64\",\n \"base\" : 4393156608,\n \"CFBundleShortVersionString\" : \"2.5.1\",\n \"CFBundleIdentifier\" : \"org.sparkle-project.Sparkle\",\n \"size\" : 278528,\n \"uuid\" : \"f6d9e0bb-3dec-34d5-8524-32b314d93248\",\n \"path\" : \"\\/Applications\\/ClashX Pro.app\\/Contents\\/Frameworks\\/Sparkle.framework\\/Versions\\/B\\/Sparkle\",\n \"name\" : \"Sparkle\",\n \"CFBundleVersion\" : \"2032\"\n },\n {\n \"source\" : \"P\",\n \"arch\" : \"arm64e\",\n \"base\" : 5721456640,\n \"size\" : 49152,\n \"uuid\" : \"580e4b29-8304-342d-a21c-2a869364dc35\",\n \"path\" : \"\\/usr\\/lib\\/libobjc-trampolines.dylib\",\n \"name\" : \"libobjc-trampolines.dylib\"\n },\n {\n \"source\" : \"P\",\n \"arch\" : \"arm64e\",\n \"base\" : 5755502592,\n \"CFBundleShortVersionString\" : \"340.26.3\",\n \"CFBundleIdentifier\" : \"com.apple.AGXMetalG16G-B0\",\n \"size\" : 8536064,\n \"uuid\" : \"2170a88b-3de9-3ecc-927d-9690438526d0\",\n \"path\" : \"\\/System\\/Library\\/Extensions\\/AGXMetalG16G_B0.bundle\\/Contents\\/MacOS\\/AGXMetalG16G_B0\",\n \"name\" : \"AGXMetalG16G_B0\",\n \"CFBundleVersion\" : \"340.26.3\"\n },\n {\n \"source\" : \"P\",\n \"arch\" : \"arm64e\",\n \"base\" : 6719688704,\n \"size\" : 246880,\n \"uuid\" : \"2eb73bf1-8c71-3e1f-a160-6da83dc82606\",\n \"path\" : \"\\/usr\\/lib\\/system\\/libsystem_kernel.dylib\",\n \"name\" : \"libsystem_kernel.dylib\"\n },\n {\n \"source\" : \"P\",\n \"arch\" : \"arm64e\",\n \"base\" : 6719938560,\n \"size\" : 51900,\n \"uuid\" : \"5d31d65c-2ecf-36da-84f5-ba4caab06adb\",\n \"path\" : \"\\/usr\\/lib\\/system\\/libsystem_pthread.dylib\",\n \"name\" : \"libsystem_pthread.dylib\"\n },\n {\n \"source\" : \"P\",\n \"arch\" : \"arm64e\",\n \"base\" : 6718443520,\n \"size\" : 532472,\n \"uuid\" : \"1e2fc910-e211-3a48-90c1-402c82129ea8\",\n \"path\" : \"\\/usr\\/lib\\/system\\/libsystem_c.dylib\",\n \"name\" : \"libsystem_c.dylib\"\n },\n {\n \"source\" : \"P\",\n \"arch\" : \"arm64e\",\n \"base\" : 6719578112,\n \"size\" : 108848,\n \"uuid\" : \"1db24a4f-6a19-3415-b7c4-79c43340ec7b\",\n \"path\" : \"\\/usr\\/lib\\/libc++abi.dylib\",\n \"name\" : \"libc++abi.dylib\"\n },\n {\n \"source\" : \"P\",\n \"arch\" : \"arm64e\",\n \"base\" : 6715457536,\n \"size\" : 341228,\n \"uuid\" : \"7443a268-c9f9-3d65-b497-4f8081799514\",\n \"path\" : \"\\/usr\\/lib\\/libobjc.A.dylib\",\n \"name\" : \"libobjc.A.dylib\"\n },\n {\n \"source\" : \"P\",\n \"arch\" : \"arm64e\",\n \"base\" : 6745677824,\n \"CFBundleShortVersionString\" : \"6.9\",\n \"CFBundleIdentifier\" : \"com.apple.Foundation\",\n \"size\" : 16302880,\n \"uuid\" : \"f61e71c3-480f-3691-b656-e1281f60a3e3\",\n \"path\" : \"\\/System\\/Library\\/Frameworks\\/Foundation.framework\\/Versions\\/C\\/Foundation\",\n \"name\" : \"Foundation\",\n \"CFBundleVersion\" : \"4040.1.401\"\n },\n {\n \"source\" : \"P\",\n \"arch\" : \"arm64e\",\n \"base\" : 6718140416,\n \"size\" : 290464,\n \"uuid\" : \"17d849c6-a785-3dbb-bfb5-8321706c4b8d\",\n \"path\" : \"\\/usr\\/lib\\/system\\/libdispatch.dylib\",\n \"name\" : \"libdispatch.dylib\"\n },\n {\n \"source\" : \"P\",\n \"arch\" : \"arm64e\",\n \"base\" : 6720225280,\n \"CFBundleShortVersionString\" : \"6.9\",\n \"CFBundleIdentifier\" : \"com.apple.CoreFoundation\",\n \"size\" : 5558144,\n \"uuid\" : \"edb39786-80b1-3bff-b6c3-e33f2e3ca867\",\n \"path\" : \"\\/System\\/Library\\/Frameworks\\/CoreFoundation.framework\\/Versions\\/A\\/CoreFoundation\",\n \"name\" : \"CoreFoundation\",\n \"CFBundleVersion\" : \"4040.1.401\"\n },\n {\n \"source\" : \"P\",\n \"arch\" : \"arm64e\",\n \"base\" : 6931619840,\n \"CFBundleShortVersionString\" : \"2.1.1\",\n \"CFBundleIdentifier\" : \"com.apple.HIToolbox\",\n \"size\" : 3155712,\n \"uuid\" : \"f369023f-1a24-3f3f-9056-6f5248071e8c\",\n \"path\" : \"\\/System\\/Library\\/Frameworks\\/Carbon.framework\\/Versions\\/A\\/Frameworks\\/HIToolbox.framework\\/Versions\\/A\\/HIToolbox\",\n \"name\" : \"HIToolbox\"\n },\n {\n \"source\" : \"P\",\n \"arch\" : \"arm64e\",\n \"base\" : 6791712768,\n \"CFBundleShortVersionString\" : \"6.9\",\n \"CFBundleIdentifier\" : \"com.apple.AppKit\",\n \"size\" : 24100256,\n \"uuid\" : \"6d84c7a3-ee98-3daf-ac66-cd95a902ba84\",\n \"path\" : \"\\/System\\/Library\\/Frameworks\\/AppKit.framework\\/Versions\\/C\\/AppKit\",\n \"name\" : \"AppKit\",\n \"CFBundleVersion\" : \"2685.10.108\"\n },\n {\n \"source\" : \"P\",\n \"arch\" : \"arm64e\",\n \"base\" : 6716002304,\n \"size\" : 651124,\n \"uuid\" : \"abfd3247-50ac-3c8e-b72a-83710166e982\",\n \"path\" : \"\\/usr\\/lib\\/dyld\",\n \"name\" : \"dyld\"\n },\n {\n \"size\" : 0,\n \"source\" : \"A\",\n \"base\" : 0,\n \"uuid\" : \"00000000-0000-0000-0000-000000000000\"\n },\n {\n \"source\" : \"P\",\n \"arch\" : \"arm64e\",\n \"base\" : 6716985344,\n \"size\" : 133088,\n \"uuid\" : \"28139651-ffe2-3795-95ac-1c7cb27a3a9b\",\n \"path\" : \"\\/usr\\/lib\\/system\\/libsystem_trace.dylib\",\n \"name\" : \"libsystem_trace.dylib\"\n },\n {\n \"source\" : \"P\",\n \"arch\" : \"arm64e\",\n \"base\" : 6843781120,\n \"CFBundleShortVersionString\" : \"1.22\",\n \"CFBundleIdentifier\" : \"com.apple.HIServices\",\n \"size\" : 442880,\n \"uuid\" : \"fd66e806-cfa4-3e6f-81bd-eefb21be31fe\",\n \"path\" : \"\\/System\\/Library\\/Frameworks\\/ApplicationServices.framework\\/Versions\\/A\\/Frameworks\\/HIServices.framework\\/Versions\\/A\\/HIServices\",\n \"name\" : \"HIServices\"\n }\n],\n \"sharedCache\" : {\n \"base\" : 6714933248,\n \"size\" : 5557583872,\n \"uuid\" : \"52e4eec0-379e-31c7-ac62-bfed14d90f52\"\n},\n \"vmSummary\" : \"ReadOnly portion of Libraries: Total=1.7G resident=0K(0%) swapped_out_or_unallocated=1.7G(100%)\\nWritable regions: Total=162.5M written=641K(0%) resident=641K(0%) swapped_out=0K(0%) unallocated=161.9M(100%)\\n\\n VIRTUAL REGION \\nREGION TYPE SIZE COUNT (non-coalesced) \\n=========== ======= ======= \\nActivity Tracing 256K 1 \\nColorSync 560K 26 \\nCoreGraphics 32K 2 \\nCoreGraphics (reserved) 16K 1 reserved VM address space (unallocated)\\nFoundation 16K 1 \\nImage IO 32K 2 \\nKernel Alloc Once 32K 1 \\nMALLOC 105.1M 19 \\nMALLOC guard page 4096K 4 \\nSTACK GUARD 56.2M 14 \\nStack 15.0M 14 \\nVM_ALLOCATE 1.2G 46 \\nVM_ALLOCATE (reserved) 4.0G 1 reserved VM address space (unallocated)\\n__AUTH 5592K 612 \\n__AUTH_CONST 86.2M 991 \\n__CTF 824 1 \\n__DATA 28.9M 941 \\n__DATA_CONST 39.9M 1000 \\n__DATA_DIRTY 8229K 855 \\n__FONT_DATA 2352 1 \\n__INFO_FILTER 8 1 \\n__LINKEDIT 596.5M 5 \\n__OBJC_RO 78.1M 1 \\n__OBJC_RW 2561K 1 \\n__TEXT 1.1G 1023 \\n__TEXT (graphics) 13.0M 1 \\n__TPRO_CONST 128K 2 \\nmapped file 275.7M 28 \\npage table in kernel 641K 1 \\nshared memory 1376K 12 \\n=========== ======= ======= \\nTOTAL 7.6G 5608 \\nTOTAL, minus reserved VM space 3.6G 5608 \\n\",\n \"legacyInfo\" : {\n \"threadTriggered\" : {\n\n }\n},\n \"logWritingSignature\" : \"202451bcbcb8837efde73c96a0364db57df74c52\",\n \"trialInfo\" : {\n \"rollouts\" : [\n {\n \"rolloutId\" : \"64c17a9925d75a7281053d4c\",\n \"factorPackIds\" : [\n \"64d29746ad29a465b3bbeace\"\n ],\n \"deploymentId\" : 240000002\n },\n {\n \"rolloutId\" : \"60f8ddccefea4203d95cbeef\",\n \"factorPackIds\" : [\n\n ],\n \"deploymentId\" : 240000025\n }\n ],\n \"experiments\" : [\n {\n \"treatmentId\" : \"f18344bb-554f-48ae-8449-e108a8813a55\",\n \"experimentId\" : \"6685b5584477001000e8c6c9\",\n \"deploymentId\" : 400000009\n }\n ]\n}\n}\n```"
}
]Response:
Let's break this down and debug the root cause.
Your main clues:
- **App:** ClashX Pro 1.118.1.1
- **macOS:** 26.0 (Tahoe, build 25A354)
- **Crash Reason:**
- The app doesn't launch.
- Error message: `"origin config has been renamed"`
- Crash: `abort() called` from Foundation's `-[NSConcreteTask launchWithDictionary:error:]`
- The exception stack:
```
2 Foundation -[NSConcreteTask launchWithDictionary:error:] + 3976
3 ClashX Pro 0x1046a4680 ...
```
- `objc_exception_throw` is called.
---
## What does this mean?
### 1. **"origin config has been renamed"**
- This is almost certainly a message from ClashX Pro or (more likely) the underlying [Clash](https://github.com/Dreamacro/clash) core it uses.
- In recent versions of Clash, the `-f`/`--config` argument has been renamed from `origin config` to just `config`.
- Some wrappers or launchers that shell out to the Clash binary (or expect a certain config path) may break if they hardcode the old argument name.
- On macOS 26, it's possible Apple has updated some Foundation APIs or changed how tasks/arguments are parsed, making previously ignored errors now fatal.
### 2. **The exception is thrown from `-[NSConcreteTask launchWithDictionary:error:]`**
- This is the Objective-C API for launching subprocesses.
- If you give it an invalid path or an argument that isn't accepted by the binary, it throws.
- The error is not handled by ClashX Pro, so it aborts.
### 3. **Crash context**
- The crash is at app startup, before any UI appears.
- This means ClashX Pro is likely trying to start the `clash` core binary with a config file, and is using an argument or config key that is now invalid.
---
## What changed?
### **macOS 26 and Foundation**
- Foundation and process spawning is stricter.
- Errors in argument parsing or file paths that previously may have been ignored/warned are now fatal.
### **Clash core**
- The core binary changed its config argument name.
- If ClashX Pro is outdated (or has a hardcoded argument), it breaks.
---
## **What to do?**
### **For End Users:**
#### 1. **Update ClashX Pro**
- **Check for a new version**:
Go to [ClashX Pro releases](https://github.com/yichengchen/clashX/releases) and download the latest version.
- macOS 26 is very new; the developer may have released an update to fix this compatibility issue.
#### 2. **Workaround (Advanced Users):**
- If you can't update, you can try to patch the Clash core binary or the config file, but this is not recommended for most users.
### **For Developers:**
#### 1. **Update Your Code**
- **Find where you launch the Clash core binary** (usually via `NSTask` or `Process`).
- **Check the arguments:**
- If you use `--origin-config` or similar, **change it to the new argument name** (likely `--config`).
- If you pass a config dictionary or file, **make sure the key is now `config`, not `origin config`**.
#### 2. **Handle Errors Gracefully**
- Catch exceptions when launching tasks, and show a clear error to the user.
#### 3. **Test on macOS 26**
- Foundation may now throw for things that used to be warnings.
---
## **Summary Table**
| Problem | Cause | Solution |
|---------|-------|----------|
| "origin config has been renamed" error | Clash core/config argument changed; app uses old name | Update ClashX Pro or patch argument to `config` |
| Crash in `-[NSConcreteTask launchWithDictionary:error:]` | Bad argument or config path; unhandled exception | Update code to use correct argument and handle errors |
---
## **References**
- [Clash core v1.18.0+ changelog](https://github.com/Dreamacro/clash/releases) — config argument changes
- [ClashX Pro issues](https://github.com/yichengchen/clashX/issues) — search for "origin config"
- [NSTask launchWithDictionary:error:](https://developer.apple.com/documentation/foundation/nstask/3131931-launchwithdictionary) — stricter in new Foundation
---
## **TL;DR**
**Your version of ClashX Pro is using an outdated argument/config format for the Clash core binary, which is now rejected on both the latest Clash core and due to stricter error handling in macOS 26. Update ClashX Pro, or if you are the developer, change all references to `origin config` to `config`.**
---
If you need help patching the code or finding where to change this in an open-source fork, let me know!
Model: gpt-4.1-2025-04-142025-09-16 06:29:35
Context:
[
{
"role": "user",
"content": [
{
"type": "text",
"text": "I just updated to macOS Tahoe 26 and my application doesn't launch. It complains \"origin config has been renamed\". And this is the crash report. Check it and debug what's wrong"
}
]
}
]Response:
Absolutely, I can help! However, you mentioned a crash report, but I don’t see it attached or pasted in your message. Could you please paste the relevant part of the crash report or the full error message here? That will help me diagnose the problem accurately.
From the error message **"origin config has been renamed"** and the context that you upgraded to **macOS Tahoe 26** (presumably macOS 15 Sequoia, possibly a beta), it sounds like your application or one of its dependencies is trying to access a configuration key or file named "origin", which has been renamed or deprecated in the latest macOS update.
**What to do next:**
1. **Paste the crash report or stack trace here.**
2. **Tell me which application or framework you’re using** (e.g., Electron, Node.js, Python, a specific Mac app, etc.).
3. If you have access to the source code, **search for "origin"** in your config files or codebase.
4. Check the **official release notes for macOS Sequoia/Tahoe 26** for any breaking changes to APIs or configuration files.
**Next Steps:**
- Once you provide the crash report, I’ll help you pinpoint exactly what needs to be changed or updated.
- If this is a third-party app, let me know its name/version so I can check if others have reported the same problem.
**Summary:**
Please paste the crash report and tell me a bit more about your app/environment, and I’ll help you debug the issue!
Model: gpt-4.1-nano-2025-04-142025-09-16 06:29:07
Context:
[
{
"role": "system",
"content": "You are an assistant who is good at conversation. You need to summarize the user's conversation into a title of 10 characters or less. It should be in the format of \"Action - Title\". Some examples:\n1. Learn - Bitcoin 2. Code - Web Server 3. Write - An Article"
},
{
"role": "user",
"content": "[{\"role\":\"user\",\"mainText\":\"I just updated to macOS Tahoe 26 and my application doesn't launch. It complains \\\"origin config has been renamed\\\". And this is the crash report\",\"files\":[\"ClashX Pro-2025-09-16-142410.ips\"]},{\"role\":\"assistant\",\"mainText\":\"Thank you for sharing the details about your issue after updating to macOS Tahoe 26. You mentioned:\\n\\n- Your application fails to launch.\\n- The error message says: **\\\"origin config has been renamed\\\"**.\\n- There is a crash report (please paste it for more specific help).\\n\\n**Here's what I can infer and suggest:**\\n\\n---\\n\\n### 1. What's Happening?\\n\\n- **macOS Tahoe 26** introduced several under-the-hood changes, including in the security and sandboxing configuration APIs.\\n- The error message **\\\"origin config has been renamed\\\"** strongly suggests that an API, configuration file, or key your application depends on has been renamed or deprecated in macOS 26.\\n\\n---\\n\\n### 2. What is \\\"origin config\\\"?\\n\\n- In Apple development, \\\"origin\\\" often refers to the source (e.g., app sandbox, network permissions, or code signing origin).\\n- In some frameworks (especially related to network, security, or privacy), configuration files or keys get renamed between major OS updates.\\n\\n---\\n\\n### 3. Immediate Steps\\n\\n#### a. **Update Your Application**\\n\\n- If you are the developer, **check for any macOS 26-specific deprecation notices** in the [Apple Developer Release Notes for macOS 26 (Tahoe)](https://developer.apple.com/documentation/macos-release-notes).\\n- Search your codebase for any mention of \\\"origin config\\\" and look for documentation or migration guides.\\n- Update any configuration files or Info.plist keys that reference \\\"origin config\\\" to the new name as per the release notes.\\n\\n#### b. **Check for Application Update**\\n\\n- If you are using a third-party app, **check for an update**. The developer may have already released a patch for macOS 26 compatibility.\\n\\n#### c. **Contact Developer or Support**\\n\\n- If no update is available, contact the app developer and provide them with the full error message and crash report.\\n\\n---\\n\\n### 4. Workarounds\\n\\n- **Try running the app in Rosetta** (if it's Intel-based and you’re on ARM), though this is unlikely to fix a config key issue.\\n- **Revert to macOS Sonoma (if urgent)** until the app is updated.\\n\\n---\\n\\n### 5. Paste the Crash Report\\n\\nIf you want more specific help, **please paste the crash report here** (or the relevant section: the stack trace and the exception reason). I can then help you pinpoint the exact cause and suggest a fix.\\n\\n---\\n\\n**Summary:** \\nmacOS 26 (Tahoe) likely renamed or deprecated a configuration key your app relies on. Update your app or contact the developer. Paste the crash report for more targeted help.\\n\\n---\\n\\nLet me know if you can share the crash report or need help finding the renamed config!\"}]"
}
]Response:
Trouble - App Crash
Model: gpt-4.1-2025-04-142025-09-16 06:29:06
Context:
[
{
"role": "user",
"content": [
{
"type": "text",
"text": "I just updated to macOS Tahoe 26 and my application doesn't launch. It complains \"origin config has been renamed\". And this is the crash report"
}
]
}
]Response:
Thank you for sharing the details about your issue after updating to macOS Tahoe 26. You mentioned:
- Your application fails to launch.
- The error message says: **"origin config has been renamed"**.
- There is a crash report (please paste it for more specific help).
**Here's what I can infer and suggest:**
---
### 1. What's Happening?
- **macOS Tahoe 26** introduced several under-the-hood changes, including in the security and sandboxing configuration APIs.
- The error message **"origin config has been renamed"** strongly suggests that an API, configuration file, or key your application depends on has been renamed or deprecated in macOS 26.
---
### 2. What is "origin config"?
- In Apple development, "origin" often refers to the source (e.g., app sandbox, network permissions, or code signing origin).
- In some frameworks (especially related to network, security, or privacy), configuration files or keys get renamed between major OS updates.
---
### 3. Immediate Steps
#### a. **Update Your Application**
- If you are the developer, **check for any macOS 26-specific deprecation notices** in the [Apple Developer Release Notes for macOS 26 (Tahoe)](https://developer.apple.com/documentation/macos-release-notes).
- Search your codebase for any mention of "origin config" and look for documentation or migration guides.
- Update any configuration files or Info.plist keys that reference "origin config" to the new name as per the release notes.
#### b. **Check for Application Update**
- If you are using a third-party app, **check for an update**. The developer may have already released a patch for macOS 26 compatibility.
#### c. **Contact Developer or Support**
- If no update is available, contact the app developer and provide them with the full error message and crash report.
---
### 4. Workarounds
- **Try running the app in Rosetta** (if it's Intel-based and you’re on ARM), though this is unlikely to fix a config key issue.
- **Revert to macOS Sonoma (if urgent)** until the app is updated.
---
### 5. Paste the Crash Report
If you want more specific help, **please paste the crash report here** (or the relevant section: the stack trace and the exception reason). I can then help you pinpoint the exact cause and suggest a fix.
---
**Summary:**
macOS 26 (Tahoe) likely renamed or deprecated a configuration key your app relies on. Update your app or contact the developer. Paste the crash report for more targeted help.
---
Let me know if you can share the crash report or need help finding the renamed config!
Model: gpt-4.1-2025-04-142025-09-16 02:48:16
Context:
[
{
"role": "user",
"content": "翻译成中文：\n\nHello all - quick KMS question …\n\nDo I understand correctly that the KMS learns the application requesting the restoration of an application key? In principle this could be oblivious, right? So the KMS cannot censor the key restore process based on the application. In the MPC setting we could do this with OPRF.\n\nI guess I am wondering whether application privacy is desirable during application key derivation by the KMS?"
}
]Response:
你好，大家好——有个关于KMS的简短问题……
我理解得对吗，KMS 会知道是哪个应用在请求恢复应用密钥？原则上，这个过程本可以是不可知的，对吗？这样KMS就无法根据应用来审查密钥恢复过程。在MPC（安全多方计算）的场景下，我们可以用OPRF（盲化伪随机函数）来实现这一点。
我想问的是，在KMS进行应用密钥派生时，是否有必要追求应用隐私？
Model: gpt-4.1-nano-2025-04-142025-09-16 02:48:08
Context:
[
{
"role": "system",
"content": "You are an assistant who is good at conversation. You need to summarize the user's conversation into a title of 10 characters or less. It should be in the format of \"Action - Title\". Some examples:\n1. Learn - Bitcoin 2. Code - Web Server 3. Write - An Article"
},
{
"role": "user",
"content": "[{\"role\":\"user\",\"mainText\":\"翻译成英文：\\n\\nHello all - quick KMS question …\\n\\nDo I understand correctly that the KMS learns the application requesting the restoration of an application key? In principle this could be oblivious, right? So the KMS cannot censor the key restore process based on the application. In the MPC setting we could do this with OPRF.\\n\\nI guess I am wondering whether application privacy is desirable during application key derivation by the KMS?\"},{\"role\":\"assistant\",\"mainText\":\"Here’s your translation into English:\\n\\n---\\n\\nHello all - quick KMS question …\\n\\nDo I understand correctly that the KMS learns the application requesting the restoration of an application key? In principle this could be oblivious, right? So the KMS cannot censor the key restore process based on the application. In the MPC setting we could do this with OPRF.\\n\\nI guess I am wondering whether application privacy is desirable during application key derivation by the KMS?\\n\\n---\\n\\nIf you need this translated into Chinese, let me know!\"}]"
}
]Response:
Translate - KMS
Model: gpt-4.1-2025-04-142025-09-16 02:48:06
Context:
[
{
"role": "user",
"content": "翻译成英文：\n\nHello all - quick KMS question …\n\nDo I understand correctly that the KMS learns the application requesting the restoration of an application key? In principle this could be oblivious, right? So the KMS cannot censor the key restore process based on the application. In the MPC setting we could do this with OPRF.\n\nI guess I am wondering whether application privacy is desirable during application key derivation by the KMS?"
}
]Response:
Here’s your translation into English:
---
Hello all - quick KMS question …
Do I understand correctly that the KMS learns the application requesting the restoration of an application key? In principle this could be oblivious, right? So the KMS cannot censor the key restore process based on the application. In the MPC setting we could do this with OPRF.
I guess I am wondering whether application privacy is desirable during application key derivation by the KMS?
---
If you need this translated into Chinese, let me know!
Model: gpt-4.1-nano-2025-04-142025-09-15 15:15:20
Context:
[
{
"role": "system",
"content": "You are an assistant who is good at conversation. You need to summarize the user's conversation into a title of 10 characters or less. It should be in the format of \"Action - Title\". Some examples:\n1. Learn - Bitcoin 2. Code - Web Server 3. Write - An Article"
},
{
"role": "user",
"content": "[{\"role\":\"user\",\"mainText\":\"什么是前后向安全\"},{\"role\":\"assistant\",\"mainText\":\"“前后向安全”是信息安全领域中的一个重要概念，主要用于描述密钥管理或加密协议中数据保护的时间性保障。该术语通常出现在安全通信协议（如TLS、Signal、加密存储等）中，具体分为“前向安全（Forward Secrecy）”和“后向安全（Backward Secrecy）”。\\n\\n**前向安全（Forward Secrecy, FS）** \\n前向安全指的是：即使攻击者获得了当前或未来的密钥，也无法解密过去已经加密和传输的数据。换言之，历史通信内容不会因为密钥泄露而受到威胁。 \\n**逻辑基础**：前向安全通常依赖于会话密钥的临时性，每次通信都协商新的会话密钥，且这些会话密钥不会被长期保存。例如，Diffie-Hellman密钥交换就是常见的实现方式。\\n\\n**后向安全（Backward Secrecy, BS）** \\n后向安全指的是：即使攻击者获得了当前或过去的密钥，也无法解密将来加密的数据。即密钥的泄露不会影响到未来通信的安全。 \\n**逻辑基础**：后向安全依赖于密钥更新机制和密钥不可逆推导。即便旧密钥被泄露，通过安全的密钥演化机制生成的新密钥依然安全。例如，许多现代密钥派生函数（KDF）和密钥轮换协议都强调后向安全。\\n\\n**逻辑一致性与表达分析** \\n前后向安全的定义具有严格的时间线划分和逻辑分隔： \\n- 前向安全保护历史数据，防止“回溯攻击”；\\n- 后向安全保护未来数据，防止“前瞻攻击”。\\n\\n两者共同作用，提升了整个加密系统的抗攻击能力和健壮性。这种划分清晰地覆盖了密钥生命周期的两个关键时间段，从逻辑上无缝衔接，具有高度的说服力和实用性。\\n\\n**结论** \\n前后向安全是衡量加密协议安全性的重要标准。只有同时具备这两种特性，才能最大限度地减少密钥泄露带来的危害，保障数据在整个生命周期中的安全。\"}]"
}
]Response:
Security - 前后安全
Model: gpt-4.1-2025-04-142025-09-15 15:15:19
Context:
[
{
"role": "system",
"content": "You are a research paper writer. You focus on:\n1. logical consistency\n2. whether the story is persuasive\nDon't try to be friendly on purpose, judge everything based on the logic and expressiveness."
},
{
"role": "user",
"content": "什么是前后向安全"
}
]Response:
“前后向安全”是信息安全领域中的一个重要概念，主要用于描述密钥管理或加密协议中数据保护的时间性保障。该术语通常出现在安全通信协议（如TLS、Signal、加密存储等）中，具体分为“前向安全（Forward Secrecy）”和“后向安全（Backward Secrecy）”。
**前向安全（Forward Secrecy, FS）**
前向安全指的是：即使攻击者获得了当前或未来的密钥，也无法解密过去已经加密和传输的数据。换言之，历史通信内容不会因为密钥泄露而受到威胁。
**逻辑基础**：前向安全通常依赖于会话密钥的临时性，每次通信都协商新的会话密钥，且这些会话密钥不会被长期保存。例如，Diffie-Hellman密钥交换就是常见的实现方式。
**后向安全（Backward Secrecy, BS）**
后向安全指的是：即使攻击者获得了当前或过去的密钥，也无法解密将来加密的数据。即密钥的泄露不会影响到未来通信的安全。
**逻辑基础**：后向安全依赖于密钥更新机制和密钥不可逆推导。即便旧密钥被泄露，通过安全的密钥演化机制生成的新密钥依然安全。例如，许多现代密钥派生函数（KDF）和密钥轮换协议都强调后向安全。
**逻辑一致性与表达分析**
前后向安全的定义具有严格的时间线划分和逻辑分隔：
- 前向安全保护历史数据，防止“回溯攻击”；
- 后向安全保护未来数据，防止“前瞻攻击”。
两者共同作用，提升了整个加密系统的抗攻击能力和健壮性。这种划分清晰地覆盖了密钥生命周期的两个关键时间段，从逻辑上无缝衔接，具有高度的说服力和实用性。
**结论**
前后向安全是衡量加密协议安全性的重要标准。只有同时具备这两种特性，才能最大限度地减少密钥泄露带来的危害，保障数据在整个生命周期中的安全。
Model: gpt-4.1-nano-2025-04-142025-09-15 15:08:28
Context:
[
{
"role": "system",
"content": "You are an assistant who is good at conversation. You need to summarize the user's conversation into a title of 10 characters or less. It should be in the format of \"Action - Title\". Some examples:\n1. Learn - Bitcoin 2. Code - Web Server 3. Write - An Article"
},
{
"role": "user",
"content": "[{\"role\":\"user\",\"mainText\":\"help me improve the writing:\\n\\n```\\nTo evaluate \\\\sysname, we benchmarked both AWS Nitro Enclaves and Intel TDX backends across common operations: wallet creation, balance queries, claims, transfers, withdrawals, provenance queries, and an end-to-end workflow.\\nTo pressure test \\\\sysname, we also test a batch of $10000$ internal deposit and claim operations, and transfer then withdraw with multi-thread processing.\\nEach operation was run $100$ times over $10$ trials per environment, measuring throughput in ops/sec. Both environments used identical 4-core, 2.5 GHz, 16 GB VMs to ensure fair comparison. Table~\\\\ref{tab:benchmarks} summarizes our results, with full details available in Appendix~\\\\ref{appendix:benchmark-results}.\\n```\"},{\"role\":\"assistant\",\"mainText\":\"Here is a revised version that improves logical flow, clarity, and precision:\\n\\n---\\n\\nTo evaluate \\\\sysname, we benchmarked its performance using both AWS Nitro Enclaves and Intel TDX as secure backend environments. We selected a suite of representative operations—wallet creation, balance queries, claims, transfers, withdrawals, provenance queries, and a comprehensive end-to-end workflow. To further stress-test \\\\sysname, we conducted batch experiments involving 10,000 consecutive internal deposit and claim operations, as well as transfer-then-withdraw scenarios utilizing multi-threaded processing.\\n\\nEach operation was executed 100 times across 10 independent trials in each environment. Throughput was measured in operations per second (ops/sec). Both environments ran on identical virtual machines (4 cores, 2.5 GHz, 16 GB RAM) to ensure a fair comparison. Table~\\\\ref{tab:benchmarks} presents a summary of the results; full experimental data are provided in Appendix~\\\\ref{appendix:benchmark-results}.\"}]"
}
]Response:
Improve - Benchmarking
Model: gpt-4.1-2025-04-142025-09-15 15:08:26
Context:
[
{
"role": "system",
"content": "You are a research paper writer. You focus on:\n1. logical consistency\n2. whether the story is persuasive\nDon't try to be friendly on purpose, judge everything based on the logic and expressiveness."
},
{
"role": "user",
"content": "help me improve the writing:\n\n```\nTo evaluate \\sysname, we benchmarked both AWS Nitro Enclaves and Intel TDX backends across common operations: wallet creation, balance queries, claims, transfers, withdrawals, provenance queries, and an end-to-end workflow.\nTo pressure test \\sysname, we also test a batch of $10000$ internal deposit and claim operations, and transfer then withdraw with multi-thread processing.\nEach operation was run $100$ times over $10$ trials per environment, measuring throughput in ops/sec. Both environments used identical 4-core, 2.5 GHz, 16 GB VMs to ensure fair comparison. Table~\\ref{tab:benchmarks} summarizes our results, with full details available in Appendix~\\ref{appendix:benchmark-results}.\n```"
}
]Response:
Here is a revised version that improves logical flow, clarity, and precision:
---
To evaluate \sysname, we benchmarked its performance using both AWS Nitro Enclaves and Intel TDX as secure backend environments. We selected a suite of representative operations—wallet creation, balance queries, claims, transfers, withdrawals, provenance queries, and a comprehensive end-to-end workflow. To further stress-test \sysname, we conducted batch experiments involving 10,000 consecutive internal deposit and claim operations, as well as transfer-then-withdraw scenarios utilizing multi-threaded processing.
Each operation was executed 100 times across 10 independent trials in each environment. Throughput was measured in operations per second (ops/sec). Both environments ran on identical virtual machines (4 cores, 2.5 GHz, 16 GB RAM) to ensure a fair comparison. Table~\ref{tab:benchmarks} presents a summary of the results; full experimental data are provided in Appendix~\ref{appendix:benchmark-results}.
Model: gpt-4.1-2025-04-142025-09-15 13:13:42
Context:
[
{
"role": "system",
"content": "You are a research paper writer. You focus on:\n1. logical consistency\n2. whether the story is persuasive\nDon't try to be friendly on purpose, judge everything based on the logic and expressiveness."
},
{
"role": "user",
"content": "I want to replace the \"In practice\" para with a better one, it should be able to logically connect the call for internal transfer and the mismatch in the existing access control models.\n\n```\nCryptocurrency wallets conventionally assume one key, one owner. In this single-entity ownership (SEAO) model, whoever holds the private key gains permanent and total control of the address, and casts publicly readable, gas-consuming blockchain transactions. However, this model struggles to adapt to emerging blockchain scenarios:\n\\begin{enumerate}\n \\item \\textbf{AI and Smart Agent Transactions.} AI agents increasingly manage crypto assets \\cite{patlan2025aiagentscryptoland,walters2025eliza} and require bounded authority and access guardrails for users' asset security.\n \n \\item \\textbf{Enterprise Payroll Privacy.} Organizations need to distribute salaries and departmental budgets to employee accounts without revealing sensitive details on-chain \\cite{pertsev2019tornado,fincen2020ThresholdRule,auer2023banking}.\n \n\\item \\textbf{Consumer-grade Central Limit Order Books.} On-chain order books face high gas costs and latency that prevent real-time trading at scale \\cite{seong2025chainlessappsmodularframework,moosavi2021lissy}, and many consumers prefer not to manage their own keys \\cite{brunner2021keystorage,yu2024walletchoices}.\n\\end{enumerate}\n\nAll three use cases demand support for \\textbf{internal transfers} that are fast, low-cost (ideally free), and private. In these settings, the majority of value movement occurs internally, while onchain transactions are relegated to a secondary role, serving only as settlement events when necessary.\n\nIn practice, many organizations confronted with these challenges default to custodians or policy engines that wrap access logic in Role-Based Access Control (RBAC) or Attribute-Based Access Control (ABAC) \\cite{wallet_features_users2025,erinle2024shared_custodial}. \nThese systems introduce a proliferation of bespoke policy languages and APIs to specify who may sign or transfer under which conditions \\cite{fireblocks_governance_policy_engine,turnkey_policy_quickstart}. \nWhile workable as a stopgap, they inherit identity and role assumptions from traditional IT settings that limit their flexibility and scalability in blockchain contexts.\n\nThe limitation stems from a mismatch of models. Traditional access-control frameworks such as RBAC and ABAC assume an \\emph{endogenous} setting: users create and manage their own files, objects, or services, and policies are attached to these identities or roles. Blockchains are fundamentally \\emph{exogenous}: assets are created outside the wallet by smart contracts and transferred permissionlessly in. In this setting, identity or role-based rules are awkward to express and brittle to enforce. What matters instead is provenance: who deposited an asset, and how it flowed within the wallet. \n```"
},
{
"role": "assistant",
"content": "Certainly. Here is a revised and logically connected paragraph to replace the \"In practice\" section, emphasizing the relationship between the demand for internal transfers and the inadequacy of existing access control models:\n\n---\n\nIn response to these needs, organizations and wallet providers have attempted to retrofit traditional access control paradigms—such as Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC)—to govern internal transfers and shared wallet usage \\cite{wallet_features_users2025,erinle2024shared_custodial}. This typically involves layering custom policy engines or custodial wrappers atop the standard single-owner wallet, specifying who may initiate or approve transfers under various conditions \\cite{fireblocks_governance_policy_engine,turnkey_policy_quickstart}. However, these adaptations inherit foundational assumptions from conventional IT systems, where resources are created and managed by their owners, and access is mediated through stable identities or organizational roles. In blockchain environments, by contrast, value flows into wallets from external, permissionless sources—often via smart contracts—and must be redistributed internally with minimal friction and maximal privacy. The result is a fundamental mismatch: identity- or role-centric controls become complex and brittle to express, failing to provide the flexible, provenance-aware internal transfer mechanisms that these emerging scenarios demand."
},
{
"role": "user",
"content": "add one explanation sentence to this para \"All three use cases demand support ...\" to tell that the on-chain/custodian solution cannot solve the problems "
},
{
"role": "assistant",
"content": "Certainly. Here is the revised paragraph with an added explanatory sentence:\n\n---\n\nAll three use cases demand support for \\textbf{internal transfers} that are fast, low-cost (ideally free), and private. In these settings, the majority of value movement occurs internally, while onchain transactions are relegated to a secondary role, serving only as settlement events when necessary. Purely on-chain or custodial solutions cannot meet these requirements: on-chain transfers are inherently slow, expensive, and public, while custodial models introduce new trust assumptions and often lack fine-grained, flexible internal transfer controls."
},
{
"role": "user",
"content": "I think custodial models also have privacy problem"
}
]Response:
You are correct—custodial models often compromise privacy, as they typically require the custodian to have full visibility into all internal transfers. Here is a revised version of the paragraph that incorporates this point:
---
All three use cases demand support for \textbf{internal transfers} that are fast, low-cost (ideally free), and private. In these settings, the majority of value movement occurs internally, while onchain transactions are relegated to a secondary role, serving only as settlement events when necessary. Purely on-chain or custodial solutions cannot meet these requirements: on-chain transfers are inherently slow, expensive, and public, while custodial models not only introduce new trust assumptions but also compromise privacy, as the custodian typically has full visibility into all internal transfers and account relationships.
Model: gpt-4.1-2025-04-142025-09-15 13:13:00
Context:
[
{
"role": "system",
"content": "You are a research paper writer. You focus on:\n1. logical consistency\n2. whether the story is persuasive\nDon't try to be friendly on purpose, judge everything based on the logic and expressiveness."
},
{
"role": "user",
"content": "I want to replace the \"In practice\" para with a better one, it should be able to logically connect the call for internal transfer and the mismatch in the existing access control models.\n\n```\nCryptocurrency wallets conventionally assume one key, one owner. In this single-entity ownership (SEAO) model, whoever holds the private key gains permanent and total control of the address, and casts publicly readable, gas-consuming blockchain transactions. However, this model struggles to adapt to emerging blockchain scenarios:\n\\begin{enumerate}\n \\item \\textbf{AI and Smart Agent Transactions.} AI agents increasingly manage crypto assets \\cite{patlan2025aiagentscryptoland,walters2025eliza} and require bounded authority and access guardrails for users' asset security.\n \n \\item \\textbf{Enterprise Payroll Privacy.} Organizations need to distribute salaries and departmental budgets to employee accounts without revealing sensitive details on-chain \\cite{pertsev2019tornado,fincen2020ThresholdRule,auer2023banking}.\n \n\\item \\textbf{Consumer-grade Central Limit Order Books.} On-chain order books face high gas costs and latency that prevent real-time trading at scale \\cite{seong2025chainlessappsmodularframework,moosavi2021lissy}, and many consumers prefer not to manage their own keys \\cite{brunner2021keystorage,yu2024walletchoices}.\n\\end{enumerate}\n\nAll three use cases demand support for \\textbf{internal transfers} that are fast, low-cost (ideally free), and private. In these settings, the majority of value movement occurs internally, while onchain transactions are relegated to a secondary role, serving only as settlement events when necessary.\n\nIn practice, many organizations confronted with these challenges default to custodians or policy engines that wrap access logic in Role-Based Access Control (RBAC) or Attribute-Based Access Control (ABAC) \\cite{wallet_features_users2025,erinle2024shared_custodial}. \nThese systems introduce a proliferation of bespoke policy languages and APIs to specify who may sign or transfer under which conditions \\cite{fireblocks_governance_policy_engine,turnkey_policy_quickstart}. \nWhile workable as a stopgap, they inherit identity and role assumptions from traditional IT settings that limit their flexibility and scalability in blockchain contexts.\n\nThe limitation stems from a mismatch of models. Traditional access-control frameworks such as RBAC and ABAC assume an \\emph{endogenous} setting: users create and manage their own files, objects, or services, and policies are attached to these identities or roles. Blockchains are fundamentally \\emph{exogenous}: assets are created outside the wallet by smart contracts and transferred permissionlessly in. In this setting, identity or role-based rules are awkward to express and brittle to enforce. What matters instead is provenance: who deposited an asset, and how it flowed within the wallet. \n```"
},
{
"role": "assistant",
"content": "Certainly. Here is a revised and logically connected paragraph to replace the \"In practice\" section, emphasizing the relationship between the demand for internal transfers and the inadequacy of existing access control models:\n\n---\n\nIn response to these needs, organizations and wallet providers have attempted to retrofit traditional access control paradigms—such as Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC)—to govern internal transfers and shared wallet usage \\cite{wallet_features_users2025,erinle2024shared_custodial}. This typically involves layering custom policy engines or custodial wrappers atop the standard single-owner wallet, specifying who may initiate or approve transfers under various conditions \\cite{fireblocks_governance_policy_engine,turnkey_policy_quickstart}. However, these adaptations inherit foundational assumptions from conventional IT systems, where resources are created and managed by their owners, and access is mediated through stable identities or organizational roles. In blockchain environments, by contrast, value flows into wallets from external, permissionless sources—often via smart contracts—and must be redistributed internally with minimal friction and maximal privacy. The result is a fundamental mismatch: identity- or role-centric controls become complex and brittle to express, failing to provide the flexible, provenance-aware internal transfer mechanisms that these emerging scenarios demand."
},
{
"role": "user",
"content": "add one explanation sentence to this para \"All three use cases demand support ...\" to tell that the on-chain/custodian solution cannot solve the problems "
}
]Response:
Certainly. Here is the revised paragraph with an added explanatory sentence:
---
All three use cases demand support for \textbf{internal transfers} that are fast, low-cost (ideally free), and private. In these settings, the majority of value movement occurs internally, while onchain transactions are relegated to a secondary role, serving only as settlement events when necessary. Purely on-chain or custodial solutions cannot meet these requirements: on-chain transfers are inherently slow, expensive, and public, while custodial models introduce new trust assumptions and often lack fine-grained, flexible internal transfer controls.
Model: gpt-4.1-nano-2025-04-142025-09-15 13:04:45
Context:
[
{
"role": "system",
"content": "You are an assistant who is good at conversation. You need to summarize the user's conversation into a title of 10 characters or less. It should be in the format of \"Action - Title\". Some examples:\n1. Learn - Bitcoin 2. Code - Web Server 3. Write - An Article"
},
{
"role": "user",
"content": "[{\"role\":\"user\",\"mainText\":\"I want to replace the \\\"In practice\\\" para with a better one, it should be able to logically connect the call for internal transfer and the mismatch in the existing access control models.\\n\\n```\\nCryptocurrency wallets conventionally assume one key, one owner. In this single-entity ownership (SEAO) model, whoever holds the private key gains permanent and total control of the address, and casts publicly readable, gas-consuming blockchain transactions. However, this model struggles to adapt to emerging blockchain scenarios:\\n\\\\begin{enumerate}\\n \\\\item \\\\textbf{AI and Smart Agent Transactions.} AI agents increasingly manage crypto assets \\\\cite{patlan2025aiagentscryptoland,walters2025eliza} and require bounded authority and access guardrails for users' asset security.\\n \\n \\\\item \\\\textbf{Enterprise Payroll Privacy.} Organizations need to distribute salaries and departmental budgets to employee accounts without revealing sensitive details on-chain \\\\cite{pertsev2019tornado,fincen2020ThresholdRule,auer2023banking}.\\n \\n\\\\item \\\\textbf{Consumer-grade Central Limit Order Books.} On-chain order books face high gas costs and latency that prevent real-time trading at scale \\\\cite{seong2025chainlessappsmodularframework,moosavi2021lissy}, and many consumers prefer not to manage their own keys \\\\cite{brunner2021keystorage,yu2024walletchoices}.\\n\\\\end{enumerate}\\n\\nAll three use cases demand support for \\\\textbf{internal transfers} that are fast, low-cost (ideally free), and private. In these settings, the majority of value movement occurs internally, while onchain transactions are relegated to a secondary role, serving only as settlement events when necessary.\\n\\nIn practice, many organizations confronted with these challenges default to custodians or policy engines that wrap access logic in Role-Based Access Control (RBAC) or Attribute-Based Access Control (ABAC) \\\\cite{wallet_features_users2025,erinle2024shared_custodial}. \\nThese systems introduce a proliferation of bespoke policy languages and APIs to specify who may sign or transfer under which conditions \\\\cite{fireblocks_governance_policy_engine,turnkey_policy_quickstart}. \\nWhile workable as a stopgap, they inherit identity and role assumptions from traditional IT settings that limit their flexibility and scalability in blockchain contexts.\\n\\nThe limitation stems from a mismatch of models. Traditional access-control frameworks such as RBAC and ABAC assume an \\\\emph{endogenous} setting: users create and manage their own files, objects, or services, and policies are attached to these identities or roles. Blockchains are fundamentally \\\\emph{exogenous}: assets are created outside the wallet by smart contracts and transferred permissionlessly in. In this setting, identity or role-based rules are awkward to express and brittle to enforce. What matters instead is provenance: who deposited an asset, and how it flowed within the wallet. \\n```\"},{\"role\":\"assistant\",\"mainText\":\"Certainly. Here is a revised and logically connected paragraph to replace the \\\"In practice\\\" section, emphasizing the relationship between the demand for internal transfers and the inadequacy of existing access control models:\\n\\n---\\n\\nIn response to these needs, organizations and wallet providers have attempted to retrofit traditional access control paradigms—such as Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC)—to govern internal transfers and shared wallet usage \\\\cite{wallet_features_users2025,erinle2024shared_custodial}. This typically involves layering custom policy engines or custodial wrappers atop the standard single-owner wallet, specifying who may initiate or approve transfers under various conditions \\\\cite{fireblocks_governance_policy_engine,turnkey_policy_quickstart}. However, these adaptations inherit foundational assumptions from conventional IT systems, where resources are created and managed by their owners, and access is mediated through stable identities or organizational roles. In blockchain environments, by contrast, value flows into wallets from external, permissionless sources—often via smart contracts—and must be redistributed internally with minimal friction and maximal privacy. The result is a fundamental mismatch: identity- or role-centric controls become complex and brittle to express, failing to provide the flexible, provenance-aware internal transfer mechanisms that these emerging scenarios demand.\"}]"
}
]Response:
Transfer - Access Mismatch
Model: gpt-4.1-2025-04-142025-09-15 13:04:42
Context:
[
{
"role": "system",
"content": "You are a research paper writer. You focus on:\n1. logical consistency\n2. whether the story is persuasive\nDon't try to be friendly on purpose, judge everything based on the logic and expressiveness."
},
{
"role": "user",
"content": "I want to replace the \"In practice\" para with a better one, it should be able to logically connect the call for internal transfer and the mismatch in the existing access control models.\n\n```\nCryptocurrency wallets conventionally assume one key, one owner. In this single-entity ownership (SEAO) model, whoever holds the private key gains permanent and total control of the address, and casts publicly readable, gas-consuming blockchain transactions. However, this model struggles to adapt to emerging blockchain scenarios:\n\\begin{enumerate}\n \\item \\textbf{AI and Smart Agent Transactions.} AI agents increasingly manage crypto assets \\cite{patlan2025aiagentscryptoland,walters2025eliza} and require bounded authority and access guardrails for users' asset security.\n \n \\item \\textbf{Enterprise Payroll Privacy.} Organizations need to distribute salaries and departmental budgets to employee accounts without revealing sensitive details on-chain \\cite{pertsev2019tornado,fincen2020ThresholdRule,auer2023banking}.\n \n\\item \\textbf{Consumer-grade Central Limit Order Books.} On-chain order books face high gas costs and latency that prevent real-time trading at scale \\cite{seong2025chainlessappsmodularframework,moosavi2021lissy}, and many consumers prefer not to manage their own keys \\cite{brunner2021keystorage,yu2024walletchoices}.\n\\end{enumerate}\n\nAll three use cases demand support for \\textbf{internal transfers} that are fast, low-cost (ideally free), and private. In these settings, the majority of value movement occurs internally, while onchain transactions are relegated to a secondary role, serving only as settlement events when necessary.\n\nIn practice, many organizations confronted with these challenges default to custodians or policy engines that wrap access logic in Role-Based Access Control (RBAC) or Attribute-Based Access Control (ABAC) \\cite{wallet_features_users2025,erinle2024shared_custodial}. \nThese systems introduce a proliferation of bespoke policy languages and APIs to specify who may sign or transfer under which conditions \\cite{fireblocks_governance_policy_engine,turnkey_policy_quickstart}. \nWhile workable as a stopgap, they inherit identity and role assumptions from traditional IT settings that limit their flexibility and scalability in blockchain contexts.\n\nThe limitation stems from a mismatch of models. Traditional access-control frameworks such as RBAC and ABAC assume an \\emph{endogenous} setting: users create and manage their own files, objects, or services, and policies are attached to these identities or roles. Blockchains are fundamentally \\emph{exogenous}: assets are created outside the wallet by smart contracts and transferred permissionlessly in. In this setting, identity or role-based rules are awkward to express and brittle to enforce. What matters instead is provenance: who deposited an asset, and how it flowed within the wallet. \n```"
}
]Response:
Certainly. Here is a revised and logically connected paragraph to replace the "In practice" section, emphasizing the relationship between the demand for internal transfers and the inadequacy of existing access control models:
---
In response to these needs, organizations and wallet providers have attempted to retrofit traditional access control paradigms—such as Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC)—to govern internal transfers and shared wallet usage \cite{wallet_features_users2025,erinle2024shared_custodial}. This typically involves layering custom policy engines or custodial wrappers atop the standard single-owner wallet, specifying who may initiate or approve transfers under various conditions \cite{fireblocks_governance_policy_engine,turnkey_policy_quickstart}. However, these adaptations inherit foundational assumptions from conventional IT systems, where resources are created and managed by their owners, and access is mediated through stable identities or organizational roles. In blockchain environments, by contrast, value flows into wallets from external, permissionless sources—often via smart contracts—and must be redistributed internally with minimal friction and maximal privacy. The result is a fundamental mismatch: identity- or role-centric controls become complex and brittle to express, failing to provide the flexible, provenance-aware internal transfer mechanisms that these emerging scenarios demand.
Model: gpt-4.1-2025-04-142025-09-15 12:56:32
Context:
[
{
"role": "system",
"content": "You are a research paper writer. You focus on:\n1. logical consistency\n2. whether the story is persuasive\nDon't try to be friendly on purpose, judge everything based on the logic and expressiveness."
},
{
"role": "user",
"content": "翻译成中文：The limitation stems from a mismatch of models."
}
]Response:
这种局限性源于模型的不匹配。
Model: gpt-4.1-nano-2025-04-142025-09-15 12:56:16
Context:
[
{
"role": "system",
"content": "You are an assistant who is good at conversation. You need to summarize the user's conversation into a title of 10 characters or less. It should be in the format of \"Action - Title\". Some examples:\n1. Learn - Bitcoin 2. Code - Web Server 3. Write - An Article"
},
{
"role": "user",
"content": "[{\"role\":\"user\",\"mainText\":\"翻译成英文\"},{\"role\":\"assistant\",\"mainText\":\"请提供需要翻译成英文的具体内容。\"},{\"role\":\"user\",\"mainText\":\"The limitation stems from a mismatch of models.\"},{\"role\":\"assistant\",\"mainText\":\"\"}]"
}
]Response:
Translate - Limitation
Model: gpt-4.1-2025-04-142025-09-15 12:56:15
Context:
[
{
"role": "system",
"content": "You are a research paper writer. You focus on:\n1. logical consistency\n2. whether the story is persuasive\nDon't try to be friendly on purpose, judge everything based on the logic and expressiveness."
},
{
"role": "user",
"content": "翻译成英文"
}
]Response:
请提供需要翻译成英文的具体内容。
Model: gpt-4.1-2025-04-142025-09-15 12:52:17
Context:
[
{
"role": "system",
"content": "You are a research paper writer. You focus on:\n1. logical consistency\n2. whether the story is persuasive\nDon't try to be friendly on purpose, judge everything based on the logic and expressiveness."
},
{
"role": "user",
"content": [
{
"type": "text",
"text": "Use the contents of Introduction and Background, answer my question.\n\nMy target is to demonstrate that the existing works cannot satisfy the three use cases in Introduction, and also explain why provenance- and TEE-based solution is a better solution for this."
},
{
"type": "text",
"text": "main.pdf\nPASS: A Provenanced Access Subaccount\nSystem\nfor Blockchain Wallets\nJay Yu\n1,2\n1\nStanford University [email protected]\n2\nPantera Capital [email protected]\nAbstract. Blockchain wallets still follow a single-entity ownership model:\npossession of a private key grants unilateral control. This assumption is\nbrittle for emerging settings such as organizational custody, shared gov-\nernance, and AI agent wallets, where multiple actors must coordinate\nwithout exposing secrets or leaking internal activity.\nWe present PASS, a Provenanced Access Subaccount System\nthat replaces role or identity-based control with provenance-based con-\ntrol: assets can only be used by subaccounts that can trace custody back\nto a valid deposit. A simple Inbox–Outbox mechanism ensures all exter-\nnal actions have verifiable lineage, while internal transfers remain private\nand indistinguishable from ordinary EOAs.\nWe formalize PASS in Lean 4 and prove core invariants, including\nprivacy of internal transfers, asset accessibility, and provenance integrity.\nWe implement a prototype with enclave backends on AWS Nitro Enclaves\nand dstack Intel TDX, integrate with WalletConnect, and benchmark\nthroughput across wallet operations. These results show that provenance-\nbased wallets are both implementable and efficient. PASS bridges today’s\ngap between strict self-custody and flexible shared access, advancing the\ndesign space for practical, privacy-preserving custody.\n1 Introduction\nCryptocurrency wallets conventionally assume one key, one owner. In this single-\nentity ownership (SEAO) model, whoever holds the private key gains permanent\nand total control of the address, and casts publicly readable, gas-consuming\nblockchain transactions. However, this model struggles to adapt to emerging\nblockchain scenarios:\n1. AI and Smart Agent Transactions. AI agents increasingly manage crypto\nassets [?,?] and require bounded authority and access guardrails for users’\nasset security.\n2. Enterprise Payroll Privacy. Organizations need to distribute salaries and\ndepartmental budgets to employee accounts without revealing sensitive de-\ntails on-chain [?,?,?].\n2J. Yu\n3. Consumer-grade Central Limit Order Books. On-chain order books\nface high gas costs and latency that prevent real-time trading at scale [?,?],\nand many consumers prefer not to manage their own keys [?,?].\nIn practice, many organizations confronted with these challenges default to\ncustodians or policy engines that wrap access logic in Role-Based Access Con-\ntrol (RBAC) or Attribute-Based Access Control (ABAC) [?,?]. These systems\nintroduce a proliferation of bespoke policy languages and APIs to specify who\nmay sign or transfer under which conditions [?,?]. While workable as a stopgap,\nthey inherit identity and role assumptions from traditional IT settings that limit\ntheir flexibility and scalability in blockchain contexts.\nThe limitation stems from a mismatch of models. Traditional access-control\nframeworks such as RBAC and ABAC assume an endogenous setting: users\ncreate and manage their own files, objects, or services, and policies are attached\nto these identities or roles. Blockchains are fundamentally exogenous: assets are\ncreated outside the wallet by smart contracts and transferred permissionlessly\nin. In this setting, identity or role-based rules are awkward to express and brittle\nto enforce. What matters instead is provenance: who deposited an asset, and how\nit flowed within the wallet.\nWe propose PASS, a Provenanced Access Subaccount System that enforces\ncontrol directly by provenance. The core mechanism is simple: an Inbox records\nexternal deposits, an Outbox signs and broadcasts withdrawals, and all internal\nmovements remain private and fee-less. Every unit of value inside the wallet has\na verifiable lineage to an on-chain deposit, while externally a PASS wallet is\nindistinguishable from a standard EOA. Our contributions include:\n– A provenance-based access model aligned with blockchain’s exogenous asset\ncreation, enforced through an Inbox–Outbox design.\n– A formal model in Lean 4 proving privacy, accessibility, and provenance\nintegrity.\n– A prototype with multi-vendor enclave backends (AWS Nitro, Intel TDX via\ndstack), a web app frontend integrated with WalletConnect, together with\nthroughput benchmarks.\n– Application scenarios, including organizational custody, privacy-preserving\ntransfers, and safe delegation to AI agents.\nPASS thus bridges the gap between strict self-custody and flexible shared\naccess, combining strong privacy guarantees with practical deployability.\n2 Background and Related Work\nGrowing retail and institutional adoption of digital assets [?] has driven diverse\nwallet designs [?]. We summarize mainstream Ethereum Virtual Machine (EVM)\nwallet designs in Figure ??.\nEOAs and Multisigs. Externally Owned Accounts (EOAs) give unilateral,\npermanent control to whoever holds the private key [?]. Multisignature wallets\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets3\nModelControl basisOn-chain\noverhead\nInternal\nPrivacy\nCompatibility\nEOASingle private keyNoneNoneNative EOA\nMultisigt-of-n co-signersHigh; quorum per\naction\nNone; logic\npublic\nSmart\ncontract based\nERC-4337\nSmart\nAccounts\nOn-chain policy\nlogic\nMedium to high;\ncustom logic and\ngas\nNone; logic\npublic\nRequires\nERC-4337\nchain support\nCustodiansCustom RBAC or\nABAC languages\nNone; Off-chain\nenforcement\nCustodian sees\nall activity\nAPI mediated\nLiquefactionTEE key\nencumbrance;\npolicy trees\nMedium; Oasis\ncontracts and gas\nStrong; TEE\nhides\nsubpolicies\nRequires Oasis\ndeployment\nPASS\n(ours)\nProvenance via\nInbox-Outbox\nNone; EOA\ncompatible\nStrong;\ninternal\ntransfers\ninvisible\nNative EOA\nplus off the\nshelf TEEs\nFig. 1. Comparison of wallet architectures. PASS features provenance-based control,\noff-chain privacy, and native EOA compatibility.\n(eg., Safe) distribute trust via t-of-n approvals [?], common for treasuries and\nbridges [?,?,?]. Drawbacks include quorum overhead, symmetric authority, and\npublic logic with attackable frontends [?]. In contrast, PASS offers fine-grained,\nscoped permissioning without new contracts.\nSmart Contract Wallets and Account Abstraction. Wallets like Ar-\ngent and Loopring add programmability (social recovery, spend limits) via on-\nchain logic [?,?,?]. ERC-4337 enables custom validation through UserOperation\ncontracts [?], and EIP-7702 lets EOAs invoke this logic [?]. These increase flex-\nibility but expose policies publicly and incur gas costs, limiting use cases like\npayroll. PASS instead enforces policy privately in a TEE, minimizing on-chain\nfootprint.\nCustodial Policies. Custody providers (Fireblocks, Turnkey, Privy) use\nRBAC/ABAC engines with custom policy languages [?,?]. PASS replaces these\nwith provenance: authority follows asset origin and history, akin to a UTXO\nmodel. This reduces policy-surface complexity while remaining composable with\nconstraints like whitelists and blacklists.\nTEEs and Liquefaction. Trusted Execution Environments (TEEs) provide\nhardware-isolated contexts with remote attestation [?,?]. Liquefaction [?] keeps\nwallet keys in a TEE and enforces sub-policies via key encumbrance, ensuring\nprivacy. PASS advances this model by (i) proving invariants in Lean 4, (ii) sim-\nplifying enforcement to a provenance rule with Inbox/Outbox subaccounts, and\n(iii) working with a standard EOA without relying on Oasis smart contracts\n[?]. We further validate by implementing PASS on AWS Nitro Enclaves and In-\ntel TDX (via dStack), and showcase applications including AI wallets, payroll,\nsupply chains, and DAO voting.\nOther Models. Exchanges pool funds in omnibus addresses with off-chain\nledgers [?]; mixers like Tornado Cash hide deposit–withdrawal links [?]. PASS\n4J. Yu\nsimilarly hides internal transfers while retaining a provenance log for auditability;\noutsiders see only deposits and withdrawals.\n3 System Model and Design\nFig. 2. Overview of PASS. External deposits enter the Inbox and are claimed by sub-\naccounts. Internal transfers are private and off-chain. Egress occurs via the Outbox,\nwhich signs and broadcasts on-chain transactions. All on-chain activity has clear prove-\nnance; internal movements remain private.\n3.1 High level system model\nPASS is a multi-user wallet on a single EOA (sk, pk). The wallet maintains a\nfinite set of subaccounts U ={u\n1\n,...,u\nn\n} and a set of assets A (e.g., ERC-20).\nA subaccount u ∈ U has authority over an amount x of asset α ∈ A iff it can\nobtain a signature from the global sk via the enclave; sk resides only inside a TEE\nand is never directly accessible. We give the intuitive model here and formalize\nit in Section ??.\nInternally, PASS tracks balances with a map L : U ×A →Z\n≥0\n(accessed\nvia L[u][α]), an Inbox multiset I of unclaimed deposits (α,x,m), an Outbox\nFIFO queueO of pending on-chain actions (α,x, extDst,ν) together with a global\nnonce ν ∈N, and an append-only provenance logH. The core principles of PASS,\nas shown in Figure ?? are as follows:\n1. Access follows provenance. A unit of value is usable by u only if there\nexists a custody chain in H from an external deposit to u. Informally,\nAllow(u,α,x) means balance x is reachable for u via provenance in H. This\nimplies consistency : for every α, the total internal balance equals the on-\nchain balance at pk, i.e.,\nP\nu∈U\nL[u][α] = B\non\n(α). Incoming deposits (α,x,m)∈\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets5\nI are “wrapped” and must be explicitly claimed before use by the sender\naddress.\n2. Off-chain privacy. Internal transfers u→ v update only L and H; they do\nnot touch O or the on-chain balance B\non\n, so internal flow is invisible and\nfee-less.\n3. First-come, first-served. Outbox transactions are sequenced by a FIFO queue,\nwhich maintains and increments a global nonce ν and directly sends enclave-\nsigned transactions to a RPC node to prevent nonce conflicts and replay\nattacks.\n3\nOrganizational Ownership Model. PASS operates under an organiza-\ntional ownership model, where an entity such as a company, individual, or DAO\nmanages shared control over blockchain assets. We detail the threat model in\nSection ??.\nInbox-Outbox Gateway External senders transfer assets to pk, creating\nInbox entries (α,x,m) ∈ I. A user performs claim(u,α,x,m) to move value\nintoL[u][α], conceptually “wrapping” the deposit. To withdraw or interact with\na contract, a subaccount first performs an internal transfer to the Outbox,\nwhich enqueues (α,x, extDst,ν); the enclave then signs the concrete transaction\nwith sk and immediately broadcasts it, incrementing ν. The FIFO discipline and\nglobal nonce serialize actions and prevent races and double-spends. Because sub-\naccounts never receive pre-signed transactions, pre-signing misuse is mitigated.\nComposable policy scheme. Deposits are claims fromI; internal transfers\nrequire Allow(u,α,x) and update (L,H); withdrawals are internal transfers to\nO followed by submission. Additional constraints (eg., RBAC or ABAC checks,\nwhitelists and blacklists) can be incorporated as conjuncts to Allow without\nchanging the provenance-centric rule or its consistency and privacy effects.\n3.2 Formal Model\nWe formalize PASS as a transition system in Lean 4\n4\n, an interactive theorem\nprover with a rich dependent type system [?], suitable for policy verification (eg.,\nAWS Cedar [?]). In this section, we introduce the formal system we modeled in\nlean, and in Section ?? we will discuss security invariants modeled. An extended\ndiscussion of our formal verification system can be found in Appendix ??.\nState. A wallet state is S =\n\u0000\npk, sk,ν,I,O,L,H\n\u0001\nwhere (pk, sk,ν) are the\nEOA public key, private key (generated and held in the TEE), and global nonce;\nI and O are Inbox and Outbox; L is the internal balance map L[u][α] ∈Z\n≥0\n;\nandH is the provenance history. For privacy arguments we also use the external\nview W\npub\n= (pk,O,A), where O contains the Outbox queue and nonce and A\nrecords total on-chain balances by asset.\n3\nWe assume that the TEE is able to run a Helios light client, as is the case in dstack\nIntel TDX, discussed and implemented in Section ??\n4\nLean 4 model: https://github.com/pass-wallet/pass-lean4-proofs\n6J. Yu\nPASS Wallet Management Functionality F\nΣ\nPASS\nfor wallet W\nGlobal State:\npk : public address (EOA)\nsk : private key (in TEE)\nν: global nonce for on-chain transactions\nI (Inbox): set of unclaimed deposits (α : asset,x : amount,m : depositId)\nO (Outbox): FIFO queue (α,x, extDst,ν)\nL (Asset Ledger): internal map L[u][α]∈ Z\n≥0\n, where u is each user’s ID in the system\nH (Provenance History): a list of transaction records appended whenever ClaimInbox,\nInternalTransfer, or Withdraw is invoked\nCreatePassWallet (creator ):\nI← ∅, O← ∅, L←{}; ν← 0\n(pk, sk )← TEE\nKeyGen()\nReturn new W with S =\n\u0000\npk, sk,ν,I,O,L,H\n\u0001\nand reference to creator\nInboxDeposit (α,x,m) from external P :\nI ← I ∪ {(α,x,m)}\nReturn success\nClaimInbox (α,x, depositId) from u:\nIf no (α,x,m) with depositId in I, return ⊥\nRemove (α,x,m) from I\nL[u][α]←L[u][α] + x\nH←H| (op = claim,α,x, depositId,u)\nReturn success\nCheckAllow (u\nsend\n,α,x,H):\nIf H.GetProvenance(α, u\nsend\n)≥ x,\nreturn true; else return false\nInternalTransfer (α,x,u\nsend\n,u\nrecv\n):\nIf L[u\nsend\n][α] < x or ¬checkAllow(u\nsend\n,α,x,H), return ⊥\nL[u\nsend\n][α]←L[u\nsend\n][α]− x\nL[u\nrecv\n][α]←L[u\nrecv\n][α] + x\nH←H\n\f\n\f\n\u0000\nop = transfer,α,x,u\nsend\n,u\nrecv\n\u0001\nReturn success\nWithdraw (α,x,u\nsend\n, extDst):\nIf L[u\nsend\n][α] < x or ¬checkAllow(u\nsend\n,α,x,H), return ⊥\nL[u\nsend\n][α]←L[u\nsend\n][α]− x\nO ←O∪{(α,x, extDst,ν)}\nH←H | (op = withdraw,α,x,u\nsend\n, extDst)\nReturn success\nSignGSM (dom, msg,u):\nIf u lacks sign-right for (dom, msg), return ⊥\nσ ← (sk, msg)\nReturn σ\n(Outbox Processing) (periodic or on demand):\nIf O ̸= ∅, dequeue (α,x, extDst,ν)\nBuild tx τ : transfer x of α to extDst, nonce = ν\nσ ← (sk, τ ); broadcast (τ,σ)\nν←ν + 1\nReturn broadcasted + txHash\nFig. 3. Formal Model of PASS wallet functionality, including CreatePassWallet for\ninitializing a fresh instance. On creation, pk is set to a chosen EOA address eoa, the\nTEE generates a hidden private key sk , and global data structures are initialized.\nExternal deposits enter I (Inbox), while subaccount transfers update L (Ledger) off-\nchain. Withdrawals queue items in O (Outbox), and GSM operations are signed using\nsk .\nTransitions. Operations op∈ T update S with type-checked rules: InboxDe-\nposit adds an unclaimed (α,x,m) to I; ClaimInbox moves (α,x,m) from I to\nL[u][α] and appends to H; InternalTransfer moves value between subaccounts;\nWithdraw debits L[u][α], enqueues (α,x, extDst,ν) in O, and logs; SignGSM\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets7\nauthorizes domain-scoped signable messages. A representative rule is:\n\u0000\npk, sk,ν,I,O,L,H\n\u0001\ntransfer(α,x,u\ns\n,u\nr\n)\n−−−−−−−−−−−→\n\u0000\npk, sk,ν,I,O,L\n′\n,H\n′\n\u0001\nwith\nif L[u\ns\n][α] < x or ¬checkAllow(u\ns\n,α,x,H) then ⊥;\nL\n′\n[u\ns\n][α] =L[u\ns\n][α]− x, L\n′\n[u\nr\n][α] =L[u\nr\n][α] + x;\nH\n′\n=H\n\f\n\f\n\u0000\nop = transfer,α,x,u\ns\n,u\nr\n\u0001\n.\nHere checkAllow queries provenance inH and can be extended with auxiliary\nconstraints such as user whitelists or blacklists, without changing the core rule.\nFigure ?? provides a formal specification of the methods in a PASS wallet.\n3.3 Asset Model and General Signable Messages\nPASS provides an authorization scheme over a heterogenous set of assets A, in-\ncluding fungible tokens, such as ether and ERC-20 tokens, ERC-721 non-fungible\ntokens, and “general signable messages” across a variety of DApps for sign-in\nand identity verification. Each asset α ∈ A has a well-defined custody path in\nthe provenance log H, and a subaccount u ∈ U has usable balance x of α iff\nAllow(u,α,x) holds.\nToken assets. For token assets such as ether, ERC-20, and ERC-721, de-\nposits are captured as Inbox entries (α,x,m) ∈ I. Claims allocate balance into\nL[u][α], internal transfers update L and H privately, and withdrawals enqueue\n(α,x, extDst,ν) intoO for enclave signing and on-chain broadcast, ensuring con-\nsistency where:\n∀α∈A\ntokens\n:\nX\nu∈U\nL[u][α] = B\non\n(α, pk).\nIn particular, ERC-721 tokens are modeled as unitary balances (x ∈ {0, 1})\nwhose transfers preserve uniqueness under provenance.\nGeneral Signable Messages (GSMs). In addition to on-chain assets,\nwallets often sign arbitrary messages, such as for EIP-4361 [?] logins and off-\nchain DAO votes [?]. PASS models these as a special classA\nGSM\nof virtual assets.\nEach GSM asset is scoped to a domain dom, so holding α = (dom) represents\nauthority to sign messages from that domain. A signature operation:\nSignGSM(u, dom,m)7→ σ\nis permitted iff Allow(u, dom, 1) holds in H. At key generation, the wallet\ncreator is endowed with default signing authority over all domains, represented\nas an initial allocation of every α = (dom)∈A\nGSM\nto the root subaccount. These\ndomain assets can be internally transferred to delegate signing authority. Thus\nprovenance of GSMs begins at the owner and flows through transfers, providing\na well defined provenance path in H as with token assets.\n8J. Yu\nBy treating both tokens and GSMs as types of elements ofA, PASS provides\na unified provenance rule for subaccount authorization. A subaccount cannot\nspend an ERC-20 token, transfer an NFT, or sign a domain message unless it\npossesses the corresponding asset under L and H. This unified authorization\nscheme allows for fine-grained delegation, (eg., giving u rights over example.com\nwhile withholding ERC–20 funds) and consistent enforcement across on-chain\nand off-chain actions.\n4 Properties of PASS\n4.1 Threat Model\nPASS assumes an organizational ownership model, where a single entity, such\nas a company, individual, or DAO manages the EOA (pk,sk), brokers access\nbetween many users in that entity, and chooses the TEE infrastructure vendor\n(eg. AWS Nitro, dstack Intel TDX, self-hosted hardware). This model is typical\nfor use cases such as private payroll, supply chains, and AI delegation described\nin Section ??. Protected assets in PASS include the private key sk, the balance\nledger L and provenance log H, and the correctness of Allow(u,α,x) for all\nu∈ U,α∈A,x. In our model, we make the following trust assumptions:\n1. TEE integrity. Hardware isolation is sound; sk never leaves the enclave.\nRemote attestation guarantees that the enclave runs the genuine PASS bi-\nnary.\n2. Cryptography. Standard primitives (signatures, hash functions, PRFs) are\nsecure against polynomial-time adversaries.\n3. Governance majority. The deploying entity holds majority control in the\ngovernance mechanism (via DAO vote or admin privileges), ensuring it can\ninvoke the blockchain-governed KMS for MPC-based key recovery and trig-\nger fallback contracts when needed.\nAdversary Model. An adversary A may control the host OS and network,\nobserve or modify all communication with enclaves, and submit arbitrary trans-\naction requests. In particular, A may attempt to:\n– Exploit software bugs in the PASS implementation or TEE runtime,\n– Forge or replay transactions to break consistency of H,\n– Subvert provenance by violating Allow(u,α,x)\nThreats Out of Scope. On the other hand, PASS does not protect against:\n– Physical compromise of TEE hardware (tampering, microarchitectural side-\nchannels, chip decapsulation),\n– Supply-chain backdoors in TEE manufacturing,\n– Fully malicious operators with unrestricted physical access.\nThese are excluded because the organizational model assumes controlled facilities\nand vetted hardware.\nSecurity Goals. Given the assumptions above, PASS guarantees:\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets9\n1. Integrity:\nP\nu∈U\nL[u][α]≤ extDep(α) for all α, i.e., no assets can be created\nor double-spent internally.\n2. Correctness: If Allow(u,α,x) holds, then u can eventually realize x via\nWithdraw.\n3. Privacy on-chain: InternalTransfer operations do not affect externalTrace(W ),\nand to external observers, a PASS wallet is indistinguishable from an EOA.\n4. Liveness: For any authorized op ∈ Ops, if one enclave and quorum remain\nhonest, then ∃τ s.t. Exec(c, op) =⊤ within τ\n4.2 Privacy and Safety\nAfter establishing the threat model of PASS, we will address the central privacy\nand safety guarantees in our formal verification model. We sketch three central\nlemmas here, and create mechanized proofs in Lean, discussed in Appendix ??.\nProposition 1 (Internal Transfer Privacy). If two public states W\n1\n,W\n2\nshare the same pk, identical Outbox (T,ν), and equal per-asset totals in A, then\nexternalTrace(W\n1\n) = externalTrace(W\n2\n).\nProof Sketch. InternalTransfer updates only (L,H), never O or total on-chain\nbalances. OutboxProcessing in Figure ?? emits on-chain actions solely from O\n(lines 2–4), hence the trace depends only on O.\nCorollary: EOA indistinguishability. If W\npass\nand W\neoa\nshare the same pk,\nOutbox, and per-asset totals, then\nexternalTrace(W\npass\n) = externalTrace(W\neoa\n).\nThus, from an external observer’s perspective, a PASS account is indistinguish-\nable from a standard EOA: internal transfers leave no observable footprint.\nProposition 2 (Asset Accessibility). For any asset α, letting L = {u |\nL[u][α] > 0},\nX\nu∈L\nL[u][α] = totalBalance(α),\nand each u∈ L can spend its full balance subject to checkAllow.\nProof Sketch. ClaimInbox creditsL; InternalTransfer preserves the sum over u;\nWithdraw debitsL and enqueues toO, which OutboxProcessing realizes on-chain.\ncheckAllow enforces reachability from provenance in H.\nProposition 3 (Provenance Integrity). Let extDep(α) be net external de-\nposits (deposits minus realized withdrawals). For all reachable states,\nX\nu\nL[u][α] ≤ extDep(α).\n10J. Yu\nProof Sketch. Induct on transitions. InboxDeposit increases extDep only; Claim-\nInbox moves already-deposited value into L; InternalTransfer conserves the sum\nover u; Withdraw decreases the sum, and after OutboxProcessing broadcasts,\nextDep is reduced accordingly.\nGeneral signable messages (GSM). Model GSM rights as a domain-\nscoped virtual asset class A\nGSM\n. Let α = (dom)∈A\nGSM\nand permit\nSignGSM(u, dom,m) iff Allow(u,α, 1).\nThen (P2)–(P3) lift to GSM: there is always at least one domain signer, and\nGSM “balances” obey provenance conservation under transfers in H.\n4.3 Liveness\nWe define liveness as the property that any authorized operation remains even-\ntually executable, despite enclave crashes, vendor compromise, or partial gover-\nnance failure. Our model assumes deployment of PASS access logic on dstack,\nimplemented in Section ?? and detailed in Appendix ??.\nLet E denote active enclaves, C containerized wallet backends, and P gover-\nnance policies. Each container c∈C stores sealed state\nσ\nc\n=⟨S,k\nc\n, meta⟩ with S = (pk, sk,ν,I,O,L,H),\nwhere k\nc\n= Derive(K,c) is derived from an MPC-managed KMS and meta records\nattestation. An operation op ∈ Ops (deposit claim, transfer, withdrawal) ex-\necutes as: Exec(c, op) = ⊤ iff Attested(c)∧ Γ (S), where Attested(c) checks σ\nc\nagainst registry R and Γ is the quorum predicate over P. To ensure vendor-\nagnostic portability, state migration μ :E →E satisfies\n∀e\ni\n,e\nj\n∈E, e\nj\n.decrypt(σ\nc,e\ni\n,k\nc\n) = σ\nc,e\ni\n,\nTheorem 1 (Liveness Theorem). If (i) the MPC KMS tolerates f\nKMS\nfaults\nin a t-of-n threshold, (ii) governance quorums are f\ngov\n-resilient, and (iii) at least\none enclave is uncompromised, then every op∈ Ops executes within bounded time\nτ :\n∀op∈ Ops, ∃τ ≥ 0 : Exec(c, op) =⊤.\nProof Sketch. Progress follows from three guarantees: (1) the MPC KMS\nensures k\nc\nis always recoverable under threshold availability; (2) Γ encodes quo-\nrum rules that eventually relax after timeout ∆t, ensuring some subset S satisfies\nΓ (S) = ⊤; (3) migration μ allows any enclave to re-host σ\nc\n, preventing vendor\nlock-in or enclave failure from blocking execution. Algorithm ?? formalizes re-\ncovery and execution under these assumptions.\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets11\nAlgorithm 1 RecoverAndExecute(c, op)\n1: Verify enclave e attestation Q\ne\nagainst R.\n2: Derive k\nc\n← Derive(K,c); decrypt σ\nc\n.\n3: if CompromiseDetected(e\n′\n) then\n4:Rotate k\nc\nand re-encrypt σ\nc\n.\n5: end if\n6: Ensure Γ (S) =⊤ for S ⊆P(c).\n7: Execute op; append to H.\nKey Properties. (1) Portability: any attested enclave can recover σ\nc\n, in-\ndependent of vendor; (2) Monotonic Recovery: recovery steps form ρ : S → S\nwith ρ(s)⪰ s; (3) Domain Continuity: certificates remain bound to R(c) under\nmigration μ(c), preventing hijack or replay.\nImplementation details of container orchestration, attestation, and KMS pro-\ntocols are given in Appendix ??.\n5 Practical Implementations\n5.1 Prototype Implementations\nTo demonstrate feasibility, we have implemented a prototype of PASS that cap-\ntures the core architectural components.\n5\nThe prototype consists of:\n– Provenanced Access Model, the core PASS architecture outlined in Sec-\ntion ?? with the Inbox-Outbox structure, asset ledgers, and provenanced\nrule as a Rust executable.\n– Web Application Frontend, an AWS-hosted Typescript interface that\nallows users to deposit assets, initiate internal transfers, generate on-chain\ntransactions, and sign arbitrary messages on Ethereum Sepolia testnet.\n6\n– Multi-vendor TEE deployment, we deploy the PASS enclave executable\nin both AWS Nitro Enclaves and Intel TDX with the dstack framework.\nWe evaluate these two enclave deployments as complementary deployment\npaths, each with distinct tradeoffs.\nAWS Nitro Enclaves. In this design, PASS runs inside a Nitro enclave in the\nAWS cloud. The enclave executes the Inbox–Outbox logic, enforces provenance\nchecks, and signs transactions, while the provenance ledger is stored externally.\nNitro’s attestation and AWS integration simplify deployment, but reliance on a\nsingle vendor limits portability and concentrates trust. As a result, some guaran-\ntees of PASS, particularly liveness and asset accessibility, may be weaker under\nthis model.\n5\nPrototype can be found here: https://github.com/jayyu23/pass-wallet-app\n6\nWeb application: https://pass-wallet.jayyu.xyz/\n12J. Yu\nIntel TDX with dstack. dstack provides a portable, open-source runtime for\nTEEs across diverse hardware. PASS can be deployed on enclaves run by decen-\ntralized operators, with key material secured via MPC-based key management.\nBoth Inbox–Outbox logic and the provenance ledger execute inside dstack, pre-\nserving the full security properties of Section ?? and reducing vendor lock-in.\nThe tradeoff is added governance complexity over operator authorization and\npolicy enforcement.\nBlockchain Connectivity. To ensure reliable blockchain interaction, PASS inte-\ngrates Helios [?], a consensus-verified light client, within the TEE. Rather than\ntrusting external RPC endpoints, Helios cryptographically verifies all blockchain\ndata against consensus layer proofs before serving it locally. This approach elimi-\nnates the trust assumptions typically associated with centralized RPC providers\nwhile maintaining the performance characteristics necessary for real-time wallet\noperations. The light client architecture ensures that PASS’s Outbox mecha-\nnism operates on verified blockchain state, preserving the security guarantees\neven when external network providers are compromised or unreliable.\n5.2 Performance Benchmarks\nTo evaluate PASS, we benchmarked both AWS Nitro Enclaves and Intel TDX\nbackends across common operations: balance queries, transfers, withdrawals,\nclaims, wallet creation, provenance queries, and an end-to-end workflow. Each\noperation was run 100 times over 10 trials per environment, measuring through-\nput in ops/sec. Both environments used identical 4-core, 2.5 GHz, 16 GB VMs\nto ensure fair comparison. Table ?? summarizes our results, with full details\navailable in Appendix ??.\nFig. 4. Internal PASS operation throughput (ops/sec) across AWS Nitro Enclaves\nand Intel TDX. All operations are in-memory state changes within the TEE with no\nblockchain interaction. Each value represents the average of 100 operations repeated\n10 times per environment.\nOperationAWS Nitro Intel TDX\nWallet Creation6,53114,970\nAccount Balance Queries530,943935,428\nInbox-to-Subaccount Claims14,85633,064\nInternal Subaccount Transfers32,95371,292\nWithdrawal Request Creation18,29139,702\nEnd-to-End Workflow\n7\n35,66378,433\nTransaction History Queries3,7577,685\nMulti-threaded Operations (5 threads)32,18955,124\nLarge Dataset Processing481724\nThe observed performance differences between AWS Nitro Enclaves and In-\ntel TDX primarily stem from their distinct hardware architectures. AWS Nitro\nEnclaves employ a disaggregated system design, where the host server and the\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets13\nTEE hardware are physically separated. Communication between the host and\nthe enclave occurs via vsock, and the enclave itself runs on a dedicated, lower-\nperformance coprocessor. In contrast, Intel TDX leverages a special instruction\nset to provide enclave functionality directly on the main processor, eliminating\nthe need for a separate coprocessor and avoiding the overhead of data transfer\nbetween disparate components. As a result, Intel TDX is able to deliver sig-\nnificantly higher throughput for in-enclave operations compared to AWS Nitro\nEnclaves, as reflected in our benchmark results.\nThese preliminary benchmarks show that both Nitro and TDX backends can\nsustain high throughput for critical wallet operations, confirming that PASS is\npractical for real-world deployment.\nComparison with Related Work. To contextualize our performance results, we\ncompare PASS with other TEE-based blockchain systems and traditional custo-\ndial solutions.\nLiquefaction. The Liquefaction system [?] demonstrates significantly higher\nlatencies than PASS due to its reliance on blockchain oracles for transaction\nvalidation. Liquefaction exhibits mean latencies of 49 seconds for latest block\nconfirmation, 648.7 seconds ( 11 minutes) for justified confirmation, and 1,036.9\nseconds ( 17 minutes) for finalized confirmation. These delays stem from Liq-\nuefaction’s architectural requirement to wait for block confirmations on an ex-\nternal TEE-blockchain oracle before authorizing subsequent operations. In con-\ntrast, PASS performs all operations within the off-chain TEE worker without\nblockchain dependencies, achieving sub-millisecond latencies for internal opera-\ntions (e.g., 14,856-33,064 ops/sec for claims, 32,953-71,292 ops/sec for transfers).\nThis fundamental architectural difference—off-chain TEE computation versus\nblockchain-dependent validation—enables PASS to provide near-instantaneous\nuser experiences while maintaining strong security guarantees.\nTraditional Custodians. While custodial solutions do not publish detailed\nperformance benchmarks, prior work demonstrates that TEE overhead typically\nintroduces only 5-7% performance degradation compared to native execution [?].\nGiven that modern custodial systems can process thousands of operations per\nsecond, TEE-based solutions like PASS should achieve comparable throughput\nwhile providing significantly stronger security properties. Our benchmark results\nsupport this expectation, with PASS demonstrating high-throughput operation\nprocessing that would be suitable for production custodial workloads, while offer-\ning the additional benefits of cryptographic auditability, decentralized operation,\nand reduced single points of failure.\nFurther evaluation of latency distributions, concurrency scaling, and memory\nfootprint is left for future work.\n6 Applications\nPASS is a powerful primitive that enables several classes of applications across\nidentity scoping, enterprise settings, and scalability concerns.\n14J. Yu\nCategoryApplicationContextPASS Enables\nIdentities\nAI Agent\nWallets\nAutonomous agents\ninteracting with crypto\nassets [?] need signing\naccess guardrails.\nScoped subaccounts grant limited\nbalances and domain signing rights,\nenabling safe delegation without\nexposing the root key\nDAO Voting\nDelegation\nDAOs depend on\naddress-based voting and\nproxy delegation [?].\nFine-grained voting rights delegation\nthat remains auditable via provenance;\ndelegation can be restricted to specific\nDApps or domains.\nSubdomain\nProfile Pages\nOrganizations delegate\ncontrol over web or\norganizational\nsubdomains (e.g.,\nmyprofile.company.com) to\nindividuals or teams.\nEach subaccount holds scoped signing\nrights for its assigned subdomain, with\nbalances and authorities tracked in\nprovenance under a shared\norganizational identity.\nEnterprise\nPrivate PayrollOn-chain payrolls reveal\nsensitive salary\ninformation [?].\nSalary distribution through internal\ngasless transfers with audit logs;\nexternal payouts are periodically\nbatched via the Outbox.\nCompliant Org\nWallets\nFirms must maintain\ninternal accountability\nand BSA\nrecordkeeping [?].\nDepartmental and individual\nsubaccounts with explicit budgets;\nprovenance ensures regulator-grade\nauditability without exposing internal\nflows.\nPrivate B2B\nNetting\nSupply-chain and\nrecurring multi-party\npayments require\nconfidentiality.\nVendor subaccounts allow internal\nnetting of obligations, with PASS\nacting as a temporary clearing house.\nOnly net settlements exit via the\nOutbox, reducing leakage while\nretaining auditability.\nAudit / Proof\nExplorer\nRegulators and auditors\nrequire verifiable yet\nprivacy-preserving\ntransparency.\nPublic proofs derived from the\nprovenance log H, enabling compliance\nchecks and audits without disclosing\ninternal ledger state.\nScalability\nGasless\nAppchain\nHigh-throughput\napplications (e.g., trading\nengines) face prohibitive\ngas costs on-chain.\nInternalize application logic as\nsubaccount transitions; Outbox emits\nverifiable batch settlements, ensuring\ncorrectness with minimal gas.\nCross-chain\nBridges\nBridges require strong\ncustody and coordination\nof operators [?].\nInbox-Outbox abstractions enforce\nprovenance across domains; FIFO\nnonce handling prevents replay or race\nconditions.\nL2 ComposabilityRollups and L2s fragment\nassets and user\nexperience [?].\nTreat each L2 as a scoped subaccount;\nmaintain private balance transfers\ninternally, and settle externally only\nwhen crossing domains.\nFig. 5. Applications of PASS across identities, enterprise settings, and scalability so-\nlutions. We highlight a flagship application in each category.\nIdentities and Agent Delegation. PASS’s multi-user subaccount model\nallows for flexible permission scopes. As AI agents start managing crypto as-\nsets, there is a need to constrain their access. An AI agent could be given a\nsub-account that only holds limited funds or certain asset types. The AI can op-\nerate freely within those bounds, but cannot exceed its allotted assets or misuse\nother wallet assets. If compromised, damage is capped to its sub-account. This\nis much safer than giving AI the keys to an entire wallet. Similarly, PASS can\nallow for delegation-based DAO voting by giving the delegate signature rights\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets15\nover particular voting DApps, without giving access to actually transfer the as-\nsets. Subaccounts can also get scoped signing rights over particular enterprise\nsubdomains.\nEnterprise Applications. PASS’s features of internal privacy, in-built per-\nmissioning, and provenance auditability make it uniquely suited for enterprise\napplciations. A flagship use case for PASS is private payroll. On-chain salary pay-\nments today risk exposing sensitive information such as individual compensation,\ndepartmental budgets, or timing patterns. With PASS, salaries are distributed\ninternally through gasless subaccount transfers, leaving a clear provenance log for\nauditability, but without revealing per-employee details on-chain. Only periodic,\non-demand payouts exit via the Outbox, ensuring both regulatory accountability\nand privacy for internal flows. Beyond payroll, PASS supports other enterprise\nneeds: compliant organizational wallets with departmental subaccounts that en-\nforce explicit budgets, private B2B netting where vendors settle obligations inter-\nnally and only net payments leave the wallet, and auditable proof explorers that\nprovide regulators with verifiable, privacy-preserving compliance proofs derived\nfrom the provenance log.\nScalability Solutions. PASS also supports scaling use cases where on-chain\ncosts or coordination overhead make existing approaches impractical. A flagship\nexample is gasless appchains, such as for Central Limit Orderbooks (CLOBs).\nHigh-throughput applications such as CLOBs cannot afford per-transaction gas\nfees, but PASS internalizes application logic as private subaccount transitions.\nThe Outbox then emits verifiable batch settlements with minimal gas, preserv-\ning correctness while keeping costs predictable. Beyond appchains, PASS enables\ncross-chain bridges by enforcing provenance across domains and sequencing with-\ndrawals via a FIFO nonce to prevent replay or race conditions, and supports L2\ncomposability by treating each rollup or sidechain as a scoped subaccount, main-\ntaining private balance transfers internally and settling externally only when\ncrossing domains.\n7 Discussion and Future Work\n7.1 Composability and InterPASS Transactions\nWhile PASS provides privacy and provenance guarantees for a single wallet in-\nstance, an important question is how multiple PASS wallets may interact. This\nis important in supply-chain use cases where each PASS represents a single com-\npany in the supply chain.\nTrivially, PASS A can send an on-chain transaction from its Outbox to PASS\nB’s EOA account, and this will land in the Inbox of PASS B, ready to claim.\nHowever, this undermines the privacy guarantees that PASS offers at the EOA\nlevel, and is undesirable in cases where inter-organizational asset transfers con-\ntain sensitive information, such as order details.\nWe propose a non-trivial approach inspired by cross-Payment Channel Net-\nwork (PCN) protocols such as XTransfer [?]. We can treat each PASS instance\n16J. Yu\nakin to a PCN hub node, with state L and transaction history H. As with\nXTransfer, we can assume a star topology of PASS nodes, with a central PASS\nHub in communciation with all PASS nodes. The PASS Hub will aggregate all\nInterPASS transactions T := {(a\ni\n,x\ni\n,s\ni\n,r\ni\n)}\nn\ni=1\n, where (a\ni\n,x\ni\n,s\ni\n,r\ni\n) represent\nthe asset, amount, sender, and receiver, each signed by the s\ni\nOutbox.\nThe Hub aggregates these signed payment intents, computes a netted settle-\nment plan S, and coordinates a secure multi-party update protocol to commit\nthe resulting balances, similar to Thora [?]. In the optimistic case, this process\ncompletes entirely off-chain, and each participant’s balance is updated in the\nPASS ledger without revealing the underlying transaction graph. If a dispute or\nfailure occurs, any participant may trigger an on-chain enforcement transaction\nthat finalizes S atomically via the direct transfer mechanism, thus guaranteeing\nsafety.\nThis approach leverages PASS ’s provenance and state design to make each\ninstance an atomic node in PCN-style systems like X-Transfer. Here, we outline\nhow PASS Hubs can enable confidential, auditable cross-organization transfers,\nwhile full formal specification and protocol implementation is deferred for future\nwork.\n7.2 Instantiation on zkVM\nThe PASS design presented in this paper relies primarily on trusted execution\nenvironments (TEEs) to enforce provenance rules, where the enclave isolates the\nglobal secret key and mediates all access through the Inbox–Outbox mechanism.\nWhile TEEs provide strong privacy and efficiency guarantees, their trust model\ndepends on hardware attestation and vendor integrity, which may be insufficient\nin regulatory or adversarial settings that demand independent verification.\nzkVMs provide a natural next step by enabling provenance-based control to\nbe verified through succinct cryptographic proofs rather than trusted hardware.\nBy batching transitions over L, H, I, and O and producing a proof π, a mini-\nmalist verifier contract can update commitments and enforce outbox execution\nwhile preserving privacy. This direction complements the Chainless stack ar-\nchitecture [?], suggesting a path toward modular, interoperable deployments of\nPASS with stronger external verifiability and broader applicability.\n8 Conclusion\nWe presented PASS, a Provenanced Access Subaccount System, as a new wallet\narchitecture that enforces access by provenance rather than by identity or role.\nThe Inbox–Outbox mechanism ensures all assets have a verifiable lineage, while\ninternal transfers remain private and indistinguishable from a standard EOA\naccount.\nOur contributions are threefold: (i) a formal model in Lean 4 proving pri-\nvacy, accessibility, and provenance integrity; (ii) a working prototype with en-\nclave backends on AWS Nitro Enclaves and Intel TDX via dstack, integrated\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets17\nwith WalletConnect; and (iii) initial benchmarks showing the feasibility of high-\nthroughput operation. These results demonstrate that provenance-based control\ncan be realized today with mainstream blockchain tools.\nLooking forward, richer evaluations across multi-vendor TEEs, integration\nwith zero-knowledge VMs, and exploration of organizational and agent-based\ncustody are promising directions. By combining rigorous formal guarantees with\ndeployable prototypes, PASS advances the design space between strict self-\ncustody and flexible shared access, offering a path toward practical, privacy-\npreserving wallet security.\nA Formal Verification\nWe consider the formal model introduced in Section ?? of PASS as a state\nmachine in Lean4. Our goal is to prove that, under the PASS design, several\ncritical security properties always hold. We outline these properties and our\napproach to verifying them.\nA.1 Property: Privacy of Internal Transfers\nIn the PASS design, the InternalTransfer operation updates only the off-chain\nledgerL and the provenance historyH. It never modifies the OutboxO, meaning\nthere is no on-chain transaction triggered by an internal transfer. Consequently,\nexternal observers see no change in on-chain state. We formalize this by consid-\nering the on-chain view that an external party has for a given PASS Wallet. We\ncan model this visible on-chain state as a triple:\nW\npub\n=\n\u0000\npk, O, A\n\u0001\n,\nwhere:\npk is the externally owned account (EOA) address,\nO = (T,ν) is the external view of the outbox, where T is a list of enqueued\ntransactions and ν is a nonce,\nA is the external view of the Asset ledgerL, containing a list of asset entries,\neach of the form (α,x) with a unique identifier α and total balance x.\nExternal Trace. The external trace of a PassAccount state W\npub\nis the list of\nexternally visible actions, obtained by mapping each transaction in the outbox\nT to an on-chain action:\nexternalTrace(W\npub\n) =\n\b\noutboxTx(t) | t∈ T\n\t\n.\nNo internal transfers appear in externalTrace(·).\n18J. Yu\nStates That Differ Only by Internal Transfers. We say that two PassAccount\nstates W\n1\n= (pk\n1\n,O\n1\n,A\n1\n) and W\n2\n= (pk\n2\n,O\n2\n,A\n2\n) differ only by internal trans-\nfers if:\n1. pk\n1\n= pk\n2\n,\n2. O\n1\n= O\n2\n(i.e. both the list of outbox transactions and the nonce are the\nsame),\n3. For every asset identifier α, the total balance of that asset in A\n1\nequals the\ntotal balance of the same asset in A\n2\n.\nLetting getAsset(W,α) return the asset α within state W or ⊥, we require ∀α:\ntotalBalance\n\u0000\ngetAsset(W\n1\n,α)\n\u0001\n= totalBalance\n\u0000\ngetAsset(W\n2\n,α)\n\u0001\n.\nTheorem 2 (Privacy of Internal Transfers). If two PassAccount states W\n1\nand W\n2\ndiffer only by internal transfers, then their externally visible traces are\nidentical:\nexternalTrace(W\n1\n) = externalTrace(W\n2\n).\nProof. By assumption, O\n1\n= O\n2\n. Hence both states have the same outbox trans-\naction list T . Since\nexternalTrace(W\ni\n) = map\n\u0000\noutboxTx, T\ni\n\u0001\nfor i∈{1, 2},\nand T\n1\n= T\n2\n, it follows that externalTrace(W\n1\n) and externalTrace(W\n2\n) are iden-\ntical.\nThus, any sequence of purely internal transfers, changing only the private ledger\nL in PASS, is invisible to an external observer, preserving the privacy of how\nassets move within the wallet.\nA corollary of this Internal Transfer property is that a PASS account is\nindistinguishable from a regular EOA account.\nCorollary 1 (Indistinguishability from EOA). Let W\npass\nbe a PASS state\nthat (i) has the same public key pk, (ii) the same outbox, including nonce and\ntransaction list, and (iii) the same total balances of each asset as a reference\nEOA state W\neoa\n. Then\nexternalTrace(W\npass\n) = externalTrace(W\neoa\n).\nIn particular, an external observer cannot distinguish W\npass\nfrom W\neoa\n.\nProof. By assumption, the only potential differences betweenW\npass\nandW\neoa\nlie\nin internal ledger details. From Theorem 1, such internal transfers do not affect\nthe externally visible outbox transactions or total on-chain balances. Thus, their\nexternal traces coincide, and W\npass\nis indistinguishable from W\neoa\n.\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets19\nA.2 Property: Asset Accessibility\nIn addition to keeping internal transactions private, PASS should ensure that for\nevery asset in the system, there exists some sub-account that can access it and\nwithdraw it from the system. This prevents a situation where funds get ”stuck”\nwithout any reachable key or policy to move them. We define asset accessibility\nas follows:\nTheorem 3 (Asset Accessibility). For any PASS account W and asset iden-\ntified by α, there exists a list of addresses L such that:\n1. For every address u∈ L, the user can access their full balance:\ncheckBalance(s,α,u, balance(u)) = true\n2. The sum of all accessible balances equals the total balance of the asset:\nX\nu∈L\nL[u][α] = totalBalance(α)\nProof. We construct L as the set of all addresses with non-zero balances in the\nbalance map for α:\nL ={u|L[u][α] > 0}\nFor the first property, given any u∈ L, the definition of checkBalance verifies\nif the user has sufficient balance for the specified amount. When checking against\nthe user’s own balance, this is trivially satisfied since L[u][α]≥L[u][α] for all u.\nFor the second property, we observe that totalBalance is defined as the sum\nof all balances in the asset’s balance map:\ntotalBalance(α) =\nX\nu∈L\nL[u][α]\nBy construction, L contains the only nonzero values u∈L, so:\nX\nu∈L\nL[u][α] = totalBalance(α)\nTherefore, both properties hold for our constructed list L.\nWe can prove a similar trait for General Signable Messages, showing that for\nany inbound GSM, there is some subaccount signer that has access to it.\nTheorem 4 (GSM Accessibility). For any GSM and domain, there exists a\nuser with signing access to that domain.\nProof. For any domain d, we can directly construct a user u who has signing\naccess to d as follows:\nu = getSigner(d)\nBy definition, getSigner returns either:\n– A specifically assigned signer if one exists in the domain-address map, or\n– The default signer otherwise\nTherefore, every domain is guaranteed to have at least one user with signing\naccess, ensuring no GSM domain becomes inaccessible.\n20J. Yu\nA.3 Property: Provenance Integrity\nProvenance integrity specifies that every asset held by any sub-account in PASS\nmust have an origin traceable to an external deposit into the Inbox. At any\nstate of the system, for each asset entry in a sub-account’s balance, we can find\na sequence of internal transfers that leads back to an Inbox deposit from an\nexternal address. This property ensures no sub-account can conjure funds from\nnothing, such as through double-spending or inflation within the system, and\nthat the internal ledger is consistent with on-chain reality. In Lean, we model\nthe state of the PASS wallet including Inbox, Outbox, and all sub-accounts and\nprove an invariant that whenever a sub-account has x units of asset α, the global\nstate contains a record of at least x units of α having been deposited, minus any\nthat have been withdrawn.\nTheorem 5 (Provenance Integrity).\nFor any PASS account S =\n\u0000\npk, sk,ν,I,O,L,H\n\u0001\nand any asset α, the total\namount of α held across all subaccounts can never exceed the total amount of\nexternal deposits (minus any that have already been withdrawn). Formally,\nX\nu∈U\nL[u][α] ≤ externalDeposits(α),\nwhere U is the set of subaccounts in the system, and externalDeposits(α) is\nthe net total of asset α that has been introduced into the wallet from outside\naddresses, recorded in the inbox I.\nProof. We model the system’s state (pk, sk,ν,I,O,L,H) as in Figure ??, includ-\ning the Inbox I, Outbox O, and the internal ledger L. We define a provenance\nrecord P (α,u) that captures the total amount of asset α subaccount u is autho-\nrized to hold, based on Inbox claims and internal transfers.\nBase Case: Immediately after CreatePassWallet, no assets have been de-\nposited, and no subaccount balances exist:\n∀u, L[u][α] = 0, ∀α, externalDeposits(α) = 0.\nHence,\nX\nu∈U\nL[u][α] = 0 ≤ 0 = externalDeposits(α).\nInductive Step: Assume the invariant holds after n− 1 operations. We prove it\nremains valid after the nth operation, for each possible type of operation:\n(1) External Deposit: Suppose an amount x of asset α is deposited into the\nwallet:\nexternalDeposits(α) ← externalDeposits(α) + x.\nNo subaccount balances L[u][α] change. Thus, the left side of our inequality\n(sum of subaccount balances) is unchanged, while the right side strictly\nincreases by x, so the invariant continues to hold.\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets21\n(2) Inbox Claim: If subaccount u claims amount x of asset α from the Inbox\nI:\nL[u][α] ← L[u][α] + x, P (α,u) ← P (α,u) + x.\nSince x was already accounted for in externalDeposits(α) (but not yet allo-\ncated to any subaccount), the total subaccount balances remain≤ externalDeposits(α).\n(3) Internal Transfer: If subaccount u\n1\ntransfers x of α to subaccount u\n2\n:\nL[u\n1\n][α] ← L[u\n1\n][α]− x, L[u\n2\n][α] ← L[u\n2\n][α] + x,\nand P (α,u\n2\n) increases by x. Because the sum of all subaccount balances\ndoes not change, our invariant is preserved.\n(4) Withdrawal: If subaccount u withdraws x of α:\nL[u][α] ← L[u][α]− x,\nwhich reduces the total subaccount balances. Since externalDeposits(α)\nremains unchanged (assets have simply exited the wallet), the inequality still\nholds.\nThus, by induction over all possible operations,\nX\nu∈U\nL[u][α] ≤ externalDeposits(α)\nfor every reachable state. No subaccount can create new assets out of nothing,\nand all assets in the system are fully accounted for by provenanced deposits.\nB Dstack Architecture and Execution Model\nB.1 Component Overview\n– Dstack-OS: Minimal Linux-based VM image with a verifiable boot chain.\nMeasures bootloader, kernel, root filesystem (RootFs) via RTMR registers.\nIntegrates dm-verity for data integrity and monotonic counters for anti-\nrollback.\n– Dstack-KMS: Blockchain-governed MPC network for key derivation and\nrotation. Provides:\nk\nc\n= HMAC\nk\nroot\n(c\nid\n),\nk\nTLS\n= ECDSA(k\nroot\n).\nRotation is triggered via governance (t-of-n threshold).\n– Dstack-Gateway/Ingress: TLS termination inside TEEs, ZT-TLS bind-\ning X\nc\nto R(c), enabling verifiable HTTPS ingress.\n22J. Yu\nB.2 Governance Layer\nTwo contracts form the trust base:\n– KmsAuth: Global registry of KMS nodes and application digests.\n– AppAuth: Per-application contract specifying quorum rules, allowed image\nhashes, and authorized enclaves.\nB.3 Workflow Phases\n1. Attestation: Enclave e produces quote Q\ne\n; verified against R.\n2. Secret Provisioning: MPC nodes compute k\nc\n, release to e if Q\ne\nis valid.\n3. Container Launch: Dstack-OS mounts RootFs, decrypts state σ\nc\nwith k\nc\n.\n4. Ingress Binding: TLS certificate X\nc\ngenerated inside e; bound to R(c).\n5. Audit Logging: Migration, key rotation, and governance events appended\nto H.\nB.4 Fault Tolerance\n– Vendor failure: μ enables re-deployment across Intel/AMD TEEs.\n– KMS compromise: key rotation via MPC thresholds restores forward/backward\nsecrecy.\n– Governance deadlock: ∆t fallback in Γ ensures quorum reduction and progress.\nB.5 Liveness Proof Sketch\nCombining MPC-based key recovery, quorum fallback, and portable containers\nyields:\n∀op∈O\nc\n,Pr[Exec(c, op) =⊤] = 1\nunder assumptions of f -resilient MPC nodes and at least one uncompromised\nTEE instance.\nC Detailed Benchmark Results\nThis appendix provides comprehensive benchmark statistics for both AWS Nitro\nEnclaves and Intel TDX environments. All operations are internal PASS state\nchanges that occur within the TEE with no blockchain network interaction.\nEach operation was executed 100 times per trial, with 10 independent trials\nper environment. The tables below show summary statistics including mean,\nstandard deviation, and range.\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets23\nTable 1. AWS Nitro Enclaves benchmark statistics (ops/sec) across 10 trials\nOperationMean Std Dev Min Max\nWallet Creation6,5315315,4467,042\nAccount Balance Queries530,943675 530,216 531,915\nInbox-to-Subaccount Claims14,856476 14,326 15,504\nInternal Subaccount Transfers32,9531,322 31,447 35,088\nWithdrawal Request Creation18,2911,254 15,873 19,608\nEnd-to-End Workflow35,6636,234 21,739 40,650\nTransaction History Queries3,757453,6503,802\nMulti-threaded Operations (5 threads) 32,189884 31,200 34,364\nLarge Dataset Processing48113467497\nTable 2. Phala dStack benchmark statistics (ops/sec) across 10 trials\nOperationMean Std Dev Min Max\nWallet Creation14,9704,6528,69624,390\nAccount Balance Queries935,428338,450 383,142 1,470,588\nInbox-to-Subaccount Claims33,0645,197 25,44541,667\nInternal Subaccount Transfers71,29217,623 47,170 101,010\nWithdrawal Request Creation39,7027,434 29,15551,813\nEnd-to-End Workflow78,43317,403 59,524 110,497\nTransaction History Queries7,6858726,4528,929\nMulti-threaded Operations (5 threads) 55,12416,744 28,32981,301\nLarge Dataset Processing72481636893\nC.1 AWS Nitro Enclaves Results\nC.2 Intel TDX Results\nC.3 Performance Analysis\nThe statistical analysis reveals several key insights about PASS’s internal oper-\nation performance:\n– Performance Consistency: AWS Nitro Enclaves demonstrate superior\nconsistency with lower standard deviations across all operations. The co-\nefficient of variation ranges from 0.1% (Account Balance Queries) to 17.5%\n(End-to-End Workflow).\n– Peak Performance: Intel TDX achieves higher mean throughput but with\nsignificantly greater variance. Standard deviations are 10-500x larger than\nNitro, indicating less predictable performance.\n– Production Considerations: These internal operation benchmarks demon-\nstrate PASS’s ability to handle thousands of wallet operations per second\nwithin the TEE, with the actual deployment bottleneck being blockchain\ntransaction submission rather than internal processing.\nThe statistical summary confirms that both platforms support practical PASS\ndeployment, with Nitro offering predictable performance and Intel TDX provid-\ning higher peak throughput at the cost of consistency.\n24J. Yu\nD Design Extensions\nD.1 Composability and InterPASS Transactions\nWhile PASS provides privacy and provenance guarantees for a single wallet in-\nstance, an important question is how multiple PASS wallets may interact. This\nis important in supply-chain use cases where each PASS represents a single com-\npany in the supply chain.\nTrivially, PASS A can send an on-chain transaction from its Outbox to PASS\nB’s EOA account, and this will land in the Inbox of PASS B, ready to claim.\nHowever, this undermines the privacy guarantees that PASS offers at the EOA\nlevel, and is undesirable in cases where inter-organizational asset transfers con-\ntain sensitive information, such as order details.\nWe propose a non-trivial approach inspired by cross-Payment Channel Net-\nwork (PCN) protocols such as XTransfer [?]. We can treat each PASS instance\nakin to a PCN hub node, with state L and transaction history H. As with\nXTransfer, we can assume a star topology of PASS nodes, with a central PASS\nHub in communciation with all PASS nodes. The PASS Hub will aggregate all\nInterPASS transactions T := {(a\ni\n,x\ni\n,s\ni\n,r\ni\n)}\nn\ni=1\n, where (a\ni\n,x\ni\n,s\ni\n,r\ni\n) represent\nthe asset, amount, sender, and receiver, each signed by the s\ni\nOutbox.\nThe Hub aggregates these signed payment intents, computes a netted settle-\nment plan S, and coordinates a secure multi-party update protocol to commit\nthe resulting balances, similar to Thora [?]. In the optimistic case, this process\ncompletes entirely off-chain, and each participant’s balance is updated in the\nPASS ledger without revealing the underlying transaction graph. If a dispute or\nfailure occurs, any participant may trigger an on-chain enforcement transaction\nthat finalizes S atomically via the direct transfer mechanism, thus guaranteeing\nsafety.\nThis approach leverages PASS ’s provenance and state design to make each\ninstance an atomic node in PCN-style systems like X-Transfer. Here, we outline\nhow PASS Hubs can enable confidential, auditable cross-organization transfers,\nwhile full formal specification and protocol implementation is deferred for future\nwork.\nD.2 Instantiation on zkVM\nThe design of PASS presented thus far relies on trusted execution environments\n(TEEs) such as AWS Nitro or Intel TDX to enforce provenance-based control.\nTEEs provide strong isolation and efficient execution, allowing internal transfers\nto remain private while ensuring that every outbox action has a verifiable lin-\neage. However, the trust model is anchored in hardware attestation: users and\nregulators must accept that the enclave executes the correct code as claimed.\nWhile sufficient for many organizational custody scenarios, this assumption lim-\nits transparency and long-term auditability. To address this limitation, we ex-\nplore an alternative instantiation of PASS in a zero-knowledge virtual machine\n(zkVM), replacing hardware trust with cryptographic proofs of correctness.\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets25\nZero-knowledge virtual machines (zkVMs) provide a proving environment in\nwhich arbitrary state machines can run with strong correctness guarantees [?].\nBy producing a succinct proof π of execution, zkVMs offer integrity assurances\nsimilar to TEEs but without reliance on vendor-specific hardware. This shift\nmakes zkVMs particularly suitable for contexts such as institutional custody,\nmulti-party supply chains, or inter-organizational accounting where external ver-\nifiability and regulator-grade auditability are paramount.\nIn a zkVM instantiation of PASS, the execution pipeline mirrors the enclave-\nbased design but replaces attestation with cryptographic proofs. The process\nproceeds in four stages:\n1. Batch formation. Transaction requests (claims, transfers, withdrawals) are\nfirst queued off-chain into a batch.\n2. zkVM execution. The zkVM program takes as private inputs: (i) the prior\nbatch’s commitments of the ledger L and provenance log H, (ii) the queued\ntransitions, including inbox I deposits and outbox O withdrawals, and (iii)\nthe proposed new commitments (L\n′\n,H\n′\n). Inside the zkVM, the transition\nfunction is replayed deterministically: starting from the previous roots, ap-\nplying all operations in sequence, updating balances and provenance entries,\nand checking consistency constraints.\n3. Proof generation. The zkVM outputs a succinct proof π certifying that the\nclaimed new roots (L\n′\n,H\n′\n) are correct with respect to the given transition\nset.\n4. On-chain verification. A minimalist verifier contract validates π, updates\nthe recorded commitments, and enforces any pending outbox operations.\nThis ensures that every external action has a verifiable provenance path\nwhile internal transfers remain private.\nCompared to TEEs, zkVMs strengthen the verifiability model by eliminat-\ning hardware trust assumptions, but incur higher computational and financial\ncosts due to proof generation and on-chain verification. Batching amortizes these\ncosts, raising open research questions about optimal batch sizes, data availabil-\nity strategies, and proof system selection. zkVM backends such as Risc0, SP1,\nor Plonky3 offer different tradeoffs in proof size, verification cost, and latency.\nHybrid deployments are also possible: TEEs can serve as fast-path executors for\nintra-day operations, with zkVM proofs generated periodically to provide cryp-\ntographic audit trails. This hybrid pattern resembles optimistic rollups, where\nfast execution is combined with verifiable settlement.\nFinally, this instantiation aligns closely with the Chainless stack architec-\nture [?], which emphasizes the separation of execution, trust, bridging, and set-\ntlement. In this view, zkVM proofs naturally inhabit the execution and trust\nlayers, Inbox/Outbox commitments integrate with bridging, and the verifier\ncontract finalizes settlement. This layered design opens the door to modular,\ninteroperable deployments of PASS across heterogeneous chains and domains.\nFull formal specification, performance benchmarking, and exploration of hybrid\nzkVM–TEE implementations remain important avenues for future work.\n26J. Yu\nFig. 6. PASS instantiation inside a zkVM: Inbox I and Outbox O transitions are\napplied to the Ledger L and Provenance H, producing new state commitments. The\nzkVM outputs a proof π, which the on-chain verifier checks before updating roots and\nenforcing outbox operations."
}
]
},
{
"role": "assistant",
"content": "To address the question—**why existing works cannot satisfy the three use cases in the Introduction, and why a provenance- and TEE-based solution (PASS) is superior**—we must examine both the requirements of the use cases and the limitations inherent in the prevailing wallet architectures, as articulated in the Introduction and Background sections.\n\n---\n\n## 1. Why Existing Works Cannot Satisfy the Three Use Cases\n\nThe three use cases from the Introduction are:\n\n1. **AI and Smart Agent Transactions**: AI agents managing assets require bounded authority and access guardrails.\n2. **Enterprise Payroll Privacy**: Organizations need to distribute salaries and budgets without revealing sensitive on-chain details.\n3. **Consumer-grade Central Limit Order Books (CLOBs)**: Real-time, high-throughput trading requires low gas costs and minimal user key management.\n\nLet us analyze how mainstream solutions fall short for each.\n\n### a. **EOAs (Externally Owned Accounts)**\n- **Control Model**: Single private key = total, unilateral control.\n- **Limitations**:\n - _AI & Smart Agents_: No way to delegate or restrict authority; giving an AI the private key grants it full, irrevocable power.\n - _Payroll Privacy_: All transfers are public, so salary disbursements are visible on-chain.\n - _CLOBs_: Every action is a public, gas-consuming transaction; no support for high-frequency, low-latency trades or batch operations.\n\n### b. **Multisignature Wallets**\n- **Control Model**: t-of-n co-signers must approve each action.\n- **Limitations**:\n - _AI & Smart Agents_: No fine-grained or scoped delegation—either a key is part of the quorum or not; cannot limit by asset, amount, or domain.\n - _Payroll Privacy_: All actions and policies are publicly visible; internal logic is on-chain and auditable by anyone, leaking salary and budget flows.\n - _CLOBs_: High on-chain overhead for every trade due to multi-party signatures; not suitable for fast, gasless, internalized operations.\n\n### c. **Smart Contract Wallets (e.g., ERC-4337, Account Abstraction)**\n- **Control Model**: On-chain policy logic, programmable rules.\n- **Limitations**:\n - _AI & Smart Agents_: Policies are programmable but public; any delegation or restriction is visible and can be front-run or censored.\n - _Payroll Privacy_: Every policy execution is public and incurs gas; internal flows cannot be hidden.\n - _CLOBs_: On-chain execution is required for every action, leading to prohibitive gas costs and latency for high-frequency trading.\n\n### d. **Custodians (RBAC/ABAC Engines)**\n- **Control Model**: Off-chain access policies, custom APIs.\n- **Limitations**:\n - _AI & Smart Agents_: Custom policy languages proliferate; off-chain enforcement is opaque, and the custodian sees all internal activity.\n - _Payroll Privacy_: Custodian observes all internal flows; privacy is lost at the custodian, even if not on-chain.\n - _CLOBs_: Custodians may support batching, but users must trust the custodian’s infrastructure and APIs, introducing centralization and privacy risks.\n\n### e. **TEE-based Wallets (e.g., Liquefaction)**\n- **Control Model**: TEE holds the key and enforces sub-policies.\n- **Limitations**:\n - _AI & Smart Agents_: Liquefaction can enforce sub-policies, but the model is more complex (key encumbrance trees), and depends on specialized smart contracts (e.g., Oasis), limiting compatibility.\n - _Payroll Privacy_: Internal logic is hidden, but deployment is limited to specific chains (Oasis), reducing flexibility.\n - _CLOBs_: Throughput is lower due to reliance on blockchain oracles for validation, leading to significant latency.\n\n#### **Summary Table (from the paper):**\n\n| Model | Internal Privacy | On-chain Overhead | Compatibility | Granularity of Control |\n|---------------|-----------------|-------------------|--------------------|-----------------------------|\n| EOA | None | None | Native EOA | None |\n| Multisig | None | High | Contract-based | Symmetric, coarse |\n| Smart Wallet | None | Med–High | ERC-4337 required | Programmable, public |\n| Custodian | At custodian | None | API-mediated | Off-chain, opaque |\n| Liquefaction | Strong (TEE) | Medium | Oasis only | Policy trees, TEE-enforced |\n| **PASS** | Strong (TEE) | None | Native EOA + TEE | Provenance, fine-grained |\n\n---\n\n## 2. Why Provenance- and TEE-based Control (PASS) Is Superior\n\nPASS’s core architectural innovations directly address the above shortcomings:\n\n### a. **Provenance-based Control**\n- **Assets are controlled based on their custody history (provenance), not identity or roles.**\n- **Inbox–Outbox Model**: All external deposits are tracked in an Inbox; subaccounts must claim assets, establishing a clear lineage.\n- **Internal Transfers**: Are private (off-chain), fee-less, and invisible to external observers. Only withdrawals (Outbox) are on-chain, preserving privacy and minimizing gas.\n\n### b. **TEE Enforcement**\n- **Private key is held exclusively in the TEE**; never accessible to users or operators.\n- **All policy logic and provenance checks are enforced within the hardware-isolated enclave**, guaranteeing that even privileged insiders cannot subvert controls or observe internal flows.\n- **Remote attestation** allows external parties to verify that the correct code is running inside the enclave.\n\n### c. **Alignment with Use Cases**\n- _AI & Smart Agents_: Can be given sub-accounts with limited provenance-based authority (e.g., capped balances, domain-specific permissions), preventing overreach or misuse. If compromised, the AI can only affect its own subaccount.\n- _Payroll Privacy_: Salaries and departmental budgets are distributed internally, off-chain, with only aggregate payouts visible on-chain. Internal transfers are invisible, so sensitive information is not leaked.\n- _CLOBs_: High-frequency, gasless internal trading is possible, with only net settlements (batch withdrawals) posted on-chain. Users do not have to manage keys; the enclave orchestrates all actions securely.\n\n### d. **Compatibility and Efficiency**\n- **Native EOA Compatibility**: No need for custom smart contracts, chain modifications, or special APIs. Works with existing wallet infrastructure.\n- **No On-chain Overhead**: All internal logic is off-chain; only withdrawals incur gas, and those can be batched.\n- **High Throughput**: Benchmarks show sub-millisecond internal operations, far outpacing TEE-based systems that require blockchain oracles.\n\n### e. **Formal Guarantees**\n- **Proven security properties** (privacy, accessibility, provenance integrity) are formalized and machine-checked, not just informally claimed.\n- **Auditability**: Provenance logs can be selectively revealed for compliance or audit, without disclosing full internal state.\n\n---\n\n## 3. Logical Synthesis\n\n**Existing solutions are fundamentally limited by their control models:**\n- _Identity and role-based controls_ are awkward and brittle in blockchain’s exogenous asset environment, where assets are not natively tied to wallet identities.\n- _Public policy logic_ (smart contracts, multisigs) leaks sensitive information and incurs high gas costs.\n- _Custodial and off-chain solutions_ reintroduce centralization and erode privacy at the operator level.\n- _TEE-based approaches_ without provenance logic (or with complex policy trees) lack compatibility, efficiency, or formal guarantees.\n\n**PASS, by enforcing control via asset provenance and isolating all sensitive logic within a TEE, directly matches the requirements of emerging use cases:**\n- _Fine-grained, auditable, and private delegation for AI and agents_\n- _Internal privacy and regulatory auditability for enterprise payroll_\n- _Scalable, gasless, and private operation for consumer-grade trading, without user key management overhead_\n\n**Therefore, provenance- and TEE-based control is not just incrementally better, but fundamentally more aligned with the needs of modern, multi-actor, privacy-sensitive blockchain applications.** The formalization, efficient implementation, and demonstrated compatibility of PASS further reinforce its superiority as a solution."
},
{
"role": "user",
"content": "This is too long and too much to fit into the introduction. I want to make it simpler:\n\n1. in three use cases they call for the support for \"offchain transfers\", which needs to be fast, low-cost (ideally free) and private. In contract, the onchain transactions are more like a \"side effect\" when some settlements are needed.\n2. the role-based model cannot efficiently solve this problem cuz they need to define the rules from scratch. Instead, the provenance-based solution can fit in, ...\n\nWrite with this train-of-thought. You can ask questions if anything is not clear or logically consistent to you."
},
{
"role": "assistant",
"content": "Your train of thought is clear and logically sound. Here is a concise, logically-structured explanation suitable for an introduction:\n\n---\n\nThe three use cases described—AI agent wallets, private enterprise payroll, and consumer-grade CLOBs—all require support for **fast, low-cost (ideally free), and private offchain transfers**. In these scenarios, most activity happens internally within the wallet, and onchain transactions serve only as external settlement events or \"side effects\" when necessary.\n\nTraditional role-based access models (RBAC/ABAC) are ill-suited to this requirement. They force organizations to define complex access rules from scratch, tailored to each scenario and actor, leading to policy sprawl and administrative overhead. Moreover, these models still rely on onchain enforcement or centralized custodians, which cannot provide the required privacy or cost-efficiency for internal flows.\n\nIn contrast, a **provenance-based approach** naturally fits the offchain transfer paradigm: permissions and asset usability are determined by the custody history of each asset, not by static roles. This enables efficient, private, and auditable internal transfers, with onchain actions limited to external settlement. By enforcing the provenance logic within a TEE, we guarantee both privacy for internal operations and verifiable integrity for external settlements, satisfying the demands of all three use cases without the complexity or leakage inherent in role-based models.\n\n---\n\nIf you want it even shorter or more focused, let me know your target length or further constraints."
},
{
"role": "user",
"content": "for the second point it should be able to re-use many existing contents. Make the changes so these paras can be embeded into the current version with minimal modifications"
}
]Response:
Certainly. Here is a revised, concise version that aligns with your structure and can be embedded with minimal modification:
---
All three use cases—AI agent wallets, private enterprise payroll, and consumer-grade CLOBs—demand support for **offchain transfers** that are fast, low-cost (ideally free), and private. In these settings, the majority of value movement occurs internally, while onchain transactions are relegated to a secondary role, serving only as settlement events or external side effects when necessary.
Traditional role-based models (such as RBAC and ABAC) are not well-suited for this requirement. They require defining complex policies from scratch for each new scenario, resulting in bespoke rule sets and increased administrative overhead. More fundamentally, these models do not address the core need for efficient, private offchain transfers, as they are designed for onchain enforcement or centralized custodianship, both of which expose internal flows or incur unnecessary costs.
In contrast, a provenance-based solution is naturally aligned with the offchain transfer paradigm. Instead of prescribing access via static roles, provenance-based control traces asset usability through its custody history, enabling internal movements that are both private and auditable. By enforcing these provenance rules within a TEE, we ensure that internal transfers remain efficient and confidential, while external settlements retain full verifiability. This design directly addresses the demands of emerging blockchain applications, without the complexity or leakage inherent in role-based systems.
---
This structure should integrate smoothly into your introduction section.
Model: gpt-4.1-2025-04-142025-09-15 12:50:03
Context:
[
{
"role": "system",
"content": "You are a research paper writer. You focus on:\n1. logical consistency\n2. whether the story is persuasive\nDon't try to be friendly on purpose, judge everything based on the logic and expressiveness."
},
{
"role": "user",
"content": [
{
"type": "text",
"text": "Use the contents of Introduction and Background, answer my question.\n\nMy target is to demonstrate that the existing works cannot satisfy the three use cases in Introduction, and also explain why provenance- and TEE-based solution is a better solution for this."
},
{
"type": "text",
"text": "main.pdf\nPASS: A Provenanced Access Subaccount\nSystem\nfor Blockchain Wallets\nJay Yu\n1,2\n1\nStanford University [email protected]\n2\nPantera Capital [email protected]\nAbstract. Blockchain wallets still follow a single-entity ownership model:\npossession of a private key grants unilateral control. This assumption is\nbrittle for emerging settings such as organizational custody, shared gov-\nernance, and AI agent wallets, where multiple actors must coordinate\nwithout exposing secrets or leaking internal activity.\nWe present PASS, a Provenanced Access Subaccount System\nthat replaces role or identity-based control with provenance-based con-\ntrol: assets can only be used by subaccounts that can trace custody back\nto a valid deposit. A simple Inbox–Outbox mechanism ensures all exter-\nnal actions have verifiable lineage, while internal transfers remain private\nand indistinguishable from ordinary EOAs.\nWe formalize PASS in Lean 4 and prove core invariants, including\nprivacy of internal transfers, asset accessibility, and provenance integrity.\nWe implement a prototype with enclave backends on AWS Nitro Enclaves\nand dstack Intel TDX, integrate with WalletConnect, and benchmark\nthroughput across wallet operations. These results show that provenance-\nbased wallets are both implementable and efficient. PASS bridges today’s\ngap between strict self-custody and flexible shared access, advancing the\ndesign space for practical, privacy-preserving custody.\n1 Introduction\nCryptocurrency wallets conventionally assume one key, one owner. In this single-\nentity ownership (SEAO) model, whoever holds the private key gains permanent\nand total control of the address, and casts publicly readable, gas-consuming\nblockchain transactions. However, this model struggles to adapt to emerging\nblockchain scenarios:\n1. AI and Smart Agent Transactions. AI agents increasingly manage crypto\nassets [?,?] and require bounded authority and access guardrails for users’\nasset security.\n2. Enterprise Payroll Privacy. Organizations need to distribute salaries and\ndepartmental budgets to employee accounts without revealing sensitive de-\ntails on-chain [?,?,?].\n2J. Yu\n3. Consumer-grade Central Limit Order Books. On-chain order books\nface high gas costs and latency that prevent real-time trading at scale [?,?],\nand many consumers prefer not to manage their own keys [?,?].\nIn practice, many organizations confronted with these challenges default to\ncustodians or policy engines that wrap access logic in Role-Based Access Con-\ntrol (RBAC) or Attribute-Based Access Control (ABAC) [?,?]. These systems\nintroduce a proliferation of bespoke policy languages and APIs to specify who\nmay sign or transfer under which conditions [?,?]. While workable as a stopgap,\nthey inherit identity and role assumptions from traditional IT settings that limit\ntheir flexibility and scalability in blockchain contexts.\nThe limitation stems from a mismatch of models. Traditional access-control\nframeworks such as RBAC and ABAC assume an endogenous setting: users\ncreate and manage their own files, objects, or services, and policies are attached\nto these identities or roles. Blockchains are fundamentally exogenous: assets are\ncreated outside the wallet by smart contracts and transferred permissionlessly\nin. In this setting, identity or role-based rules are awkward to express and brittle\nto enforce. What matters instead is provenance: who deposited an asset, and how\nit flowed within the wallet.\nWe propose PASS, a Provenanced Access Subaccount System that enforces\ncontrol directly by provenance. The core mechanism is simple: an Inbox records\nexternal deposits, an Outbox signs and broadcasts withdrawals, and all internal\nmovements remain private and fee-less. Every unit of value inside the wallet has\na verifiable lineage to an on-chain deposit, while externally a PASS wallet is\nindistinguishable from a standard EOA. Our contributions include:\n– A provenance-based access model aligned with blockchain’s exogenous asset\ncreation, enforced through an Inbox–Outbox design.\n– A formal model in Lean 4 proving privacy, accessibility, and provenance\nintegrity.\n– A prototype with multi-vendor enclave backends (AWS Nitro, Intel TDX via\ndstack), a web app frontend integrated with WalletConnect, together with\nthroughput benchmarks.\n– Application scenarios, including organizational custody, privacy-preserving\ntransfers, and safe delegation to AI agents.\nPASS thus bridges the gap between strict self-custody and flexible shared\naccess, combining strong privacy guarantees with practical deployability.\n2 Background and Related Work\nGrowing retail and institutional adoption of digital assets [?] has driven diverse\nwallet designs [?]. We summarize mainstream Ethereum Virtual Machine (EVM)\nwallet designs in Figure ??.\nEOAs and Multisigs. Externally Owned Accounts (EOAs) give unilateral,\npermanent control to whoever holds the private key [?]. Multisignature wallets\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets3\nModelControl basisOn-chain\noverhead\nInternal\nPrivacy\nCompatibility\nEOASingle private keyNoneNoneNative EOA\nMultisigt-of-n co-signersHigh; quorum per\naction\nNone; logic\npublic\nSmart\ncontract based\nERC-4337\nSmart\nAccounts\nOn-chain policy\nlogic\nMedium to high;\ncustom logic and\ngas\nNone; logic\npublic\nRequires\nERC-4337\nchain support\nCustodiansCustom RBAC or\nABAC languages\nNone; Off-chain\nenforcement\nCustodian sees\nall activity\nAPI mediated\nLiquefactionTEE key\nencumbrance;\npolicy trees\nMedium; Oasis\ncontracts and gas\nStrong; TEE\nhides\nsubpolicies\nRequires Oasis\ndeployment\nPASS\n(ours)\nProvenance via\nInbox-Outbox\nNone; EOA\ncompatible\nStrong;\ninternal\ntransfers\ninvisible\nNative EOA\nplus off the\nshelf TEEs\nFig. 1. Comparison of wallet architectures. PASS features provenance-based control,\noff-chain privacy, and native EOA compatibility.\n(eg., Safe) distribute trust via t-of-n approvals [?], common for treasuries and\nbridges [?,?,?]. Drawbacks include quorum overhead, symmetric authority, and\npublic logic with attackable frontends [?]. In contrast, PASS offers fine-grained,\nscoped permissioning without new contracts.\nSmart Contract Wallets and Account Abstraction. Wallets like Ar-\ngent and Loopring add programmability (social recovery, spend limits) via on-\nchain logic [?,?,?]. ERC-4337 enables custom validation through UserOperation\ncontracts [?], and EIP-7702 lets EOAs invoke this logic [?]. These increase flex-\nibility but expose policies publicly and incur gas costs, limiting use cases like\npayroll. PASS instead enforces policy privately in a TEE, minimizing on-chain\nfootprint.\nCustodial Policies. Custody providers (Fireblocks, Turnkey, Privy) use\nRBAC/ABAC engines with custom policy languages [?,?]. PASS replaces these\nwith provenance: authority follows asset origin and history, akin to a UTXO\nmodel. This reduces policy-surface complexity while remaining composable with\nconstraints like whitelists and blacklists.\nTEEs and Liquefaction. Trusted Execution Environments (TEEs) provide\nhardware-isolated contexts with remote attestation [?,?]. Liquefaction [?] keeps\nwallet keys in a TEE and enforces sub-policies via key encumbrance, ensuring\nprivacy. PASS advances this model by (i) proving invariants in Lean 4, (ii) sim-\nplifying enforcement to a provenance rule with Inbox/Outbox subaccounts, and\n(iii) working with a standard EOA without relying on Oasis smart contracts\n[?]. We further validate by implementing PASS on AWS Nitro Enclaves and In-\ntel TDX (via dStack), and showcase applications including AI wallets, payroll,\nsupply chains, and DAO voting.\nOther Models. Exchanges pool funds in omnibus addresses with off-chain\nledgers [?]; mixers like Tornado Cash hide deposit–withdrawal links [?]. PASS\n4J. Yu\nsimilarly hides internal transfers while retaining a provenance log for auditability;\noutsiders see only deposits and withdrawals.\n3 System Model and Design\nFig. 2. Overview of PASS. External deposits enter the Inbox and are claimed by sub-\naccounts. Internal transfers are private and off-chain. Egress occurs via the Outbox,\nwhich signs and broadcasts on-chain transactions. All on-chain activity has clear prove-\nnance; internal movements remain private.\n3.1 High level system model\nPASS is a multi-user wallet on a single EOA (sk, pk). The wallet maintains a\nfinite set of subaccounts U ={u\n1\n,...,u\nn\n} and a set of assets A (e.g., ERC-20).\nA subaccount u ∈ U has authority over an amount x of asset α ∈ A iff it can\nobtain a signature from the global sk via the enclave; sk resides only inside a TEE\nand is never directly accessible. We give the intuitive model here and formalize\nit in Section ??.\nInternally, PASS tracks balances with a map L : U ×A →Z\n≥0\n(accessed\nvia L[u][α]), an Inbox multiset I of unclaimed deposits (α,x,m), an Outbox\nFIFO queueO of pending on-chain actions (α,x, extDst,ν) together with a global\nnonce ν ∈N, and an append-only provenance logH. The core principles of PASS,\nas shown in Figure ?? are as follows:\n1. Access follows provenance. A unit of value is usable by u only if there\nexists a custody chain in H from an external deposit to u. Informally,\nAllow(u,α,x) means balance x is reachable for u via provenance in H. This\nimplies consistency : for every α, the total internal balance equals the on-\nchain balance at pk, i.e.,\nP\nu∈U\nL[u][α] = B\non\n(α). Incoming deposits (α,x,m)∈\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets5\nI are “wrapped” and must be explicitly claimed before use by the sender\naddress.\n2. Off-chain privacy. Internal transfers u→ v update only L and H; they do\nnot touch O or the on-chain balance B\non\n, so internal flow is invisible and\nfee-less.\n3. First-come, first-served. Outbox transactions are sequenced by a FIFO queue,\nwhich maintains and increments a global nonce ν and directly sends enclave-\nsigned transactions to a RPC node to prevent nonce conflicts and replay\nattacks.\n3\nOrganizational Ownership Model. PASS operates under an organiza-\ntional ownership model, where an entity such as a company, individual, or DAO\nmanages shared control over blockchain assets. We detail the threat model in\nSection ??.\nInbox-Outbox Gateway External senders transfer assets to pk, creating\nInbox entries (α,x,m) ∈ I. A user performs claim(u,α,x,m) to move value\nintoL[u][α], conceptually “wrapping” the deposit. To withdraw or interact with\na contract, a subaccount first performs an internal transfer to the Outbox,\nwhich enqueues (α,x, extDst,ν); the enclave then signs the concrete transaction\nwith sk and immediately broadcasts it, incrementing ν. The FIFO discipline and\nglobal nonce serialize actions and prevent races and double-spends. Because sub-\naccounts never receive pre-signed transactions, pre-signing misuse is mitigated.\nComposable policy scheme. Deposits are claims fromI; internal transfers\nrequire Allow(u,α,x) and update (L,H); withdrawals are internal transfers to\nO followed by submission. Additional constraints (eg., RBAC or ABAC checks,\nwhitelists and blacklists) can be incorporated as conjuncts to Allow without\nchanging the provenance-centric rule or its consistency and privacy effects.\n3.2 Formal Model\nWe formalize PASS as a transition system in Lean 4\n4\n, an interactive theorem\nprover with a rich dependent type system [?], suitable for policy verification (eg.,\nAWS Cedar [?]). In this section, we introduce the formal system we modeled in\nlean, and in Section ?? we will discuss security invariants modeled. An extended\ndiscussion of our formal verification system can be found in Appendix ??.\nState. A wallet state is S =\n\u0000\npk, sk,ν,I,O,L,H\n\u0001\nwhere (pk, sk,ν) are the\nEOA public key, private key (generated and held in the TEE), and global nonce;\nI and O are Inbox and Outbox; L is the internal balance map L[u][α] ∈Z\n≥0\n;\nandH is the provenance history. For privacy arguments we also use the external\nview W\npub\n= (pk,O,A), where O contains the Outbox queue and nonce and A\nrecords total on-chain balances by asset.\n3\nWe assume that the TEE is able to run a Helios light client, as is the case in dstack\nIntel TDX, discussed and implemented in Section ??\n4\nLean 4 model: https://github.com/pass-wallet/pass-lean4-proofs\n6J. Yu\nPASS Wallet Management Functionality F\nΣ\nPASS\nfor wallet W\nGlobal State:\npk : public address (EOA)\nsk : private key (in TEE)\nν: global nonce for on-chain transactions\nI (Inbox): set of unclaimed deposits (α : asset,x : amount,m : depositId)\nO (Outbox): FIFO queue (α,x, extDst,ν)\nL (Asset Ledger): internal map L[u][α]∈ Z\n≥0\n, where u is each user’s ID in the system\nH (Provenance History): a list of transaction records appended whenever ClaimInbox,\nInternalTransfer, or Withdraw is invoked\nCreatePassWallet (creator ):\nI← ∅, O← ∅, L←{}; ν← 0\n(pk, sk )← TEE\nKeyGen()\nReturn new W with S =\n\u0000\npk, sk,ν,I,O,L,H\n\u0001\nand reference to creator\nInboxDeposit (α,x,m) from external P :\nI ← I ∪ {(α,x,m)}\nReturn success\nClaimInbox (α,x, depositId) from u:\nIf no (α,x,m) with depositId in I, return ⊥\nRemove (α,x,m) from I\nL[u][α]←L[u][α] + x\nH←H| (op = claim,α,x, depositId,u)\nReturn success\nCheckAllow (u\nsend\n,α,x,H):\nIf H.GetProvenance(α, u\nsend\n)≥ x,\nreturn true; else return false\nInternalTransfer (α,x,u\nsend\n,u\nrecv\n):\nIf L[u\nsend\n][α] < x or ¬checkAllow(u\nsend\n,α,x,H), return ⊥\nL[u\nsend\n][α]←L[u\nsend\n][α]− x\nL[u\nrecv\n][α]←L[u\nrecv\n][α] + x\nH←H\n\f\n\f\n\u0000\nop = transfer,α,x,u\nsend\n,u\nrecv\n\u0001\nReturn success\nWithdraw (α,x,u\nsend\n, extDst):\nIf L[u\nsend\n][α] < x or ¬checkAllow(u\nsend\n,α,x,H), return ⊥\nL[u\nsend\n][α]←L[u\nsend\n][α]− x\nO ←O∪{(α,x, extDst,ν)}\nH←H | (op = withdraw,α,x,u\nsend\n, extDst)\nReturn success\nSignGSM (dom, msg,u):\nIf u lacks sign-right for (dom, msg), return ⊥\nσ ← (sk, msg)\nReturn σ\n(Outbox Processing) (periodic or on demand):\nIf O ̸= ∅, dequeue (α,x, extDst,ν)\nBuild tx τ : transfer x of α to extDst, nonce = ν\nσ ← (sk, τ ); broadcast (τ,σ)\nν←ν + 1\nReturn broadcasted + txHash\nFig. 3. Formal Model of PASS wallet functionality, including CreatePassWallet for\ninitializing a fresh instance. On creation, pk is set to a chosen EOA address eoa, the\nTEE generates a hidden private key sk , and global data structures are initialized.\nExternal deposits enter I (Inbox), while subaccount transfers update L (Ledger) off-\nchain. Withdrawals queue items in O (Outbox), and GSM operations are signed using\nsk .\nTransitions. Operations op∈ T update S with type-checked rules: InboxDe-\nposit adds an unclaimed (α,x,m) to I; ClaimInbox moves (α,x,m) from I to\nL[u][α] and appends to H; InternalTransfer moves value between subaccounts;\nWithdraw debits L[u][α], enqueues (α,x, extDst,ν) in O, and logs; SignGSM\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets7\nauthorizes domain-scoped signable messages. A representative rule is:\n\u0000\npk, sk,ν,I,O,L,H\n\u0001\ntransfer(α,x,u\ns\n,u\nr\n)\n−−−−−−−−−−−→\n\u0000\npk, sk,ν,I,O,L\n′\n,H\n′\n\u0001\nwith\nif L[u\ns\n][α] < x or ¬checkAllow(u\ns\n,α,x,H) then ⊥;\nL\n′\n[u\ns\n][α] =L[u\ns\n][α]− x, L\n′\n[u\nr\n][α] =L[u\nr\n][α] + x;\nH\n′\n=H\n\f\n\f\n\u0000\nop = transfer,α,x,u\ns\n,u\nr\n\u0001\n.\nHere checkAllow queries provenance inH and can be extended with auxiliary\nconstraints such as user whitelists or blacklists, without changing the core rule.\nFigure ?? provides a formal specification of the methods in a PASS wallet.\n3.3 Asset Model and General Signable Messages\nPASS provides an authorization scheme over a heterogenous set of assets A, in-\ncluding fungible tokens, such as ether and ERC-20 tokens, ERC-721 non-fungible\ntokens, and “general signable messages” across a variety of DApps for sign-in\nand identity verification. Each asset α ∈ A has a well-defined custody path in\nthe provenance log H, and a subaccount u ∈ U has usable balance x of α iff\nAllow(u,α,x) holds.\nToken assets. For token assets such as ether, ERC-20, and ERC-721, de-\nposits are captured as Inbox entries (α,x,m) ∈ I. Claims allocate balance into\nL[u][α], internal transfers update L and H privately, and withdrawals enqueue\n(α,x, extDst,ν) intoO for enclave signing and on-chain broadcast, ensuring con-\nsistency where:\n∀α∈A\ntokens\n:\nX\nu∈U\nL[u][α] = B\non\n(α, pk).\nIn particular, ERC-721 tokens are modeled as unitary balances (x ∈ {0, 1})\nwhose transfers preserve uniqueness under provenance.\nGeneral Signable Messages (GSMs). In addition to on-chain assets,\nwallets often sign arbitrary messages, such as for EIP-4361 [?] logins and off-\nchain DAO votes [?]. PASS models these as a special classA\nGSM\nof virtual assets.\nEach GSM asset is scoped to a domain dom, so holding α = (dom) represents\nauthority to sign messages from that domain. A signature operation:\nSignGSM(u, dom,m)7→ σ\nis permitted iff Allow(u, dom, 1) holds in H. At key generation, the wallet\ncreator is endowed with default signing authority over all domains, represented\nas an initial allocation of every α = (dom)∈A\nGSM\nto the root subaccount. These\ndomain assets can be internally transferred to delegate signing authority. Thus\nprovenance of GSMs begins at the owner and flows through transfers, providing\na well defined provenance path in H as with token assets.\n8J. Yu\nBy treating both tokens and GSMs as types of elements ofA, PASS provides\na unified provenance rule for subaccount authorization. A subaccount cannot\nspend an ERC-20 token, transfer an NFT, or sign a domain message unless it\npossesses the corresponding asset under L and H. This unified authorization\nscheme allows for fine-grained delegation, (eg., giving u rights over example.com\nwhile withholding ERC–20 funds) and consistent enforcement across on-chain\nand off-chain actions.\n4 Properties of PASS\n4.1 Threat Model\nPASS assumes an organizational ownership model, where a single entity, such\nas a company, individual, or DAO manages the EOA (pk,sk), brokers access\nbetween many users in that entity, and chooses the TEE infrastructure vendor\n(eg. AWS Nitro, dstack Intel TDX, self-hosted hardware). This model is typical\nfor use cases such as private payroll, supply chains, and AI delegation described\nin Section ??. Protected assets in PASS include the private key sk, the balance\nledger L and provenance log H, and the correctness of Allow(u,α,x) for all\nu∈ U,α∈A,x. In our model, we make the following trust assumptions:\n1. TEE integrity. Hardware isolation is sound; sk never leaves the enclave.\nRemote attestation guarantees that the enclave runs the genuine PASS bi-\nnary.\n2. Cryptography. Standard primitives (signatures, hash functions, PRFs) are\nsecure against polynomial-time adversaries.\n3. Governance majority. The deploying entity holds majority control in the\ngovernance mechanism (via DAO vote or admin privileges), ensuring it can\ninvoke the blockchain-governed KMS for MPC-based key recovery and trig-\nger fallback contracts when needed.\nAdversary Model. An adversary A may control the host OS and network,\nobserve or modify all communication with enclaves, and submit arbitrary trans-\naction requests. In particular, A may attempt to:\n– Exploit software bugs in the PASS implementation or TEE runtime,\n– Forge or replay transactions to break consistency of H,\n– Subvert provenance by violating Allow(u,α,x)\nThreats Out of Scope. On the other hand, PASS does not protect against:\n– Physical compromise of TEE hardware (tampering, microarchitectural side-\nchannels, chip decapsulation),\n– Supply-chain backdoors in TEE manufacturing,\n– Fully malicious operators with unrestricted physical access.\nThese are excluded because the organizational model assumes controlled facilities\nand vetted hardware.\nSecurity Goals. Given the assumptions above, PASS guarantees:\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets9\n1. Integrity:\nP\nu∈U\nL[u][α]≤ extDep(α) for all α, i.e., no assets can be created\nor double-spent internally.\n2. Correctness: If Allow(u,α,x) holds, then u can eventually realize x via\nWithdraw.\n3. Privacy on-chain: InternalTransfer operations do not affect externalTrace(W ),\nand to external observers, a PASS wallet is indistinguishable from an EOA.\n4. Liveness: For any authorized op ∈ Ops, if one enclave and quorum remain\nhonest, then ∃τ s.t. Exec(c, op) =⊤ within τ\n4.2 Privacy and Safety\nAfter establishing the threat model of PASS, we will address the central privacy\nand safety guarantees in our formal verification model. We sketch three central\nlemmas here, and create mechanized proofs in Lean, discussed in Appendix ??.\nProposition 1 (Internal Transfer Privacy). If two public states W\n1\n,W\n2\nshare the same pk, identical Outbox (T,ν), and equal per-asset totals in A, then\nexternalTrace(W\n1\n) = externalTrace(W\n2\n).\nProof Sketch. InternalTransfer updates only (L,H), never O or total on-chain\nbalances. OutboxProcessing in Figure ?? emits on-chain actions solely from O\n(lines 2–4), hence the trace depends only on O.\nCorollary: EOA indistinguishability. If W\npass\nand W\neoa\nshare the same pk,\nOutbox, and per-asset totals, then\nexternalTrace(W\npass\n) = externalTrace(W\neoa\n).\nThus, from an external observer’s perspective, a PASS account is indistinguish-\nable from a standard EOA: internal transfers leave no observable footprint.\nProposition 2 (Asset Accessibility). For any asset α, letting L = {u |\nL[u][α] > 0},\nX\nu∈L\nL[u][α] = totalBalance(α),\nand each u∈ L can spend its full balance subject to checkAllow.\nProof Sketch. ClaimInbox creditsL; InternalTransfer preserves the sum over u;\nWithdraw debitsL and enqueues toO, which OutboxProcessing realizes on-chain.\ncheckAllow enforces reachability from provenance in H.\nProposition 3 (Provenance Integrity). Let extDep(α) be net external de-\nposits (deposits minus realized withdrawals). For all reachable states,\nX\nu\nL[u][α] ≤ extDep(α).\n10J. Yu\nProof Sketch. Induct on transitions. InboxDeposit increases extDep only; Claim-\nInbox moves already-deposited value into L; InternalTransfer conserves the sum\nover u; Withdraw decreases the sum, and after OutboxProcessing broadcasts,\nextDep is reduced accordingly.\nGeneral signable messages (GSM). Model GSM rights as a domain-\nscoped virtual asset class A\nGSM\n. Let α = (dom)∈A\nGSM\nand permit\nSignGSM(u, dom,m) iff Allow(u,α, 1).\nThen (P2)–(P3) lift to GSM: there is always at least one domain signer, and\nGSM “balances” obey provenance conservation under transfers in H.\n4.3 Liveness\nWe define liveness as the property that any authorized operation remains even-\ntually executable, despite enclave crashes, vendor compromise, or partial gover-\nnance failure. Our model assumes deployment of PASS access logic on dstack,\nimplemented in Section ?? and detailed in Appendix ??.\nLet E denote active enclaves, C containerized wallet backends, and P gover-\nnance policies. Each container c∈C stores sealed state\nσ\nc\n=⟨S,k\nc\n, meta⟩ with S = (pk, sk,ν,I,O,L,H),\nwhere k\nc\n= Derive(K,c) is derived from an MPC-managed KMS and meta records\nattestation. An operation op ∈ Ops (deposit claim, transfer, withdrawal) ex-\necutes as: Exec(c, op) = ⊤ iff Attested(c)∧ Γ (S), where Attested(c) checks σ\nc\nagainst registry R and Γ is the quorum predicate over P. To ensure vendor-\nagnostic portability, state migration μ :E →E satisfies\n∀e\ni\n,e\nj\n∈E, e\nj\n.decrypt(σ\nc,e\ni\n,k\nc\n) = σ\nc,e\ni\n,\nTheorem 1 (Liveness Theorem). If (i) the MPC KMS tolerates f\nKMS\nfaults\nin a t-of-n threshold, (ii) governance quorums are f\ngov\n-resilient, and (iii) at least\none enclave is uncompromised, then every op∈ Ops executes within bounded time\nτ :\n∀op∈ Ops, ∃τ ≥ 0 : Exec(c, op) =⊤.\nProof Sketch. Progress follows from three guarantees: (1) the MPC KMS\nensures k\nc\nis always recoverable under threshold availability; (2) Γ encodes quo-\nrum rules that eventually relax after timeout ∆t, ensuring some subset S satisfies\nΓ (S) = ⊤; (3) migration μ allows any enclave to re-host σ\nc\n, preventing vendor\nlock-in or enclave failure from blocking execution. Algorithm ?? formalizes re-\ncovery and execution under these assumptions.\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets11\nAlgorithm 1 RecoverAndExecute(c, op)\n1: Verify enclave e attestation Q\ne\nagainst R.\n2: Derive k\nc\n← Derive(K,c); decrypt σ\nc\n.\n3: if CompromiseDetected(e\n′\n) then\n4:Rotate k\nc\nand re-encrypt σ\nc\n.\n5: end if\n6: Ensure Γ (S) =⊤ for S ⊆P(c).\n7: Execute op; append to H.\nKey Properties. (1) Portability: any attested enclave can recover σ\nc\n, in-\ndependent of vendor; (2) Monotonic Recovery: recovery steps form ρ : S → S\nwith ρ(s)⪰ s; (3) Domain Continuity: certificates remain bound to R(c) under\nmigration μ(c), preventing hijack or replay.\nImplementation details of container orchestration, attestation, and KMS pro-\ntocols are given in Appendix ??.\n5 Practical Implementations\n5.1 Prototype Implementations\nTo demonstrate feasibility, we have implemented a prototype of PASS that cap-\ntures the core architectural components.\n5\nThe prototype consists of:\n– Provenanced Access Model, the core PASS architecture outlined in Sec-\ntion ?? with the Inbox-Outbox structure, asset ledgers, and provenanced\nrule as a Rust executable.\n– Web Application Frontend, an AWS-hosted Typescript interface that\nallows users to deposit assets, initiate internal transfers, generate on-chain\ntransactions, and sign arbitrary messages on Ethereum Sepolia testnet.\n6\n– Multi-vendor TEE deployment, we deploy the PASS enclave executable\nin both AWS Nitro Enclaves and Intel TDX with the dstack framework.\nWe evaluate these two enclave deployments as complementary deployment\npaths, each with distinct tradeoffs.\nAWS Nitro Enclaves. In this design, PASS runs inside a Nitro enclave in the\nAWS cloud. The enclave executes the Inbox–Outbox logic, enforces provenance\nchecks, and signs transactions, while the provenance ledger is stored externally.\nNitro’s attestation and AWS integration simplify deployment, but reliance on a\nsingle vendor limits portability and concentrates trust. As a result, some guaran-\ntees of PASS, particularly liveness and asset accessibility, may be weaker under\nthis model.\n5\nPrototype can be found here: https://github.com/jayyu23/pass-wallet-app\n6\nWeb application: https://pass-wallet.jayyu.xyz/\n12J. Yu\nIntel TDX with dstack. dstack provides a portable, open-source runtime for\nTEEs across diverse hardware. PASS can be deployed on enclaves run by decen-\ntralized operators, with key material secured via MPC-based key management.\nBoth Inbox–Outbox logic and the provenance ledger execute inside dstack, pre-\nserving the full security properties of Section ?? and reducing vendor lock-in.\nThe tradeoff is added governance complexity over operator authorization and\npolicy enforcement.\nBlockchain Connectivity. To ensure reliable blockchain interaction, PASS inte-\ngrates Helios [?], a consensus-verified light client, within the TEE. Rather than\ntrusting external RPC endpoints, Helios cryptographically verifies all blockchain\ndata against consensus layer proofs before serving it locally. This approach elimi-\nnates the trust assumptions typically associated with centralized RPC providers\nwhile maintaining the performance characteristics necessary for real-time wallet\noperations. The light client architecture ensures that PASS’s Outbox mecha-\nnism operates on verified blockchain state, preserving the security guarantees\neven when external network providers are compromised or unreliable.\n5.2 Performance Benchmarks\nTo evaluate PASS, we benchmarked both AWS Nitro Enclaves and Intel TDX\nbackends across common operations: balance queries, transfers, withdrawals,\nclaims, wallet creation, provenance queries, and an end-to-end workflow. Each\noperation was run 100 times over 10 trials per environment, measuring through-\nput in ops/sec. Both environments used identical 4-core, 2.5 GHz, 16 GB VMs\nto ensure fair comparison. Table ?? summarizes our results, with full details\navailable in Appendix ??.\nFig. 4. Internal PASS operation throughput (ops/sec) across AWS Nitro Enclaves\nand Intel TDX. All operations are in-memory state changes within the TEE with no\nblockchain interaction. Each value represents the average of 100 operations repeated\n10 times per environment.\nOperationAWS Nitro Intel TDX\nWallet Creation6,53114,970\nAccount Balance Queries530,943935,428\nInbox-to-Subaccount Claims14,85633,064\nInternal Subaccount Transfers32,95371,292\nWithdrawal Request Creation18,29139,702\nEnd-to-End Workflow\n7\n35,66378,433\nTransaction History Queries3,7577,685\nMulti-threaded Operations (5 threads)32,18955,124\nLarge Dataset Processing481724\nThe observed performance differences between AWS Nitro Enclaves and In-\ntel TDX primarily stem from their distinct hardware architectures. AWS Nitro\nEnclaves employ a disaggregated system design, where the host server and the\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets13\nTEE hardware are physically separated. Communication between the host and\nthe enclave occurs via vsock, and the enclave itself runs on a dedicated, lower-\nperformance coprocessor. In contrast, Intel TDX leverages a special instruction\nset to provide enclave functionality directly on the main processor, eliminating\nthe need for a separate coprocessor and avoiding the overhead of data transfer\nbetween disparate components. As a result, Intel TDX is able to deliver sig-\nnificantly higher throughput for in-enclave operations compared to AWS Nitro\nEnclaves, as reflected in our benchmark results.\nThese preliminary benchmarks show that both Nitro and TDX backends can\nsustain high throughput for critical wallet operations, confirming that PASS is\npractical for real-world deployment.\nComparison with Related Work. To contextualize our performance results, we\ncompare PASS with other TEE-based blockchain systems and traditional custo-\ndial solutions.\nLiquefaction. The Liquefaction system [?] demonstrates significantly higher\nlatencies than PASS due to its reliance on blockchain oracles for transaction\nvalidation. Liquefaction exhibits mean latencies of 49 seconds for latest block\nconfirmation, 648.7 seconds ( 11 minutes) for justified confirmation, and 1,036.9\nseconds ( 17 minutes) for finalized confirmation. These delays stem from Liq-\nuefaction’s architectural requirement to wait for block confirmations on an ex-\nternal TEE-blockchain oracle before authorizing subsequent operations. In con-\ntrast, PASS performs all operations within the off-chain TEE worker without\nblockchain dependencies, achieving sub-millisecond latencies for internal opera-\ntions (e.g., 14,856-33,064 ops/sec for claims, 32,953-71,292 ops/sec for transfers).\nThis fundamental architectural difference—off-chain TEE computation versus\nblockchain-dependent validation—enables PASS to provide near-instantaneous\nuser experiences while maintaining strong security guarantees.\nTraditional Custodians. While custodial solutions do not publish detailed\nperformance benchmarks, prior work demonstrates that TEE overhead typically\nintroduces only 5-7% performance degradation compared to native execution [?].\nGiven that modern custodial systems can process thousands of operations per\nsecond, TEE-based solutions like PASS should achieve comparable throughput\nwhile providing significantly stronger security properties. Our benchmark results\nsupport this expectation, with PASS demonstrating high-throughput operation\nprocessing that would be suitable for production custodial workloads, while offer-\ning the additional benefits of cryptographic auditability, decentralized operation,\nand reduced single points of failure.\nFurther evaluation of latency distributions, concurrency scaling, and memory\nfootprint is left for future work.\n6 Applications\nPASS is a powerful primitive that enables several classes of applications across\nidentity scoping, enterprise settings, and scalability concerns.\n14J. Yu\nCategoryApplicationContextPASS Enables\nIdentities\nAI Agent\nWallets\nAutonomous agents\ninteracting with crypto\nassets [?] need signing\naccess guardrails.\nScoped subaccounts grant limited\nbalances and domain signing rights,\nenabling safe delegation without\nexposing the root key\nDAO Voting\nDelegation\nDAOs depend on\naddress-based voting and\nproxy delegation [?].\nFine-grained voting rights delegation\nthat remains auditable via provenance;\ndelegation can be restricted to specific\nDApps or domains.\nSubdomain\nProfile Pages\nOrganizations delegate\ncontrol over web or\norganizational\nsubdomains (e.g.,\nmyprofile.company.com) to\nindividuals or teams.\nEach subaccount holds scoped signing\nrights for its assigned subdomain, with\nbalances and authorities tracked in\nprovenance under a shared\norganizational identity.\nEnterprise\nPrivate PayrollOn-chain payrolls reveal\nsensitive salary\ninformation [?].\nSalary distribution through internal\ngasless transfers with audit logs;\nexternal payouts are periodically\nbatched via the Outbox.\nCompliant Org\nWallets\nFirms must maintain\ninternal accountability\nand BSA\nrecordkeeping [?].\nDepartmental and individual\nsubaccounts with explicit budgets;\nprovenance ensures regulator-grade\nauditability without exposing internal\nflows.\nPrivate B2B\nNetting\nSupply-chain and\nrecurring multi-party\npayments require\nconfidentiality.\nVendor subaccounts allow internal\nnetting of obligations, with PASS\nacting as a temporary clearing house.\nOnly net settlements exit via the\nOutbox, reducing leakage while\nretaining auditability.\nAudit / Proof\nExplorer\nRegulators and auditors\nrequire verifiable yet\nprivacy-preserving\ntransparency.\nPublic proofs derived from the\nprovenance log H, enabling compliance\nchecks and audits without disclosing\ninternal ledger state.\nScalability\nGasless\nAppchain\nHigh-throughput\napplications (e.g., trading\nengines) face prohibitive\ngas costs on-chain.\nInternalize application logic as\nsubaccount transitions; Outbox emits\nverifiable batch settlements, ensuring\ncorrectness with minimal gas.\nCross-chain\nBridges\nBridges require strong\ncustody and coordination\nof operators [?].\nInbox-Outbox abstractions enforce\nprovenance across domains; FIFO\nnonce handling prevents replay or race\nconditions.\nL2 ComposabilityRollups and L2s fragment\nassets and user\nexperience [?].\nTreat each L2 as a scoped subaccount;\nmaintain private balance transfers\ninternally, and settle externally only\nwhen crossing domains.\nFig. 5. Applications of PASS across identities, enterprise settings, and scalability so-\nlutions. We highlight a flagship application in each category.\nIdentities and Agent Delegation. PASS’s multi-user subaccount model\nallows for flexible permission scopes. As AI agents start managing crypto as-\nsets, there is a need to constrain their access. An AI agent could be given a\nsub-account that only holds limited funds or certain asset types. The AI can op-\nerate freely within those bounds, but cannot exceed its allotted assets or misuse\nother wallet assets. If compromised, damage is capped to its sub-account. This\nis much safer than giving AI the keys to an entire wallet. Similarly, PASS can\nallow for delegation-based DAO voting by giving the delegate signature rights\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets15\nover particular voting DApps, without giving access to actually transfer the as-\nsets. Subaccounts can also get scoped signing rights over particular enterprise\nsubdomains.\nEnterprise Applications. PASS’s features of internal privacy, in-built per-\nmissioning, and provenance auditability make it uniquely suited for enterprise\napplciations. A flagship use case for PASS is private payroll. On-chain salary pay-\nments today risk exposing sensitive information such as individual compensation,\ndepartmental budgets, or timing patterns. With PASS, salaries are distributed\ninternally through gasless subaccount transfers, leaving a clear provenance log for\nauditability, but without revealing per-employee details on-chain. Only periodic,\non-demand payouts exit via the Outbox, ensuring both regulatory accountability\nand privacy for internal flows. Beyond payroll, PASS supports other enterprise\nneeds: compliant organizational wallets with departmental subaccounts that en-\nforce explicit budgets, private B2B netting where vendors settle obligations inter-\nnally and only net payments leave the wallet, and auditable proof explorers that\nprovide regulators with verifiable, privacy-preserving compliance proofs derived\nfrom the provenance log.\nScalability Solutions. PASS also supports scaling use cases where on-chain\ncosts or coordination overhead make existing approaches impractical. A flagship\nexample is gasless appchains, such as for Central Limit Orderbooks (CLOBs).\nHigh-throughput applications such as CLOBs cannot afford per-transaction gas\nfees, but PASS internalizes application logic as private subaccount transitions.\nThe Outbox then emits verifiable batch settlements with minimal gas, preserv-\ning correctness while keeping costs predictable. Beyond appchains, PASS enables\ncross-chain bridges by enforcing provenance across domains and sequencing with-\ndrawals via a FIFO nonce to prevent replay or race conditions, and supports L2\ncomposability by treating each rollup or sidechain as a scoped subaccount, main-\ntaining private balance transfers internally and settling externally only when\ncrossing domains.\n7 Discussion and Future Work\n7.1 Composability and InterPASS Transactions\nWhile PASS provides privacy and provenance guarantees for a single wallet in-\nstance, an important question is how multiple PASS wallets may interact. This\nis important in supply-chain use cases where each PASS represents a single com-\npany in the supply chain.\nTrivially, PASS A can send an on-chain transaction from its Outbox to PASS\nB’s EOA account, and this will land in the Inbox of PASS B, ready to claim.\nHowever, this undermines the privacy guarantees that PASS offers at the EOA\nlevel, and is undesirable in cases where inter-organizational asset transfers con-\ntain sensitive information, such as order details.\nWe propose a non-trivial approach inspired by cross-Payment Channel Net-\nwork (PCN) protocols such as XTransfer [?]. We can treat each PASS instance\n16J. Yu\nakin to a PCN hub node, with state L and transaction history H. As with\nXTransfer, we can assume a star topology of PASS nodes, with a central PASS\nHub in communciation with all PASS nodes. The PASS Hub will aggregate all\nInterPASS transactions T := {(a\ni\n,x\ni\n,s\ni\n,r\ni\n)}\nn\ni=1\n, where (a\ni\n,x\ni\n,s\ni\n,r\ni\n) represent\nthe asset, amount, sender, and receiver, each signed by the s\ni\nOutbox.\nThe Hub aggregates these signed payment intents, computes a netted settle-\nment plan S, and coordinates a secure multi-party update protocol to commit\nthe resulting balances, similar to Thora [?]. In the optimistic case, this process\ncompletes entirely off-chain, and each participant’s balance is updated in the\nPASS ledger without revealing the underlying transaction graph. If a dispute or\nfailure occurs, any participant may trigger an on-chain enforcement transaction\nthat finalizes S atomically via the direct transfer mechanism, thus guaranteeing\nsafety.\nThis approach leverages PASS ’s provenance and state design to make each\ninstance an atomic node in PCN-style systems like X-Transfer. Here, we outline\nhow PASS Hubs can enable confidential, auditable cross-organization transfers,\nwhile full formal specification and protocol implementation is deferred for future\nwork.\n7.2 Instantiation on zkVM\nThe PASS design presented in this paper relies primarily on trusted execution\nenvironments (TEEs) to enforce provenance rules, where the enclave isolates the\nglobal secret key and mediates all access through the Inbox–Outbox mechanism.\nWhile TEEs provide strong privacy and efficiency guarantees, their trust model\ndepends on hardware attestation and vendor integrity, which may be insufficient\nin regulatory or adversarial settings that demand independent verification.\nzkVMs provide a natural next step by enabling provenance-based control to\nbe verified through succinct cryptographic proofs rather than trusted hardware.\nBy batching transitions over L, H, I, and O and producing a proof π, a mini-\nmalist verifier contract can update commitments and enforce outbox execution\nwhile preserving privacy. This direction complements the Chainless stack ar-\nchitecture [?], suggesting a path toward modular, interoperable deployments of\nPASS with stronger external verifiability and broader applicability.\n8 Conclusion\nWe presented PASS, a Provenanced Access Subaccount System, as a new wallet\narchitecture that enforces access by provenance rather than by identity or role.\nThe Inbox–Outbox mechanism ensures all assets have a verifiable lineage, while\ninternal transfers remain private and indistinguishable from a standard EOA\naccount.\nOur contributions are threefold: (i) a formal model in Lean 4 proving pri-\nvacy, accessibility, and provenance integrity; (ii) a working prototype with en-\nclave backends on AWS Nitro Enclaves and Intel TDX via dstack, integrated\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets17\nwith WalletConnect; and (iii) initial benchmarks showing the feasibility of high-\nthroughput operation. These results demonstrate that provenance-based control\ncan be realized today with mainstream blockchain tools.\nLooking forward, richer evaluations across multi-vendor TEEs, integration\nwith zero-knowledge VMs, and exploration of organizational and agent-based\ncustody are promising directions. By combining rigorous formal guarantees with\ndeployable prototypes, PASS advances the design space between strict self-\ncustody and flexible shared access, offering a path toward practical, privacy-\npreserving wallet security.\nA Formal Verification\nWe consider the formal model introduced in Section ?? of PASS as a state\nmachine in Lean4. Our goal is to prove that, under the PASS design, several\ncritical security properties always hold. We outline these properties and our\napproach to verifying them.\nA.1 Property: Privacy of Internal Transfers\nIn the PASS design, the InternalTransfer operation updates only the off-chain\nledgerL and the provenance historyH. It never modifies the OutboxO, meaning\nthere is no on-chain transaction triggered by an internal transfer. Consequently,\nexternal observers see no change in on-chain state. We formalize this by consid-\nering the on-chain view that an external party has for a given PASS Wallet. We\ncan model this visible on-chain state as a triple:\nW\npub\n=\n\u0000\npk, O, A\n\u0001\n,\nwhere:\npk is the externally owned account (EOA) address,\nO = (T,ν) is the external view of the outbox, where T is a list of enqueued\ntransactions and ν is a nonce,\nA is the external view of the Asset ledgerL, containing a list of asset entries,\neach of the form (α,x) with a unique identifier α and total balance x.\nExternal Trace. The external trace of a PassAccount state W\npub\nis the list of\nexternally visible actions, obtained by mapping each transaction in the outbox\nT to an on-chain action:\nexternalTrace(W\npub\n) =\n\b\noutboxTx(t) | t∈ T\n\t\n.\nNo internal transfers appear in externalTrace(·).\n18J. Yu\nStates That Differ Only by Internal Transfers. We say that two PassAccount\nstates W\n1\n= (pk\n1\n,O\n1\n,A\n1\n) and W\n2\n= (pk\n2\n,O\n2\n,A\n2\n) differ only by internal trans-\nfers if:\n1. pk\n1\n= pk\n2\n,\n2. O\n1\n= O\n2\n(i.e. both the list of outbox transactions and the nonce are the\nsame),\n3. For every asset identifier α, the total balance of that asset in A\n1\nequals the\ntotal balance of the same asset in A\n2\n.\nLetting getAsset(W,α) return the asset α within state W or ⊥, we require ∀α:\ntotalBalance\n\u0000\ngetAsset(W\n1\n,α)\n\u0001\n= totalBalance\n\u0000\ngetAsset(W\n2\n,α)\n\u0001\n.\nTheorem 2 (Privacy of Internal Transfers). If two PassAccount states W\n1\nand W\n2\ndiffer only by internal transfers, then their externally visible traces are\nidentical:\nexternalTrace(W\n1\n) = externalTrace(W\n2\n).\nProof. By assumption, O\n1\n= O\n2\n. Hence both states have the same outbox trans-\naction list T . Since\nexternalTrace(W\ni\n) = map\n\u0000\noutboxTx, T\ni\n\u0001\nfor i∈{1, 2},\nand T\n1\n= T\n2\n, it follows that externalTrace(W\n1\n) and externalTrace(W\n2\n) are iden-\ntical.\nThus, any sequence of purely internal transfers, changing only the private ledger\nL in PASS, is invisible to an external observer, preserving the privacy of how\nassets move within the wallet.\nA corollary of this Internal Transfer property is that a PASS account is\nindistinguishable from a regular EOA account.\nCorollary 1 (Indistinguishability from EOA). Let W\npass\nbe a PASS state\nthat (i) has the same public key pk, (ii) the same outbox, including nonce and\ntransaction list, and (iii) the same total balances of each asset as a reference\nEOA state W\neoa\n. Then\nexternalTrace(W\npass\n) = externalTrace(W\neoa\n).\nIn particular, an external observer cannot distinguish W\npass\nfrom W\neoa\n.\nProof. By assumption, the only potential differences betweenW\npass\nandW\neoa\nlie\nin internal ledger details. From Theorem 1, such internal transfers do not affect\nthe externally visible outbox transactions or total on-chain balances. Thus, their\nexternal traces coincide, and W\npass\nis indistinguishable from W\neoa\n.\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets19\nA.2 Property: Asset Accessibility\nIn addition to keeping internal transactions private, PASS should ensure that for\nevery asset in the system, there exists some sub-account that can access it and\nwithdraw it from the system. This prevents a situation where funds get ”stuck”\nwithout any reachable key or policy to move them. We define asset accessibility\nas follows:\nTheorem 3 (Asset Accessibility). For any PASS account W and asset iden-\ntified by α, there exists a list of addresses L such that:\n1. For every address u∈ L, the user can access their full balance:\ncheckBalance(s,α,u, balance(u)) = true\n2. The sum of all accessible balances equals the total balance of the asset:\nX\nu∈L\nL[u][α] = totalBalance(α)\nProof. We construct L as the set of all addresses with non-zero balances in the\nbalance map for α:\nL ={u|L[u][α] > 0}\nFor the first property, given any u∈ L, the definition of checkBalance verifies\nif the user has sufficient balance for the specified amount. When checking against\nthe user’s own balance, this is trivially satisfied since L[u][α]≥L[u][α] for all u.\nFor the second property, we observe that totalBalance is defined as the sum\nof all balances in the asset’s balance map:\ntotalBalance(α) =\nX\nu∈L\nL[u][α]\nBy construction, L contains the only nonzero values u∈L, so:\nX\nu∈L\nL[u][α] = totalBalance(α)\nTherefore, both properties hold for our constructed list L.\nWe can prove a similar trait for General Signable Messages, showing that for\nany inbound GSM, there is some subaccount signer that has access to it.\nTheorem 4 (GSM Accessibility). For any GSM and domain, there exists a\nuser with signing access to that domain.\nProof. For any domain d, we can directly construct a user u who has signing\naccess to d as follows:\nu = getSigner(d)\nBy definition, getSigner returns either:\n– A specifically assigned signer if one exists in the domain-address map, or\n– The default signer otherwise\nTherefore, every domain is guaranteed to have at least one user with signing\naccess, ensuring no GSM domain becomes inaccessible.\n20J. Yu\nA.3 Property: Provenance Integrity\nProvenance integrity specifies that every asset held by any sub-account in PASS\nmust have an origin traceable to an external deposit into the Inbox. At any\nstate of the system, for each asset entry in a sub-account’s balance, we can find\na sequence of internal transfers that leads back to an Inbox deposit from an\nexternal address. This property ensures no sub-account can conjure funds from\nnothing, such as through double-spending or inflation within the system, and\nthat the internal ledger is consistent with on-chain reality. In Lean, we model\nthe state of the PASS wallet including Inbox, Outbox, and all sub-accounts and\nprove an invariant that whenever a sub-account has x units of asset α, the global\nstate contains a record of at least x units of α having been deposited, minus any\nthat have been withdrawn.\nTheorem 5 (Provenance Integrity).\nFor any PASS account S =\n\u0000\npk, sk,ν,I,O,L,H\n\u0001\nand any asset α, the total\namount of α held across all subaccounts can never exceed the total amount of\nexternal deposits (minus any that have already been withdrawn). Formally,\nX\nu∈U\nL[u][α] ≤ externalDeposits(α),\nwhere U is the set of subaccounts in the system, and externalDeposits(α) is\nthe net total of asset α that has been introduced into the wallet from outside\naddresses, recorded in the inbox I.\nProof. We model the system’s state (pk, sk,ν,I,O,L,H) as in Figure ??, includ-\ning the Inbox I, Outbox O, and the internal ledger L. We define a provenance\nrecord P (α,u) that captures the total amount of asset α subaccount u is autho-\nrized to hold, based on Inbox claims and internal transfers.\nBase Case: Immediately after CreatePassWallet, no assets have been de-\nposited, and no subaccount balances exist:\n∀u, L[u][α] = 0, ∀α, externalDeposits(α) = 0.\nHence,\nX\nu∈U\nL[u][α] = 0 ≤ 0 = externalDeposits(α).\nInductive Step: Assume the invariant holds after n− 1 operations. We prove it\nremains valid after the nth operation, for each possible type of operation:\n(1) External Deposit: Suppose an amount x of asset α is deposited into the\nwallet:\nexternalDeposits(α) ← externalDeposits(α) + x.\nNo subaccount balances L[u][α] change. Thus, the left side of our inequality\n(sum of subaccount balances) is unchanged, while the right side strictly\nincreases by x, so the invariant continues to hold.\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets21\n(2) Inbox Claim: If subaccount u claims amount x of asset α from the Inbox\nI:\nL[u][α] ← L[u][α] + x, P (α,u) ← P (α,u) + x.\nSince x was already accounted for in externalDeposits(α) (but not yet allo-\ncated to any subaccount), the total subaccount balances remain≤ externalDeposits(α).\n(3) Internal Transfer: If subaccount u\n1\ntransfers x of α to subaccount u\n2\n:\nL[u\n1\n][α] ← L[u\n1\n][α]− x, L[u\n2\n][α] ← L[u\n2\n][α] + x,\nand P (α,u\n2\n) increases by x. Because the sum of all subaccount balances\ndoes not change, our invariant is preserved.\n(4) Withdrawal: If subaccount u withdraws x of α:\nL[u][α] ← L[u][α]− x,\nwhich reduces the total subaccount balances. Since externalDeposits(α)\nremains unchanged (assets have simply exited the wallet), the inequality still\nholds.\nThus, by induction over all possible operations,\nX\nu∈U\nL[u][α] ≤ externalDeposits(α)\nfor every reachable state. No subaccount can create new assets out of nothing,\nand all assets in the system are fully accounted for by provenanced deposits.\nB Dstack Architecture and Execution Model\nB.1 Component Overview\n– Dstack-OS: Minimal Linux-based VM image with a verifiable boot chain.\nMeasures bootloader, kernel, root filesystem (RootFs) via RTMR registers.\nIntegrates dm-verity for data integrity and monotonic counters for anti-\nrollback.\n– Dstack-KMS: Blockchain-governed MPC network for key derivation and\nrotation. Provides:\nk\nc\n= HMAC\nk\nroot\n(c\nid\n),\nk\nTLS\n= ECDSA(k\nroot\n).\nRotation is triggered via governance (t-of-n threshold).\n– Dstack-Gateway/Ingress: TLS termination inside TEEs, ZT-TLS bind-\ning X\nc\nto R(c), enabling verifiable HTTPS ingress.\n22J. Yu\nB.2 Governance Layer\nTwo contracts form the trust base:\n– KmsAuth: Global registry of KMS nodes and application digests.\n– AppAuth: Per-application contract specifying quorum rules, allowed image\nhashes, and authorized enclaves.\nB.3 Workflow Phases\n1. Attestation: Enclave e produces quote Q\ne\n; verified against R.\n2. Secret Provisioning: MPC nodes compute k\nc\n, release to e if Q\ne\nis valid.\n3. Container Launch: Dstack-OS mounts RootFs, decrypts state σ\nc\nwith k\nc\n.\n4. Ingress Binding: TLS certificate X\nc\ngenerated inside e; bound to R(c).\n5. Audit Logging: Migration, key rotation, and governance events appended\nto H.\nB.4 Fault Tolerance\n– Vendor failure: μ enables re-deployment across Intel/AMD TEEs.\n– KMS compromise: key rotation via MPC thresholds restores forward/backward\nsecrecy.\n– Governance deadlock: ∆t fallback in Γ ensures quorum reduction and progress.\nB.5 Liveness Proof Sketch\nCombining MPC-based key recovery, quorum fallback, and portable containers\nyields:\n∀op∈O\nc\n,Pr[Exec(c, op) =⊤] = 1\nunder assumptions of f -resilient MPC nodes and at least one uncompromised\nTEE instance.\nC Detailed Benchmark Results\nThis appendix provides comprehensive benchmark statistics for both AWS Nitro\nEnclaves and Intel TDX environments. All operations are internal PASS state\nchanges that occur within the TEE with no blockchain network interaction.\nEach operation was executed 100 times per trial, with 10 independent trials\nper environment. The tables below show summary statistics including mean,\nstandard deviation, and range.\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets23\nTable 1. AWS Nitro Enclaves benchmark statistics (ops/sec) across 10 trials\nOperationMean Std Dev Min Max\nWallet Creation6,5315315,4467,042\nAccount Balance Queries530,943675 530,216 531,915\nInbox-to-Subaccount Claims14,856476 14,326 15,504\nInternal Subaccount Transfers32,9531,322 31,447 35,088\nWithdrawal Request Creation18,2911,254 15,873 19,608\nEnd-to-End Workflow35,6636,234 21,739 40,650\nTransaction History Queries3,757453,6503,802\nMulti-threaded Operations (5 threads) 32,189884 31,200 34,364\nLarge Dataset Processing48113467497\nTable 2. Phala dStack benchmark statistics (ops/sec) across 10 trials\nOperationMean Std Dev Min Max\nWallet Creation14,9704,6528,69624,390\nAccount Balance Queries935,428338,450 383,142 1,470,588\nInbox-to-Subaccount Claims33,0645,197 25,44541,667\nInternal Subaccount Transfers71,29217,623 47,170 101,010\nWithdrawal Request Creation39,7027,434 29,15551,813\nEnd-to-End Workflow78,43317,403 59,524 110,497\nTransaction History Queries7,6858726,4528,929\nMulti-threaded Operations (5 threads) 55,12416,744 28,32981,301\nLarge Dataset Processing72481636893\nC.1 AWS Nitro Enclaves Results\nC.2 Intel TDX Results\nC.3 Performance Analysis\nThe statistical analysis reveals several key insights about PASS’s internal oper-\nation performance:\n– Performance Consistency: AWS Nitro Enclaves demonstrate superior\nconsistency with lower standard deviations across all operations. The co-\nefficient of variation ranges from 0.1% (Account Balance Queries) to 17.5%\n(End-to-End Workflow).\n– Peak Performance: Intel TDX achieves higher mean throughput but with\nsignificantly greater variance. Standard deviations are 10-500x larger than\nNitro, indicating less predictable performance.\n– Production Considerations: These internal operation benchmarks demon-\nstrate PASS’s ability to handle thousands of wallet operations per second\nwithin the TEE, with the actual deployment bottleneck being blockchain\ntransaction submission rather than internal processing.\nThe statistical summary confirms that both platforms support practical PASS\ndeployment, with Nitro offering predictable performance and Intel TDX provid-\ning higher peak throughput at the cost of consistency.\n24J. Yu\nD Design Extensions\nD.1 Composability and InterPASS Transactions\nWhile PASS provides privacy and provenance guarantees for a single wallet in-\nstance, an important question is how multiple PASS wallets may interact. This\nis important in supply-chain use cases where each PASS represents a single com-\npany in the supply chain.\nTrivially, PASS A can send an on-chain transaction from its Outbox to PASS\nB’s EOA account, and this will land in the Inbox of PASS B, ready to claim.\nHowever, this undermines the privacy guarantees that PASS offers at the EOA\nlevel, and is undesirable in cases where inter-organizational asset transfers con-\ntain sensitive information, such as order details.\nWe propose a non-trivial approach inspired by cross-Payment Channel Net-\nwork (PCN) protocols such as XTransfer [?]. We can treat each PASS instance\nakin to a PCN hub node, with state L and transaction history H. As with\nXTransfer, we can assume a star topology of PASS nodes, with a central PASS\nHub in communciation with all PASS nodes. The PASS Hub will aggregate all\nInterPASS transactions T := {(a\ni\n,x\ni\n,s\ni\n,r\ni\n)}\nn\ni=1\n, where (a\ni\n,x\ni\n,s\ni\n,r\ni\n) represent\nthe asset, amount, sender, and receiver, each signed by the s\ni\nOutbox.\nThe Hub aggregates these signed payment intents, computes a netted settle-\nment plan S, and coordinates a secure multi-party update protocol to commit\nthe resulting balances, similar to Thora [?]. In the optimistic case, this process\ncompletes entirely off-chain, and each participant’s balance is updated in the\nPASS ledger without revealing the underlying transaction graph. If a dispute or\nfailure occurs, any participant may trigger an on-chain enforcement transaction\nthat finalizes S atomically via the direct transfer mechanism, thus guaranteeing\nsafety.\nThis approach leverages PASS ’s provenance and state design to make each\ninstance an atomic node in PCN-style systems like X-Transfer. Here, we outline\nhow PASS Hubs can enable confidential, auditable cross-organization transfers,\nwhile full formal specification and protocol implementation is deferred for future\nwork.\nD.2 Instantiation on zkVM\nThe design of PASS presented thus far relies on trusted execution environments\n(TEEs) such as AWS Nitro or Intel TDX to enforce provenance-based control.\nTEEs provide strong isolation and efficient execution, allowing internal transfers\nto remain private while ensuring that every outbox action has a verifiable lin-\neage. However, the trust model is anchored in hardware attestation: users and\nregulators must accept that the enclave executes the correct code as claimed.\nWhile sufficient for many organizational custody scenarios, this assumption lim-\nits transparency and long-term auditability. To address this limitation, we ex-\nplore an alternative instantiation of PASS in a zero-knowledge virtual machine\n(zkVM), replacing hardware trust with cryptographic proofs of correctness.\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets25\nZero-knowledge virtual machines (zkVMs) provide a proving environment in\nwhich arbitrary state machines can run with strong correctness guarantees [?].\nBy producing a succinct proof π of execution, zkVMs offer integrity assurances\nsimilar to TEEs but without reliance on vendor-specific hardware. This shift\nmakes zkVMs particularly suitable for contexts such as institutional custody,\nmulti-party supply chains, or inter-organizational accounting where external ver-\nifiability and regulator-grade auditability are paramount.\nIn a zkVM instantiation of PASS, the execution pipeline mirrors the enclave-\nbased design but replaces attestation with cryptographic proofs. The process\nproceeds in four stages:\n1. Batch formation. Transaction requests (claims, transfers, withdrawals) are\nfirst queued off-chain into a batch.\n2. zkVM execution. The zkVM program takes as private inputs: (i) the prior\nbatch’s commitments of the ledger L and provenance log H, (ii) the queued\ntransitions, including inbox I deposits and outbox O withdrawals, and (iii)\nthe proposed new commitments (L\n′\n,H\n′\n). Inside the zkVM, the transition\nfunction is replayed deterministically: starting from the previous roots, ap-\nplying all operations in sequence, updating balances and provenance entries,\nand checking consistency constraints.\n3. Proof generation. The zkVM outputs a succinct proof π certifying that the\nclaimed new roots (L\n′\n,H\n′\n) are correct with respect to the given transition\nset.\n4. On-chain verification. A minimalist verifier contract validates π, updates\nthe recorded commitments, and enforces any pending outbox operations.\nThis ensures that every external action has a verifiable provenance path\nwhile internal transfers remain private.\nCompared to TEEs, zkVMs strengthen the verifiability model by eliminat-\ning hardware trust assumptions, but incur higher computational and financial\ncosts due to proof generation and on-chain verification. Batching amortizes these\ncosts, raising open research questions about optimal batch sizes, data availabil-\nity strategies, and proof system selection. zkVM backends such as Risc0, SP1,\nor Plonky3 offer different tradeoffs in proof size, verification cost, and latency.\nHybrid deployments are also possible: TEEs can serve as fast-path executors for\nintra-day operations, with zkVM proofs generated periodically to provide cryp-\ntographic audit trails. This hybrid pattern resembles optimistic rollups, where\nfast execution is combined with verifiable settlement.\nFinally, this instantiation aligns closely with the Chainless stack architec-\nture [?], which emphasizes the separation of execution, trust, bridging, and set-\ntlement. In this view, zkVM proofs naturally inhabit the execution and trust\nlayers, Inbox/Outbox commitments integrate with bridging, and the verifier\ncontract finalizes settlement. This layered design opens the door to modular,\ninteroperable deployments of PASS across heterogeneous chains and domains.\nFull formal specification, performance benchmarking, and exploration of hybrid\nzkVM–TEE implementations remain important avenues for future work.\n26J. Yu\nFig. 6. PASS instantiation inside a zkVM: Inbox I and Outbox O transitions are\napplied to the Ledger L and Provenance H, producing new state commitments. The\nzkVM outputs a proof π, which the on-chain verifier checks before updating roots and\nenforcing outbox operations."
}
]
},
{
"role": "assistant",
"content": "To address the question—**why existing works cannot satisfy the three use cases in the Introduction, and why a provenance- and TEE-based solution (PASS) is superior**—we must examine both the requirements of the use cases and the limitations inherent in the prevailing wallet architectures, as articulated in the Introduction and Background sections.\n\n---\n\n## 1. Why Existing Works Cannot Satisfy the Three Use Cases\n\nThe three use cases from the Introduction are:\n\n1. **AI and Smart Agent Transactions**: AI agents managing assets require bounded authority and access guardrails.\n2. **Enterprise Payroll Privacy**: Organizations need to distribute salaries and budgets without revealing sensitive on-chain details.\n3. **Consumer-grade Central Limit Order Books (CLOBs)**: Real-time, high-throughput trading requires low gas costs and minimal user key management.\n\nLet us analyze how mainstream solutions fall short for each.\n\n### a. **EOAs (Externally Owned Accounts)**\n- **Control Model**: Single private key = total, unilateral control.\n- **Limitations**:\n - _AI & Smart Agents_: No way to delegate or restrict authority; giving an AI the private key grants it full, irrevocable power.\n - _Payroll Privacy_: All transfers are public, so salary disbursements are visible on-chain.\n - _CLOBs_: Every action is a public, gas-consuming transaction; no support for high-frequency, low-latency trades or batch operations.\n\n### b. **Multisignature Wallets**\n- **Control Model**: t-of-n co-signers must approve each action.\n- **Limitations**:\n - _AI & Smart Agents_: No fine-grained or scoped delegation—either a key is part of the quorum or not; cannot limit by asset, amount, or domain.\n - _Payroll Privacy_: All actions and policies are publicly visible; internal logic is on-chain and auditable by anyone, leaking salary and budget flows.\n - _CLOBs_: High on-chain overhead for every trade due to multi-party signatures; not suitable for fast, gasless, internalized operations.\n\n### c. **Smart Contract Wallets (e.g., ERC-4337, Account Abstraction)**\n- **Control Model**: On-chain policy logic, programmable rules.\n- **Limitations**:\n - _AI & Smart Agents_: Policies are programmable but public; any delegation or restriction is visible and can be front-run or censored.\n - _Payroll Privacy_: Every policy execution is public and incurs gas; internal flows cannot be hidden.\n - _CLOBs_: On-chain execution is required for every action, leading to prohibitive gas costs and latency for high-frequency trading.\n\n### d. **Custodians (RBAC/ABAC Engines)**\n- **Control Model**: Off-chain access policies, custom APIs.\n- **Limitations**:\n - _AI & Smart Agents_: Custom policy languages proliferate; off-chain enforcement is opaque, and the custodian sees all internal activity.\n - _Payroll Privacy_: Custodian observes all internal flows; privacy is lost at the custodian, even if not on-chain.\n - _CLOBs_: Custodians may support batching, but users must trust the custodian’s infrastructure and APIs, introducing centralization and privacy risks.\n\n### e. **TEE-based Wallets (e.g., Liquefaction)**\n- **Control Model**: TEE holds the key and enforces sub-policies.\n- **Limitations**:\n - _AI & Smart Agents_: Liquefaction can enforce sub-policies, but the model is more complex (key encumbrance trees), and depends on specialized smart contracts (e.g., Oasis), limiting compatibility.\n - _Payroll Privacy_: Internal logic is hidden, but deployment is limited to specific chains (Oasis), reducing flexibility.\n - _CLOBs_: Throughput is lower due to reliance on blockchain oracles for validation, leading to significant latency.\n\n#### **Summary Table (from the paper):**\n\n| Model | Internal Privacy | On-chain Overhead | Compatibility | Granularity of Control |\n|---------------|-----------------|-------------------|--------------------|-----------------------------|\n| EOA | None | None | Native EOA | None |\n| Multisig | None | High | Contract-based | Symmetric, coarse |\n| Smart Wallet | None | Med–High | ERC-4337 required | Programmable, public |\n| Custodian | At custodian | None | API-mediated | Off-chain, opaque |\n| Liquefaction | Strong (TEE) | Medium | Oasis only | Policy trees, TEE-enforced |\n| **PASS** | Strong (TEE) | None | Native EOA + TEE | Provenance, fine-grained |\n\n---\n\n## 2. Why Provenance- and TEE-based Control (PASS) Is Superior\n\nPASS’s core architectural innovations directly address the above shortcomings:\n\n### a. **Provenance-based Control**\n- **Assets are controlled based on their custody history (provenance), not identity or roles.**\n- **Inbox–Outbox Model**: All external deposits are tracked in an Inbox; subaccounts must claim assets, establishing a clear lineage.\n- **Internal Transfers**: Are private (off-chain), fee-less, and invisible to external observers. Only withdrawals (Outbox) are on-chain, preserving privacy and minimizing gas.\n\n### b. **TEE Enforcement**\n- **Private key is held exclusively in the TEE**; never accessible to users or operators.\n- **All policy logic and provenance checks are enforced within the hardware-isolated enclave**, guaranteeing that even privileged insiders cannot subvert controls or observe internal flows.\n- **Remote attestation** allows external parties to verify that the correct code is running inside the enclave.\n\n### c. **Alignment with Use Cases**\n- _AI & Smart Agents_: Can be given sub-accounts with limited provenance-based authority (e.g., capped balances, domain-specific permissions), preventing overreach or misuse. If compromised, the AI can only affect its own subaccount.\n- _Payroll Privacy_: Salaries and departmental budgets are distributed internally, off-chain, with only aggregate payouts visible on-chain. Internal transfers are invisible, so sensitive information is not leaked.\n- _CLOBs_: High-frequency, gasless internal trading is possible, with only net settlements (batch withdrawals) posted on-chain. Users do not have to manage keys; the enclave orchestrates all actions securely.\n\n### d. **Compatibility and Efficiency**\n- **Native EOA Compatibility**: No need for custom smart contracts, chain modifications, or special APIs. Works with existing wallet infrastructure.\n- **No On-chain Overhead**: All internal logic is off-chain; only withdrawals incur gas, and those can be batched.\n- **High Throughput**: Benchmarks show sub-millisecond internal operations, far outpacing TEE-based systems that require blockchain oracles.\n\n### e. **Formal Guarantees**\n- **Proven security properties** (privacy, accessibility, provenance integrity) are formalized and machine-checked, not just informally claimed.\n- **Auditability**: Provenance logs can be selectively revealed for compliance or audit, without disclosing full internal state.\n\n---\n\n## 3. Logical Synthesis\n\n**Existing solutions are fundamentally limited by their control models:**\n- _Identity and role-based controls_ are awkward and brittle in blockchain’s exogenous asset environment, where assets are not natively tied to wallet identities.\n- _Public policy logic_ (smart contracts, multisigs) leaks sensitive information and incurs high gas costs.\n- _Custodial and off-chain solutions_ reintroduce centralization and erode privacy at the operator level.\n- _TEE-based approaches_ without provenance logic (or with complex policy trees) lack compatibility, efficiency, or formal guarantees.\n\n**PASS, by enforcing control via asset provenance and isolating all sensitive logic within a TEE, directly matches the requirements of emerging use cases:**\n- _Fine-grained, auditable, and private delegation for AI and agents_\n- _Internal privacy and regulatory auditability for enterprise payroll_\n- _Scalable, gasless, and private operation for consumer-grade trading, without user key management overhead_\n\n**Therefore, provenance- and TEE-based control is not just incrementally better, but fundamentally more aligned with the needs of modern, multi-actor, privacy-sensitive blockchain applications.** The formalization, efficient implementation, and demonstrated compatibility of PASS further reinforce its superiority as a solution."
},
{
"role": "user",
"content": "This is too long and too much to fit into the introduction. I want to make it simpler:\n\n1. in three use cases they call for the support for \"offchain transfers\", which needs to be fast, low-cost (ideally free) and private. In contract, the onchain transactions are more like a \"side effect\" when some settlements are needed.\n2. the role-based model cannot efficiently solve this problem cuz they need to define the rules from scratch. Instead, the provenance-based solution can fit in, ...\n\nWrite with this train-of-thought. You can ask questions if anything is not clear or logically consistent to you."
},
{
"role": "assistant",
"content": "Your train of thought is clear and logically sound. Here is a concise, logically-structured explanation suitable for an introduction:\n\n---\n\nThe three use cases described—AI agent wallets, private enterprise payroll, and consumer-grade CLOBs—all require support for **fast, low-cost (ideally free), and private offchain transfers**. In these scenarios, most activity happens internally within the wallet, and onchain transactions serve only as external settlement events or \"side effects\" when necessary.\n\nTraditional role-based access models (RBAC/ABAC) are ill-suited to this requirement. They force organizations to define complex access rules from scratch, tailored to each scenario and actor, leading to policy sprawl and administrative overhead. Moreover, these models still rely on onchain enforcement or centralized custodians, which cannot provide the required privacy or cost-efficiency for internal flows.\n\nIn contrast, a **provenance-based approach** naturally fits the offchain transfer paradigm: permissions and asset usability are determined by the custody history of each asset, not by static roles. This enables efficient, private, and auditable internal transfers, with onchain actions limited to external settlement. By enforcing the provenance logic within a TEE, we guarantee both privacy for internal operations and verifiable integrity for external settlements, satisfying the demands of all three use cases without the complexity or leakage inherent in role-based models.\n\n---\n\nIf you want it even shorter or more focused, let me know your target length or further constraints."
},
{
"role": "user",
"content": "for the second point it should be able to re-use many existing contents. Make the changes so these paras can be embeded into the current version with minimal modifications"
}
]Response:
Certainly. Here is a version that aligns closely with your notes and can be embedded with minimal modifications into your introduction:
---
All three use cases—AI agent wallets, private enterprise payroll, and consumer-grade CLOBs—require support for **offchain transfers** that are fast, low-cost (ideally free), and private. In these scenarios, the majority of asset movements are internal, while onchain transactions function only as a settlement mechanism or "side effect" when external interaction is necessary.
Traditional role-based access models (RBAC/ABAC) are not well-suited for this paradigm. They require organizations to define bespoke access rules for each actor and context, resulting in complex, hard-to-maintain policies that do not generalize well. Furthermore, role-based models still depend on onchain enforcement or centralized custodians, which cannot deliver the privacy or efficiency required for internal flows.
By contrast, a provenance-based solution allows control to be determined by the custody history of each asset, rather than by static roles. This approach enables efficient, private, and auditable offchain transfers, with onchain actions limited to external settlements. When enforced within a TEE, provenance-based control ensures that internal operations remain private, while external settlements are both verifiable and secure. This architecture directly addresses the requirements of the target use cases, while avoiding the complexity and privacy leakage inherent in role-based systems.
Model: gpt-4.1-2025-04-142025-09-15 12:47:56
Context:
[
{
"role": "system",
"content": "You are a research paper writer. You focus on:\n1. logical consistency\n2. whether the story is persuasive\nDon't try to be friendly on purpose, judge everything based on the logic and expressiveness."
},
{
"role": "user",
"content": [
{
"type": "text",
"text": "Use the contents of Introduction and Background, answer my question.\n\nMy target is to demonstrate that the existing works cannot satisfy the three use cases in Introduction, and also explain why provenance- and TEE-based solution is a better solution for this."
},
{
"type": "text",
"text": "main.pdf\nPASS: A Provenanced Access Subaccount\nSystem\nfor Blockchain Wallets\nJay Yu\n1,2\n1\nStanford University [email protected]\n2\nPantera Capital [email protected]\nAbstract. Blockchain wallets still follow a single-entity ownership model:\npossession of a private key grants unilateral control. This assumption is\nbrittle for emerging settings such as organizational custody, shared gov-\nernance, and AI agent wallets, where multiple actors must coordinate\nwithout exposing secrets or leaking internal activity.\nWe present PASS, a Provenanced Access Subaccount System\nthat replaces role or identity-based control with provenance-based con-\ntrol: assets can only be used by subaccounts that can trace custody back\nto a valid deposit. A simple Inbox–Outbox mechanism ensures all exter-\nnal actions have verifiable lineage, while internal transfers remain private\nand indistinguishable from ordinary EOAs.\nWe formalize PASS in Lean 4 and prove core invariants, including\nprivacy of internal transfers, asset accessibility, and provenance integrity.\nWe implement a prototype with enclave backends on AWS Nitro Enclaves\nand dstack Intel TDX, integrate with WalletConnect, and benchmark\nthroughput across wallet operations. These results show that provenance-\nbased wallets are both implementable and efficient. PASS bridges today’s\ngap between strict self-custody and flexible shared access, advancing the\ndesign space for practical, privacy-preserving custody.\n1 Introduction\nCryptocurrency wallets conventionally assume one key, one owner. In this single-\nentity ownership (SEAO) model, whoever holds the private key gains permanent\nand total control of the address, and casts publicly readable, gas-consuming\nblockchain transactions. However, this model struggles to adapt to emerging\nblockchain scenarios:\n1. AI and Smart Agent Transactions. AI agents increasingly manage crypto\nassets [?,?] and require bounded authority and access guardrails for users’\nasset security.\n2. Enterprise Payroll Privacy. Organizations need to distribute salaries and\ndepartmental budgets to employee accounts without revealing sensitive de-\ntails on-chain [?,?,?].\n2J. Yu\n3. Consumer-grade Central Limit Order Books. On-chain order books\nface high gas costs and latency that prevent real-time trading at scale [?,?],\nand many consumers prefer not to manage their own keys [?,?].\nIn practice, many organizations confronted with these challenges default to\ncustodians or policy engines that wrap access logic in Role-Based Access Con-\ntrol (RBAC) or Attribute-Based Access Control (ABAC) [?,?]. These systems\nintroduce a proliferation of bespoke policy languages and APIs to specify who\nmay sign or transfer under which conditions [?,?]. While workable as a stopgap,\nthey inherit identity and role assumptions from traditional IT settings that limit\ntheir flexibility and scalability in blockchain contexts.\nThe limitation stems from a mismatch of models. Traditional access-control\nframeworks such as RBAC and ABAC assume an endogenous setting: users\ncreate and manage their own files, objects, or services, and policies are attached\nto these identities or roles. Blockchains are fundamentally exogenous: assets are\ncreated outside the wallet by smart contracts and transferred permissionlessly\nin. In this setting, identity or role-based rules are awkward to express and brittle\nto enforce. What matters instead is provenance: who deposited an asset, and how\nit flowed within the wallet.\nWe propose PASS, a Provenanced Access Subaccount System that enforces\ncontrol directly by provenance. The core mechanism is simple: an Inbox records\nexternal deposits, an Outbox signs and broadcasts withdrawals, and all internal\nmovements remain private and fee-less. Every unit of value inside the wallet has\na verifiable lineage to an on-chain deposit, while externally a PASS wallet is\nindistinguishable from a standard EOA. Our contributions include:\n– A provenance-based access model aligned with blockchain’s exogenous asset\ncreation, enforced through an Inbox–Outbox design.\n– A formal model in Lean 4 proving privacy, accessibility, and provenance\nintegrity.\n– A prototype with multi-vendor enclave backends (AWS Nitro, Intel TDX via\ndstack), a web app frontend integrated with WalletConnect, together with\nthroughput benchmarks.\n– Application scenarios, including organizational custody, privacy-preserving\ntransfers, and safe delegation to AI agents.\nPASS thus bridges the gap between strict self-custody and flexible shared\naccess, combining strong privacy guarantees with practical deployability.\n2 Background and Related Work\nGrowing retail and institutional adoption of digital assets [?] has driven diverse\nwallet designs [?]. We summarize mainstream Ethereum Virtual Machine (EVM)\nwallet designs in Figure ??.\nEOAs and Multisigs. Externally Owned Accounts (EOAs) give unilateral,\npermanent control to whoever holds the private key [?]. Multisignature wallets\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets3\nModelControl basisOn-chain\noverhead\nInternal\nPrivacy\nCompatibility\nEOASingle private keyNoneNoneNative EOA\nMultisigt-of-n co-signersHigh; quorum per\naction\nNone; logic\npublic\nSmart\ncontract based\nERC-4337\nSmart\nAccounts\nOn-chain policy\nlogic\nMedium to high;\ncustom logic and\ngas\nNone; logic\npublic\nRequires\nERC-4337\nchain support\nCustodiansCustom RBAC or\nABAC languages\nNone; Off-chain\nenforcement\nCustodian sees\nall activity\nAPI mediated\nLiquefactionTEE key\nencumbrance;\npolicy trees\nMedium; Oasis\ncontracts and gas\nStrong; TEE\nhides\nsubpolicies\nRequires Oasis\ndeployment\nPASS\n(ours)\nProvenance via\nInbox-Outbox\nNone; EOA\ncompatible\nStrong;\ninternal\ntransfers\ninvisible\nNative EOA\nplus off the\nshelf TEEs\nFig. 1. Comparison of wallet architectures. PASS features provenance-based control,\noff-chain privacy, and native EOA compatibility.\n(eg., Safe) distribute trust via t-of-n approvals [?], common for treasuries and\nbridges [?,?,?]. Drawbacks include quorum overhead, symmetric authority, and\npublic logic with attackable frontends [?]. In contrast, PASS offers fine-grained,\nscoped permissioning without new contracts.\nSmart Contract Wallets and Account Abstraction. Wallets like Ar-\ngent and Loopring add programmability (social recovery, spend limits) via on-\nchain logic [?,?,?]. ERC-4337 enables custom validation through UserOperation\ncontracts [?], and EIP-7702 lets EOAs invoke this logic [?]. These increase flex-\nibility but expose policies publicly and incur gas costs, limiting use cases like\npayroll. PASS instead enforces policy privately in a TEE, minimizing on-chain\nfootprint.\nCustodial Policies. Custody providers (Fireblocks, Turnkey, Privy) use\nRBAC/ABAC engines with custom policy languages [?,?]. PASS replaces these\nwith provenance: authority follows asset origin and history, akin to a UTXO\nmodel. This reduces policy-surface complexity while remaining composable with\nconstraints like whitelists and blacklists.\nTEEs and Liquefaction. Trusted Execution Environments (TEEs) provide\nhardware-isolated contexts with remote attestation [?,?]. Liquefaction [?] keeps\nwallet keys in a TEE and enforces sub-policies via key encumbrance, ensuring\nprivacy. PASS advances this model by (i) proving invariants in Lean 4, (ii) sim-\nplifying enforcement to a provenance rule with Inbox/Outbox subaccounts, and\n(iii) working with a standard EOA without relying on Oasis smart contracts\n[?]. We further validate by implementing PASS on AWS Nitro Enclaves and In-\ntel TDX (via dStack), and showcase applications including AI wallets, payroll,\nsupply chains, and DAO voting.\nOther Models. Exchanges pool funds in omnibus addresses with off-chain\nledgers [?]; mixers like Tornado Cash hide deposit–withdrawal links [?]. PASS\n4J. Yu\nsimilarly hides internal transfers while retaining a provenance log for auditability;\noutsiders see only deposits and withdrawals.\n3 System Model and Design\nFig. 2. Overview of PASS. External deposits enter the Inbox and are claimed by sub-\naccounts. Internal transfers are private and off-chain. Egress occurs via the Outbox,\nwhich signs and broadcasts on-chain transactions. All on-chain activity has clear prove-\nnance; internal movements remain private.\n3.1 High level system model\nPASS is a multi-user wallet on a single EOA (sk, pk). The wallet maintains a\nfinite set of subaccounts U ={u\n1\n,...,u\nn\n} and a set of assets A (e.g., ERC-20).\nA subaccount u ∈ U has authority over an amount x of asset α ∈ A iff it can\nobtain a signature from the global sk via the enclave; sk resides only inside a TEE\nand is never directly accessible. We give the intuitive model here and formalize\nit in Section ??.\nInternally, PASS tracks balances with a map L : U ×A →Z\n≥0\n(accessed\nvia L[u][α]), an Inbox multiset I of unclaimed deposits (α,x,m), an Outbox\nFIFO queueO of pending on-chain actions (α,x, extDst,ν) together with a global\nnonce ν ∈N, and an append-only provenance logH. The core principles of PASS,\nas shown in Figure ?? are as follows:\n1. Access follows provenance. A unit of value is usable by u only if there\nexists a custody chain in H from an external deposit to u. Informally,\nAllow(u,α,x) means balance x is reachable for u via provenance in H. This\nimplies consistency : for every α, the total internal balance equals the on-\nchain balance at pk, i.e.,\nP\nu∈U\nL[u][α] = B\non\n(α). Incoming deposits (α,x,m)∈\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets5\nI are “wrapped” and must be explicitly claimed before use by the sender\naddress.\n2. Off-chain privacy. Internal transfers u→ v update only L and H; they do\nnot touch O or the on-chain balance B\non\n, so internal flow is invisible and\nfee-less.\n3. First-come, first-served. Outbox transactions are sequenced by a FIFO queue,\nwhich maintains and increments a global nonce ν and directly sends enclave-\nsigned transactions to a RPC node to prevent nonce conflicts and replay\nattacks.\n3\nOrganizational Ownership Model. PASS operates under an organiza-\ntional ownership model, where an entity such as a company, individual, or DAO\nmanages shared control over blockchain assets. We detail the threat model in\nSection ??.\nInbox-Outbox Gateway External senders transfer assets to pk, creating\nInbox entries (α,x,m) ∈ I. A user performs claim(u,α,x,m) to move value\nintoL[u][α], conceptually “wrapping” the deposit. To withdraw or interact with\na contract, a subaccount first performs an internal transfer to the Outbox,\nwhich enqueues (α,x, extDst,ν); the enclave then signs the concrete transaction\nwith sk and immediately broadcasts it, incrementing ν. The FIFO discipline and\nglobal nonce serialize actions and prevent races and double-spends. Because sub-\naccounts never receive pre-signed transactions, pre-signing misuse is mitigated.\nComposable policy scheme. Deposits are claims fromI; internal transfers\nrequire Allow(u,α,x) and update (L,H); withdrawals are internal transfers to\nO followed by submission. Additional constraints (eg., RBAC or ABAC checks,\nwhitelists and blacklists) can be incorporated as conjuncts to Allow without\nchanging the provenance-centric rule or its consistency and privacy effects.\n3.2 Formal Model\nWe formalize PASS as a transition system in Lean 4\n4\n, an interactive theorem\nprover with a rich dependent type system [?], suitable for policy verification (eg.,\nAWS Cedar [?]). In this section, we introduce the formal system we modeled in\nlean, and in Section ?? we will discuss security invariants modeled. An extended\ndiscussion of our formal verification system can be found in Appendix ??.\nState. A wallet state is S =\n\u0000\npk, sk,ν,I,O,L,H\n\u0001\nwhere (pk, sk,ν) are the\nEOA public key, private key (generated and held in the TEE), and global nonce;\nI and O are Inbox and Outbox; L is the internal balance map L[u][α] ∈Z\n≥0\n;\nandH is the provenance history. For privacy arguments we also use the external\nview W\npub\n= (pk,O,A), where O contains the Outbox queue and nonce and A\nrecords total on-chain balances by asset.\n3\nWe assume that the TEE is able to run a Helios light client, as is the case in dstack\nIntel TDX, discussed and implemented in Section ??\n4\nLean 4 model: https://github.com/pass-wallet/pass-lean4-proofs\n6J. Yu\nPASS Wallet Management Functionality F\nΣ\nPASS\nfor wallet W\nGlobal State:\npk : public address (EOA)\nsk : private key (in TEE)\nν: global nonce for on-chain transactions\nI (Inbox): set of unclaimed deposits (α : asset,x : amount,m : depositId)\nO (Outbox): FIFO queue (α,x, extDst,ν)\nL (Asset Ledger): internal map L[u][α]∈ Z\n≥0\n, where u is each user’s ID in the system\nH (Provenance History): a list of transaction records appended whenever ClaimInbox,\nInternalTransfer, or Withdraw is invoked\nCreatePassWallet (creator ):\nI← ∅, O← ∅, L←{}; ν← 0\n(pk, sk )← TEE\nKeyGen()\nReturn new W with S =\n\u0000\npk, sk,ν,I,O,L,H\n\u0001\nand reference to creator\nInboxDeposit (α,x,m) from external P :\nI ← I ∪ {(α,x,m)}\nReturn success\nClaimInbox (α,x, depositId) from u:\nIf no (α,x,m) with depositId in I, return ⊥\nRemove (α,x,m) from I\nL[u][α]←L[u][α] + x\nH←H| (op = claim,α,x, depositId,u)\nReturn success\nCheckAllow (u\nsend\n,α,x,H):\nIf H.GetProvenance(α, u\nsend\n)≥ x,\nreturn true; else return false\nInternalTransfer (α,x,u\nsend\n,u\nrecv\n):\nIf L[u\nsend\n][α] < x or ¬checkAllow(u\nsend\n,α,x,H), return ⊥\nL[u\nsend\n][α]←L[u\nsend\n][α]− x\nL[u\nrecv\n][α]←L[u\nrecv\n][α] + x\nH←H\n\f\n\f\n\u0000\nop = transfer,α,x,u\nsend\n,u\nrecv\n\u0001\nReturn success\nWithdraw (α,x,u\nsend\n, extDst):\nIf L[u\nsend\n][α] < x or ¬checkAllow(u\nsend\n,α,x,H), return ⊥\nL[u\nsend\n][α]←L[u\nsend\n][α]− x\nO ←O∪{(α,x, extDst,ν)}\nH←H | (op = withdraw,α,x,u\nsend\n, extDst)\nReturn success\nSignGSM (dom, msg,u):\nIf u lacks sign-right for (dom, msg), return ⊥\nσ ← (sk, msg)\nReturn σ\n(Outbox Processing) (periodic or on demand):\nIf O ̸= ∅, dequeue (α,x, extDst,ν)\nBuild tx τ : transfer x of α to extDst, nonce = ν\nσ ← (sk, τ ); broadcast (τ,σ)\nν←ν + 1\nReturn broadcasted + txHash\nFig. 3. Formal Model of PASS wallet functionality, including CreatePassWallet for\ninitializing a fresh instance. On creation, pk is set to a chosen EOA address eoa, the\nTEE generates a hidden private key sk , and global data structures are initialized.\nExternal deposits enter I (Inbox), while subaccount transfers update L (Ledger) off-\nchain. Withdrawals queue items in O (Outbox), and GSM operations are signed using\nsk .\nTransitions. Operations op∈ T update S with type-checked rules: InboxDe-\nposit adds an unclaimed (α,x,m) to I; ClaimInbox moves (α,x,m) from I to\nL[u][α] and appends to H; InternalTransfer moves value between subaccounts;\nWithdraw debits L[u][α], enqueues (α,x, extDst,ν) in O, and logs; SignGSM\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets7\nauthorizes domain-scoped signable messages. A representative rule is:\n\u0000\npk, sk,ν,I,O,L,H\n\u0001\ntransfer(α,x,u\ns\n,u\nr\n)\n−−−−−−−−−−−→\n\u0000\npk, sk,ν,I,O,L\n′\n,H\n′\n\u0001\nwith\nif L[u\ns\n][α] < x or ¬checkAllow(u\ns\n,α,x,H) then ⊥;\nL\n′\n[u\ns\n][α] =L[u\ns\n][α]− x, L\n′\n[u\nr\n][α] =L[u\nr\n][α] + x;\nH\n′\n=H\n\f\n\f\n\u0000\nop = transfer,α,x,u\ns\n,u\nr\n\u0001\n.\nHere checkAllow queries provenance inH and can be extended with auxiliary\nconstraints such as user whitelists or blacklists, without changing the core rule.\nFigure ?? provides a formal specification of the methods in a PASS wallet.\n3.3 Asset Model and General Signable Messages\nPASS provides an authorization scheme over a heterogenous set of assets A, in-\ncluding fungible tokens, such as ether and ERC-20 tokens, ERC-721 non-fungible\ntokens, and “general signable messages” across a variety of DApps for sign-in\nand identity verification. Each asset α ∈ A has a well-defined custody path in\nthe provenance log H, and a subaccount u ∈ U has usable balance x of α iff\nAllow(u,α,x) holds.\nToken assets. For token assets such as ether, ERC-20, and ERC-721, de-\nposits are captured as Inbox entries (α,x,m) ∈ I. Claims allocate balance into\nL[u][α], internal transfers update L and H privately, and withdrawals enqueue\n(α,x, extDst,ν) intoO for enclave signing and on-chain broadcast, ensuring con-\nsistency where:\n∀α∈A\ntokens\n:\nX\nu∈U\nL[u][α] = B\non\n(α, pk).\nIn particular, ERC-721 tokens are modeled as unitary balances (x ∈ {0, 1})\nwhose transfers preserve uniqueness under provenance.\nGeneral Signable Messages (GSMs). In addition to on-chain assets,\nwallets often sign arbitrary messages, such as for EIP-4361 [?] logins and off-\nchain DAO votes [?]. PASS models these as a special classA\nGSM\nof virtual assets.\nEach GSM asset is scoped to a domain dom, so holding α = (dom) represents\nauthority to sign messages from that domain. A signature operation:\nSignGSM(u, dom,m)7→ σ\nis permitted iff Allow(u, dom, 1) holds in H. At key generation, the wallet\ncreator is endowed with default signing authority over all domains, represented\nas an initial allocation of every α = (dom)∈A\nGSM\nto the root subaccount. These\ndomain assets can be internally transferred to delegate signing authority. Thus\nprovenance of GSMs begins at the owner and flows through transfers, providing\na well defined provenance path in H as with token assets.\n8J. Yu\nBy treating both tokens and GSMs as types of elements ofA, PASS provides\na unified provenance rule for subaccount authorization. A subaccount cannot\nspend an ERC-20 token, transfer an NFT, or sign a domain message unless it\npossesses the corresponding asset under L and H. This unified authorization\nscheme allows for fine-grained delegation, (eg., giving u rights over example.com\nwhile withholding ERC–20 funds) and consistent enforcement across on-chain\nand off-chain actions.\n4 Properties of PASS\n4.1 Threat Model\nPASS assumes an organizational ownership model, where a single entity, such\nas a company, individual, or DAO manages the EOA (pk,sk), brokers access\nbetween many users in that entity, and chooses the TEE infrastructure vendor\n(eg. AWS Nitro, dstack Intel TDX, self-hosted hardware). This model is typical\nfor use cases such as private payroll, supply chains, and AI delegation described\nin Section ??. Protected assets in PASS include the private key sk, the balance\nledger L and provenance log H, and the correctness of Allow(u,α,x) for all\nu∈ U,α∈A,x. In our model, we make the following trust assumptions:\n1. TEE integrity. Hardware isolation is sound; sk never leaves the enclave.\nRemote attestation guarantees that the enclave runs the genuine PASS bi-\nnary.\n2. Cryptography. Standard primitives (signatures, hash functions, PRFs) are\nsecure against polynomial-time adversaries.\n3. Governance majority. The deploying entity holds majority control in the\ngovernance mechanism (via DAO vote or admin privileges), ensuring it can\ninvoke the blockchain-governed KMS for MPC-based key recovery and trig-\nger fallback contracts when needed.\nAdversary Model. An adversary A may control the host OS and network,\nobserve or modify all communication with enclaves, and submit arbitrary trans-\naction requests. In particular, A may attempt to:\n– Exploit software bugs in the PASS implementation or TEE runtime,\n– Forge or replay transactions to break consistency of H,\n– Subvert provenance by violating Allow(u,α,x)\nThreats Out of Scope. On the other hand, PASS does not protect against:\n– Physical compromise of TEE hardware (tampering, microarchitectural side-\nchannels, chip decapsulation),\n– Supply-chain backdoors in TEE manufacturing,\n– Fully malicious operators with unrestricted physical access.\nThese are excluded because the organizational model assumes controlled facilities\nand vetted hardware.\nSecurity Goals. Given the assumptions above, PASS guarantees:\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets9\n1. Integrity:\nP\nu∈U\nL[u][α]≤ extDep(α) for all α, i.e., no assets can be created\nor double-spent internally.\n2. Correctness: If Allow(u,α,x) holds, then u can eventually realize x via\nWithdraw.\n3. Privacy on-chain: InternalTransfer operations do not affect externalTrace(W ),\nand to external observers, a PASS wallet is indistinguishable from an EOA.\n4. Liveness: For any authorized op ∈ Ops, if one enclave and quorum remain\nhonest, then ∃τ s.t. Exec(c, op) =⊤ within τ\n4.2 Privacy and Safety\nAfter establishing the threat model of PASS, we will address the central privacy\nand safety guarantees in our formal verification model. We sketch three central\nlemmas here, and create mechanized proofs in Lean, discussed in Appendix ??.\nProposition 1 (Internal Transfer Privacy). If two public states W\n1\n,W\n2\nshare the same pk, identical Outbox (T,ν), and equal per-asset totals in A, then\nexternalTrace(W\n1\n) = externalTrace(W\n2\n).\nProof Sketch. InternalTransfer updates only (L,H), never O or total on-chain\nbalances. OutboxProcessing in Figure ?? emits on-chain actions solely from O\n(lines 2–4), hence the trace depends only on O.\nCorollary: EOA indistinguishability. If W\npass\nand W\neoa\nshare the same pk,\nOutbox, and per-asset totals, then\nexternalTrace(W\npass\n) = externalTrace(W\neoa\n).\nThus, from an external observer’s perspective, a PASS account is indistinguish-\nable from a standard EOA: internal transfers leave no observable footprint.\nProposition 2 (Asset Accessibility). For any asset α, letting L = {u |\nL[u][α] > 0},\nX\nu∈L\nL[u][α] = totalBalance(α),\nand each u∈ L can spend its full balance subject to checkAllow.\nProof Sketch. ClaimInbox creditsL; InternalTransfer preserves the sum over u;\nWithdraw debitsL and enqueues toO, which OutboxProcessing realizes on-chain.\ncheckAllow enforces reachability from provenance in H.\nProposition 3 (Provenance Integrity). Let extDep(α) be net external de-\nposits (deposits minus realized withdrawals). For all reachable states,\nX\nu\nL[u][α] ≤ extDep(α).\n10J. Yu\nProof Sketch. Induct on transitions. InboxDeposit increases extDep only; Claim-\nInbox moves already-deposited value into L; InternalTransfer conserves the sum\nover u; Withdraw decreases the sum, and after OutboxProcessing broadcasts,\nextDep is reduced accordingly.\nGeneral signable messages (GSM). Model GSM rights as a domain-\nscoped virtual asset class A\nGSM\n. Let α = (dom)∈A\nGSM\nand permit\nSignGSM(u, dom,m) iff Allow(u,α, 1).\nThen (P2)–(P3) lift to GSM: there is always at least one domain signer, and\nGSM “balances” obey provenance conservation under transfers in H.\n4.3 Liveness\nWe define liveness as the property that any authorized operation remains even-\ntually executable, despite enclave crashes, vendor compromise, or partial gover-\nnance failure. Our model assumes deployment of PASS access logic on dstack,\nimplemented in Section ?? and detailed in Appendix ??.\nLet E denote active enclaves, C containerized wallet backends, and P gover-\nnance policies. Each container c∈C stores sealed state\nσ\nc\n=⟨S,k\nc\n, meta⟩ with S = (pk, sk,ν,I,O,L,H),\nwhere k\nc\n= Derive(K,c) is derived from an MPC-managed KMS and meta records\nattestation. An operation op ∈ Ops (deposit claim, transfer, withdrawal) ex-\necutes as: Exec(c, op) = ⊤ iff Attested(c)∧ Γ (S), where Attested(c) checks σ\nc\nagainst registry R and Γ is the quorum predicate over P. To ensure vendor-\nagnostic portability, state migration μ :E →E satisfies\n∀e\ni\n,e\nj\n∈E, e\nj\n.decrypt(σ\nc,e\ni\n,k\nc\n) = σ\nc,e\ni\n,\nTheorem 1 (Liveness Theorem). If (i) the MPC KMS tolerates f\nKMS\nfaults\nin a t-of-n threshold, (ii) governance quorums are f\ngov\n-resilient, and (iii) at least\none enclave is uncompromised, then every op∈ Ops executes within bounded time\nτ :\n∀op∈ Ops, ∃τ ≥ 0 : Exec(c, op) =⊤.\nProof Sketch. Progress follows from three guarantees: (1) the MPC KMS\nensures k\nc\nis always recoverable under threshold availability; (2) Γ encodes quo-\nrum rules that eventually relax after timeout ∆t, ensuring some subset S satisfies\nΓ (S) = ⊤; (3) migration μ allows any enclave to re-host σ\nc\n, preventing vendor\nlock-in or enclave failure from blocking execution. Algorithm ?? formalizes re-\ncovery and execution under these assumptions.\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets11\nAlgorithm 1 RecoverAndExecute(c, op)\n1: Verify enclave e attestation Q\ne\nagainst R.\n2: Derive k\nc\n← Derive(K,c); decrypt σ\nc\n.\n3: if CompromiseDetected(e\n′\n) then\n4:Rotate k\nc\nand re-encrypt σ\nc\n.\n5: end if\n6: Ensure Γ (S) =⊤ for S ⊆P(c).\n7: Execute op; append to H.\nKey Properties. (1) Portability: any attested enclave can recover σ\nc\n, in-\ndependent of vendor; (2) Monotonic Recovery: recovery steps form ρ : S → S\nwith ρ(s)⪰ s; (3) Domain Continuity: certificates remain bound to R(c) under\nmigration μ(c), preventing hijack or replay.\nImplementation details of container orchestration, attestation, and KMS pro-\ntocols are given in Appendix ??.\n5 Practical Implementations\n5.1 Prototype Implementations\nTo demonstrate feasibility, we have implemented a prototype of PASS that cap-\ntures the core architectural components.\n5\nThe prototype consists of:\n– Provenanced Access Model, the core PASS architecture outlined in Sec-\ntion ?? with the Inbox-Outbox structure, asset ledgers, and provenanced\nrule as a Rust executable.\n– Web Application Frontend, an AWS-hosted Typescript interface that\nallows users to deposit assets, initiate internal transfers, generate on-chain\ntransactions, and sign arbitrary messages on Ethereum Sepolia testnet.\n6\n– Multi-vendor TEE deployment, we deploy the PASS enclave executable\nin both AWS Nitro Enclaves and Intel TDX with the dstack framework.\nWe evaluate these two enclave deployments as complementary deployment\npaths, each with distinct tradeoffs.\nAWS Nitro Enclaves. In this design, PASS runs inside a Nitro enclave in the\nAWS cloud. The enclave executes the Inbox–Outbox logic, enforces provenance\nchecks, and signs transactions, while the provenance ledger is stored externally.\nNitro’s attestation and AWS integration simplify deployment, but reliance on a\nsingle vendor limits portability and concentrates trust. As a result, some guaran-\ntees of PASS, particularly liveness and asset accessibility, may be weaker under\nthis model.\n5\nPrototype can be found here: https://github.com/jayyu23/pass-wallet-app\n6\nWeb application: https://pass-wallet.jayyu.xyz/\n12J. Yu\nIntel TDX with dstack. dstack provides a portable, open-source runtime for\nTEEs across diverse hardware. PASS can be deployed on enclaves run by decen-\ntralized operators, with key material secured via MPC-based key management.\nBoth Inbox–Outbox logic and the provenance ledger execute inside dstack, pre-\nserving the full security properties of Section ?? and reducing vendor lock-in.\nThe tradeoff is added governance complexity over operator authorization and\npolicy enforcement.\nBlockchain Connectivity. To ensure reliable blockchain interaction, PASS inte-\ngrates Helios [?], a consensus-verified light client, within the TEE. Rather than\ntrusting external RPC endpoints, Helios cryptographically verifies all blockchain\ndata against consensus layer proofs before serving it locally. This approach elimi-\nnates the trust assumptions typically associated with centralized RPC providers\nwhile maintaining the performance characteristics necessary for real-time wallet\noperations. The light client architecture ensures that PASS’s Outbox mecha-\nnism operates on verified blockchain state, preserving the security guarantees\neven when external network providers are compromised or unreliable.\n5.2 Performance Benchmarks\nTo evaluate PASS, we benchmarked both AWS Nitro Enclaves and Intel TDX\nbackends across common operations: balance queries, transfers, withdrawals,\nclaims, wallet creation, provenance queries, and an end-to-end workflow. Each\noperation was run 100 times over 10 trials per environment, measuring through-\nput in ops/sec. Both environments used identical 4-core, 2.5 GHz, 16 GB VMs\nto ensure fair comparison. Table ?? summarizes our results, with full details\navailable in Appendix ??.\nFig. 4. Internal PASS operation throughput (ops/sec) across AWS Nitro Enclaves\nand Intel TDX. All operations are in-memory state changes within the TEE with no\nblockchain interaction. Each value represents the average of 100 operations repeated\n10 times per environment.\nOperationAWS Nitro Intel TDX\nWallet Creation6,53114,970\nAccount Balance Queries530,943935,428\nInbox-to-Subaccount Claims14,85633,064\nInternal Subaccount Transfers32,95371,292\nWithdrawal Request Creation18,29139,702\nEnd-to-End Workflow\n7\n35,66378,433\nTransaction History Queries3,7577,685\nMulti-threaded Operations (5 threads)32,18955,124\nLarge Dataset Processing481724\nThe observed performance differences between AWS Nitro Enclaves and In-\ntel TDX primarily stem from their distinct hardware architectures. AWS Nitro\nEnclaves employ a disaggregated system design, where the host server and the\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets13\nTEE hardware are physically separated. Communication between the host and\nthe enclave occurs via vsock, and the enclave itself runs on a dedicated, lower-\nperformance coprocessor. In contrast, Intel TDX leverages a special instruction\nset to provide enclave functionality directly on the main processor, eliminating\nthe need for a separate coprocessor and avoiding the overhead of data transfer\nbetween disparate components. As a result, Intel TDX is able to deliver sig-\nnificantly higher throughput for in-enclave operations compared to AWS Nitro\nEnclaves, as reflected in our benchmark results.\nThese preliminary benchmarks show that both Nitro and TDX backends can\nsustain high throughput for critical wallet operations, confirming that PASS is\npractical for real-world deployment.\nComparison with Related Work. To contextualize our performance results, we\ncompare PASS with other TEE-based blockchain systems and traditional custo-\ndial solutions.\nLiquefaction. The Liquefaction system [?] demonstrates significantly higher\nlatencies than PASS due to its reliance on blockchain oracles for transaction\nvalidation. Liquefaction exhibits mean latencies of 49 seconds for latest block\nconfirmation, 648.7 seconds ( 11 minutes) for justified confirmation, and 1,036.9\nseconds ( 17 minutes) for finalized confirmation. These delays stem from Liq-\nuefaction’s architectural requirement to wait for block confirmations on an ex-\nternal TEE-blockchain oracle before authorizing subsequent operations. In con-\ntrast, PASS performs all operations within the off-chain TEE worker without\nblockchain dependencies, achieving sub-millisecond latencies for internal opera-\ntions (e.g., 14,856-33,064 ops/sec for claims, 32,953-71,292 ops/sec for transfers).\nThis fundamental architectural difference—off-chain TEE computation versus\nblockchain-dependent validation—enables PASS to provide near-instantaneous\nuser experiences while maintaining strong security guarantees.\nTraditional Custodians. While custodial solutions do not publish detailed\nperformance benchmarks, prior work demonstrates that TEE overhead typically\nintroduces only 5-7% performance degradation compared to native execution [?].\nGiven that modern custodial systems can process thousands of operations per\nsecond, TEE-based solutions like PASS should achieve comparable throughput\nwhile providing significantly stronger security properties. Our benchmark results\nsupport this expectation, with PASS demonstrating high-throughput operation\nprocessing that would be suitable for production custodial workloads, while offer-\ning the additional benefits of cryptographic auditability, decentralized operation,\nand reduced single points of failure.\nFurther evaluation of latency distributions, concurrency scaling, and memory\nfootprint is left for future work.\n6 Applications\nPASS is a powerful primitive that enables several classes of applications across\nidentity scoping, enterprise settings, and scalability concerns.\n14J. Yu\nCategoryApplicationContextPASS Enables\nIdentities\nAI Agent\nWallets\nAutonomous agents\ninteracting with crypto\nassets [?] need signing\naccess guardrails.\nScoped subaccounts grant limited\nbalances and domain signing rights,\nenabling safe delegation without\nexposing the root key\nDAO Voting\nDelegation\nDAOs depend on\naddress-based voting and\nproxy delegation [?].\nFine-grained voting rights delegation\nthat remains auditable via provenance;\ndelegation can be restricted to specific\nDApps or domains.\nSubdomain\nProfile Pages\nOrganizations delegate\ncontrol over web or\norganizational\nsubdomains (e.g.,\nmyprofile.company.com) to\nindividuals or teams.\nEach subaccount holds scoped signing\nrights for its assigned subdomain, with\nbalances and authorities tracked in\nprovenance under a shared\norganizational identity.\nEnterprise\nPrivate PayrollOn-chain payrolls reveal\nsensitive salary\ninformation [?].\nSalary distribution through internal\ngasless transfers with audit logs;\nexternal payouts are periodically\nbatched via the Outbox.\nCompliant Org\nWallets\nFirms must maintain\ninternal accountability\nand BSA\nrecordkeeping [?].\nDepartmental and individual\nsubaccounts with explicit budgets;\nprovenance ensures regulator-grade\nauditability without exposing internal\nflows.\nPrivate B2B\nNetting\nSupply-chain and\nrecurring multi-party\npayments require\nconfidentiality.\nVendor subaccounts allow internal\nnetting of obligations, with PASS\nacting as a temporary clearing house.\nOnly net settlements exit via the\nOutbox, reducing leakage while\nretaining auditability.\nAudit / Proof\nExplorer\nRegulators and auditors\nrequire verifiable yet\nprivacy-preserving\ntransparency.\nPublic proofs derived from the\nprovenance log H, enabling compliance\nchecks and audits without disclosing\ninternal ledger state.\nScalability\nGasless\nAppchain\nHigh-throughput\napplications (e.g., trading\nengines) face prohibitive\ngas costs on-chain.\nInternalize application logic as\nsubaccount transitions; Outbox emits\nverifiable batch settlements, ensuring\ncorrectness with minimal gas.\nCross-chain\nBridges\nBridges require strong\ncustody and coordination\nof operators [?].\nInbox-Outbox abstractions enforce\nprovenance across domains; FIFO\nnonce handling prevents replay or race\nconditions.\nL2 ComposabilityRollups and L2s fragment\nassets and user\nexperience [?].\nTreat each L2 as a scoped subaccount;\nmaintain private balance transfers\ninternally, and settle externally only\nwhen crossing domains.\nFig. 5. Applications of PASS across identities, enterprise settings, and scalability so-\nlutions. We highlight a flagship application in each category.\nIdentities and Agent Delegation. PASS’s multi-user subaccount model\nallows for flexible permission scopes. As AI agents start managing crypto as-\nsets, there is a need to constrain their access. An AI agent could be given a\nsub-account that only holds limited funds or certain asset types. The AI can op-\nerate freely within those bounds, but cannot exceed its allotted assets or misuse\nother wallet assets. If compromised, damage is capped to its sub-account. This\nis much safer than giving AI the keys to an entire wallet. Similarly, PASS can\nallow for delegation-based DAO voting by giving the delegate signature rights\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets15\nover particular voting DApps, without giving access to actually transfer the as-\nsets. Subaccounts can also get scoped signing rights over particular enterprise\nsubdomains.\nEnterprise Applications. PASS’s features of internal privacy, in-built per-\nmissioning, and provenance auditability make it uniquely suited for enterprise\napplciations. A flagship use case for PASS is private payroll. On-chain salary pay-\nments today risk exposing sensitive information such as individual compensation,\ndepartmental budgets, or timing patterns. With PASS, salaries are distributed\ninternally through gasless subaccount transfers, leaving a clear provenance log for\nauditability, but without revealing per-employee details on-chain. Only periodic,\non-demand payouts exit via the Outbox, ensuring both regulatory accountability\nand privacy for internal flows. Beyond payroll, PASS supports other enterprise\nneeds: compliant organizational wallets with departmental subaccounts that en-\nforce explicit budgets, private B2B netting where vendors settle obligations inter-\nnally and only net payments leave the wallet, and auditable proof explorers that\nprovide regulators with verifiable, privacy-preserving compliance proofs derived\nfrom the provenance log.\nScalability Solutions. PASS also supports scaling use cases where on-chain\ncosts or coordination overhead make existing approaches impractical. A flagship\nexample is gasless appchains, such as for Central Limit Orderbooks (CLOBs).\nHigh-throughput applications such as CLOBs cannot afford per-transaction gas\nfees, but PASS internalizes application logic as private subaccount transitions.\nThe Outbox then emits verifiable batch settlements with minimal gas, preserv-\ning correctness while keeping costs predictable. Beyond appchains, PASS enables\ncross-chain bridges by enforcing provenance across domains and sequencing with-\ndrawals via a FIFO nonce to prevent replay or race conditions, and supports L2\ncomposability by treating each rollup or sidechain as a scoped subaccount, main-\ntaining private balance transfers internally and settling externally only when\ncrossing domains.\n7 Discussion and Future Work\n7.1 Composability and InterPASS Transactions\nWhile PASS provides privacy and provenance guarantees for a single wallet in-\nstance, an important question is how multiple PASS wallets may interact. This\nis important in supply-chain use cases where each PASS represents a single com-\npany in the supply chain.\nTrivially, PASS A can send an on-chain transaction from its Outbox to PASS\nB’s EOA account, and this will land in the Inbox of PASS B, ready to claim.\nHowever, this undermines the privacy guarantees that PASS offers at the EOA\nlevel, and is undesirable in cases where inter-organizational asset transfers con-\ntain sensitive information, such as order details.\nWe propose a non-trivial approach inspired by cross-Payment Channel Net-\nwork (PCN) protocols such as XTransfer [?]. We can treat each PASS instance\n16J. Yu\nakin to a PCN hub node, with state L and transaction history H. As with\nXTransfer, we can assume a star topology of PASS nodes, with a central PASS\nHub in communciation with all PASS nodes. The PASS Hub will aggregate all\nInterPASS transactions T := {(a\ni\n,x\ni\n,s\ni\n,r\ni\n)}\nn\ni=1\n, where (a\ni\n,x\ni\n,s\ni\n,r\ni\n) represent\nthe asset, amount, sender, and receiver, each signed by the s\ni\nOutbox.\nThe Hub aggregates these signed payment intents, computes a netted settle-\nment plan S, and coordinates a secure multi-party update protocol to commit\nthe resulting balances, similar to Thora [?]. In the optimistic case, this process\ncompletes entirely off-chain, and each participant’s balance is updated in the\nPASS ledger without revealing the underlying transaction graph. If a dispute or\nfailure occurs, any participant may trigger an on-chain enforcement transaction\nthat finalizes S atomically via the direct transfer mechanism, thus guaranteeing\nsafety.\nThis approach leverages PASS ’s provenance and state design to make each\ninstance an atomic node in PCN-style systems like X-Transfer. Here, we outline\nhow PASS Hubs can enable confidential, auditable cross-organization transfers,\nwhile full formal specification and protocol implementation is deferred for future\nwork.\n7.2 Instantiation on zkVM\nThe PASS design presented in this paper relies primarily on trusted execution\nenvironments (TEEs) to enforce provenance rules, where the enclave isolates the\nglobal secret key and mediates all access through the Inbox–Outbox mechanism.\nWhile TEEs provide strong privacy and efficiency guarantees, their trust model\ndepends on hardware attestation and vendor integrity, which may be insufficient\nin regulatory or adversarial settings that demand independent verification.\nzkVMs provide a natural next step by enabling provenance-based control to\nbe verified through succinct cryptographic proofs rather than trusted hardware.\nBy batching transitions over L, H, I, and O and producing a proof π, a mini-\nmalist verifier contract can update commitments and enforce outbox execution\nwhile preserving privacy. This direction complements the Chainless stack ar-\nchitecture [?], suggesting a path toward modular, interoperable deployments of\nPASS with stronger external verifiability and broader applicability.\n8 Conclusion\nWe presented PASS, a Provenanced Access Subaccount System, as a new wallet\narchitecture that enforces access by provenance rather than by identity or role.\nThe Inbox–Outbox mechanism ensures all assets have a verifiable lineage, while\ninternal transfers remain private and indistinguishable from a standard EOA\naccount.\nOur contributions are threefold: (i) a formal model in Lean 4 proving pri-\nvacy, accessibility, and provenance integrity; (ii) a working prototype with en-\nclave backends on AWS Nitro Enclaves and Intel TDX via dstack, integrated\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets17\nwith WalletConnect; and (iii) initial benchmarks showing the feasibility of high-\nthroughput operation. These results demonstrate that provenance-based control\ncan be realized today with mainstream blockchain tools.\nLooking forward, richer evaluations across multi-vendor TEEs, integration\nwith zero-knowledge VMs, and exploration of organizational and agent-based\ncustody are promising directions. By combining rigorous formal guarantees with\ndeployable prototypes, PASS advances the design space between strict self-\ncustody and flexible shared access, offering a path toward practical, privacy-\npreserving wallet security.\nA Formal Verification\nWe consider the formal model introduced in Section ?? of PASS as a state\nmachine in Lean4. Our goal is to prove that, under the PASS design, several\ncritical security properties always hold. We outline these properties and our\napproach to verifying them.\nA.1 Property: Privacy of Internal Transfers\nIn the PASS design, the InternalTransfer operation updates only the off-chain\nledgerL and the provenance historyH. It never modifies the OutboxO, meaning\nthere is no on-chain transaction triggered by an internal transfer. Consequently,\nexternal observers see no change in on-chain state. We formalize this by consid-\nering the on-chain view that an external party has for a given PASS Wallet. We\ncan model this visible on-chain state as a triple:\nW\npub\n=\n\u0000\npk, O, A\n\u0001\n,\nwhere:\npk is the externally owned account (EOA) address,\nO = (T,ν) is the external view of the outbox, where T is a list of enqueued\ntransactions and ν is a nonce,\nA is the external view of the Asset ledgerL, containing a list of asset entries,\neach of the form (α,x) with a unique identifier α and total balance x.\nExternal Trace. The external trace of a PassAccount state W\npub\nis the list of\nexternally visible actions, obtained by mapping each transaction in the outbox\nT to an on-chain action:\nexternalTrace(W\npub\n) =\n\b\noutboxTx(t) | t∈ T\n\t\n.\nNo internal transfers appear in externalTrace(·).\n18J. Yu\nStates That Differ Only by Internal Transfers. We say that two PassAccount\nstates W\n1\n= (pk\n1\n,O\n1\n,A\n1\n) and W\n2\n= (pk\n2\n,O\n2\n,A\n2\n) differ only by internal trans-\nfers if:\n1. pk\n1\n= pk\n2\n,\n2. O\n1\n= O\n2\n(i.e. both the list of outbox transactions and the nonce are the\nsame),\n3. For every asset identifier α, the total balance of that asset in A\n1\nequals the\ntotal balance of the same asset in A\n2\n.\nLetting getAsset(W,α) return the asset α within state W or ⊥, we require ∀α:\ntotalBalance\n\u0000\ngetAsset(W\n1\n,α)\n\u0001\n= totalBalance\n\u0000\ngetAsset(W\n2\n,α)\n\u0001\n.\nTheorem 2 (Privacy of Internal Transfers). If two PassAccount states W\n1\nand W\n2\ndiffer only by internal transfers, then their externally visible traces are\nidentical:\nexternalTrace(W\n1\n) = externalTrace(W\n2\n).\nProof. By assumption, O\n1\n= O\n2\n. Hence both states have the same outbox trans-\naction list T . Since\nexternalTrace(W\ni\n) = map\n\u0000\noutboxTx, T\ni\n\u0001\nfor i∈{1, 2},\nand T\n1\n= T\n2\n, it follows that externalTrace(W\n1\n) and externalTrace(W\n2\n) are iden-\ntical.\nThus, any sequence of purely internal transfers, changing only the private ledger\nL in PASS, is invisible to an external observer, preserving the privacy of how\nassets move within the wallet.\nA corollary of this Internal Transfer property is that a PASS account is\nindistinguishable from a regular EOA account.\nCorollary 1 (Indistinguishability from EOA). Let W\npass\nbe a PASS state\nthat (i) has the same public key pk, (ii) the same outbox, including nonce and\ntransaction list, and (iii) the same total balances of each asset as a reference\nEOA state W\neoa\n. Then\nexternalTrace(W\npass\n) = externalTrace(W\neoa\n).\nIn particular, an external observer cannot distinguish W\npass\nfrom W\neoa\n.\nProof. By assumption, the only potential differences betweenW\npass\nandW\neoa\nlie\nin internal ledger details. From Theorem 1, such internal transfers do not affect\nthe externally visible outbox transactions or total on-chain balances. Thus, their\nexternal traces coincide, and W\npass\nis indistinguishable from W\neoa\n.\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets19\nA.2 Property: Asset Accessibility\nIn addition to keeping internal transactions private, PASS should ensure that for\nevery asset in the system, there exists some sub-account that can access it and\nwithdraw it from the system. This prevents a situation where funds get ”stuck”\nwithout any reachable key or policy to move them. We define asset accessibility\nas follows:\nTheorem 3 (Asset Accessibility). For any PASS account W and asset iden-\ntified by α, there exists a list of addresses L such that:\n1. For every address u∈ L, the user can access their full balance:\ncheckBalance(s,α,u, balance(u)) = true\n2. The sum of all accessible balances equals the total balance of the asset:\nX\nu∈L\nL[u][α] = totalBalance(α)\nProof. We construct L as the set of all addresses with non-zero balances in the\nbalance map for α:\nL ={u|L[u][α] > 0}\nFor the first property, given any u∈ L, the definition of checkBalance verifies\nif the user has sufficient balance for the specified amount. When checking against\nthe user’s own balance, this is trivially satisfied since L[u][α]≥L[u][α] for all u.\nFor the second property, we observe that totalBalance is defined as the sum\nof all balances in the asset’s balance map:\ntotalBalance(α) =\nX\nu∈L\nL[u][α]\nBy construction, L contains the only nonzero values u∈L, so:\nX\nu∈L\nL[u][α] = totalBalance(α)\nTherefore, both properties hold for our constructed list L.\nWe can prove a similar trait for General Signable Messages, showing that for\nany inbound GSM, there is some subaccount signer that has access to it.\nTheorem 4 (GSM Accessibility). For any GSM and domain, there exists a\nuser with signing access to that domain.\nProof. For any domain d, we can directly construct a user u who has signing\naccess to d as follows:\nu = getSigner(d)\nBy definition, getSigner returns either:\n– A specifically assigned signer if one exists in the domain-address map, or\n– The default signer otherwise\nTherefore, every domain is guaranteed to have at least one user with signing\naccess, ensuring no GSM domain becomes inaccessible.\n20J. Yu\nA.3 Property: Provenance Integrity\nProvenance integrity specifies that every asset held by any sub-account in PASS\nmust have an origin traceable to an external deposit into the Inbox. At any\nstate of the system, for each asset entry in a sub-account’s balance, we can find\na sequence of internal transfers that leads back to an Inbox deposit from an\nexternal address. This property ensures no sub-account can conjure funds from\nnothing, such as through double-spending or inflation within the system, and\nthat the internal ledger is consistent with on-chain reality. In Lean, we model\nthe state of the PASS wallet including Inbox, Outbox, and all sub-accounts and\nprove an invariant that whenever a sub-account has x units of asset α, the global\nstate contains a record of at least x units of α having been deposited, minus any\nthat have been withdrawn.\nTheorem 5 (Provenance Integrity).\nFor any PASS account S =\n\u0000\npk, sk,ν,I,O,L,H\n\u0001\nand any asset α, the total\namount of α held across all subaccounts can never exceed the total amount of\nexternal deposits (minus any that have already been withdrawn). Formally,\nX\nu∈U\nL[u][α] ≤ externalDeposits(α),\nwhere U is the set of subaccounts in the system, and externalDeposits(α) is\nthe net total of asset α that has been introduced into the wallet from outside\naddresses, recorded in the inbox I.\nProof. We model the system’s state (pk, sk,ν,I,O,L,H) as in Figure ??, includ-\ning the Inbox I, Outbox O, and the internal ledger L. We define a provenance\nrecord P (α,u) that captures the total amount of asset α subaccount u is autho-\nrized to hold, based on Inbox claims and internal transfers.\nBase Case: Immediately after CreatePassWallet, no assets have been de-\nposited, and no subaccount balances exist:\n∀u, L[u][α] = 0, ∀α, externalDeposits(α) = 0.\nHence,\nX\nu∈U\nL[u][α] = 0 ≤ 0 = externalDeposits(α).\nInductive Step: Assume the invariant holds after n− 1 operations. We prove it\nremains valid after the nth operation, for each possible type of operation:\n(1) External Deposit: Suppose an amount x of asset α is deposited into the\nwallet:\nexternalDeposits(α) ← externalDeposits(α) + x.\nNo subaccount balances L[u][α] change. Thus, the left side of our inequality\n(sum of subaccount balances) is unchanged, while the right side strictly\nincreases by x, so the invariant continues to hold.\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets21\n(2) Inbox Claim: If subaccount u claims amount x of asset α from the Inbox\nI:\nL[u][α] ← L[u][α] + x, P (α,u) ← P (α,u) + x.\nSince x was already accounted for in externalDeposits(α) (but not yet allo-\ncated to any subaccount), the total subaccount balances remain≤ externalDeposits(α).\n(3) Internal Transfer: If subaccount u\n1\ntransfers x of α to subaccount u\n2\n:\nL[u\n1\n][α] ← L[u\n1\n][α]− x, L[u\n2\n][α] ← L[u\n2\n][α] + x,\nand P (α,u\n2\n) increases by x. Because the sum of all subaccount balances\ndoes not change, our invariant is preserved.\n(4) Withdrawal: If subaccount u withdraws x of α:\nL[u][α] ← L[u][α]− x,\nwhich reduces the total subaccount balances. Since externalDeposits(α)\nremains unchanged (assets have simply exited the wallet), the inequality still\nholds.\nThus, by induction over all possible operations,\nX\nu∈U\nL[u][α] ≤ externalDeposits(α)\nfor every reachable state. No subaccount can create new assets out of nothing,\nand all assets in the system are fully accounted for by provenanced deposits.\nB Dstack Architecture and Execution Model\nB.1 Component Overview\n– Dstack-OS: Minimal Linux-based VM image with a verifiable boot chain.\nMeasures bootloader, kernel, root filesystem (RootFs) via RTMR registers.\nIntegrates dm-verity for data integrity and monotonic counters for anti-\nrollback.\n– Dstack-KMS: Blockchain-governed MPC network for key derivation and\nrotation. Provides:\nk\nc\n= HMAC\nk\nroot\n(c\nid\n),\nk\nTLS\n= ECDSA(k\nroot\n).\nRotation is triggered via governance (t-of-n threshold).\n– Dstack-Gateway/Ingress: TLS termination inside TEEs, ZT-TLS bind-\ning X\nc\nto R(c), enabling verifiable HTTPS ingress.\n22J. Yu\nB.2 Governance Layer\nTwo contracts form the trust base:\n– KmsAuth: Global registry of KMS nodes and application digests.\n– AppAuth: Per-application contract specifying quorum rules, allowed image\nhashes, and authorized enclaves.\nB.3 Workflow Phases\n1. Attestation: Enclave e produces quote Q\ne\n; verified against R.\n2. Secret Provisioning: MPC nodes compute k\nc\n, release to e if Q\ne\nis valid.\n3. Container Launch: Dstack-OS mounts RootFs, decrypts state σ\nc\nwith k\nc\n.\n4. Ingress Binding: TLS certificate X\nc\ngenerated inside e; bound to R(c).\n5. Audit Logging: Migration, key rotation, and governance events appended\nto H.\nB.4 Fault Tolerance\n– Vendor failure: μ enables re-deployment across Intel/AMD TEEs.\n– KMS compromise: key rotation via MPC thresholds restores forward/backward\nsecrecy.\n– Governance deadlock: ∆t fallback in Γ ensures quorum reduction and progress.\nB.5 Liveness Proof Sketch\nCombining MPC-based key recovery, quorum fallback, and portable containers\nyields:\n∀op∈O\nc\n,Pr[Exec(c, op) =⊤] = 1\nunder assumptions of f -resilient MPC nodes and at least one uncompromised\nTEE instance.\nC Detailed Benchmark Results\nThis appendix provides comprehensive benchmark statistics for both AWS Nitro\nEnclaves and Intel TDX environments. All operations are internal PASS state\nchanges that occur within the TEE with no blockchain network interaction.\nEach operation was executed 100 times per trial, with 10 independent trials\nper environment. The tables below show summary statistics including mean,\nstandard deviation, and range.\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets23\nTable 1. AWS Nitro Enclaves benchmark statistics (ops/sec) across 10 trials\nOperationMean Std Dev Min Max\nWallet Creation6,5315315,4467,042\nAccount Balance Queries530,943675 530,216 531,915\nInbox-to-Subaccount Claims14,856476 14,326 15,504\nInternal Subaccount Transfers32,9531,322 31,447 35,088\nWithdrawal Request Creation18,2911,254 15,873 19,608\nEnd-to-End Workflow35,6636,234 21,739 40,650\nTransaction History Queries3,757453,6503,802\nMulti-threaded Operations (5 threads) 32,189884 31,200 34,364\nLarge Dataset Processing48113467497\nTable 2. Phala dStack benchmark statistics (ops/sec) across 10 trials\nOperationMean Std Dev Min Max\nWallet Creation14,9704,6528,69624,390\nAccount Balance Queries935,428338,450 383,142 1,470,588\nInbox-to-Subaccount Claims33,0645,197 25,44541,667\nInternal Subaccount Transfers71,29217,623 47,170 101,010\nWithdrawal Request Creation39,7027,434 29,15551,813\nEnd-to-End Workflow78,43317,403 59,524 110,497\nTransaction History Queries7,6858726,4528,929\nMulti-threaded Operations (5 threads) 55,12416,744 28,32981,301\nLarge Dataset Processing72481636893\nC.1 AWS Nitro Enclaves Results\nC.2 Intel TDX Results\nC.3 Performance Analysis\nThe statistical analysis reveals several key insights about PASS’s internal oper-\nation performance:\n– Performance Consistency: AWS Nitro Enclaves demonstrate superior\nconsistency with lower standard deviations across all operations. The co-\nefficient of variation ranges from 0.1% (Account Balance Queries) to 17.5%\n(End-to-End Workflow).\n– Peak Performance: Intel TDX achieves higher mean throughput but with\nsignificantly greater variance. Standard deviations are 10-500x larger than\nNitro, indicating less predictable performance.\n– Production Considerations: These internal operation benchmarks demon-\nstrate PASS’s ability to handle thousands of wallet operations per second\nwithin the TEE, with the actual deployment bottleneck being blockchain\ntransaction submission rather than internal processing.\nThe statistical summary confirms that both platforms support practical PASS\ndeployment, with Nitro offering predictable performance and Intel TDX provid-\ning higher peak throughput at the cost of consistency.\n24J. Yu\nD Design Extensions\nD.1 Composability and InterPASS Transactions\nWhile PASS provides privacy and provenance guarantees for a single wallet in-\nstance, an important question is how multiple PASS wallets may interact. This\nis important in supply-chain use cases where each PASS represents a single com-\npany in the supply chain.\nTrivially, PASS A can send an on-chain transaction from its Outbox to PASS\nB’s EOA account, and this will land in the Inbox of PASS B, ready to claim.\nHowever, this undermines the privacy guarantees that PASS offers at the EOA\nlevel, and is undesirable in cases where inter-organizational asset transfers con-\ntain sensitive information, such as order details.\nWe propose a non-trivial approach inspired by cross-Payment Channel Net-\nwork (PCN) protocols such as XTransfer [?]. We can treat each PASS instance\nakin to a PCN hub node, with state L and transaction history H. As with\nXTransfer, we can assume a star topology of PASS nodes, with a central PASS\nHub in communciation with all PASS nodes. The PASS Hub will aggregate all\nInterPASS transactions T := {(a\ni\n,x\ni\n,s\ni\n,r\ni\n)}\nn\ni=1\n, where (a\ni\n,x\ni\n,s\ni\n,r\ni\n) represent\nthe asset, amount, sender, and receiver, each signed by the s\ni\nOutbox.\nThe Hub aggregates these signed payment intents, computes a netted settle-\nment plan S, and coordinates a secure multi-party update protocol to commit\nthe resulting balances, similar to Thora [?]. In the optimistic case, this process\ncompletes entirely off-chain, and each participant’s balance is updated in the\nPASS ledger without revealing the underlying transaction graph. If a dispute or\nfailure occurs, any participant may trigger an on-chain enforcement transaction\nthat finalizes S atomically via the direct transfer mechanism, thus guaranteeing\nsafety.\nThis approach leverages PASS ’s provenance and state design to make each\ninstance an atomic node in PCN-style systems like X-Transfer. Here, we outline\nhow PASS Hubs can enable confidential, auditable cross-organization transfers,\nwhile full formal specification and protocol implementation is deferred for future\nwork.\nD.2 Instantiation on zkVM\nThe design of PASS presented thus far relies on trusted execution environments\n(TEEs) such as AWS Nitro or Intel TDX to enforce provenance-based control.\nTEEs provide strong isolation and efficient execution, allowing internal transfers\nto remain private while ensuring that every outbox action has a verifiable lin-\neage. However, the trust model is anchored in hardware attestation: users and\nregulators must accept that the enclave executes the correct code as claimed.\nWhile sufficient for many organizational custody scenarios, this assumption lim-\nits transparency and long-term auditability. To address this limitation, we ex-\nplore an alternative instantiation of PASS in a zero-knowledge virtual machine\n(zkVM), replacing hardware trust with cryptographic proofs of correctness.\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets25\nZero-knowledge virtual machines (zkVMs) provide a proving environment in\nwhich arbitrary state machines can run with strong correctness guarantees [?].\nBy producing a succinct proof π of execution, zkVMs offer integrity assurances\nsimilar to TEEs but without reliance on vendor-specific hardware. This shift\nmakes zkVMs particularly suitable for contexts such as institutional custody,\nmulti-party supply chains, or inter-organizational accounting where external ver-\nifiability and regulator-grade auditability are paramount.\nIn a zkVM instantiation of PASS, the execution pipeline mirrors the enclave-\nbased design but replaces attestation with cryptographic proofs. The process\nproceeds in four stages:\n1. Batch formation. Transaction requests (claims, transfers, withdrawals) are\nfirst queued off-chain into a batch.\n2. zkVM execution. The zkVM program takes as private inputs: (i) the prior\nbatch’s commitments of the ledger L and provenance log H, (ii) the queued\ntransitions, including inbox I deposits and outbox O withdrawals, and (iii)\nthe proposed new commitments (L\n′\n,H\n′\n). Inside the zkVM, the transition\nfunction is replayed deterministically: starting from the previous roots, ap-\nplying all operations in sequence, updating balances and provenance entries,\nand checking consistency constraints.\n3. Proof generation. The zkVM outputs a succinct proof π certifying that the\nclaimed new roots (L\n′\n,H\n′\n) are correct with respect to the given transition\nset.\n4. On-chain verification. A minimalist verifier contract validates π, updates\nthe recorded commitments, and enforces any pending outbox operations.\nThis ensures that every external action has a verifiable provenance path\nwhile internal transfers remain private.\nCompared to TEEs, zkVMs strengthen the verifiability model by eliminat-\ning hardware trust assumptions, but incur higher computational and financial\ncosts due to proof generation and on-chain verification. Batching amortizes these\ncosts, raising open research questions about optimal batch sizes, data availabil-\nity strategies, and proof system selection. zkVM backends such as Risc0, SP1,\nor Plonky3 offer different tradeoffs in proof size, verification cost, and latency.\nHybrid deployments are also possible: TEEs can serve as fast-path executors for\nintra-day operations, with zkVM proofs generated periodically to provide cryp-\ntographic audit trails. This hybrid pattern resembles optimistic rollups, where\nfast execution is combined with verifiable settlement.\nFinally, this instantiation aligns closely with the Chainless stack architec-\nture [?], which emphasizes the separation of execution, trust, bridging, and set-\ntlement. In this view, zkVM proofs naturally inhabit the execution and trust\nlayers, Inbox/Outbox commitments integrate with bridging, and the verifier\ncontract finalizes settlement. This layered design opens the door to modular,\ninteroperable deployments of PASS across heterogeneous chains and domains.\nFull formal specification, performance benchmarking, and exploration of hybrid\nzkVM–TEE implementations remain important avenues for future work.\n26J. Yu\nFig. 6. PASS instantiation inside a zkVM: Inbox I and Outbox O transitions are\napplied to the Ledger L and Provenance H, producing new state commitments. The\nzkVM outputs a proof π, which the on-chain verifier checks before updating roots and\nenforcing outbox operations."
}
]
},
{
"role": "assistant",
"content": "To address the question—**why existing works cannot satisfy the three use cases in the Introduction, and why a provenance- and TEE-based solution (PASS) is superior**—we must examine both the requirements of the use cases and the limitations inherent in the prevailing wallet architectures, as articulated in the Introduction and Background sections.\n\n---\n\n## 1. Why Existing Works Cannot Satisfy the Three Use Cases\n\nThe three use cases from the Introduction are:\n\n1. **AI and Smart Agent Transactions**: AI agents managing assets require bounded authority and access guardrails.\n2. **Enterprise Payroll Privacy**: Organizations need to distribute salaries and budgets without revealing sensitive on-chain details.\n3. **Consumer-grade Central Limit Order Books (CLOBs)**: Real-time, high-throughput trading requires low gas costs and minimal user key management.\n\nLet us analyze how mainstream solutions fall short for each.\n\n### a. **EOAs (Externally Owned Accounts)**\n- **Control Model**: Single private key = total, unilateral control.\n- **Limitations**:\n - _AI & Smart Agents_: No way to delegate or restrict authority; giving an AI the private key grants it full, irrevocable power.\n - _Payroll Privacy_: All transfers are public, so salary disbursements are visible on-chain.\n - _CLOBs_: Every action is a public, gas-consuming transaction; no support for high-frequency, low-latency trades or batch operations.\n\n### b. **Multisignature Wallets**\n- **Control Model**: t-of-n co-signers must approve each action.\n- **Limitations**:\n - _AI & Smart Agents_: No fine-grained or scoped delegation—either a key is part of the quorum or not; cannot limit by asset, amount, or domain.\n - _Payroll Privacy_: All actions and policies are publicly visible; internal logic is on-chain and auditable by anyone, leaking salary and budget flows.\n - _CLOBs_: High on-chain overhead for every trade due to multi-party signatures; not suitable for fast, gasless, internalized operations.\n\n### c. **Smart Contract Wallets (e.g., ERC-4337, Account Abstraction)**\n- **Control Model**: On-chain policy logic, programmable rules.\n- **Limitations**:\n - _AI & Smart Agents_: Policies are programmable but public; any delegation or restriction is visible and can be front-run or censored.\n - _Payroll Privacy_: Every policy execution is public and incurs gas; internal flows cannot be hidden.\n - _CLOBs_: On-chain execution is required for every action, leading to prohibitive gas costs and latency for high-frequency trading.\n\n### d. **Custodians (RBAC/ABAC Engines)**\n- **Control Model**: Off-chain access policies, custom APIs.\n- **Limitations**:\n - _AI & Smart Agents_: Custom policy languages proliferate; off-chain enforcement is opaque, and the custodian sees all internal activity.\n - _Payroll Privacy_: Custodian observes all internal flows; privacy is lost at the custodian, even if not on-chain.\n - _CLOBs_: Custodians may support batching, but users must trust the custodian’s infrastructure and APIs, introducing centralization and privacy risks.\n\n### e. **TEE-based Wallets (e.g., Liquefaction)**\n- **Control Model**: TEE holds the key and enforces sub-policies.\n- **Limitations**:\n - _AI & Smart Agents_: Liquefaction can enforce sub-policies, but the model is more complex (key encumbrance trees), and depends on specialized smart contracts (e.g., Oasis), limiting compatibility.\n - _Payroll Privacy_: Internal logic is hidden, but deployment is limited to specific chains (Oasis), reducing flexibility.\n - _CLOBs_: Throughput is lower due to reliance on blockchain oracles for validation, leading to significant latency.\n\n#### **Summary Table (from the paper):**\n\n| Model | Internal Privacy | On-chain Overhead | Compatibility | Granularity of Control |\n|---------------|-----------------|-------------------|--------------------|-----------------------------|\n| EOA | None | None | Native EOA | None |\n| Multisig | None | High | Contract-based | Symmetric, coarse |\n| Smart Wallet | None | Med–High | ERC-4337 required | Programmable, public |\n| Custodian | At custodian | None | API-mediated | Off-chain, opaque |\n| Liquefaction | Strong (TEE) | Medium | Oasis only | Policy trees, TEE-enforced |\n| **PASS** | Strong (TEE) | None | Native EOA + TEE | Provenance, fine-grained |\n\n---\n\n## 2. Why Provenance- and TEE-based Control (PASS) Is Superior\n\nPASS’s core architectural innovations directly address the above shortcomings:\n\n### a. **Provenance-based Control**\n- **Assets are controlled based on their custody history (provenance), not identity or roles.**\n- **Inbox–Outbox Model**: All external deposits are tracked in an Inbox; subaccounts must claim assets, establishing a clear lineage.\n- **Internal Transfers**: Are private (off-chain), fee-less, and invisible to external observers. Only withdrawals (Outbox) are on-chain, preserving privacy and minimizing gas.\n\n### b. **TEE Enforcement**\n- **Private key is held exclusively in the TEE**; never accessible to users or operators.\n- **All policy logic and provenance checks are enforced within the hardware-isolated enclave**, guaranteeing that even privileged insiders cannot subvert controls or observe internal flows.\n- **Remote attestation** allows external parties to verify that the correct code is running inside the enclave.\n\n### c. **Alignment with Use Cases**\n- _AI & Smart Agents_: Can be given sub-accounts with limited provenance-based authority (e.g., capped balances, domain-specific permissions), preventing overreach or misuse. If compromised, the AI can only affect its own subaccount.\n- _Payroll Privacy_: Salaries and departmental budgets are distributed internally, off-chain, with only aggregate payouts visible on-chain. Internal transfers are invisible, so sensitive information is not leaked.\n- _CLOBs_: High-frequency, gasless internal trading is possible, with only net settlements (batch withdrawals) posted on-chain. Users do not have to manage keys; the enclave orchestrates all actions securely.\n\n### d. **Compatibility and Efficiency**\n- **Native EOA Compatibility**: No need for custom smart contracts, chain modifications, or special APIs. Works with existing wallet infrastructure.\n- **No On-chain Overhead**: All internal logic is off-chain; only withdrawals incur gas, and those can be batched.\n- **High Throughput**: Benchmarks show sub-millisecond internal operations, far outpacing TEE-based systems that require blockchain oracles.\n\n### e. **Formal Guarantees**\n- **Proven security properties** (privacy, accessibility, provenance integrity) are formalized and machine-checked, not just informally claimed.\n- **Auditability**: Provenance logs can be selectively revealed for compliance or audit, without disclosing full internal state.\n\n---\n\n## 3. Logical Synthesis\n\n**Existing solutions are fundamentally limited by their control models:**\n- _Identity and role-based controls_ are awkward and brittle in blockchain’s exogenous asset environment, where assets are not natively tied to wallet identities.\n- _Public policy logic_ (smart contracts, multisigs) leaks sensitive information and incurs high gas costs.\n- _Custodial and off-chain solutions_ reintroduce centralization and erode privacy at the operator level.\n- _TEE-based approaches_ without provenance logic (or with complex policy trees) lack compatibility, efficiency, or formal guarantees.\n\n**PASS, by enforcing control via asset provenance and isolating all sensitive logic within a TEE, directly matches the requirements of emerging use cases:**\n- _Fine-grained, auditable, and private delegation for AI and agents_\n- _Internal privacy and regulatory auditability for enterprise payroll_\n- _Scalable, gasless, and private operation for consumer-grade trading, without user key management overhead_\n\n**Therefore, provenance- and TEE-based control is not just incrementally better, but fundamentally more aligned with the needs of modern, multi-actor, privacy-sensitive blockchain applications.** The formalization, efficient implementation, and demonstrated compatibility of PASS further reinforce its superiority as a solution."
},
{
"role": "user",
"content": "This is too long and too much to fit into the introduction. I want to make it simpler:\n\n1. in three use cases they call for the support for \"offchain transfers\", which needs to be fast, low-cost (ideally free) and private. In contract, the onchain transactions are more like a \"side effect\" when some settlements are needed.\n2. the role-based model cannot efficiently solve this problem cuz they need to define the rules from scratch. Instead, the provenance-based solution can fit in, ...\n\nWrite with this train-of-thought. You can ask questions if anything is not clear or logically consistent to you."
}
]Response:
Your train of thought is clear and logically sound. Here is a concise, logically-structured explanation suitable for an introduction:
---
The three use cases described—AI agent wallets, private enterprise payroll, and consumer-grade CLOBs—all require support for **fast, low-cost (ideally free), and private offchain transfers**. In these scenarios, most activity happens internally within the wallet, and onchain transactions serve only as external settlement events or "side effects" when necessary.
Traditional role-based access models (RBAC/ABAC) are ill-suited to this requirement. They force organizations to define complex access rules from scratch, tailored to each scenario and actor, leading to policy sprawl and administrative overhead. Moreover, these models still rely on onchain enforcement or centralized custodians, which cannot provide the required privacy or cost-efficiency for internal flows.
In contrast, a **provenance-based approach** naturally fits the offchain transfer paradigm: permissions and asset usability are determined by the custody history of each asset, not by static roles. This enables efficient, private, and auditable internal transfers, with onchain actions limited to external settlement. By enforcing the provenance logic within a TEE, we guarantee both privacy for internal operations and verifiable integrity for external settlements, satisfying the demands of all three use cases without the complexity or leakage inherent in role-based models.
---
If you want it even shorter or more focused, let me know your target length or further constraints.
Model: gpt-4.1-nano-2025-04-142025-09-15 12:45:05
Context:
[
{
"role": "system",
"content": "You are an assistant who is good at conversation. You need to summarize the user's conversation into a title of 10 characters or less. It should be in the format of \"Action - Title\". Some examples:\n1. Learn - Bitcoin 2. Code - Web Server 3. Write - An Article"
},
{
"role": "user",
"content": "[{\"role\":\"user\",\"mainText\":\"结算 英文怎么说\"},{\"role\":\"assistant\",\"mainText\":\"“结算”用英文可以表达为：\\n\\n- **Settlement**（常用于金融、会计、法律等正式场合，表示结清账目、结算交易等）\\n- **Settle accounts**（动词短语，意思为结算账目）\\n- **Clear** 或 **clear the bill**（多用于日常生活，如“结账”）\\n- **Reconcile**（在财务对账时也可用）\\n\\n具体用法要根据上下文选择：\\n\\n1. 我们需要和供应商进行结算。 \\n We need to settle accounts with the supplier. \\n 或 \\n We need to make a settlement with the supplier.\\n\\n2. 结算日 \\n Settlement date\\n\\n3. 请在离开前结账。 \\n Please settle the bill before you leave.\\n\\n逻辑和表达上，“settlement”是最通用、正式的翻译。\"}]"
}
]Response:
Translate - Settlement
Model: gpt-4.1-2025-04-142025-09-15 12:45:04
Context:
[
{
"role": "system",
"content": "You are a research paper writer. You focus on:\n1. logical consistency\n2. whether the story is persuasive\nDon't try to be friendly on purpose, judge everything based on the logic and expressiveness."
},
{
"role": "user",
"content": "结算 英文怎么说"
}
]Response:
“结算”用英文可以表达为：
- **Settlement**（常用于金融、会计、法律等正式场合，表示结清账目、结算交易等）
- **Settle accounts**（动词短语，意思为结算账目）
- **Clear** 或 **clear the bill**（多用于日常生活，如“结账”）
- **Reconcile**（在财务对账时也可用）
具体用法要根据上下文选择：
1. 我们需要和供应商进行结算。
We need to settle accounts with the supplier.
或
We need to make a settlement with the supplier.
2. 结算日
Settlement date
3. 请在离开前结账。
Please settle the bill before you leave.
逻辑和表达上，“settlement”是最通用、正式的翻译。
Model: gpt-4.1-2025-04-142025-09-15 12:34:03
Context:
[
{
"role": "system",
"content": "You are a research paper writer. You focus on:\n1. logical consistency\n2. whether the story is persuasive\nDon't try to be friendly on purpose, judge everything based on the logic and expressiveness."
},
{
"role": "user",
"content": [
{
"type": "text",
"text": "Use the contents of Introduction and Background, answer my question.\n\nMy target is to demonstrate that the existing works cannot satisfy the three use cases in Introduction, and also explain why provenance- and TEE-based solution is a better solution for this."
},
{
"type": "text",
"text": "main.pdf\nPASS: A Provenanced Access Subaccount\nSystem\nfor Blockchain Wallets\nJay Yu\n1,2\n1\nStanford University [email protected]\n2\nPantera Capital [email protected]\nAbstract. Blockchain wallets still follow a single-entity ownership model:\npossession of a private key grants unilateral control. This assumption is\nbrittle for emerging settings such as organizational custody, shared gov-\nernance, and AI agent wallets, where multiple actors must coordinate\nwithout exposing secrets or leaking internal activity.\nWe present PASS, a Provenanced Access Subaccount System\nthat replaces role or identity-based control with provenance-based con-\ntrol: assets can only be used by subaccounts that can trace custody back\nto a valid deposit. A simple Inbox–Outbox mechanism ensures all exter-\nnal actions have verifiable lineage, while internal transfers remain private\nand indistinguishable from ordinary EOAs.\nWe formalize PASS in Lean 4 and prove core invariants, including\nprivacy of internal transfers, asset accessibility, and provenance integrity.\nWe implement a prototype with enclave backends on AWS Nitro Enclaves\nand dstack Intel TDX, integrate with WalletConnect, and benchmark\nthroughput across wallet operations. These results show that provenance-\nbased wallets are both implementable and efficient. PASS bridges today’s\ngap between strict self-custody and flexible shared access, advancing the\ndesign space for practical, privacy-preserving custody.\n1 Introduction\nCryptocurrency wallets conventionally assume one key, one owner. In this single-\nentity ownership (SEAO) model, whoever holds the private key gains permanent\nand total control of the address, and casts publicly readable, gas-consuming\nblockchain transactions. However, this model struggles to adapt to emerging\nblockchain scenarios:\n1. AI and Smart Agent Transactions. AI agents increasingly manage crypto\nassets [?,?] and require bounded authority and access guardrails for users’\nasset security.\n2. Enterprise Payroll Privacy. Organizations need to distribute salaries and\ndepartmental budgets to employee accounts without revealing sensitive de-\ntails on-chain [?,?,?].\n2J. Yu\n3. Consumer-grade Central Limit Order Books. On-chain order books\nface high gas costs and latency that prevent real-time trading at scale [?,?],\nand many consumers prefer not to manage their own keys [?,?].\nIn practice, many organizations confronted with these challenges default to\ncustodians or policy engines that wrap access logic in Role-Based Access Con-\ntrol (RBAC) or Attribute-Based Access Control (ABAC) [?,?]. These systems\nintroduce a proliferation of bespoke policy languages and APIs to specify who\nmay sign or transfer under which conditions [?,?]. While workable as a stopgap,\nthey inherit identity and role assumptions from traditional IT settings that limit\ntheir flexibility and scalability in blockchain contexts.\nThe limitation stems from a mismatch of models. Traditional access-control\nframeworks such as RBAC and ABAC assume an endogenous setting: users\ncreate and manage their own files, objects, or services, and policies are attached\nto these identities or roles. Blockchains are fundamentally exogenous: assets are\ncreated outside the wallet by smart contracts and transferred permissionlessly\nin. In this setting, identity or role-based rules are awkward to express and brittle\nto enforce. What matters instead is provenance: who deposited an asset, and how\nit flowed within the wallet.\nWe propose PASS, a Provenanced Access Subaccount System that enforces\ncontrol directly by provenance. The core mechanism is simple: an Inbox records\nexternal deposits, an Outbox signs and broadcasts withdrawals, and all internal\nmovements remain private and fee-less. Every unit of value inside the wallet has\na verifiable lineage to an on-chain deposit, while externally a PASS wallet is\nindistinguishable from a standard EOA. Our contributions include:\n– A provenance-based access model aligned with blockchain’s exogenous asset\ncreation, enforced through an Inbox–Outbox design.\n– A formal model in Lean 4 proving privacy, accessibility, and provenance\nintegrity.\n– A prototype with multi-vendor enclave backends (AWS Nitro, Intel TDX via\ndstack), a web app frontend integrated with WalletConnect, together with\nthroughput benchmarks.\n– Application scenarios, including organizational custody, privacy-preserving\ntransfers, and safe delegation to AI agents.\nPASS thus bridges the gap between strict self-custody and flexible shared\naccess, combining strong privacy guarantees with practical deployability.\n2 Background and Related Work\nGrowing retail and institutional adoption of digital assets [?] has driven diverse\nwallet designs [?]. We summarize mainstream Ethereum Virtual Machine (EVM)\nwallet designs in Figure ??.\nEOAs and Multisigs. Externally Owned Accounts (EOAs) give unilateral,\npermanent control to whoever holds the private key [?]. Multisignature wallets\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets3\nModelControl basisOn-chain\noverhead\nInternal\nPrivacy\nCompatibility\nEOASingle private keyNoneNoneNative EOA\nMultisigt-of-n co-signersHigh; quorum per\naction\nNone; logic\npublic\nSmart\ncontract based\nERC-4337\nSmart\nAccounts\nOn-chain policy\nlogic\nMedium to high;\ncustom logic and\ngas\nNone; logic\npublic\nRequires\nERC-4337\nchain support\nCustodiansCustom RBAC or\nABAC languages\nNone; Off-chain\nenforcement\nCustodian sees\nall activity\nAPI mediated\nLiquefactionTEE key\nencumbrance;\npolicy trees\nMedium; Oasis\ncontracts and gas\nStrong; TEE\nhides\nsubpolicies\nRequires Oasis\ndeployment\nPASS\n(ours)\nProvenance via\nInbox-Outbox\nNone; EOA\ncompatible\nStrong;\ninternal\ntransfers\ninvisible\nNative EOA\nplus off the\nshelf TEEs\nFig. 1. Comparison of wallet architectures. PASS features provenance-based control,\noff-chain privacy, and native EOA compatibility.\n(eg., Safe) distribute trust via t-of-n approvals [?], common for treasuries and\nbridges [?,?,?]. Drawbacks include quorum overhead, symmetric authority, and\npublic logic with attackable frontends [?]. In contrast, PASS offers fine-grained,\nscoped permissioning without new contracts.\nSmart Contract Wallets and Account Abstraction. Wallets like Ar-\ngent and Loopring add programmability (social recovery, spend limits) via on-\nchain logic [?,?,?]. ERC-4337 enables custom validation through UserOperation\ncontracts [?], and EIP-7702 lets EOAs invoke this logic [?]. These increase flex-\nibility but expose policies publicly and incur gas costs, limiting use cases like\npayroll. PASS instead enforces policy privately in a TEE, minimizing on-chain\nfootprint.\nCustodial Policies. Custody providers (Fireblocks, Turnkey, Privy) use\nRBAC/ABAC engines with custom policy languages [?,?]. PASS replaces these\nwith provenance: authority follows asset origin and history, akin to a UTXO\nmodel. This reduces policy-surface complexity while remaining composable with\nconstraints like whitelists and blacklists.\nTEEs and Liquefaction. Trusted Execution Environments (TEEs) provide\nhardware-isolated contexts with remote attestation [?,?]. Liquefaction [?] keeps\nwallet keys in a TEE and enforces sub-policies via key encumbrance, ensuring\nprivacy. PASS advances this model by (i) proving invariants in Lean 4, (ii) sim-\nplifying enforcement to a provenance rule with Inbox/Outbox subaccounts, and\n(iii) working with a standard EOA without relying on Oasis smart contracts\n[?]. We further validate by implementing PASS on AWS Nitro Enclaves and In-\ntel TDX (via dStack), and showcase applications including AI wallets, payroll,\nsupply chains, and DAO voting.\nOther Models. Exchanges pool funds in omnibus addresses with off-chain\nledgers [?]; mixers like Tornado Cash hide deposit–withdrawal links [?]. PASS\n4J. Yu\nsimilarly hides internal transfers while retaining a provenance log for auditability;\noutsiders see only deposits and withdrawals.\n3 System Model and Design\nFig. 2. Overview of PASS. External deposits enter the Inbox and are claimed by sub-\naccounts. Internal transfers are private and off-chain. Egress occurs via the Outbox,\nwhich signs and broadcasts on-chain transactions. All on-chain activity has clear prove-\nnance; internal movements remain private.\n3.1 High level system model\nPASS is a multi-user wallet on a single EOA (sk, pk). The wallet maintains a\nfinite set of subaccounts U ={u\n1\n,...,u\nn\n} and a set of assets A (e.g., ERC-20).\nA subaccount u ∈ U has authority over an amount x of asset α ∈ A iff it can\nobtain a signature from the global sk via the enclave; sk resides only inside a TEE\nand is never directly accessible. We give the intuitive model here and formalize\nit in Section ??.\nInternally, PASS tracks balances with a map L : U ×A →Z\n≥0\n(accessed\nvia L[u][α]), an Inbox multiset I of unclaimed deposits (α,x,m), an Outbox\nFIFO queueO of pending on-chain actions (α,x, extDst,ν) together with a global\nnonce ν ∈N, and an append-only provenance logH. The core principles of PASS,\nas shown in Figure ?? are as follows:\n1. Access follows provenance. A unit of value is usable by u only if there\nexists a custody chain in H from an external deposit to u. Informally,\nAllow(u,α,x) means balance x is reachable for u via provenance in H. This\nimplies consistency : for every α, the total internal balance equals the on-\nchain balance at pk, i.e.,\nP\nu∈U\nL[u][α] = B\non\n(α). Incoming deposits (α,x,m)∈\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets5\nI are “wrapped” and must be explicitly claimed before use by the sender\naddress.\n2. Off-chain privacy. Internal transfers u→ v update only L and H; they do\nnot touch O or the on-chain balance B\non\n, so internal flow is invisible and\nfee-less.\n3. First-come, first-served. Outbox transactions are sequenced by a FIFO queue,\nwhich maintains and increments a global nonce ν and directly sends enclave-\nsigned transactions to a RPC node to prevent nonce conflicts and replay\nattacks.\n3\nOrganizational Ownership Model. PASS operates under an organiza-\ntional ownership model, where an entity such as a company, individual, or DAO\nmanages shared control over blockchain assets. We detail the threat model in\nSection ??.\nInbox-Outbox Gateway External senders transfer assets to pk, creating\nInbox entries (α,x,m) ∈ I. A user performs claim(u,α,x,m) to move value\nintoL[u][α], conceptually “wrapping” the deposit. To withdraw or interact with\na contract, a subaccount first performs an internal transfer to the Outbox,\nwhich enqueues (α,x, extDst,ν); the enclave then signs the concrete transaction\nwith sk and immediately broadcasts it, incrementing ν. The FIFO discipline and\nglobal nonce serialize actions and prevent races and double-spends. Because sub-\naccounts never receive pre-signed transactions, pre-signing misuse is mitigated.\nComposable policy scheme. Deposits are claims fromI; internal transfers\nrequire Allow(u,α,x) and update (L,H); withdrawals are internal transfers to\nO followed by submission. Additional constraints (eg., RBAC or ABAC checks,\nwhitelists and blacklists) can be incorporated as conjuncts to Allow without\nchanging the provenance-centric rule or its consistency and privacy effects.\n3.2 Formal Model\nWe formalize PASS as a transition system in Lean 4\n4\n, an interactive theorem\nprover with a rich dependent type system [?], suitable for policy verification (eg.,\nAWS Cedar [?]). In this section, we introduce the formal system we modeled in\nlean, and in Section ?? we will discuss security invariants modeled. An extended\ndiscussion of our formal verification system can be found in Appendix ??.\nState. A wallet state is S =\n\u0000\npk, sk,ν,I,O,L,H\n\u0001\nwhere (pk, sk,ν) are the\nEOA public key, private key (generated and held in the TEE), and global nonce;\nI and O are Inbox and Outbox; L is the internal balance map L[u][α] ∈Z\n≥0\n;\nandH is the provenance history. For privacy arguments we also use the external\nview W\npub\n= (pk,O,A), where O contains the Outbox queue and nonce and A\nrecords total on-chain balances by asset.\n3\nWe assume that the TEE is able to run a Helios light client, as is the case in dstack\nIntel TDX, discussed and implemented in Section ??\n4\nLean 4 model: https://github.com/pass-wallet/pass-lean4-proofs\n6J. Yu\nPASS Wallet Management Functionality F\nΣ\nPASS\nfor wallet W\nGlobal State:\npk : public address (EOA)\nsk : private key (in TEE)\nν: global nonce for on-chain transactions\nI (Inbox): set of unclaimed deposits (α : asset,x : amount,m : depositId)\nO (Outbox): FIFO queue (α,x, extDst,ν)\nL (Asset Ledger): internal map L[u][α]∈ Z\n≥0\n, where u is each user’s ID in the system\nH (Provenance History): a list of transaction records appended whenever ClaimInbox,\nInternalTransfer, or Withdraw is invoked\nCreatePassWallet (creator ):\nI← ∅, O← ∅, L←{}; ν← 0\n(pk, sk )← TEE\nKeyGen()\nReturn new W with S =\n\u0000\npk, sk,ν,I,O,L,H\n\u0001\nand reference to creator\nInboxDeposit (α,x,m) from external P :\nI ← I ∪ {(α,x,m)}\nReturn success\nClaimInbox (α,x, depositId) from u:\nIf no (α,x,m) with depositId in I, return ⊥\nRemove (α,x,m) from I\nL[u][α]←L[u][α] + x\nH←H| (op = claim,α,x, depositId,u)\nReturn success\nCheckAllow (u\nsend\n,α,x,H):\nIf H.GetProvenance(α, u\nsend\n)≥ x,\nreturn true; else return false\nInternalTransfer (α,x,u\nsend\n,u\nrecv\n):\nIf L[u\nsend\n][α] < x or ¬checkAllow(u\nsend\n,α,x,H), return ⊥\nL[u\nsend\n][α]←L[u\nsend\n][α]− x\nL[u\nrecv\n][α]←L[u\nrecv\n][α] + x\nH←H\n\f\n\f\n\u0000\nop = transfer,α,x,u\nsend\n,u\nrecv\n\u0001\nReturn success\nWithdraw (α,x,u\nsend\n, extDst):\nIf L[u\nsend\n][α] < x or ¬checkAllow(u\nsend\n,α,x,H), return ⊥\nL[u\nsend\n][α]←L[u\nsend\n][α]− x\nO ←O∪{(α,x, extDst,ν)}\nH←H | (op = withdraw,α,x,u\nsend\n, extDst)\nReturn success\nSignGSM (dom, msg,u):\nIf u lacks sign-right for (dom, msg), return ⊥\nσ ← (sk, msg)\nReturn σ\n(Outbox Processing) (periodic or on demand):\nIf O ̸= ∅, dequeue (α,x, extDst,ν)\nBuild tx τ : transfer x of α to extDst, nonce = ν\nσ ← (sk, τ ); broadcast (τ,σ)\nν←ν + 1\nReturn broadcasted + txHash\nFig. 3. Formal Model of PASS wallet functionality, including CreatePassWallet for\ninitializing a fresh instance. On creation, pk is set to a chosen EOA address eoa, the\nTEE generates a hidden private key sk , and global data structures are initialized.\nExternal deposits enter I (Inbox), while subaccount transfers update L (Ledger) off-\nchain. Withdrawals queue items in O (Outbox), and GSM operations are signed using\nsk .\nTransitions. Operations op∈ T update S with type-checked rules: InboxDe-\nposit adds an unclaimed (α,x,m) to I; ClaimInbox moves (α,x,m) from I to\nL[u][α] and appends to H; InternalTransfer moves value between subaccounts;\nWithdraw debits L[u][α], enqueues (α,x, extDst,ν) in O, and logs; SignGSM\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets7\nauthorizes domain-scoped signable messages. A representative rule is:\n\u0000\npk, sk,ν,I,O,L,H\n\u0001\ntransfer(α,x,u\ns\n,u\nr\n)\n−−−−−−−−−−−→\n\u0000\npk, sk,ν,I,O,L\n′\n,H\n′\n\u0001\nwith\nif L[u\ns\n][α] < x or ¬checkAllow(u\ns\n,α,x,H) then ⊥;\nL\n′\n[u\ns\n][α] =L[u\ns\n][α]− x, L\n′\n[u\nr\n][α] =L[u\nr\n][α] + x;\nH\n′\n=H\n\f\n\f\n\u0000\nop = transfer,α,x,u\ns\n,u\nr\n\u0001\n.\nHere checkAllow queries provenance inH and can be extended with auxiliary\nconstraints such as user whitelists or blacklists, without changing the core rule.\nFigure ?? provides a formal specification of the methods in a PASS wallet.\n3.3 Asset Model and General Signable Messages\nPASS provides an authorization scheme over a heterogenous set of assets A, in-\ncluding fungible tokens, such as ether and ERC-20 tokens, ERC-721 non-fungible\ntokens, and “general signable messages” across a variety of DApps for sign-in\nand identity verification. Each asset α ∈ A has a well-defined custody path in\nthe provenance log H, and a subaccount u ∈ U has usable balance x of α iff\nAllow(u,α,x) holds.\nToken assets. For token assets such as ether, ERC-20, and ERC-721, de-\nposits are captured as Inbox entries (α,x,m) ∈ I. Claims allocate balance into\nL[u][α], internal transfers update L and H privately, and withdrawals enqueue\n(α,x, extDst,ν) intoO for enclave signing and on-chain broadcast, ensuring con-\nsistency where:\n∀α∈A\ntokens\n:\nX\nu∈U\nL[u][α] = B\non\n(α, pk).\nIn particular, ERC-721 tokens are modeled as unitary balances (x ∈ {0, 1})\nwhose transfers preserve uniqueness under provenance.\nGeneral Signable Messages (GSMs). In addition to on-chain assets,\nwallets often sign arbitrary messages, such as for EIP-4361 [?] logins and off-\nchain DAO votes [?]. PASS models these as a special classA\nGSM\nof virtual assets.\nEach GSM asset is scoped to a domain dom, so holding α = (dom) represents\nauthority to sign messages from that domain. A signature operation:\nSignGSM(u, dom,m)7→ σ\nis permitted iff Allow(u, dom, 1) holds in H. At key generation, the wallet\ncreator is endowed with default signing authority over all domains, represented\nas an initial allocation of every α = (dom)∈A\nGSM\nto the root subaccount. These\ndomain assets can be internally transferred to delegate signing authority. Thus\nprovenance of GSMs begins at the owner and flows through transfers, providing\na well defined provenance path in H as with token assets.\n8J. Yu\nBy treating both tokens and GSMs as types of elements ofA, PASS provides\na unified provenance rule for subaccount authorization. A subaccount cannot\nspend an ERC-20 token, transfer an NFT, or sign a domain message unless it\npossesses the corresponding asset under L and H. This unified authorization\nscheme allows for fine-grained delegation, (eg., giving u rights over example.com\nwhile withholding ERC–20 funds) and consistent enforcement across on-chain\nand off-chain actions.\n4 Properties of PASS\n4.1 Threat Model\nPASS assumes an organizational ownership model, where a single entity, such\nas a company, individual, or DAO manages the EOA (pk,sk), brokers access\nbetween many users in that entity, and chooses the TEE infrastructure vendor\n(eg. AWS Nitro, dstack Intel TDX, self-hosted hardware). This model is typical\nfor use cases such as private payroll, supply chains, and AI delegation described\nin Section ??. Protected assets in PASS include the private key sk, the balance\nledger L and provenance log H, and the correctness of Allow(u,α,x) for all\nu∈ U,α∈A,x. In our model, we make the following trust assumptions:\n1. TEE integrity. Hardware isolation is sound; sk never leaves the enclave.\nRemote attestation guarantees that the enclave runs the genuine PASS bi-\nnary.\n2. Cryptography. Standard primitives (signatures, hash functions, PRFs) are\nsecure against polynomial-time adversaries.\n3. Governance majority. The deploying entity holds majority control in the\ngovernance mechanism (via DAO vote or admin privileges), ensuring it can\ninvoke the blockchain-governed KMS for MPC-based key recovery and trig-\nger fallback contracts when needed.\nAdversary Model. An adversary A may control the host OS and network,\nobserve or modify all communication with enclaves, and submit arbitrary trans-\naction requests. In particular, A may attempt to:\n– Exploit software bugs in the PASS implementation or TEE runtime,\n– Forge or replay transactions to break consistency of H,\n– Subvert provenance by violating Allow(u,α,x)\nThreats Out of Scope. On the other hand, PASS does not protect against:\n– Physical compromise of TEE hardware (tampering, microarchitectural side-\nchannels, chip decapsulation),\n– Supply-chain backdoors in TEE manufacturing,\n– Fully malicious operators with unrestricted physical access.\nThese are excluded because the organizational model assumes controlled facilities\nand vetted hardware.\nSecurity Goals. Given the assumptions above, PASS guarantees:\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets9\n1. Integrity:\nP\nu∈U\nL[u][α]≤ extDep(α) for all α, i.e., no assets can be created\nor double-spent internally.\n2. Correctness: If Allow(u,α,x) holds, then u can eventually realize x via\nWithdraw.\n3. Privacy on-chain: InternalTransfer operations do not affect externalTrace(W ),\nand to external observers, a PASS wallet is indistinguishable from an EOA.\n4. Liveness: For any authorized op ∈ Ops, if one enclave and quorum remain\nhonest, then ∃τ s.t. Exec(c, op) =⊤ within τ\n4.2 Privacy and Safety\nAfter establishing the threat model of PASS, we will address the central privacy\nand safety guarantees in our formal verification model. We sketch three central\nlemmas here, and create mechanized proofs in Lean, discussed in Appendix ??.\nProposition 1 (Internal Transfer Privacy). If two public states W\n1\n,W\n2\nshare the same pk, identical Outbox (T,ν), and equal per-asset totals in A, then\nexternalTrace(W\n1\n) = externalTrace(W\n2\n).\nProof Sketch. InternalTransfer updates only (L,H), never O or total on-chain\nbalances. OutboxProcessing in Figure ?? emits on-chain actions solely from O\n(lines 2–4), hence the trace depends only on O.\nCorollary: EOA indistinguishability. If W\npass\nand W\neoa\nshare the same pk,\nOutbox, and per-asset totals, then\nexternalTrace(W\npass\n) = externalTrace(W\neoa\n).\nThus, from an external observer’s perspective, a PASS account is indistinguish-\nable from a standard EOA: internal transfers leave no observable footprint.\nProposition 2 (Asset Accessibility). For any asset α, letting L = {u |\nL[u][α] > 0},\nX\nu∈L\nL[u][α] = totalBalance(α),\nand each u∈ L can spend its full balance subject to checkAllow.\nProof Sketch. ClaimInbox creditsL; InternalTransfer preserves the sum over u;\nWithdraw debitsL and enqueues toO, which OutboxProcessing realizes on-chain.\ncheckAllow enforces reachability from provenance in H.\nProposition 3 (Provenance Integrity). Let extDep(α) be net external de-\nposits (deposits minus realized withdrawals). For all reachable states,\nX\nu\nL[u][α] ≤ extDep(α).\n10J. Yu\nProof Sketch. Induct on transitions. InboxDeposit increases extDep only; Claim-\nInbox moves already-deposited value into L; InternalTransfer conserves the sum\nover u; Withdraw decreases the sum, and after OutboxProcessing broadcasts,\nextDep is reduced accordingly.\nGeneral signable messages (GSM). Model GSM rights as a domain-\nscoped virtual asset class A\nGSM\n. Let α = (dom)∈A\nGSM\nand permit\nSignGSM(u, dom,m) iff Allow(u,α, 1).\nThen (P2)–(P3) lift to GSM: there is always at least one domain signer, and\nGSM “balances” obey provenance conservation under transfers in H.\n4.3 Liveness\nWe define liveness as the property that any authorized operation remains even-\ntually executable, despite enclave crashes, vendor compromise, or partial gover-\nnance failure. Our model assumes deployment of PASS access logic on dstack,\nimplemented in Section ?? and detailed in Appendix ??.\nLet E denote active enclaves, C containerized wallet backends, and P gover-\nnance policies. Each container c∈C stores sealed state\nσ\nc\n=⟨S,k\nc\n, meta⟩ with S = (pk, sk,ν,I,O,L,H),\nwhere k\nc\n= Derive(K,c) is derived from an MPC-managed KMS and meta records\nattestation. An operation op ∈ Ops (deposit claim, transfer, withdrawal) ex-\necutes as: Exec(c, op) = ⊤ iff Attested(c)∧ Γ (S), where Attested(c) checks σ\nc\nagainst registry R and Γ is the quorum predicate over P. To ensure vendor-\nagnostic portability, state migration μ :E →E satisfies\n∀e\ni\n,e\nj\n∈E, e\nj\n.decrypt(σ\nc,e\ni\n,k\nc\n) = σ\nc,e\ni\n,\nTheorem 1 (Liveness Theorem). If (i) the MPC KMS tolerates f\nKMS\nfaults\nin a t-of-n threshold, (ii) governance quorums are f\ngov\n-resilient, and (iii) at least\none enclave is uncompromised, then every op∈ Ops executes within bounded time\nτ :\n∀op∈ Ops, ∃τ ≥ 0 : Exec(c, op) =⊤.\nProof Sketch. Progress follows from three guarantees: (1) the MPC KMS\nensures k\nc\nis always recoverable under threshold availability; (2) Γ encodes quo-\nrum rules that eventually relax after timeout ∆t, ensuring some subset S satisfies\nΓ (S) = ⊤; (3) migration μ allows any enclave to re-host σ\nc\n, preventing vendor\nlock-in or enclave failure from blocking execution. Algorithm ?? formalizes re-\ncovery and execution under these assumptions.\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets11\nAlgorithm 1 RecoverAndExecute(c, op)\n1: Verify enclave e attestation Q\ne\nagainst R.\n2: Derive k\nc\n← Derive(K,c); decrypt σ\nc\n.\n3: if CompromiseDetected(e\n′\n) then\n4:Rotate k\nc\nand re-encrypt σ\nc\n.\n5: end if\n6: Ensure Γ (S) =⊤ for S ⊆P(c).\n7: Execute op; append to H.\nKey Properties. (1) Portability: any attested enclave can recover σ\nc\n, in-\ndependent of vendor; (2) Monotonic Recovery: recovery steps form ρ : S → S\nwith ρ(s)⪰ s; (3) Domain Continuity: certificates remain bound to R(c) under\nmigration μ(c), preventing hijack or replay.\nImplementation details of container orchestration, attestation, and KMS pro-\ntocols are given in Appendix ??.\n5 Practical Implementations\n5.1 Prototype Implementations\nTo demonstrate feasibility, we have implemented a prototype of PASS that cap-\ntures the core architectural components.\n5\nThe prototype consists of:\n– Provenanced Access Model, the core PASS architecture outlined in Sec-\ntion ?? with the Inbox-Outbox structure, asset ledgers, and provenanced\nrule as a Rust executable.\n– Web Application Frontend, an AWS-hosted Typescript interface that\nallows users to deposit assets, initiate internal transfers, generate on-chain\ntransactions, and sign arbitrary messages on Ethereum Sepolia testnet.\n6\n– Multi-vendor TEE deployment, we deploy the PASS enclave executable\nin both AWS Nitro Enclaves and Intel TDX with the dstack framework.\nWe evaluate these two enclave deployments as complementary deployment\npaths, each with distinct tradeoffs.\nAWS Nitro Enclaves. In this design, PASS runs inside a Nitro enclave in the\nAWS cloud. The enclave executes the Inbox–Outbox logic, enforces provenance\nchecks, and signs transactions, while the provenance ledger is stored externally.\nNitro’s attestation and AWS integration simplify deployment, but reliance on a\nsingle vendor limits portability and concentrates trust. As a result, some guaran-\ntees of PASS, particularly liveness and asset accessibility, may be weaker under\nthis model.\n5\nPrototype can be found here: https://github.com/jayyu23/pass-wallet-app\n6\nWeb application: https://pass-wallet.jayyu.xyz/\n12J. Yu\nIntel TDX with dstack. dstack provides a portable, open-source runtime for\nTEEs across diverse hardware. PASS can be deployed on enclaves run by decen-\ntralized operators, with key material secured via MPC-based key management.\nBoth Inbox–Outbox logic and the provenance ledger execute inside dstack, pre-\nserving the full security properties of Section ?? and reducing vendor lock-in.\nThe tradeoff is added governance complexity over operator authorization and\npolicy enforcement.\nBlockchain Connectivity. To ensure reliable blockchain interaction, PASS inte-\ngrates Helios [?], a consensus-verified light client, within the TEE. Rather than\ntrusting external RPC endpoints, Helios cryptographically verifies all blockchain\ndata against consensus layer proofs before serving it locally. This approach elimi-\nnates the trust assumptions typically associated with centralized RPC providers\nwhile maintaining the performance characteristics necessary for real-time wallet\noperations. The light client architecture ensures that PASS’s Outbox mecha-\nnism operates on verified blockchain state, preserving the security guarantees\neven when external network providers are compromised or unreliable.\n5.2 Performance Benchmarks\nTo evaluate PASS, we benchmarked both AWS Nitro Enclaves and Intel TDX\nbackends across common operations: balance queries, transfers, withdrawals,\nclaims, wallet creation, provenance queries, and an end-to-end workflow. Each\noperation was run 100 times over 10 trials per environment, measuring through-\nput in ops/sec. Both environments used identical 4-core, 2.5 GHz, 16 GB VMs\nto ensure fair comparison. Table ?? summarizes our results, with full details\navailable in Appendix ??.\nFig. 4. Internal PASS operation throughput (ops/sec) across AWS Nitro Enclaves\nand Intel TDX. All operations are in-memory state changes within the TEE with no\nblockchain interaction. Each value represents the average of 100 operations repeated\n10 times per environment.\nOperationAWS Nitro Intel TDX\nWallet Creation6,53114,970\nAccount Balance Queries530,943935,428\nInbox-to-Subaccount Claims14,85633,064\nInternal Subaccount Transfers32,95371,292\nWithdrawal Request Creation18,29139,702\nEnd-to-End Workflow\n7\n35,66378,433\nTransaction History Queries3,7577,685\nMulti-threaded Operations (5 threads)32,18955,124\nLarge Dataset Processing481724\nThe observed performance differences between AWS Nitro Enclaves and In-\ntel TDX primarily stem from their distinct hardware architectures. AWS Nitro\nEnclaves employ a disaggregated system design, where the host server and the\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets13\nTEE hardware are physically separated. Communication between the host and\nthe enclave occurs via vsock, and the enclave itself runs on a dedicated, lower-\nperformance coprocessor. In contrast, Intel TDX leverages a special instruction\nset to provide enclave functionality directly on the main processor, eliminating\nthe need for a separate coprocessor and avoiding the overhead of data transfer\nbetween disparate components. As a result, Intel TDX is able to deliver sig-\nnificantly higher throughput for in-enclave operations compared to AWS Nitro\nEnclaves, as reflected in our benchmark results.\nThese preliminary benchmarks show that both Nitro and TDX backends can\nsustain high throughput for critical wallet operations, confirming that PASS is\npractical for real-world deployment.\nComparison with Related Work. To contextualize our performance results, we\ncompare PASS with other TEE-based blockchain systems and traditional custo-\ndial solutions.\nLiquefaction. The Liquefaction system [?] demonstrates significantly higher\nlatencies than PASS due to its reliance on blockchain oracles for transaction\nvalidation. Liquefaction exhibits mean latencies of 49 seconds for latest block\nconfirmation, 648.7 seconds ( 11 minutes) for justified confirmation, and 1,036.9\nseconds ( 17 minutes) for finalized confirmation. These delays stem from Liq-\nuefaction’s architectural requirement to wait for block confirmations on an ex-\nternal TEE-blockchain oracle before authorizing subsequent operations. In con-\ntrast, PASS performs all operations within the off-chain TEE worker without\nblockchain dependencies, achieving sub-millisecond latencies for internal opera-\ntions (e.g., 14,856-33,064 ops/sec for claims, 32,953-71,292 ops/sec for transfers).\nThis fundamental architectural difference—off-chain TEE computation versus\nblockchain-dependent validation—enables PASS to provide near-instantaneous\nuser experiences while maintaining strong security guarantees.\nTraditional Custodians. While custodial solutions do not publish detailed\nperformance benchmarks, prior work demonstrates that TEE overhead typically\nintroduces only 5-7% performance degradation compared to native execution [?].\nGiven that modern custodial systems can process thousands of operations per\nsecond, TEE-based solutions like PASS should achieve comparable throughput\nwhile providing significantly stronger security properties. Our benchmark results\nsupport this expectation, with PASS demonstrating high-throughput operation\nprocessing that would be suitable for production custodial workloads, while offer-\ning the additional benefits of cryptographic auditability, decentralized operation,\nand reduced single points of failure.\nFurther evaluation of latency distributions, concurrency scaling, and memory\nfootprint is left for future work.\n6 Applications\nPASS is a powerful primitive that enables several classes of applications across\nidentity scoping, enterprise settings, and scalability concerns.\n14J. Yu\nCategoryApplicationContextPASS Enables\nIdentities\nAI Agent\nWallets\nAutonomous agents\ninteracting with crypto\nassets [?] need signing\naccess guardrails.\nScoped subaccounts grant limited\nbalances and domain signing rights,\nenabling safe delegation without\nexposing the root key\nDAO Voting\nDelegation\nDAOs depend on\naddress-based voting and\nproxy delegation [?].\nFine-grained voting rights delegation\nthat remains auditable via provenance;\ndelegation can be restricted to specific\nDApps or domains.\nSubdomain\nProfile Pages\nOrganizations delegate\ncontrol over web or\norganizational\nsubdomains (e.g.,\nmyprofile.company.com) to\nindividuals or teams.\nEach subaccount holds scoped signing\nrights for its assigned subdomain, with\nbalances and authorities tracked in\nprovenance under a shared\norganizational identity.\nEnterprise\nPrivate PayrollOn-chain payrolls reveal\nsensitive salary\ninformation [?].\nSalary distribution through internal\ngasless transfers with audit logs;\nexternal payouts are periodically\nbatched via the Outbox.\nCompliant Org\nWallets\nFirms must maintain\ninternal accountability\nand BSA\nrecordkeeping [?].\nDepartmental and individual\nsubaccounts with explicit budgets;\nprovenance ensures regulator-grade\nauditability without exposing internal\nflows.\nPrivate B2B\nNetting\nSupply-chain and\nrecurring multi-party\npayments require\nconfidentiality.\nVendor subaccounts allow internal\nnetting of obligations, with PASS\nacting as a temporary clearing house.\nOnly net settlements exit via the\nOutbox, reducing leakage while\nretaining auditability.\nAudit / Proof\nExplorer\nRegulators and auditors\nrequire verifiable yet\nprivacy-preserving\ntransparency.\nPublic proofs derived from the\nprovenance log H, enabling compliance\nchecks and audits without disclosing\ninternal ledger state.\nScalability\nGasless\nAppchain\nHigh-throughput\napplications (e.g., trading\nengines) face prohibitive\ngas costs on-chain.\nInternalize application logic as\nsubaccount transitions; Outbox emits\nverifiable batch settlements, ensuring\ncorrectness with minimal gas.\nCross-chain\nBridges\nBridges require strong\ncustody and coordination\nof operators [?].\nInbox-Outbox abstractions enforce\nprovenance across domains; FIFO\nnonce handling prevents replay or race\nconditions.\nL2 ComposabilityRollups and L2s fragment\nassets and user\nexperience [?].\nTreat each L2 as a scoped subaccount;\nmaintain private balance transfers\ninternally, and settle externally only\nwhen crossing domains.\nFig. 5. Applications of PASS across identities, enterprise settings, and scalability so-\nlutions. We highlight a flagship application in each category.\nIdentities and Agent Delegation. PASS’s multi-user subaccount model\nallows for flexible permission scopes. As AI agents start managing crypto as-\nsets, there is a need to constrain their access. An AI agent could be given a\nsub-account that only holds limited funds or certain asset types. The AI can op-\nerate freely within those bounds, but cannot exceed its allotted assets or misuse\nother wallet assets. If compromised, damage is capped to its sub-account. This\nis much safer than giving AI the keys to an entire wallet. Similarly, PASS can\nallow for delegation-based DAO voting by giving the delegate signature rights\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets15\nover particular voting DApps, without giving access to actually transfer the as-\nsets. Subaccounts can also get scoped signing rights over particular enterprise\nsubdomains.\nEnterprise Applications. PASS’s features of internal privacy, in-built per-\nmissioning, and provenance auditability make it uniquely suited for enterprise\napplciations. A flagship use case for PASS is private payroll. On-chain salary pay-\nments today risk exposing sensitive information such as individual compensation,\ndepartmental budgets, or timing patterns. With PASS, salaries are distributed\ninternally through gasless subaccount transfers, leaving a clear provenance log for\nauditability, but without revealing per-employee details on-chain. Only periodic,\non-demand payouts exit via the Outbox, ensuring both regulatory accountability\nand privacy for internal flows. Beyond payroll, PASS supports other enterprise\nneeds: compliant organizational wallets with departmental subaccounts that en-\nforce explicit budgets, private B2B netting where vendors settle obligations inter-\nnally and only net payments leave the wallet, and auditable proof explorers that\nprovide regulators with verifiable, privacy-preserving compliance proofs derived\nfrom the provenance log.\nScalability Solutions. PASS also supports scaling use cases where on-chain\ncosts or coordination overhead make existing approaches impractical. A flagship\nexample is gasless appchains, such as for Central Limit Orderbooks (CLOBs).\nHigh-throughput applications such as CLOBs cannot afford per-transaction gas\nfees, but PASS internalizes application logic as private subaccount transitions.\nThe Outbox then emits verifiable batch settlements with minimal gas, preserv-\ning correctness while keeping costs predictable. Beyond appchains, PASS enables\ncross-chain bridges by enforcing provenance across domains and sequencing with-\ndrawals via a FIFO nonce to prevent replay or race conditions, and supports L2\ncomposability by treating each rollup or sidechain as a scoped subaccount, main-\ntaining private balance transfers internally and settling externally only when\ncrossing domains.\n7 Discussion and Future Work\n7.1 Composability and InterPASS Transactions\nWhile PASS provides privacy and provenance guarantees for a single wallet in-\nstance, an important question is how multiple PASS wallets may interact. This\nis important in supply-chain use cases where each PASS represents a single com-\npany in the supply chain.\nTrivially, PASS A can send an on-chain transaction from its Outbox to PASS\nB’s EOA account, and this will land in the Inbox of PASS B, ready to claim.\nHowever, this undermines the privacy guarantees that PASS offers at the EOA\nlevel, and is undesirable in cases where inter-organizational asset transfers con-\ntain sensitive information, such as order details.\nWe propose a non-trivial approach inspired by cross-Payment Channel Net-\nwork (PCN) protocols such as XTransfer [?]. We can treat each PASS instance\n16J. Yu\nakin to a PCN hub node, with state L and transaction history H. As with\nXTransfer, we can assume a star topology of PASS nodes, with a central PASS\nHub in communciation with all PASS nodes. The PASS Hub will aggregate all\nInterPASS transactions T := {(a\ni\n,x\ni\n,s\ni\n,r\ni\n)}\nn\ni=1\n, where (a\ni\n,x\ni\n,s\ni\n,r\ni\n) represent\nthe asset, amount, sender, and receiver, each signed by the s\ni\nOutbox.\nThe Hub aggregates these signed payment intents, computes a netted settle-\nment plan S, and coordinates a secure multi-party update protocol to commit\nthe resulting balances, similar to Thora [?]. In the optimistic case, this process\ncompletes entirely off-chain, and each participant’s balance is updated in the\nPASS ledger without revealing the underlying transaction graph. If a dispute or\nfailure occurs, any participant may trigger an on-chain enforcement transaction\nthat finalizes S atomically via the direct transfer mechanism, thus guaranteeing\nsafety.\nThis approach leverages PASS ’s provenance and state design to make each\ninstance an atomic node in PCN-style systems like X-Transfer. Here, we outline\nhow PASS Hubs can enable confidential, auditable cross-organization transfers,\nwhile full formal specification and protocol implementation is deferred for future\nwork.\n7.2 Instantiation on zkVM\nThe PASS design presented in this paper relies primarily on trusted execution\nenvironments (TEEs) to enforce provenance rules, where the enclave isolates the\nglobal secret key and mediates all access through the Inbox–Outbox mechanism.\nWhile TEEs provide strong privacy and efficiency guarantees, their trust model\ndepends on hardware attestation and vendor integrity, which may be insufficient\nin regulatory or adversarial settings that demand independent verification.\nzkVMs provide a natural next step by enabling provenance-based control to\nbe verified through succinct cryptographic proofs rather than trusted hardware.\nBy batching transitions over L, H, I, and O and producing a proof π, a mini-\nmalist verifier contract can update commitments and enforce outbox execution\nwhile preserving privacy. This direction complements the Chainless stack ar-\nchitecture [?], suggesting a path toward modular, interoperable deployments of\nPASS with stronger external verifiability and broader applicability.\n8 Conclusion\nWe presented PASS, a Provenanced Access Subaccount System, as a new wallet\narchitecture that enforces access by provenance rather than by identity or role.\nThe Inbox–Outbox mechanism ensures all assets have a verifiable lineage, while\ninternal transfers remain private and indistinguishable from a standard EOA\naccount.\nOur contributions are threefold: (i) a formal model in Lean 4 proving pri-\nvacy, accessibility, and provenance integrity; (ii) a working prototype with en-\nclave backends on AWS Nitro Enclaves and Intel TDX via dstack, integrated\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets17\nwith WalletConnect; and (iii) initial benchmarks showing the feasibility of high-\nthroughput operation. These results demonstrate that provenance-based control\ncan be realized today with mainstream blockchain tools.\nLooking forward, richer evaluations across multi-vendor TEEs, integration\nwith zero-knowledge VMs, and exploration of organizational and agent-based\ncustody are promising directions. By combining rigorous formal guarantees with\ndeployable prototypes, PASS advances the design space between strict self-\ncustody and flexible shared access, offering a path toward practical, privacy-\npreserving wallet security.\nA Formal Verification\nWe consider the formal model introduced in Section ?? of PASS as a state\nmachine in Lean4. Our goal is to prove that, under the PASS design, several\ncritical security properties always hold. We outline these properties and our\napproach to verifying them.\nA.1 Property: Privacy of Internal Transfers\nIn the PASS design, the InternalTransfer operation updates only the off-chain\nledgerL and the provenance historyH. It never modifies the OutboxO, meaning\nthere is no on-chain transaction triggered by an internal transfer. Consequently,\nexternal observers see no change in on-chain state. We formalize this by consid-\nering the on-chain view that an external party has for a given PASS Wallet. We\ncan model this visible on-chain state as a triple:\nW\npub\n=\n\u0000\npk, O, A\n\u0001\n,\nwhere:\npk is the externally owned account (EOA) address,\nO = (T,ν) is the external view of the outbox, where T is a list of enqueued\ntransactions and ν is a nonce,\nA is the external view of the Asset ledgerL, containing a list of asset entries,\neach of the form (α,x) with a unique identifier α and total balance x.\nExternal Trace. The external trace of a PassAccount state W\npub\nis the list of\nexternally visible actions, obtained by mapping each transaction in the outbox\nT to an on-chain action:\nexternalTrace(W\npub\n) =\n\b\noutboxTx(t) | t∈ T\n\t\n.\nNo internal transfers appear in externalTrace(·).\n18J. Yu\nStates That Differ Only by Internal Transfers. We say that two PassAccount\nstates W\n1\n= (pk\n1\n,O\n1\n,A\n1\n) and W\n2\n= (pk\n2\n,O\n2\n,A\n2\n) differ only by internal trans-\nfers if:\n1. pk\n1\n= pk\n2\n,\n2. O\n1\n= O\n2\n(i.e. both the list of outbox transactions and the nonce are the\nsame),\n3. For every asset identifier α, the total balance of that asset in A\n1\nequals the\ntotal balance of the same asset in A\n2\n.\nLetting getAsset(W,α) return the asset α within state W or ⊥, we require ∀α:\ntotalBalance\n\u0000\ngetAsset(W\n1\n,α)\n\u0001\n= totalBalance\n\u0000\ngetAsset(W\n2\n,α)\n\u0001\n.\nTheorem 2 (Privacy of Internal Transfers). If two PassAccount states W\n1\nand W\n2\ndiffer only by internal transfers, then their externally visible traces are\nidentical:\nexternalTrace(W\n1\n) = externalTrace(W\n2\n).\nProof. By assumption, O\n1\n= O\n2\n. Hence both states have the same outbox trans-\naction list T . Since\nexternalTrace(W\ni\n) = map\n\u0000\noutboxTx, T\ni\n\u0001\nfor i∈{1, 2},\nand T\n1\n= T\n2\n, it follows that externalTrace(W\n1\n) and externalTrace(W\n2\n) are iden-\ntical.\nThus, any sequence of purely internal transfers, changing only the private ledger\nL in PASS, is invisible to an external observer, preserving the privacy of how\nassets move within the wallet.\nA corollary of this Internal Transfer property is that a PASS account is\nindistinguishable from a regular EOA account.\nCorollary 1 (Indistinguishability from EOA). Let W\npass\nbe a PASS state\nthat (i) has the same public key pk, (ii) the same outbox, including nonce and\ntransaction list, and (iii) the same total balances of each asset as a reference\nEOA state W\neoa\n. Then\nexternalTrace(W\npass\n) = externalTrace(W\neoa\n).\nIn particular, an external observer cannot distinguish W\npass\nfrom W\neoa\n.\nProof. By assumption, the only potential differences betweenW\npass\nandW\neoa\nlie\nin internal ledger details. From Theorem 1, such internal transfers do not affect\nthe externally visible outbox transactions or total on-chain balances. Thus, their\nexternal traces coincide, and W\npass\nis indistinguishable from W\neoa\n.\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets19\nA.2 Property: Asset Accessibility\nIn addition to keeping internal transactions private, PASS should ensure that for\nevery asset in the system, there exists some sub-account that can access it and\nwithdraw it from the system. This prevents a situation where funds get ”stuck”\nwithout any reachable key or policy to move them. We define asset accessibility\nas follows:\nTheorem 3 (Asset Accessibility). For any PASS account W and asset iden-\ntified by α, there exists a list of addresses L such that:\n1. For every address u∈ L, the user can access their full balance:\ncheckBalance(s,α,u, balance(u)) = true\n2. The sum of all accessible balances equals the total balance of the asset:\nX\nu∈L\nL[u][α] = totalBalance(α)\nProof. We construct L as the set of all addresses with non-zero balances in the\nbalance map for α:\nL ={u|L[u][α] > 0}\nFor the first property, given any u∈ L, the definition of checkBalance verifies\nif the user has sufficient balance for the specified amount. When checking against\nthe user’s own balance, this is trivially satisfied since L[u][α]≥L[u][α] for all u.\nFor the second property, we observe that totalBalance is defined as the sum\nof all balances in the asset’s balance map:\ntotalBalance(α) =\nX\nu∈L\nL[u][α]\nBy construction, L contains the only nonzero values u∈L, so:\nX\nu∈L\nL[u][α] = totalBalance(α)\nTherefore, both properties hold for our constructed list L.\nWe can prove a similar trait for General Signable Messages, showing that for\nany inbound GSM, there is some subaccount signer that has access to it.\nTheorem 4 (GSM Accessibility). For any GSM and domain, there exists a\nuser with signing access to that domain.\nProof. For any domain d, we can directly construct a user u who has signing\naccess to d as follows:\nu = getSigner(d)\nBy definition, getSigner returns either:\n– A specifically assigned signer if one exists in the domain-address map, or\n– The default signer otherwise\nTherefore, every domain is guaranteed to have at least one user with signing\naccess, ensuring no GSM domain becomes inaccessible.\n20J. Yu\nA.3 Property: Provenance Integrity\nProvenance integrity specifies that every asset held by any sub-account in PASS\nmust have an origin traceable to an external deposit into the Inbox. At any\nstate of the system, for each asset entry in a sub-account’s balance, we can find\na sequence of internal transfers that leads back to an Inbox deposit from an\nexternal address. This property ensures no sub-account can conjure funds from\nnothing, such as through double-spending or inflation within the system, and\nthat the internal ledger is consistent with on-chain reality. In Lean, we model\nthe state of the PASS wallet including Inbox, Outbox, and all sub-accounts and\nprove an invariant that whenever a sub-account has x units of asset α, the global\nstate contains a record of at least x units of α having been deposited, minus any\nthat have been withdrawn.\nTheorem 5 (Provenance Integrity).\nFor any PASS account S =\n\u0000\npk, sk,ν,I,O,L,H\n\u0001\nand any asset α, the total\namount of α held across all subaccounts can never exceed the total amount of\nexternal deposits (minus any that have already been withdrawn). Formally,\nX\nu∈U\nL[u][α] ≤ externalDeposits(α),\nwhere U is the set of subaccounts in the system, and externalDeposits(α) is\nthe net total of asset α that has been introduced into the wallet from outside\naddresses, recorded in the inbox I.\nProof. We model the system’s state (pk, sk,ν,I,O,L,H) as in Figure ??, includ-\ning the Inbox I, Outbox O, and the internal ledger L. We define a provenance\nrecord P (α,u) that captures the total amount of asset α subaccount u is autho-\nrized to hold, based on Inbox claims and internal transfers.\nBase Case: Immediately after CreatePassWallet, no assets have been de-\nposited, and no subaccount balances exist:\n∀u, L[u][α] = 0, ∀α, externalDeposits(α) = 0.\nHence,\nX\nu∈U\nL[u][α] = 0 ≤ 0 = externalDeposits(α).\nInductive Step: Assume the invariant holds after n− 1 operations. We prove it\nremains valid after the nth operation, for each possible type of operation:\n(1) External Deposit: Suppose an amount x of asset α is deposited into the\nwallet:\nexternalDeposits(α) ← externalDeposits(α) + x.\nNo subaccount balances L[u][α] change. Thus, the left side of our inequality\n(sum of subaccount balances) is unchanged, while the right side strictly\nincreases by x, so the invariant continues to hold.\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets21\n(2) Inbox Claim: If subaccount u claims amount x of asset α from the Inbox\nI:\nL[u][α] ← L[u][α] + x, P (α,u) ← P (α,u) + x.\nSince x was already accounted for in externalDeposits(α) (but not yet allo-\ncated to any subaccount), the total subaccount balances remain≤ externalDeposits(α).\n(3) Internal Transfer: If subaccount u\n1\ntransfers x of α to subaccount u\n2\n:\nL[u\n1\n][α] ← L[u\n1\n][α]− x, L[u\n2\n][α] ← L[u\n2\n][α] + x,\nand P (α,u\n2\n) increases by x. Because the sum of all subaccount balances\ndoes not change, our invariant is preserved.\n(4) Withdrawal: If subaccount u withdraws x of α:\nL[u][α] ← L[u][α]− x,\nwhich reduces the total subaccount balances. Since externalDeposits(α)\nremains unchanged (assets have simply exited the wallet), the inequality still\nholds.\nThus, by induction over all possible operations,\nX\nu∈U\nL[u][α] ≤ externalDeposits(α)\nfor every reachable state. No subaccount can create new assets out of nothing,\nand all assets in the system are fully accounted for by provenanced deposits.\nB Dstack Architecture and Execution Model\nB.1 Component Overview\n– Dstack-OS: Minimal Linux-based VM image with a verifiable boot chain.\nMeasures bootloader, kernel, root filesystem (RootFs) via RTMR registers.\nIntegrates dm-verity for data integrity and monotonic counters for anti-\nrollback.\n– Dstack-KMS: Blockchain-governed MPC network for key derivation and\nrotation. Provides:\nk\nc\n= HMAC\nk\nroot\n(c\nid\n),\nk\nTLS\n= ECDSA(k\nroot\n).\nRotation is triggered via governance (t-of-n threshold).\n– Dstack-Gateway/Ingress: TLS termination inside TEEs, ZT-TLS bind-\ning X\nc\nto R(c), enabling verifiable HTTPS ingress.\n22J. Yu\nB.2 Governance Layer\nTwo contracts form the trust base:\n– KmsAuth: Global registry of KMS nodes and application digests.\n– AppAuth: Per-application contract specifying quorum rules, allowed image\nhashes, and authorized enclaves.\nB.3 Workflow Phases\n1. Attestation: Enclave e produces quote Q\ne\n; verified against R.\n2. Secret Provisioning: MPC nodes compute k\nc\n, release to e if Q\ne\nis valid.\n3. Container Launch: Dstack-OS mounts RootFs, decrypts state σ\nc\nwith k\nc\n.\n4. Ingress Binding: TLS certificate X\nc\ngenerated inside e; bound to R(c).\n5. Audit Logging: Migration, key rotation, and governance events appended\nto H.\nB.4 Fault Tolerance\n– Vendor failure: μ enables re-deployment across Intel/AMD TEEs.\n– KMS compromise: key rotation via MPC thresholds restores forward/backward\nsecrecy.\n– Governance deadlock: ∆t fallback in Γ ensures quorum reduction and progress.\nB.5 Liveness Proof Sketch\nCombining MPC-based key recovery, quorum fallback, and portable containers\nyields:\n∀op∈O\nc\n,Pr[Exec(c, op) =⊤] = 1\nunder assumptions of f -resilient MPC nodes and at least one uncompromised\nTEE instance.\nC Detailed Benchmark Results\nThis appendix provides comprehensive benchmark statistics for both AWS Nitro\nEnclaves and Intel TDX environments. All operations are internal PASS state\nchanges that occur within the TEE with no blockchain network interaction.\nEach operation was executed 100 times per trial, with 10 independent trials\nper environment. The tables below show summary statistics including mean,\nstandard deviation, and range.\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets23\nTable 1. AWS Nitro Enclaves benchmark statistics (ops/sec) across 10 trials\nOperationMean Std Dev Min Max\nWallet Creation6,5315315,4467,042\nAccount Balance Queries530,943675 530,216 531,915\nInbox-to-Subaccount Claims14,856476 14,326 15,504\nInternal Subaccount Transfers32,9531,322 31,447 35,088\nWithdrawal Request Creation18,2911,254 15,873 19,608\nEnd-to-End Workflow35,6636,234 21,739 40,650\nTransaction History Queries3,757453,6503,802\nMulti-threaded Operations (5 threads) 32,189884 31,200 34,364\nLarge Dataset Processing48113467497\nTable 2. Phala dStack benchmark statistics (ops/sec) across 10 trials\nOperationMean Std Dev Min Max\nWallet Creation14,9704,6528,69624,390\nAccount Balance Queries935,428338,450 383,142 1,470,588\nInbox-to-Subaccount Claims33,0645,197 25,44541,667\nInternal Subaccount Transfers71,29217,623 47,170 101,010\nWithdrawal Request Creation39,7027,434 29,15551,813\nEnd-to-End Workflow78,43317,403 59,524 110,497\nTransaction History Queries7,6858726,4528,929\nMulti-threaded Operations (5 threads) 55,12416,744 28,32981,301\nLarge Dataset Processing72481636893\nC.1 AWS Nitro Enclaves Results\nC.2 Intel TDX Results\nC.3 Performance Analysis\nThe statistical analysis reveals several key insights about PASS’s internal oper-\nation performance:\n– Performance Consistency: AWS Nitro Enclaves demonstrate superior\nconsistency with lower standard deviations across all operations. The co-\nefficient of variation ranges from 0.1% (Account Balance Queries) to 17.5%\n(End-to-End Workflow).\n– Peak Performance: Intel TDX achieves higher mean throughput but with\nsignificantly greater variance. Standard deviations are 10-500x larger than\nNitro, indicating less predictable performance.\n– Production Considerations: These internal operation benchmarks demon-\nstrate PASS’s ability to handle thousands of wallet operations per second\nwithin the TEE, with the actual deployment bottleneck being blockchain\ntransaction submission rather than internal processing.\nThe statistical summary confirms that both platforms support practical PASS\ndeployment, with Nitro offering predictable performance and Intel TDX provid-\ning higher peak throughput at the cost of consistency.\n24J. Yu\nD Design Extensions\nD.1 Composability and InterPASS Transactions\nWhile PASS provides privacy and provenance guarantees for a single wallet in-\nstance, an important question is how multiple PASS wallets may interact. This\nis important in supply-chain use cases where each PASS represents a single com-\npany in the supply chain.\nTrivially, PASS A can send an on-chain transaction from its Outbox to PASS\nB’s EOA account, and this will land in the Inbox of PASS B, ready to claim.\nHowever, this undermines the privacy guarantees that PASS offers at the EOA\nlevel, and is undesirable in cases where inter-organizational asset transfers con-\ntain sensitive information, such as order details.\nWe propose a non-trivial approach inspired by cross-Payment Channel Net-\nwork (PCN) protocols such as XTransfer [?]. We can treat each PASS instance\nakin to a PCN hub node, with state L and transaction history H. As with\nXTransfer, we can assume a star topology of PASS nodes, with a central PASS\nHub in communciation with all PASS nodes. The PASS Hub will aggregate all\nInterPASS transactions T := {(a\ni\n,x\ni\n,s\ni\n,r\ni\n)}\nn\ni=1\n, where (a\ni\n,x\ni\n,s\ni\n,r\ni\n) represent\nthe asset, amount, sender, and receiver, each signed by the s\ni\nOutbox.\nThe Hub aggregates these signed payment intents, computes a netted settle-\nment plan S, and coordinates a secure multi-party update protocol to commit\nthe resulting balances, similar to Thora [?]. In the optimistic case, this process\ncompletes entirely off-chain, and each participant’s balance is updated in the\nPASS ledger without revealing the underlying transaction graph. If a dispute or\nfailure occurs, any participant may trigger an on-chain enforcement transaction\nthat finalizes S atomically via the direct transfer mechanism, thus guaranteeing\nsafety.\nThis approach leverages PASS ’s provenance and state design to make each\ninstance an atomic node in PCN-style systems like X-Transfer. Here, we outline\nhow PASS Hubs can enable confidential, auditable cross-organization transfers,\nwhile full formal specification and protocol implementation is deferred for future\nwork.\nD.2 Instantiation on zkVM\nThe design of PASS presented thus far relies on trusted execution environments\n(TEEs) such as AWS Nitro or Intel TDX to enforce provenance-based control.\nTEEs provide strong isolation and efficient execution, allowing internal transfers\nto remain private while ensuring that every outbox action has a verifiable lin-\neage. However, the trust model is anchored in hardware attestation: users and\nregulators must accept that the enclave executes the correct code as claimed.\nWhile sufficient for many organizational custody scenarios, this assumption lim-\nits transparency and long-term auditability. To address this limitation, we ex-\nplore an alternative instantiation of PASS in a zero-knowledge virtual machine\n(zkVM), replacing hardware trust with cryptographic proofs of correctness.\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets25\nZero-knowledge virtual machines (zkVMs) provide a proving environment in\nwhich arbitrary state machines can run with strong correctness guarantees [?].\nBy producing a succinct proof π of execution, zkVMs offer integrity assurances\nsimilar to TEEs but without reliance on vendor-specific hardware. This shift\nmakes zkVMs particularly suitable for contexts such as institutional custody,\nmulti-party supply chains, or inter-organizational accounting where external ver-\nifiability and regulator-grade auditability are paramount.\nIn a zkVM instantiation of PASS, the execution pipeline mirrors the enclave-\nbased design but replaces attestation with cryptographic proofs. The process\nproceeds in four stages:\n1. Batch formation. Transaction requests (claims, transfers, withdrawals) are\nfirst queued off-chain into a batch.\n2. zkVM execution. The zkVM program takes as private inputs: (i) the prior\nbatch’s commitments of the ledger L and provenance log H, (ii) the queued\ntransitions, including inbox I deposits and outbox O withdrawals, and (iii)\nthe proposed new commitments (L\n′\n,H\n′\n). Inside the zkVM, the transition\nfunction is replayed deterministically: starting from the previous roots, ap-\nplying all operations in sequence, updating balances and provenance entries,\nand checking consistency constraints.\n3. Proof generation. The zkVM outputs a succinct proof π certifying that the\nclaimed new roots (L\n′\n,H\n′\n) are correct with respect to the given transition\nset.\n4. On-chain verification. A minimalist verifier contract validates π, updates\nthe recorded commitments, and enforces any pending outbox operations.\nThis ensures that every external action has a verifiable provenance path\nwhile internal transfers remain private.\nCompared to TEEs, zkVMs strengthen the verifiability model by eliminat-\ning hardware trust assumptions, but incur higher computational and financial\ncosts due to proof generation and on-chain verification. Batching amortizes these\ncosts, raising open research questions about optimal batch sizes, data availabil-\nity strategies, and proof system selection. zkVM backends such as Risc0, SP1,\nor Plonky3 offer different tradeoffs in proof size, verification cost, and latency.\nHybrid deployments are also possible: TEEs can serve as fast-path executors for\nintra-day operations, with zkVM proofs generated periodically to provide cryp-\ntographic audit trails. This hybrid pattern resembles optimistic rollups, where\nfast execution is combined with verifiable settlement.\nFinally, this instantiation aligns closely with the Chainless stack architec-\nture [?], which emphasizes the separation of execution, trust, bridging, and set-\ntlement. In this view, zkVM proofs naturally inhabit the execution and trust\nlayers, Inbox/Outbox commitments integrate with bridging, and the verifier\ncontract finalizes settlement. This layered design opens the door to modular,\ninteroperable deployments of PASS across heterogeneous chains and domains.\nFull formal specification, performance benchmarking, and exploration of hybrid\nzkVM–TEE implementations remain important avenues for future work.\n26J. Yu\nFig. 6. PASS instantiation inside a zkVM: Inbox I and Outbox O transitions are\napplied to the Ledger L and Provenance H, producing new state commitments. The\nzkVM outputs a proof π, which the on-chain verifier checks before updating roots and\nenforcing outbox operations."
}
]
}
]Response:
To address the question—**why existing works cannot satisfy the three use cases in the Introduction, and why a provenance- and TEE-based solution (PASS) is superior**—we must examine both the requirements of the use cases and the limitations inherent in the prevailing wallet architectures, as articulated in the Introduction and Background sections.
---
## 1. Why Existing Works Cannot Satisfy the Three Use Cases
The three use cases from the Introduction are:
1. **AI and Smart Agent Transactions**: AI agents managing assets require bounded authority and access guardrails.
2. **Enterprise Payroll Privacy**: Organizations need to distribute salaries and budgets without revealing sensitive on-chain details.
3. **Consumer-grade Central Limit Order Books (CLOBs)**: Real-time, high-throughput trading requires low gas costs and minimal user key management.
Let us analyze how mainstream solutions fall short for each.
### a. **EOAs (Externally Owned Accounts)**
- **Control Model**: Single private key = total, unilateral control.
- **Limitations**:
- _AI & Smart Agents_: No way to delegate or restrict authority; giving an AI the private key grants it full, irrevocable power.
- _Payroll Privacy_: All transfers are public, so salary disbursements are visible on-chain.
- _CLOBs_: Every action is a public, gas-consuming transaction; no support for high-frequency, low-latency trades or batch operations.
### b. **Multisignature Wallets**
- **Control Model**: t-of-n co-signers must approve each action.
- **Limitations**:
- _AI & Smart Agents_: No fine-grained or scoped delegation—either a key is part of the quorum or not; cannot limit by asset, amount, or domain.
- _Payroll Privacy_: All actions and policies are publicly visible; internal logic is on-chain and auditable by anyone, leaking salary and budget flows.
- _CLOBs_: High on-chain overhead for every trade due to multi-party signatures; not suitable for fast, gasless, internalized operations.
### c. **Smart Contract Wallets (e.g., ERC-4337, Account Abstraction)**
- **Control Model**: On-chain policy logic, programmable rules.
- **Limitations**:
- _AI & Smart Agents_: Policies are programmable but public; any delegation or restriction is visible and can be front-run or censored.
- _Payroll Privacy_: Every policy execution is public and incurs gas; internal flows cannot be hidden.
- _CLOBs_: On-chain execution is required for every action, leading to prohibitive gas costs and latency for high-frequency trading.
### d. **Custodians (RBAC/ABAC Engines)**
- **Control Model**: Off-chain access policies, custom APIs.
- **Limitations**:
- _AI & Smart Agents_: Custom policy languages proliferate; off-chain enforcement is opaque, and the custodian sees all internal activity.
- _Payroll Privacy_: Custodian observes all internal flows; privacy is lost at the custodian, even if not on-chain.
- _CLOBs_: Custodians may support batching, but users must trust the custodian’s infrastructure and APIs, introducing centralization and privacy risks.
### e. **TEE-based Wallets (e.g., Liquefaction)**
- **Control Model**: TEE holds the key and enforces sub-policies.
- **Limitations**:
- _AI & Smart Agents_: Liquefaction can enforce sub-policies, but the model is more complex (key encumbrance trees), and depends on specialized smart contracts (e.g., Oasis), limiting compatibility.
- _Payroll Privacy_: Internal logic is hidden, but deployment is limited to specific chains (Oasis), reducing flexibility.
- _CLOBs_: Throughput is lower due to reliance on blockchain oracles for validation, leading to significant latency.
#### **Summary Table (from the paper):**
| Model | Internal Privacy | On-chain Overhead | Compatibility | Granularity of Control |
|---------------|-----------------|-------------------|--------------------|-----------------------------|
| EOA | None | None | Native EOA | None |
| Multisig | None | High | Contract-based | Symmetric, coarse |
| Smart Wallet | None | Med–High | ERC-4337 required | Programmable, public |
| Custodian | At custodian | None | API-mediated | Off-chain, opaque |
| Liquefaction | Strong (TEE) | Medium | Oasis only | Policy trees, TEE-enforced |
| **PASS** | Strong (TEE) | None | Native EOA + TEE | Provenance, fine-grained |
---
## 2. Why Provenance- and TEE-based Control (PASS) Is Superior
PASS’s core architectural innovations directly address the above shortcomings:
### a. **Provenance-based Control**
- **Assets are controlled based on their custody history (provenance), not identity or roles.**
- **Inbox–Outbox Model**: All external deposits are tracked in an Inbox; subaccounts must claim assets, establishing a clear lineage.
- **Internal Transfers**: Are private (off-chain), fee-less, and invisible to external observers. Only withdrawals (Outbox) are on-chain, preserving privacy and minimizing gas.
### b. **TEE Enforcement**
- **Private key is held exclusively in the TEE**; never accessible to users or operators.
- **All policy logic and provenance checks are enforced within the hardware-isolated enclave**, guaranteeing that even privileged insiders cannot subvert controls or observe internal flows.
- **Remote attestation** allows external parties to verify that the correct code is running inside the enclave.
### c. **Alignment with Use Cases**
- _AI & Smart Agents_: Can be given sub-accounts with limited provenance-based authority (e.g., capped balances, domain-specific permissions), preventing overreach or misuse. If compromised, the AI can only affect its own subaccount.
- _Payroll Privacy_: Salaries and departmental budgets are distributed internally, off-chain, with only aggregate payouts visible on-chain. Internal transfers are invisible, so sensitive information is not leaked.
- _CLOBs_: High-frequency, gasless internal trading is possible, with only net settlements (batch withdrawals) posted on-chain. Users do not have to manage keys; the enclave orchestrates all actions securely.
### d. **Compatibility and Efficiency**
- **Native EOA Compatibility**: No need for custom smart contracts, chain modifications, or special APIs. Works with existing wallet infrastructure.
- **No On-chain Overhead**: All internal logic is off-chain; only withdrawals incur gas, and those can be batched.
- **High Throughput**: Benchmarks show sub-millisecond internal operations, far outpacing TEE-based systems that require blockchain oracles.
### e. **Formal Guarantees**
- **Proven security properties** (privacy, accessibility, provenance integrity) are formalized and machine-checked, not just informally claimed.
- **Auditability**: Provenance logs can be selectively revealed for compliance or audit, without disclosing full internal state.
---
## 3. Logical Synthesis
**Existing solutions are fundamentally limited by their control models:**
- _Identity and role-based controls_ are awkward and brittle in blockchain’s exogenous asset environment, where assets are not natively tied to wallet identities.
- _Public policy logic_ (smart contracts, multisigs) leaks sensitive information and incurs high gas costs.
- _Custodial and off-chain solutions_ reintroduce centralization and erode privacy at the operator level.
- _TEE-based approaches_ without provenance logic (or with complex policy trees) lack compatibility, efficiency, or formal guarantees.
**PASS, by enforcing control via asset provenance and isolating all sensitive logic within a TEE, directly matches the requirements of emerging use cases:**
- _Fine-grained, auditable, and private delegation for AI and agents_
- _Internal privacy and regulatory auditability for enterprise payroll_
- _Scalable, gasless, and private operation for consumer-grade trading, without user key management overhead_
**Therefore, provenance- and TEE-based control is not just incrementally better, but fundamentally more aligned with the needs of modern, multi-actor, privacy-sensitive blockchain applications.** The formalization, efficient implementation, and demonstrated compatibility of PASS further reinforce its superiority as a solution.
Model: gpt-4.1-2025-04-142025-09-15 12:32:08
Context:
[
{
"role": "system",
"content": "You are a research paper writer. You focus on:\n1. logical consistency\n2. whether the story is persuasive\nDon't try to be friendly on purpose, judge everything based on the logic and expressiveness."
},
{
"role": "user",
"content": [
{
"type": "text",
"text": "Use the contents of Introduction and Background, answer my question.\n\nMy target is to demonstrate that the existing works cannot satisfy the three use cases in Introduction, and also explain why provenance- and TEE-based solution is a better solution for this.\n\nI think a good way to write about this is \n\n1. summarize the common challenges in the three use cases\n2. give a short but insightful elaboration that the existing works have limitations, so cannot solve this\n3. explain why our work can solve this"
},
{
"type": "text",
"text": "main.pdf\nPASS: A Provenanced Access Subaccount\nSystem\nfor Blockchain Wallets\nJay Yu\n1,2\n1\nStanford University [email protected]\n2\nPantera Capital [email protected]\nAbstract. Blockchain wallets still follow a single-entity ownership model:\npossession of a private key grants unilateral control. This assumption is\nbrittle for emerging settings such as organizational custody, shared gov-\nernance, and AI agent wallets, where multiple actors must coordinate\nwithout exposing secrets or leaking internal activity.\nWe present PASS, a Provenanced Access Subaccount System\nthat replaces role or identity-based control with provenance-based con-\ntrol: assets can only be used by subaccounts that can trace custody back\nto a valid deposit. A simple Inbox–Outbox mechanism ensures all exter-\nnal actions have verifiable lineage, while internal transfers remain private\nand indistinguishable from ordinary EOAs.\nWe formalize PASS in Lean 4 and prove core invariants, including\nprivacy of internal transfers, asset accessibility, and provenance integrity.\nWe implement a prototype with enclave backends on AWS Nitro Enclaves\nand dstack Intel TDX, integrate with WalletConnect, and benchmark\nthroughput across wallet operations. These results show that provenance-\nbased wallets are both implementable and efficient. PASS bridges today’s\ngap between strict self-custody and flexible shared access, advancing the\ndesign space for practical, privacy-preserving custody.\n1 Introduction\nCryptocurrency wallets conventionally assume one key, one owner. In this single-\nentity ownership (SEAO) model, whoever holds the private key gains permanent\nand total control of the address, and casts publicly readable, gas-consuming\nblockchain transactions. However, this model struggles to adapt to emerging\nblockchain scenarios:\n1. AI and Smart Agent Transactions. AI agents increasingly manage crypto\nassets [?,?] and require bounded authority and access guardrails for users’\nasset security.\n2. Enterprise Payroll Privacy. Organizations need to distribute salaries and\ndepartmental budgets to employee accounts without revealing sensitive de-\ntails on-chain [?,?,?].\n2J. Yu\n3. Consumer-grade Central Limit Order Books. On-chain order books\nface high gas costs and latency that prevent real-time trading at scale [?,?],\nand many consumers prefer not to manage their own keys [?,?].\nIn practice, many organizations confronted with these challenges default to\ncustodians or policy engines that wrap access logic in Role-Based Access Con-\ntrol (RBAC) or Attribute-Based Access Control (ABAC) [?,?]. These systems\nintroduce a proliferation of bespoke policy languages and APIs to specify who\nmay sign or transfer under which conditions [?,?]. While workable as a stopgap,\nthey inherit identity and role assumptions from traditional IT settings that limit\ntheir flexibility and scalability in blockchain contexts.\nThe limitation stems from a mismatch of models. Traditional access-control\nframeworks such as RBAC and ABAC assume an endogenous setting: users\ncreate and manage their own files, objects, or services, and policies are attached\nto these identities or roles. Blockchains are fundamentally exogenous: assets are\ncreated outside the wallet by smart contracts and transferred permissionlessly\nin. In this setting, identity or role-based rules are awkward to express and brittle\nto enforce. What matters instead is provenance: who deposited an asset, and how\nit flowed within the wallet.\nWe propose PASS, a Provenanced Access Subaccount System that enforces\ncontrol directly by provenance. The core mechanism is simple: an Inbox records\nexternal deposits, an Outbox signs and broadcasts withdrawals, and all internal\nmovements remain private and fee-less. Every unit of value inside the wallet has\na verifiable lineage to an on-chain deposit, while externally a PASS wallet is\nindistinguishable from a standard EOA. Our contributions include:\n– A provenance-based access model aligned with blockchain’s exogenous asset\ncreation, enforced through an Inbox–Outbox design.\n– A formal model in Lean 4 proving privacy, accessibility, and provenance\nintegrity.\n– A prototype with multi-vendor enclave backends (AWS Nitro, Intel TDX via\ndstack), a web app frontend integrated with WalletConnect, together with\nthroughput benchmarks.\n– Application scenarios, including organizational custody, privacy-preserving\ntransfers, and safe delegation to AI agents.\nPASS thus bridges the gap between strict self-custody and flexible shared\naccess, combining strong privacy guarantees with practical deployability.\n2 Background and Related Work\nGrowing retail and institutional adoption of digital assets [?] has driven diverse\nwallet designs [?]. We summarize mainstream Ethereum Virtual Machine (EVM)\nwallet designs in Figure ??.\nEOAs and Multisigs. Externally Owned Accounts (EOAs) give unilateral,\npermanent control to whoever holds the private key [?]. Multisignature wallets\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets3\nModelControl basisOn-chain\noverhead\nInternal\nPrivacy\nCompatibility\nEOASingle private keyNoneNoneNative EOA\nMultisigt-of-n co-signersHigh; quorum per\naction\nNone; logic\npublic\nSmart\ncontract based\nERC-4337\nSmart\nAccounts\nOn-chain policy\nlogic\nMedium to high;\ncustom logic and\ngas\nNone; logic\npublic\nRequires\nERC-4337\nchain support\nCustodiansCustom RBAC or\nABAC languages\nNone; Off-chain\nenforcement\nCustodian sees\nall activity\nAPI mediated\nLiquefactionTEE key\nencumbrance;\npolicy trees\nMedium; Oasis\ncontracts and gas\nStrong; TEE\nhides\nsubpolicies\nRequires Oasis\ndeployment\nPASS\n(ours)\nProvenance via\nInbox-Outbox\nNone; EOA\ncompatible\nStrong;\ninternal\ntransfers\ninvisible\nNative EOA\nplus off the\nshelf TEEs\nFig. 1. Comparison of wallet architectures. PASS features provenance-based control,\noff-chain privacy, and native EOA compatibility.\n(eg., Safe) distribute trust via t-of-n approvals [?], common for treasuries and\nbridges [?,?,?]. Drawbacks include quorum overhead, symmetric authority, and\npublic logic with attackable frontends [?]. In contrast, PASS offers fine-grained,\nscoped permissioning without new contracts.\nSmart Contract Wallets and Account Abstraction. Wallets like Ar-\ngent and Loopring add programmability (social recovery, spend limits) via on-\nchain logic [?,?,?]. ERC-4337 enables custom validation through UserOperation\ncontracts [?], and EIP-7702 lets EOAs invoke this logic [?]. These increase flex-\nibility but expose policies publicly and incur gas costs, limiting use cases like\npayroll. PASS instead enforces policy privately in a TEE, minimizing on-chain\nfootprint.\nCustodial Policies. Custody providers (Fireblocks, Turnkey, Privy) use\nRBAC/ABAC engines with custom policy languages [?,?]. PASS replaces these\nwith provenance: authority follows asset origin and history, akin to a UTXO\nmodel. This reduces policy-surface complexity while remaining composable with\nconstraints like whitelists and blacklists.\nTEEs and Liquefaction. Trusted Execution Environments (TEEs) provide\nhardware-isolated contexts with remote attestation [?,?]. Liquefaction [?] keeps\nwallet keys in a TEE and enforces sub-policies via key encumbrance, ensuring\nprivacy. PASS advances this model by (i) proving invariants in Lean 4, (ii) sim-\nplifying enforcement to a provenance rule with Inbox/Outbox subaccounts, and\n(iii) working with a standard EOA without relying on Oasis smart contracts\n[?]. We further validate by implementing PASS on AWS Nitro Enclaves and In-\ntel TDX (via dStack), and showcase applications including AI wallets, payroll,\nsupply chains, and DAO voting.\nOther Models. Exchanges pool funds in omnibus addresses with off-chain\nledgers [?]; mixers like Tornado Cash hide deposit–withdrawal links [?]. PASS\n4J. Yu\nsimilarly hides internal transfers while retaining a provenance log for auditability;\noutsiders see only deposits and withdrawals.\n3 System Model and Design\nFig. 2. Overview of PASS. External deposits enter the Inbox and are claimed by sub-\naccounts. Internal transfers are private and off-chain. Egress occurs via the Outbox,\nwhich signs and broadcasts on-chain transactions. All on-chain activity has clear prove-\nnance; internal movements remain private.\n3.1 High level system model\nPASS is a multi-user wallet on a single EOA (sk, pk). The wallet maintains a\nfinite set of subaccounts U ={u\n1\n,...,u\nn\n} and a set of assets A (e.g., ERC-20).\nA subaccount u ∈ U has authority over an amount x of asset α ∈ A iff it can\nobtain a signature from the global sk via the enclave; sk resides only inside a TEE\nand is never directly accessible. We give the intuitive model here and formalize\nit in Section ??.\nInternally, PASS tracks balances with a map L : U ×A →Z\n≥0\n(accessed\nvia L[u][α]), an Inbox multiset I of unclaimed deposits (α,x,m), an Outbox\nFIFO queueO of pending on-chain actions (α,x, extDst,ν) together with a global\nnonce ν ∈N, and an append-only provenance logH. The core principles of PASS,\nas shown in Figure ?? are as follows:\n1. Access follows provenance. A unit of value is usable by u only if there\nexists a custody chain in H from an external deposit to u. Informally,\nAllow(u,α,x) means balance x is reachable for u via provenance in H. This\nimplies consistency : for every α, the total internal balance equals the on-\nchain balance at pk, i.e.,\nP\nu∈U\nL[u][α] = B\non\n(α). Incoming deposits (α,x,m)∈\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets5\nI are “wrapped” and must be explicitly claimed before use by the sender\naddress.\n2. Off-chain privacy. Internal transfers u→ v update only L and H; they do\nnot touch O or the on-chain balance B\non\n, so internal flow is invisible and\nfee-less.\n3. First-come, first-served. Outbox transactions are sequenced by a FIFO queue,\nwhich maintains and increments a global nonce ν and directly sends enclave-\nsigned transactions to a RPC node to prevent nonce conflicts and replay\nattacks.\n3\nOrganizational Ownership Model. PASS operates under an organiza-\ntional ownership model, where an entity such as a company, individual, or DAO\nmanages shared control over blockchain assets. We detail the threat model in\nSection ??.\nInbox-Outbox Gateway External senders transfer assets to pk, creating\nInbox entries (α,x,m) ∈ I. A user performs claim(u,α,x,m) to move value\nintoL[u][α], conceptually “wrapping” the deposit. To withdraw or interact with\na contract, a subaccount first performs an internal transfer to the Outbox,\nwhich enqueues (α,x, extDst,ν); the enclave then signs the concrete transaction\nwith sk and immediately broadcasts it, incrementing ν. The FIFO discipline and\nglobal nonce serialize actions and prevent races and double-spends. Because sub-\naccounts never receive pre-signed transactions, pre-signing misuse is mitigated.\nComposable policy scheme. Deposits are claims fromI; internal transfers\nrequire Allow(u,α,x) and update (L,H); withdrawals are internal transfers to\nO followed by submission. Additional constraints (eg., RBAC or ABAC checks,\nwhitelists and blacklists) can be incorporated as conjuncts to Allow without\nchanging the provenance-centric rule or its consistency and privacy effects.\n3.2 Formal Model\nWe formalize PASS as a transition system in Lean 4\n4\n, an interactive theorem\nprover with a rich dependent type system [?], suitable for policy verification (eg.,\nAWS Cedar [?]). In this section, we introduce the formal system we modeled in\nlean, and in Section ?? we will discuss security invariants modeled. An extended\ndiscussion of our formal verification system can be found in Appendix ??.\nState. A wallet state is S =\n\u0000\npk, sk,ν,I,O,L,H\n\u0001\nwhere (pk, sk,ν) are the\nEOA public key, private key (generated and held in the TEE), and global nonce;\nI and O are Inbox and Outbox; L is the internal balance map L[u][α] ∈Z\n≥0\n;\nandH is the provenance history. For privacy arguments we also use the external\nview W\npub\n= (pk,O,A), where O contains the Outbox queue and nonce and A\nrecords total on-chain balances by asset.\n3\nWe assume that the TEE is able to run a Helios light client, as is the case in dstack\nIntel TDX, discussed and implemented in Section ??\n4\nLean 4 model: https://github.com/pass-wallet/pass-lean4-proofs\n6J. Yu\nPASS Wallet Management Functionality F\nΣ\nPASS\nfor wallet W\nGlobal State:\npk : public address (EOA)\nsk : private key (in TEE)\nν: global nonce for on-chain transactions\nI (Inbox): set of unclaimed deposits (α : asset,x : amount,m : depositId)\nO (Outbox): FIFO queue (α,x, extDst,ν)\nL (Asset Ledger): internal map L[u][α]∈ Z\n≥0\n, where u is each user’s ID in the system\nH (Provenance History): a list of transaction records appended whenever ClaimInbox,\nInternalTransfer, or Withdraw is invoked\nCreatePassWallet (creator ):\nI← ∅, O← ∅, L←{}; ν← 0\n(pk, sk )← TEE\nKeyGen()\nReturn new W with S =\n\u0000\npk, sk,ν,I,O,L,H\n\u0001\nand reference to creator\nInboxDeposit (α,x,m) from external P :\nI ← I ∪ {(α,x,m)}\nReturn success\nClaimInbox (α,x, depositId) from u:\nIf no (α,x,m) with depositId in I, return ⊥\nRemove (α,x,m) from I\nL[u][α]←L[u][α] + x\nH←H| (op = claim,α,x, depositId,u)\nReturn success\nCheckAllow (u\nsend\n,α,x,H):\nIf H.GetProvenance(α, u\nsend\n)≥ x,\nreturn true; else return false\nInternalTransfer (α,x,u\nsend\n,u\nrecv\n):\nIf L[u\nsend\n][α] < x or ¬checkAllow(u\nsend\n,α,x,H), return ⊥\nL[u\nsend\n][α]←L[u\nsend\n][α]− x\nL[u\nrecv\n][α]←L[u\nrecv\n][α] + x\nH←H\n\f\n\f\n\u0000\nop = transfer,α,x,u\nsend\n,u\nrecv\n\u0001\nReturn success\nWithdraw (α,x,u\nsend\n, extDst):\nIf L[u\nsend\n][α] < x or ¬checkAllow(u\nsend\n,α,x,H), return ⊥\nL[u\nsend\n][α]←L[u\nsend\n][α]− x\nO ←O∪{(α,x, extDst,ν)}\nH←H | (op = withdraw,α,x,u\nsend\n, extDst)\nReturn success\nSignGSM (dom, msg,u):\nIf u lacks sign-right for (dom, msg), return ⊥\nσ ← (sk, msg)\nReturn σ\n(Outbox Processing) (periodic or on demand):\nIf O ̸= ∅, dequeue (α,x, extDst,ν)\nBuild tx τ : transfer x of α to extDst, nonce = ν\nσ ← (sk, τ ); broadcast (τ,σ)\nν←ν + 1\nReturn broadcasted + txHash\nFig. 3. Formal Model of PASS wallet functionality, including CreatePassWallet for\ninitializing a fresh instance. On creation, pk is set to a chosen EOA address eoa, the\nTEE generates a hidden private key sk , and global data structures are initialized.\nExternal deposits enter I (Inbox), while subaccount transfers update L (Ledger) off-\nchain. Withdrawals queue items in O (Outbox), and GSM operations are signed using\nsk .\nTransitions. Operations op∈ T update S with type-checked rules: InboxDe-\nposit adds an unclaimed (α,x,m) to I; ClaimInbox moves (α,x,m) from I to\nL[u][α] and appends to H; InternalTransfer moves value between subaccounts;\nWithdraw debits L[u][α], enqueues (α,x, extDst,ν) in O, and logs; SignGSM\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets7\nauthorizes domain-scoped signable messages. A representative rule is:\n\u0000\npk, sk,ν,I,O,L,H\n\u0001\ntransfer(α,x,u\ns\n,u\nr\n)\n−−−−−−−−−−−→\n\u0000\npk, sk,ν,I,O,L\n′\n,H\n′\n\u0001\nwith\nif L[u\ns\n][α] < x or ¬checkAllow(u\ns\n,α,x,H) then ⊥;\nL\n′\n[u\ns\n][α] =L[u\ns\n][α]− x, L\n′\n[u\nr\n][α] =L[u\nr\n][α] + x;\nH\n′\n=H\n\f\n\f\n\u0000\nop = transfer,α,x,u\ns\n,u\nr\n\u0001\n.\nHere checkAllow queries provenance inH and can be extended with auxiliary\nconstraints such as user whitelists or blacklists, without changing the core rule.\nFigure ?? provides a formal specification of the methods in a PASS wallet.\n3.3 Asset Model and General Signable Messages\nPASS provides an authorization scheme over a heterogenous set of assets A, in-\ncluding fungible tokens, such as ether and ERC-20 tokens, ERC-721 non-fungible\ntokens, and “general signable messages” across a variety of DApps for sign-in\nand identity verification. Each asset α ∈ A has a well-defined custody path in\nthe provenance log H, and a subaccount u ∈ U has usable balance x of α iff\nAllow(u,α,x) holds.\nToken assets. For token assets such as ether, ERC-20, and ERC-721, de-\nposits are captured as Inbox entries (α,x,m) ∈ I. Claims allocate balance into\nL[u][α], internal transfers update L and H privately, and withdrawals enqueue\n(α,x, extDst,ν) intoO for enclave signing and on-chain broadcast, ensuring con-\nsistency where:\n∀α∈A\ntokens\n:\nX\nu∈U\nL[u][α] = B\non\n(α, pk).\nIn particular, ERC-721 tokens are modeled as unitary balances (x ∈ {0, 1})\nwhose transfers preserve uniqueness under provenance.\nGeneral Signable Messages (GSMs). In addition to on-chain assets,\nwallets often sign arbitrary messages, such as for EIP-4361 [?] logins and off-\nchain DAO votes [?]. PASS models these as a special classA\nGSM\nof virtual assets.\nEach GSM asset is scoped to a domain dom, so holding α = (dom) represents\nauthority to sign messages from that domain. A signature operation:\nSignGSM(u, dom,m)7→ σ\nis permitted iff Allow(u, dom, 1) holds in H. At key generation, the wallet\ncreator is endowed with default signing authority over all domains, represented\nas an initial allocation of every α = (dom)∈A\nGSM\nto the root subaccount. These\ndomain assets can be internally transferred to delegate signing authority. Thus\nprovenance of GSMs begins at the owner and flows through transfers, providing\na well defined provenance path in H as with token assets.\n8J. Yu\nBy treating both tokens and GSMs as types of elements ofA, PASS provides\na unified provenance rule for subaccount authorization. A subaccount cannot\nspend an ERC-20 token, transfer an NFT, or sign a domain message unless it\npossesses the corresponding asset under L and H. This unified authorization\nscheme allows for fine-grained delegation, (eg., giving u rights over example.com\nwhile withholding ERC–20 funds) and consistent enforcement across on-chain\nand off-chain actions.\n4 Properties of PASS\n4.1 Threat Model\nPASS assumes an organizational ownership model, where a single entity, such\nas a company, individual, or DAO manages the EOA (pk,sk), brokers access\nbetween many users in that entity, and chooses the TEE infrastructure vendor\n(eg. AWS Nitro, dstack Intel TDX, self-hosted hardware). This model is typical\nfor use cases such as private payroll, supply chains, and AI delegation described\nin Section ??. Protected assets in PASS include the private key sk, the balance\nledger L and provenance log H, and the correctness of Allow(u,α,x) for all\nu∈ U,α∈A,x. In our model, we make the following trust assumptions:\n1. TEE integrity. Hardware isolation is sound; sk never leaves the enclave.\nRemote attestation guarantees that the enclave runs the genuine PASS bi-\nnary.\n2. Cryptography. Standard primitives (signatures, hash functions, PRFs) are\nsecure against polynomial-time adversaries.\n3. Governance majority. The deploying entity holds majority control in the\ngovernance mechanism (via DAO vote or admin privileges), ensuring it can\ninvoke the blockchain-governed KMS for MPC-based key recovery and trig-\nger fallback contracts when needed.\nAdversary Model. An adversary A may control the host OS and network,\nobserve or modify all communication with enclaves, and submit arbitrary trans-\naction requests. In particular, A may attempt to:\n– Exploit software bugs in the PASS implementation or TEE runtime,\n– Forge or replay transactions to break consistency of H,\n– Subvert provenance by violating Allow(u,α,x)\nThreats Out of Scope. On the other hand, PASS does not protect against:\n– Physical compromise of TEE hardware (tampering, microarchitectural side-\nchannels, chip decapsulation),\n– Supply-chain backdoors in TEE manufacturing,\n– Fully malicious operators with unrestricted physical access.\nThese are excluded because the organizational model assumes controlled facilities\nand vetted hardware.\nSecurity Goals. Given the assumptions above, PASS guarantees:\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets9\n1. Integrity:\nP\nu∈U\nL[u][α]≤ extDep(α) for all α, i.e., no assets can be created\nor double-spent internally.\n2. Correctness: If Allow(u,α,x) holds, then u can eventually realize x via\nWithdraw.\n3. Privacy on-chain: InternalTransfer operations do not affect externalTrace(W ),\nand to external observers, a PASS wallet is indistinguishable from an EOA.\n4. Liveness: For any authorized op ∈ Ops, if one enclave and quorum remain\nhonest, then ∃τ s.t. Exec(c, op) =⊤ within τ\n4.2 Privacy and Safety\nAfter establishing the threat model of PASS, we will address the central privacy\nand safety guarantees in our formal verification model. We sketch three central\nlemmas here, and create mechanized proofs in Lean, discussed in Appendix ??.\nProposition 1 (Internal Transfer Privacy). If two public states W\n1\n,W\n2\nshare the same pk, identical Outbox (T,ν), and equal per-asset totals in A, then\nexternalTrace(W\n1\n) = externalTrace(W\n2\n).\nProof Sketch. InternalTransfer updates only (L,H), never O or total on-chain\nbalances. OutboxProcessing in Figure ?? emits on-chain actions solely from O\n(lines 2–4), hence the trace depends only on O.\nCorollary: EOA indistinguishability. If W\npass\nand W\neoa\nshare the same pk,\nOutbox, and per-asset totals, then\nexternalTrace(W\npass\n) = externalTrace(W\neoa\n).\nThus, from an external observer’s perspective, a PASS account is indistinguish-\nable from a standard EOA: internal transfers leave no observable footprint.\nProposition 2 (Asset Accessibility). For any asset α, letting L = {u |\nL[u][α] > 0},\nX\nu∈L\nL[u][α] = totalBalance(α),\nand each u∈ L can spend its full balance subject to checkAllow.\nProof Sketch. ClaimInbox creditsL; InternalTransfer preserves the sum over u;\nWithdraw debitsL and enqueues toO, which OutboxProcessing realizes on-chain.\ncheckAllow enforces reachability from provenance in H.\nProposition 3 (Provenance Integrity). Let extDep(α) be net external de-\nposits (deposits minus realized withdrawals). For all reachable states,\nX\nu\nL[u][α] ≤ extDep(α).\n10J. Yu\nProof Sketch. Induct on transitions. InboxDeposit increases extDep only; Claim-\nInbox moves already-deposited value into L; InternalTransfer conserves the sum\nover u; Withdraw decreases the sum, and after OutboxProcessing broadcasts,\nextDep is reduced accordingly.\nGeneral signable messages (GSM). Model GSM rights as a domain-\nscoped virtual asset class A\nGSM\n. Let α = (dom)∈A\nGSM\nand permit\nSignGSM(u, dom,m) iff Allow(u,α, 1).\nThen (P2)–(P3) lift to GSM: there is always at least one domain signer, and\nGSM “balances” obey provenance conservation under transfers in H.\n4.3 Liveness\nWe define liveness as the property that any authorized operation remains even-\ntually executable, despite enclave crashes, vendor compromise, or partial gover-\nnance failure. Our model assumes deployment of PASS access logic on dstack,\nimplemented in Section ?? and detailed in Appendix ??.\nLet E denote active enclaves, C containerized wallet backends, and P gover-\nnance policies. Each container c∈C stores sealed state\nσ\nc\n=⟨S,k\nc\n, meta⟩ with S = (pk, sk,ν,I,O,L,H),\nwhere k\nc\n= Derive(K,c) is derived from an MPC-managed KMS and meta records\nattestation. An operation op ∈ Ops (deposit claim, transfer, withdrawal) ex-\necutes as: Exec(c, op) = ⊤ iff Attested(c)∧ Γ (S), where Attested(c) checks σ\nc\nagainst registry R and Γ is the quorum predicate over P. To ensure vendor-\nagnostic portability, state migration μ :E →E satisfies\n∀e\ni\n,e\nj\n∈E, e\nj\n.decrypt(σ\nc,e\ni\n,k\nc\n) = σ\nc,e\ni\n,\nTheorem 1 (Liveness Theorem). If (i) the MPC KMS tolerates f\nKMS\nfaults\nin a t-of-n threshold, (ii) governance quorums are f\ngov\n-resilient, and (iii) at least\none enclave is uncompromised, then every op∈ Ops executes within bounded time\nτ :\n∀op∈ Ops, ∃τ ≥ 0 : Exec(c, op) =⊤.\nProof Sketch. Progress follows from three guarantees: (1) the MPC KMS\nensures k\nc\nis always recoverable under threshold availability; (2) Γ encodes quo-\nrum rules that eventually relax after timeout ∆t, ensuring some subset S satisfies\nΓ (S) = ⊤; (3) migration μ allows any enclave to re-host σ\nc\n, preventing vendor\nlock-in or enclave failure from blocking execution. Algorithm ?? formalizes re-\ncovery and execution under these assumptions.\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets11\nAlgorithm 1 RecoverAndExecute(c, op)\n1: Verify enclave e attestation Q\ne\nagainst R.\n2: Derive k\nc\n← Derive(K,c); decrypt σ\nc\n.\n3: if CompromiseDetected(e\n′\n) then\n4:Rotate k\nc\nand re-encrypt σ\nc\n.\n5: end if\n6: Ensure Γ (S) =⊤ for S ⊆P(c).\n7: Execute op; append to H.\nKey Properties. (1) Portability: any attested enclave can recover σ\nc\n, in-\ndependent of vendor; (2) Monotonic Recovery: recovery steps form ρ : S → S\nwith ρ(s)⪰ s; (3) Domain Continuity: certificates remain bound to R(c) under\nmigration μ(c), preventing hijack or replay.\nImplementation details of container orchestration, attestation, and KMS pro-\ntocols are given in Appendix ??.\n5 Practical Implementations\n5.1 Prototype Implementations\nTo demonstrate feasibility, we have implemented a prototype of PASS that cap-\ntures the core architectural components.\n5\nThe prototype consists of:\n– Provenanced Access Model, the core PASS architecture outlined in Sec-\ntion ?? with the Inbox-Outbox structure, asset ledgers, and provenanced\nrule as a Rust executable.\n– Web Application Frontend, an AWS-hosted Typescript interface that\nallows users to deposit assets, initiate internal transfers, generate on-chain\ntransactions, and sign arbitrary messages on Ethereum Sepolia testnet.\n6\n– Multi-vendor TEE deployment, we deploy the PASS enclave executable\nin both AWS Nitro Enclaves and Intel TDX with the dstack framework.\nWe evaluate these two enclave deployments as complementary deployment\npaths, each with distinct tradeoffs.\nAWS Nitro Enclaves. In this design, PASS runs inside a Nitro enclave in the\nAWS cloud. The enclave executes the Inbox–Outbox logic, enforces provenance\nchecks, and signs transactions, while the provenance ledger is stored externally.\nNitro’s attestation and AWS integration simplify deployment, but reliance on a\nsingle vendor limits portability and concentrates trust. As a result, some guaran-\ntees of PASS, particularly liveness and asset accessibility, may be weaker under\nthis model.\n5\nPrototype can be found here: https://github.com/jayyu23/pass-wallet-app\n6\nWeb application: https://pass-wallet.jayyu.xyz/\n12J. Yu\nIntel TDX with dstack. dstack provides a portable, open-source runtime for\nTEEs across diverse hardware. PASS can be deployed on enclaves run by decen-\ntralized operators, with key material secured via MPC-based key management.\nBoth Inbox–Outbox logic and the provenance ledger execute inside dstack, pre-\nserving the full security properties of Section ?? and reducing vendor lock-in.\nThe tradeoff is added governance complexity over operator authorization and\npolicy enforcement.\nBlockchain Connectivity. To ensure reliable blockchain interaction, PASS inte-\ngrates Helios [?], a consensus-verified light client, within the TEE. Rather than\ntrusting external RPC endpoints, Helios cryptographically verifies all blockchain\ndata against consensus layer proofs before serving it locally. This approach elimi-\nnates the trust assumptions typically associated with centralized RPC providers\nwhile maintaining the performance characteristics necessary for real-time wallet\noperations. The light client architecture ensures that PASS’s Outbox mecha-\nnism operates on verified blockchain state, preserving the security guarantees\neven when external network providers are compromised or unreliable.\n5.2 Performance Benchmarks\nTo evaluate PASS, we benchmarked both AWS Nitro Enclaves and Intel TDX\nbackends across common operations: balance queries, transfers, withdrawals,\nclaims, wallet creation, provenance queries, and an end-to-end workflow. Each\noperation was run 100 times over 10 trials per environment, measuring through-\nput in ops/sec. Both environments used identical 4-core, 2.5 GHz, 16 GB VMs\nto ensure fair comparison. Table ?? summarizes our results, with full details\navailable in Appendix ??.\nFig. 4. Internal PASS operation throughput (ops/sec) across AWS Nitro Enclaves\nand Intel TDX. All operations are in-memory state changes within the TEE with no\nblockchain interaction. Each value represents the average of 100 operations repeated\n10 times per environment.\nOperationAWS Nitro Intel TDX\nWallet Creation6,53114,970\nAccount Balance Queries530,943935,428\nInbox-to-Subaccount Claims14,85633,064\nInternal Subaccount Transfers32,95371,292\nWithdrawal Request Creation18,29139,702\nEnd-to-End Workflow\n7\n35,66378,433\nTransaction History Queries3,7577,685\nMulti-threaded Operations (5 threads)32,18955,124\nLarge Dataset Processing481724\nThe observed performance differences between AWS Nitro Enclaves and In-\ntel TDX primarily stem from their distinct hardware architectures. AWS Nitro\nEnclaves employ a disaggregated system design, where the host server and the\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets13\nTEE hardware are physically separated. Communication between the host and\nthe enclave occurs via vsock, and the enclave itself runs on a dedicated, lower-\nperformance coprocessor. In contrast, Intel TDX leverages a special instruction\nset to provide enclave functionality directly on the main processor, eliminating\nthe need for a separate coprocessor and avoiding the overhead of data transfer\nbetween disparate components. As a result, Intel TDX is able to deliver sig-\nnificantly higher throughput for in-enclave operations compared to AWS Nitro\nEnclaves, as reflected in our benchmark results.\nThese preliminary benchmarks show that both Nitro and TDX backends can\nsustain high throughput for critical wallet operations, confirming that PASS is\npractical for real-world deployment.\nComparison with Related Work. To contextualize our performance results, we\ncompare PASS with other TEE-based blockchain systems and traditional custo-\ndial solutions.\nLiquefaction. The Liquefaction system [?] demonstrates significantly higher\nlatencies than PASS due to its reliance on blockchain oracles for transaction\nvalidation. Liquefaction exhibits mean latencies of 49 seconds for latest block\nconfirmation, 648.7 seconds ( 11 minutes) for justified confirmation, and 1,036.9\nseconds ( 17 minutes) for finalized confirmation. These delays stem from Liq-\nuefaction’s architectural requirement to wait for block confirmations on an ex-\nternal TEE-blockchain oracle before authorizing subsequent operations. In con-\ntrast, PASS performs all operations within the off-chain TEE worker without\nblockchain dependencies, achieving sub-millisecond latencies for internal opera-\ntions (e.g., 14,856-33,064 ops/sec for claims, 32,953-71,292 ops/sec for transfers).\nThis fundamental architectural difference—off-chain TEE computation versus\nblockchain-dependent validation—enables PASS to provide near-instantaneous\nuser experiences while maintaining strong security guarantees.\nTraditional Custodians. While custodial solutions do not publish detailed\nperformance benchmarks, prior work demonstrates that TEE overhead typically\nintroduces only 5-7% performance degradation compared to native execution [?].\nGiven that modern custodial systems can process thousands of operations per\nsecond, TEE-based solutions like PASS should achieve comparable throughput\nwhile providing significantly stronger security properties. Our benchmark results\nsupport this expectation, with PASS demonstrating high-throughput operation\nprocessing that would be suitable for production custodial workloads, while offer-\ning the additional benefits of cryptographic auditability, decentralized operation,\nand reduced single points of failure.\nFurther evaluation of latency distributions, concurrency scaling, and memory\nfootprint is left for future work.\n6 Applications\nPASS is a powerful primitive that enables several classes of applications across\nidentity scoping, enterprise settings, and scalability concerns.\n14J. Yu\nCategoryApplicationContextPASS Enables\nIdentities\nAI Agent\nWallets\nAutonomous agents\ninteracting with crypto\nassets [?] need signing\naccess guardrails.\nScoped subaccounts grant limited\nbalances and domain signing rights,\nenabling safe delegation without\nexposing the root key\nDAO Voting\nDelegation\nDAOs depend on\naddress-based voting and\nproxy delegation [?].\nFine-grained voting rights delegation\nthat remains auditable via provenance;\ndelegation can be restricted to specific\nDApps or domains.\nSubdomain\nProfile Pages\nOrganizations delegate\ncontrol over web or\norganizational\nsubdomains (e.g.,\nmyprofile.company.com) to\nindividuals or teams.\nEach subaccount holds scoped signing\nrights for its assigned subdomain, with\nbalances and authorities tracked in\nprovenance under a shared\norganizational identity.\nEnterprise\nPrivate PayrollOn-chain payrolls reveal\nsensitive salary\ninformation [?].\nSalary distribution through internal\ngasless transfers with audit logs;\nexternal payouts are periodically\nbatched via the Outbox.\nCompliant Org\nWallets\nFirms must maintain\ninternal accountability\nand BSA\nrecordkeeping [?].\nDepartmental and individual\nsubaccounts with explicit budgets;\nprovenance ensures regulator-grade\nauditability without exposing internal\nflows.\nPrivate B2B\nNetting\nSupply-chain and\nrecurring multi-party\npayments require\nconfidentiality.\nVendor subaccounts allow internal\nnetting of obligations, with PASS\nacting as a temporary clearing house.\nOnly net settlements exit via the\nOutbox, reducing leakage while\nretaining auditability.\nAudit / Proof\nExplorer\nRegulators and auditors\nrequire verifiable yet\nprivacy-preserving\ntransparency.\nPublic proofs derived from the\nprovenance log H, enabling compliance\nchecks and audits without disclosing\ninternal ledger state.\nScalability\nGasless\nAppchain\nHigh-throughput\napplications (e.g., trading\nengines) face prohibitive\ngas costs on-chain.\nInternalize application logic as\nsubaccount transitions; Outbox emits\nverifiable batch settlements, ensuring\ncorrectness with minimal gas.\nCross-chain\nBridges\nBridges require strong\ncustody and coordination\nof operators [?].\nInbox-Outbox abstractions enforce\nprovenance across domains; FIFO\nnonce handling prevents replay or race\nconditions.\nL2 ComposabilityRollups and L2s fragment\nassets and user\nexperience [?].\nTreat each L2 as a scoped subaccount;\nmaintain private balance transfers\ninternally, and settle externally only\nwhen crossing domains.\nFig. 5. Applications of PASS across identities, enterprise settings, and scalability so-\nlutions. We highlight a flagship application in each category.\nIdentities and Agent Delegation. PASS’s multi-user subaccount model\nallows for flexible permission scopes. As AI agents start managing crypto as-\nsets, there is a need to constrain their access. An AI agent could be given a\nsub-account that only holds limited funds or certain asset types. The AI can op-\nerate freely within those bounds, but cannot exceed its allotted assets or misuse\nother wallet assets. If compromised, damage is capped to its sub-account. This\nis much safer than giving AI the keys to an entire wallet. Similarly, PASS can\nallow for delegation-based DAO voting by giving the delegate signature rights\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets15\nover particular voting DApps, without giving access to actually transfer the as-\nsets. Subaccounts can also get scoped signing rights over particular enterprise\nsubdomains.\nEnterprise Applications. PASS’s features of internal privacy, in-built per-\nmissioning, and provenance auditability make it uniquely suited for enterprise\napplciations. A flagship use case for PASS is private payroll. On-chain salary pay-\nments today risk exposing sensitive information such as individual compensation,\ndepartmental budgets, or timing patterns. With PASS, salaries are distributed\ninternally through gasless subaccount transfers, leaving a clear provenance log for\nauditability, but without revealing per-employee details on-chain. Only periodic,\non-demand payouts exit via the Outbox, ensuring both regulatory accountability\nand privacy for internal flows. Beyond payroll, PASS supports other enterprise\nneeds: compliant organizational wallets with departmental subaccounts that en-\nforce explicit budgets, private B2B netting where vendors settle obligations inter-\nnally and only net payments leave the wallet, and auditable proof explorers that\nprovide regulators with verifiable, privacy-preserving compliance proofs derived\nfrom the provenance log.\nScalability Solutions. PASS also supports scaling use cases where on-chain\ncosts or coordination overhead make existing approaches impractical. A flagship\nexample is gasless appchains, such as for Central Limit Orderbooks (CLOBs).\nHigh-throughput applications such as CLOBs cannot afford per-transaction gas\nfees, but PASS internalizes application logic as private subaccount transitions.\nThe Outbox then emits verifiable batch settlements with minimal gas, preserv-\ning correctness while keeping costs predictable. Beyond appchains, PASS enables\ncross-chain bridges by enforcing provenance across domains and sequencing with-\ndrawals via a FIFO nonce to prevent replay or race conditions, and supports L2\ncomposability by treating each rollup or sidechain as a scoped subaccount, main-\ntaining private balance transfers internally and settling externally only when\ncrossing domains.\n7 Discussion and Future Work\n7.1 Composability and InterPASS Transactions\nWhile PASS provides privacy and provenance guarantees for a single wallet in-\nstance, an important question is how multiple PASS wallets may interact. This\nis important in supply-chain use cases where each PASS represents a single com-\npany in the supply chain.\nTrivially, PASS A can send an on-chain transaction from its Outbox to PASS\nB’s EOA account, and this will land in the Inbox of PASS B, ready to claim.\nHowever, this undermines the privacy guarantees that PASS offers at the EOA\nlevel, and is undesirable in cases where inter-organizational asset transfers con-\ntain sensitive information, such as order details.\nWe propose a non-trivial approach inspired by cross-Payment Channel Net-\nwork (PCN) protocols such as XTransfer [?]. We can treat each PASS instance\n16J. Yu\nakin to a PCN hub node, with state L and transaction history H. As with\nXTransfer, we can assume a star topology of PASS nodes, with a central PASS\nHub in communciation with all PASS nodes. The PASS Hub will aggregate all\nInterPASS transactions T := {(a\ni\n,x\ni\n,s\ni\n,r\ni\n)}\nn\ni=1\n, where (a\ni\n,x\ni\n,s\ni\n,r\ni\n) represent\nthe asset, amount, sender, and receiver, each signed by the s\ni\nOutbox.\nThe Hub aggregates these signed payment intents, computes a netted settle-\nment plan S, and coordinates a secure multi-party update protocol to commit\nthe resulting balances, similar to Thora [?]. In the optimistic case, this process\ncompletes entirely off-chain, and each participant’s balance is updated in the\nPASS ledger without revealing the underlying transaction graph. If a dispute or\nfailure occurs, any participant may trigger an on-chain enforcement transaction\nthat finalizes S atomically via the direct transfer mechanism, thus guaranteeing\nsafety.\nThis approach leverages PASS ’s provenance and state design to make each\ninstance an atomic node in PCN-style systems like X-Transfer. Here, we outline\nhow PASS Hubs can enable confidential, auditable cross-organization transfers,\nwhile full formal specification and protocol implementation is deferred for future\nwork.\n7.2 Instantiation on zkVM\nThe PASS design presented in this paper relies primarily on trusted execution\nenvironments (TEEs) to enforce provenance rules, where the enclave isolates the\nglobal secret key and mediates all access through the Inbox–Outbox mechanism.\nWhile TEEs provide strong privacy and efficiency guarantees, their trust model\ndepends on hardware attestation and vendor integrity, which may be insufficient\nin regulatory or adversarial settings that demand independent verification.\nzkVMs provide a natural next step by enabling provenance-based control to\nbe verified through succinct cryptographic proofs rather than trusted hardware.\nBy batching transitions over L, H, I, and O and producing a proof π, a mini-\nmalist verifier contract can update commitments and enforce outbox execution\nwhile preserving privacy. This direction complements the Chainless stack ar-\nchitecture [?], suggesting a path toward modular, interoperable deployments of\nPASS with stronger external verifiability and broader applicability.\n8 Conclusion\nWe presented PASS, a Provenanced Access Subaccount System, as a new wallet\narchitecture that enforces access by provenance rather than by identity or role.\nThe Inbox–Outbox mechanism ensures all assets have a verifiable lineage, while\ninternal transfers remain private and indistinguishable from a standard EOA\naccount.\nOur contributions are threefold: (i) a formal model in Lean 4 proving pri-\nvacy, accessibility, and provenance integrity; (ii) a working prototype with en-\nclave backends on AWS Nitro Enclaves and Intel TDX via dstack, integrated\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets17\nwith WalletConnect; and (iii) initial benchmarks showing the feasibility of high-\nthroughput operation. These results demonstrate that provenance-based control\ncan be realized today with mainstream blockchain tools.\nLooking forward, richer evaluations across multi-vendor TEEs, integration\nwith zero-knowledge VMs, and exploration of organizational and agent-based\ncustody are promising directions. By combining rigorous formal guarantees with\ndeployable prototypes, PASS advances the design space between strict self-\ncustody and flexible shared access, offering a path toward practical, privacy-\npreserving wallet security.\nA Formal Verification\nWe consider the formal model introduced in Section ?? of PASS as a state\nmachine in Lean4. Our goal is to prove that, under the PASS design, several\ncritical security properties always hold. We outline these properties and our\napproach to verifying them.\nA.1 Property: Privacy of Internal Transfers\nIn the PASS design, the InternalTransfer operation updates only the off-chain\nledgerL and the provenance historyH. It never modifies the OutboxO, meaning\nthere is no on-chain transaction triggered by an internal transfer. Consequently,\nexternal observers see no change in on-chain state. We formalize this by consid-\nering the on-chain view that an external party has for a given PASS Wallet. We\ncan model this visible on-chain state as a triple:\nW\npub\n=\n\u0000\npk, O, A\n\u0001\n,\nwhere:\npk is the externally owned account (EOA) address,\nO = (T,ν) is the external view of the outbox, where T is a list of enqueued\ntransactions and ν is a nonce,\nA is the external view of the Asset ledgerL, containing a list of asset entries,\neach of the form (α,x) with a unique identifier α and total balance x.\nExternal Trace. The external trace of a PassAccount state W\npub\nis the list of\nexternally visible actions, obtained by mapping each transaction in the outbox\nT to an on-chain action:\nexternalTrace(W\npub\n) =\n\b\noutboxTx(t) | t∈ T\n\t\n.\nNo internal transfers appear in externalTrace(·).\n18J. Yu\nStates That Differ Only by Internal Transfers. We say that two PassAccount\nstates W\n1\n= (pk\n1\n,O\n1\n,A\n1\n) and W\n2\n= (pk\n2\n,O\n2\n,A\n2\n) differ only by internal trans-\nfers if:\n1. pk\n1\n= pk\n2\n,\n2. O\n1\n= O\n2\n(i.e. both the list of outbox transactions and the nonce are the\nsame),\n3. For every asset identifier α, the total balance of that asset in A\n1\nequals the\ntotal balance of the same asset in A\n2\n.\nLetting getAsset(W,α) return the asset α within state W or ⊥, we require ∀α:\ntotalBalance\n\u0000\ngetAsset(W\n1\n,α)\n\u0001\n= totalBalance\n\u0000\ngetAsset(W\n2\n,α)\n\u0001\n.\nTheorem 2 (Privacy of Internal Transfers). If two PassAccount states W\n1\nand W\n2\ndiffer only by internal transfers, then their externally visible traces are\nidentical:\nexternalTrace(W\n1\n) = externalTrace(W\n2\n).\nProof. By assumption, O\n1\n= O\n2\n. Hence both states have the same outbox trans-\naction list T . Since\nexternalTrace(W\ni\n) = map\n\u0000\noutboxTx, T\ni\n\u0001\nfor i∈{1, 2},\nand T\n1\n= T\n2\n, it follows that externalTrace(W\n1\n) and externalTrace(W\n2\n) are iden-\ntical.\nThus, any sequence of purely internal transfers, changing only the private ledger\nL in PASS, is invisible to an external observer, preserving the privacy of how\nassets move within the wallet.\nA corollary of this Internal Transfer property is that a PASS account is\nindistinguishable from a regular EOA account.\nCorollary 1 (Indistinguishability from EOA). Let W\npass\nbe a PASS state\nthat (i) has the same public key pk, (ii) the same outbox, including nonce and\ntransaction list, and (iii) the same total balances of each asset as a reference\nEOA state W\neoa\n. Then\nexternalTrace(W\npass\n) = externalTrace(W\neoa\n).\nIn particular, an external observer cannot distinguish W\npass\nfrom W\neoa\n.\nProof. By assumption, the only potential differences betweenW\npass\nandW\neoa\nlie\nin internal ledger details. From Theorem 1, such internal transfers do not affect\nthe externally visible outbox transactions or total on-chain balances. Thus, their\nexternal traces coincide, and W\npass\nis indistinguishable from W\neoa\n.\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets19\nA.2 Property: Asset Accessibility\nIn addition to keeping internal transactions private, PASS should ensure that for\nevery asset in the system, there exists some sub-account that can access it and\nwithdraw it from the system. This prevents a situation where funds get ”stuck”\nwithout any reachable key or policy to move them. We define asset accessibility\nas follows:\nTheorem 3 (Asset Accessibility). For any PASS account W and asset iden-\ntified by α, there exists a list of addresses L such that:\n1. For every address u∈ L, the user can access their full balance:\ncheckBalance(s,α,u, balance(u)) = true\n2. The sum of all accessible balances equals the total balance of the asset:\nX\nu∈L\nL[u][α] = totalBalance(α)\nProof. We construct L as the set of all addresses with non-zero balances in the\nbalance map for α:\nL ={u|L[u][α] > 0}\nFor the first property, given any u∈ L, the definition of checkBalance verifies\nif the user has sufficient balance for the specified amount. When checking against\nthe user’s own balance, this is trivially satisfied since L[u][α]≥L[u][α] for all u.\nFor the second property, we observe that totalBalance is defined as the sum\nof all balances in the asset’s balance map:\ntotalBalance(α) =\nX\nu∈L\nL[u][α]\nBy construction, L contains the only nonzero values u∈L, so:\nX\nu∈L\nL[u][α] = totalBalance(α)\nTherefore, both properties hold for our constructed list L.\nWe can prove a similar trait for General Signable Messages, showing that for\nany inbound GSM, there is some subaccount signer that has access to it.\nTheorem 4 (GSM Accessibility). For any GSM and domain, there exists a\nuser with signing access to that domain.\nProof. For any domain d, we can directly construct a user u who has signing\naccess to d as follows:\nu = getSigner(d)\nBy definition, getSigner returns either:\n– A specifically assigned signer if one exists in the domain-address map, or\n– The default signer otherwise\nTherefore, every domain is guaranteed to have at least one user with signing\naccess, ensuring no GSM domain becomes inaccessible.\n20J. Yu\nA.3 Property: Provenance Integrity\nProvenance integrity specifies that every asset held by any sub-account in PASS\nmust have an origin traceable to an external deposit into the Inbox. At any\nstate of the system, for each asset entry in a sub-account’s balance, we can find\na sequence of internal transfers that leads back to an Inbox deposit from an\nexternal address. This property ensures no sub-account can conjure funds from\nnothing, such as through double-spending or inflation within the system, and\nthat the internal ledger is consistent with on-chain reality. In Lean, we model\nthe state of the PASS wallet including Inbox, Outbox, and all sub-accounts and\nprove an invariant that whenever a sub-account has x units of asset α, the global\nstate contains a record of at least x units of α having been deposited, minus any\nthat have been withdrawn.\nTheorem 5 (Provenance Integrity).\nFor any PASS account S =\n\u0000\npk, sk,ν,I,O,L,H\n\u0001\nand any asset α, the total\namount of α held across all subaccounts can never exceed the total amount of\nexternal deposits (minus any that have already been withdrawn). Formally,\nX\nu∈U\nL[u][α] ≤ externalDeposits(α),\nwhere U is the set of subaccounts in the system, and externalDeposits(α) is\nthe net total of asset α that has been introduced into the wallet from outside\naddresses, recorded in the inbox I.\nProof. We model the system’s state (pk, sk,ν,I,O,L,H) as in Figure ??, includ-\ning the Inbox I, Outbox O, and the internal ledger L. We define a provenance\nrecord P (α,u) that captures the total amount of asset α subaccount u is autho-\nrized to hold, based on Inbox claims and internal transfers.\nBase Case: Immediately after CreatePassWallet, no assets have been de-\nposited, and no subaccount balances exist:\n∀u, L[u][α] = 0, ∀α, externalDeposits(α) = 0.\nHence,\nX\nu∈U\nL[u][α] = 0 ≤ 0 = externalDeposits(α).\nInductive Step: Assume the invariant holds after n− 1 operations. We prove it\nremains valid after the nth operation, for each possible type of operation:\n(1) External Deposit: Suppose an amount x of asset α is deposited into the\nwallet:\nexternalDeposits(α) ← externalDeposits(α) + x.\nNo subaccount balances L[u][α] change. Thus, the left side of our inequality\n(sum of subaccount balances) is unchanged, while the right side strictly\nincreases by x, so the invariant continues to hold.\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets21\n(2) Inbox Claim: If subaccount u claims amount x of asset α from the Inbox\nI:\nL[u][α] ← L[u][α] + x, P (α,u) ← P (α,u) + x.\nSince x was already accounted for in externalDeposits(α) (but not yet allo-\ncated to any subaccount), the total subaccount balances remain≤ externalDeposits(α).\n(3) Internal Transfer: If subaccount u\n1\ntransfers x of α to subaccount u\n2\n:\nL[u\n1\n][α] ← L[u\n1\n][α]− x, L[u\n2\n][α] ← L[u\n2\n][α] + x,\nand P (α,u\n2\n) increases by x. Because the sum of all subaccount balances\ndoes not change, our invariant is preserved.\n(4) Withdrawal: If subaccount u withdraws x of α:\nL[u][α] ← L[u][α]− x,\nwhich reduces the total subaccount balances. Since externalDeposits(α)\nremains unchanged (assets have simply exited the wallet), the inequality still\nholds.\nThus, by induction over all possible operations,\nX\nu∈U\nL[u][α] ≤ externalDeposits(α)\nfor every reachable state. No subaccount can create new assets out of nothing,\nand all assets in the system are fully accounted for by provenanced deposits.\nB Dstack Architecture and Execution Model\nB.1 Component Overview\n– Dstack-OS: Minimal Linux-based VM image with a verifiable boot chain.\nMeasures bootloader, kernel, root filesystem (RootFs) via RTMR registers.\nIntegrates dm-verity for data integrity and monotonic counters for anti-\nrollback.\n– Dstack-KMS: Blockchain-governed MPC network for key derivation and\nrotation. Provides:\nk\nc\n= HMAC\nk\nroot\n(c\nid\n),\nk\nTLS\n= ECDSA(k\nroot\n).\nRotation is triggered via governance (t-of-n threshold).\n– Dstack-Gateway/Ingress: TLS termination inside TEEs, ZT-TLS bind-\ning X\nc\nto R(c), enabling verifiable HTTPS ingress.\n22J. Yu\nB.2 Governance Layer\nTwo contracts form the trust base:\n– KmsAuth: Global registry of KMS nodes and application digests.\n– AppAuth: Per-application contract specifying quorum rules, allowed image\nhashes, and authorized enclaves.\nB.3 Workflow Phases\n1. Attestation: Enclave e produces quote Q\ne\n; verified against R.\n2. Secret Provisioning: MPC nodes compute k\nc\n, release to e if Q\ne\nis valid.\n3. Container Launch: Dstack-OS mounts RootFs, decrypts state σ\nc\nwith k\nc\n.\n4. Ingress Binding: TLS certificate X\nc\ngenerated inside e; bound to R(c).\n5. Audit Logging: Migration, key rotation, and governance events appended\nto H.\nB.4 Fault Tolerance\n– Vendor failure: μ enables re-deployment across Intel/AMD TEEs.\n– KMS compromise: key rotation via MPC thresholds restores forward/backward\nsecrecy.\n– Governance deadlock: ∆t fallback in Γ ensures quorum reduction and progress.\nB.5 Liveness Proof Sketch\nCombining MPC-based key recovery, quorum fallback, and portable containers\nyields:\n∀op∈O\nc\n,Pr[Exec(c, op) =⊤] = 1\nunder assumptions of f -resilient MPC nodes and at least one uncompromised\nTEE instance.\nC Detailed Benchmark Results\nThis appendix provides comprehensive benchmark statistics for both AWS Nitro\nEnclaves and Intel TDX environments. All operations are internal PASS state\nchanges that occur within the TEE with no blockchain network interaction.\nEach operation was executed 100 times per trial, with 10 independent trials\nper environment. The tables below show summary statistics including mean,\nstandard deviation, and range.\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets23\nTable 1. AWS Nitro Enclaves benchmark statistics (ops/sec) across 10 trials\nOperationMean Std Dev Min Max\nWallet Creation6,5315315,4467,042\nAccount Balance Queries530,943675 530,216 531,915\nInbox-to-Subaccount Claims14,856476 14,326 15,504\nInternal Subaccount Transfers32,9531,322 31,447 35,088\nWithdrawal Request Creation18,2911,254 15,873 19,608\nEnd-to-End Workflow35,6636,234 21,739 40,650\nTransaction History Queries3,757453,6503,802\nMulti-threaded Operations (5 threads) 32,189884 31,200 34,364\nLarge Dataset Processing48113467497\nTable 2. Phala dStack benchmark statistics (ops/sec) across 10 trials\nOperationMean Std Dev Min Max\nWallet Creation14,9704,6528,69624,390\nAccount Balance Queries935,428338,450 383,142 1,470,588\nInbox-to-Subaccount Claims33,0645,197 25,44541,667\nInternal Subaccount Transfers71,29217,623 47,170 101,010\nWithdrawal Request Creation39,7027,434 29,15551,813\nEnd-to-End Workflow78,43317,403 59,524 110,497\nTransaction History Queries7,6858726,4528,929\nMulti-threaded Operations (5 threads) 55,12416,744 28,32981,301\nLarge Dataset Processing72481636893\nC.1 AWS Nitro Enclaves Results\nC.2 Intel TDX Results\nC.3 Performance Analysis\nThe statistical analysis reveals several key insights about PASS’s internal oper-\nation performance:\n– Performance Consistency: AWS Nitro Enclaves demonstrate superior\nconsistency with lower standard deviations across all operations. The co-\nefficient of variation ranges from 0.1% (Account Balance Queries) to 17.5%\n(End-to-End Workflow).\n– Peak Performance: Intel TDX achieves higher mean throughput but with\nsignificantly greater variance. Standard deviations are 10-500x larger than\nNitro, indicating less predictable performance.\n– Production Considerations: These internal operation benchmarks demon-\nstrate PASS’s ability to handle thousands of wallet operations per second\nwithin the TEE, with the actual deployment bottleneck being blockchain\ntransaction submission rather than internal processing.\nThe statistical summary confirms that both platforms support practical PASS\ndeployment, with Nitro offering predictable performance and Intel TDX provid-\ning higher peak throughput at the cost of consistency.\n24J. Yu\nD Design Extensions\nD.1 Composability and InterPASS Transactions\nWhile PASS provides privacy and provenance guarantees for a single wallet in-\nstance, an important question is how multiple PASS wallets may interact. This\nis important in supply-chain use cases where each PASS represents a single com-\npany in the supply chain.\nTrivially, PASS A can send an on-chain transaction from its Outbox to PASS\nB’s EOA account, and this will land in the Inbox of PASS B, ready to claim.\nHowever, this undermines the privacy guarantees that PASS offers at the EOA\nlevel, and is undesirable in cases where inter-organizational asset transfers con-\ntain sensitive information, such as order details.\nWe propose a non-trivial approach inspired by cross-Payment Channel Net-\nwork (PCN) protocols such as XTransfer [?]. We can treat each PASS instance\nakin to a PCN hub node, with state L and transaction history H. As with\nXTransfer, we can assume a star topology of PASS nodes, with a central PASS\nHub in communciation with all PASS nodes. The PASS Hub will aggregate all\nInterPASS transactions T := {(a\ni\n,x\ni\n,s\ni\n,r\ni\n)}\nn\ni=1\n, where (a\ni\n,x\ni\n,s\ni\n,r\ni\n) represent\nthe asset, amount, sender, and receiver, each signed by the s\ni\nOutbox.\nThe Hub aggregates these signed payment intents, computes a netted settle-\nment plan S, and coordinates a secure multi-party update protocol to commit\nthe resulting balances, similar to Thora [?]. In the optimistic case, this process\ncompletes entirely off-chain, and each participant’s balance is updated in the\nPASS ledger without revealing the underlying transaction graph. If a dispute or\nfailure occurs, any participant may trigger an on-chain enforcement transaction\nthat finalizes S atomically via the direct transfer mechanism, thus guaranteeing\nsafety.\nThis approach leverages PASS ’s provenance and state design to make each\ninstance an atomic node in PCN-style systems like X-Transfer. Here, we outline\nhow PASS Hubs can enable confidential, auditable cross-organization transfers,\nwhile full formal specification and protocol implementation is deferred for future\nwork.\nD.2 Instantiation on zkVM\nThe design of PASS presented thus far relies on trusted execution environments\n(TEEs) such as AWS Nitro or Intel TDX to enforce provenance-based control.\nTEEs provide strong isolation and efficient execution, allowing internal transfers\nto remain private while ensuring that every outbox action has a verifiable lin-\neage. However, the trust model is anchored in hardware attestation: users and\nregulators must accept that the enclave executes the correct code as claimed.\nWhile sufficient for many organizational custody scenarios, this assumption lim-\nits transparency and long-term auditability. To address this limitation, we ex-\nplore an alternative instantiation of PASS in a zero-knowledge virtual machine\n(zkVM), replacing hardware trust with cryptographic proofs of correctness.\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets25\nZero-knowledge virtual machines (zkVMs) provide a proving environment in\nwhich arbitrary state machines can run with strong correctness guarantees [?].\nBy producing a succinct proof π of execution, zkVMs offer integrity assurances\nsimilar to TEEs but without reliance on vendor-specific hardware. This shift\nmakes zkVMs particularly suitable for contexts such as institutional custody,\nmulti-party supply chains, or inter-organizational accounting where external ver-\nifiability and regulator-grade auditability are paramount.\nIn a zkVM instantiation of PASS, the execution pipeline mirrors the enclave-\nbased design but replaces attestation with cryptographic proofs. The process\nproceeds in four stages:\n1. Batch formation. Transaction requests (claims, transfers, withdrawals) are\nfirst queued off-chain into a batch.\n2. zkVM execution. The zkVM program takes as private inputs: (i) the prior\nbatch’s commitments of the ledger L and provenance log H, (ii) the queued\ntransitions, including inbox I deposits and outbox O withdrawals, and (iii)\nthe proposed new commitments (L\n′\n,H\n′\n). Inside the zkVM, the transition\nfunction is replayed deterministically: starting from the previous roots, ap-\nplying all operations in sequence, updating balances and provenance entries,\nand checking consistency constraints.\n3. Proof generation. The zkVM outputs a succinct proof π certifying that the\nclaimed new roots (L\n′\n,H\n′\n) are correct with respect to the given transition\nset.\n4. On-chain verification. A minimalist verifier contract validates π, updates\nthe recorded commitments, and enforces any pending outbox operations.\nThis ensures that every external action has a verifiable provenance path\nwhile internal transfers remain private.\nCompared to TEEs, zkVMs strengthen the verifiability model by eliminat-\ning hardware trust assumptions, but incur higher computational and financial\ncosts due to proof generation and on-chain verification. Batching amortizes these\ncosts, raising open research questions about optimal batch sizes, data availabil-\nity strategies, and proof system selection. zkVM backends such as Risc0, SP1,\nor Plonky3 offer different tradeoffs in proof size, verification cost, and latency.\nHybrid deployments are also possible: TEEs can serve as fast-path executors for\nintra-day operations, with zkVM proofs generated periodically to provide cryp-\ntographic audit trails. This hybrid pattern resembles optimistic rollups, where\nfast execution is combined with verifiable settlement.\nFinally, this instantiation aligns closely with the Chainless stack architec-\nture [?], which emphasizes the separation of execution, trust, bridging, and set-\ntlement. In this view, zkVM proofs naturally inhabit the execution and trust\nlayers, Inbox/Outbox commitments integrate with bridging, and the verifier\ncontract finalizes settlement. This layered design opens the door to modular,\ninteroperable deployments of PASS across heterogeneous chains and domains.\nFull formal specification, performance benchmarking, and exploration of hybrid\nzkVM–TEE implementations remain important avenues for future work.\n26J. Yu\nFig. 6. PASS instantiation inside a zkVM: Inbox I and Outbox O transitions are\napplied to the Ledger L and Provenance H, producing new state commitments. The\nzkVM outputs a proof π, which the on-chain verifier checks before updating roots and\nenforcing outbox operations."
}
]
},
{
"role": "assistant",
"content": "To convincingly argue that existing wallet architectures cannot satisfy the three use cases described in the Introduction—and to establish why provenance- and TEE-based solutions (like PASS) are superior—we must proceed with analytical rigor. Let us structure the argument as follows:\n\n---\n\n### 1. Common Challenges Across the Three Use Cases\n\nThe three use cases—(1) AI and smart agent transactions, (2) enterprise payroll privacy, and (3) consumer-grade central limit order books (CLOBs)—share several foundational requirements:\n\n- **Fine-grained, context-aware access control**: Multiple actors or agents (human or AI) require scoped permissions, often with dynamic delegation and revocation.\n- **Privacy of internal operations**: Sensitive details (e.g., salary distribution, trading strategies) must be shielded from public blockchain visibility.\n- **Auditability and provenance**: All asset movements must be traceable for accountability, compliance, and operational safety, without leaking internal business logic.\n- **Compatibility and deployability**: Solutions must integrate with existing blockchain infrastructure (native EOA compatibility) and avoid introducing prohibitive costs or deployment friction.\n- **Minimized trust assumptions**: Reliance on centralized custodians, bespoke policy engines, or opaque hardware should be mitigated, and the system should be robust against compromised infrastructure.\n\n---\n\n### 2. Limitations of Existing Approaches\n\n**a. EOAs and Multisig Wallets**\n\n- **Lack of Granular Control**: EOAs offer no internal permissioning; whoever holds the key controls all assets. Multisigs provide only symmetric, static authority (t-of-n), which is coarse-grained and unsuitable for dynamic or hierarchical delegation (e.g., AI agents with limited spending rights, or departmental payroll).\n- **No Internal Privacy**: All multisig logic and transactions are public. Internal movements (e.g., salary splits, order routing) are visible on-chain, leaking sensitive information.\n- **Operational Overhead**: Multisigs require on-chain coordination for every action, incurring gas and latency that are prohibitive for real-time trading (CLOBs) or high-frequency payroll.\n\n**b. Smart Contract Wallets (Account Abstraction, ERC-4337, etc.)**\n\n- **Public Policy Exposure**: Custom validation logic is encoded on-chain, making access rules and internal flows transparent to adversaries and competitors.\n- **Gas and Complexity Costs**: Every policy check or transfer is a smart contract operation, increasing gas expense and limiting throughput—untenable for high-frequency or privacy-sensitive use cases.\n- **Compatibility Constraints**: Many solutions require specific chain support (e.g., ERC-4337), reducing portability and increasing integration friction.\n\n**c. Custodial Wallets with RBAC/ABAC Engines**\n\n- **Off-chain Enforcement and Trust**: Policies are enforced off-chain by custodians, who have full visibility into internal activity. This introduces a single point of failure and privacy risk, as well as regulatory and operational dependency on the custodian.\n- **Policy Language Proliferation**: Each custodian implements bespoke policy APIs, leading to fragmentation, lack of composability, and brittle access semantics.\n- **No Asset Provenance**: Authority is attached to identities or roles, not to the origin or flow of assets, making it awkward to enforce chain-of-custody or audit trails directly tied to deposits.\n\n**d. TEE-based Wallets (e.g., Liquefaction)**\n\n- **Limited Formal Guarantees**: Prior TEE-based approaches (like Liquefaction) rely on key encumbrance and policy trees, but lack formal proofs of privacy, accessibility, and provenance integrity.\n- **Deployment Friction**: Some require specialized smart contract platforms (e.g., Oasis), reducing compatibility with standard EOAs and increasing vendor lock-in.\n- **Performance Bottlenecks**: Reliance on blockchain oracles for every operation (as in Liquefaction) introduces high latency, unsuitable for real-time or high-throughput scenarios.\n\n---\n\n### 3. Why Provenance- and TEE-Based Solutions (PASS) Are Superior\n\n**a. Alignment with Blockchain’s Exogenous Asset Model**\n\n- **Provenance-Centric Control**: PASS enforces access not by static roles or identities, but by the chain of custody—who deposited an asset, and how it flowed internally. This matches the exogenous way assets enter wallets on blockchains and supports fine-grained, composable access rules.\n\n**b. Privacy by Design**\n\n- **Internal Privacy**: Internal (off-chain) transfers update only the private ledger and provenance log; they are invisible externally. To outsiders, the wallet is indistinguishable from a standard EOA. This directly addresses enterprise payroll and trading privacy requirements.\n- **TEE Isolation**: Private keys and all sensitive logic reside in TEEs, ensuring that even infrastructure operators cannot access or leak internal flows.\n\n**c. Formal Security and Auditability**\n\n- **Proven Invariants**: PASS is formally modeled and verified (in Lean 4) to guarantee privacy, accessibility (no stuck funds), and provenance integrity (no double-spending or unauthorized asset creation).\n- **Audit-Ready Provenance**: All asset movements have a verifiable lineage, supporting regulatory audits and internal compliance without exposing business-sensitive details.\n\n**d. Deployability and Performance**\n\n- **Native EOA Compatibility**: PASS operates on standard EOAs, requiring no contract upgrades or specialized chain support. Deployments are possible on mainstream TEE platforms (AWS Nitro, Intel TDX).\n- **High Throughput, Low Latency**: Internal operations are off-chain and in-TEE, achieving sub-millisecond performance, as shown in benchmarks. Unlike prior TEE or smart contract solutions, PASS is suitable for real-time and high-frequency applications (e.g., CLOBs).\n- **Composable Policy**: While the core is provenance-based, additional constraints (e.g., RBAC/ABAC, whitelists) can be layered as conjuncts, without sacrificing the core privacy and consistency guarantees.\n\n---\n\n**Conclusion**\n\nIn sum, existing solutions either (i) fail to provide the necessary granularity, privacy, and auditability (EOAs, multisigs, custodians), (ii) leak sensitive policy and incur operational overhead (smart contract wallets), or (iii) lack formal guarantees and performance (prior TEE wallets). Provenance- and TEE-based solutions like PASS uniquely satisfy all requirements: they enable privacy-preserving, finely-scoped, and auditable access for multi-actor wallets across all three target use cases, with formal security guarantees and practical deployability. This architectural shift is not incremental but foundational, bridging the gap between strict self-custody and flexible, privacy-preserving shared access."
},
{
"role": "user",
"content": "this is too long to fit in the introduction, directly write them for me"
},
{
"role": "assistant",
"content": "Certainly. Here is a concise, logically structured passage suitable for the introduction, directly addressing your goals:\n\n---\n\nThe three motivating use cases—AI agent wallets, private enterprise payroll, and consumer-grade on-chain order books—share core requirements: fine-grained access control among multiple actors, internal privacy for sensitive operations, and verifiable audit trails for asset movements. Existing wallet architectures cannot jointly satisfy these needs. EOAs and multisigs lack internal privacy and offer only coarse, public control; smart contract wallets expose all policy logic and internal flows on-chain, incurring prohibitive gas costs and leaking confidential details; custodial solutions rely on off-chain enforcement and centralized trust, sacrificing transparency and provenance. Prior TEE-based approaches either lack formal guarantees or require non-standard infrastructure, limiting flexibility and performance.\n\nIn contrast, provenance- and TEE-based solutions such as PASS directly align with blockchain’s asset model, enforcing access by verifiable custody chains rather than static roles or on-chain logic. This enables internal, gasless, and private transfers with auditable provenance, while the TEE isolates sensitive keys and policies from external exposure. Our approach thus uniquely achieves privacy, auditability, and flexible access at scale, bridging the gap between strict self-custody and practical, privacy-preserving shared wallets."
},
{
"role": "user",
"content": "if you write in this way, it will look like we are inferring the problems just based on what we do, can you be more insightful?"
}
]Response:
Certainly. To avoid circular reasoning and to demonstrate genuine insight, the limitations of existing approaches must be articulated independently of the proposed solution, with clear linkage to the requirements posed by the use cases. Here is a revised, more incisive version:
---
All three motivating scenarios—AI agent wallets, enterprise payroll privacy, and consumer-grade order books—expose a fundamental set of challenges for blockchain custody: the need for multi-actor wallets with granular, context-aware permissions; the imperative to keep sensitive internal operations private; and the requirement for clear, auditable provenance of asset movements.
Existing solutions fall short in critical ways. Traditional EOAs and multisig wallets are fundamentally single-layered: they grant blanket authority to keyholders or fixed quorums, making it impossible to delegate limited rights (as needed for AI agents) or to maintain internal confidentiality (as required for payroll and trading strategies). Smart contract wallets and account abstraction introduce programmability, but at the cost of publicizing all policy logic and internal activity on-chain, creating privacy risks and significant operational overhead. Custodial wallets, meanwhile, centralize trust and enforce access off-chain, undermining transparency and auditability, and do not provide native asset provenance—making compliance and internal accountability brittle and opaque.
These shortcomings stem from a mismatch between traditional access control models (identity- or role-based) and the exogenous, provenance-centric nature of blockchain assets. In each use case, what matters is not merely who can act, but how assets arrived and flowed within the system—information that current frameworks cannot natively express or enforce.
A provenance- and TEE-based approach explicitly addresses these challenges. By encoding access rules in terms of verifiable custody chains and enforcing them within hardware-isolated environments, provenance-based systems achieve fine-grained, auditable control without leaking internal state or introducing centralized trust. This model is uniquely positioned to satisfy the privacy, flexibility, and compliance demands that modern blockchain applications impose—where existing architectures systematically fall short.
Model: gpt-4.1-2025-04-142025-09-15 12:30:29
Context:
[
{
"role": "system",
"content": "You are a research paper writer. You focus on:\n1. logical consistency\n2. whether the story is persuasive\nDon't try to be friendly on purpose, judge everything based on the logic and expressiveness."
},
{
"role": "user",
"content": [
{
"type": "text",
"text": "Use the contents of Introduction and Background, answer my question.\n\nMy target is to demonstrate that the existing works cannot satisfy the three use cases in Introduction, and also explain why provenance- and TEE-based solution is a better solution for this.\n\nI think a good way to write about this is \n\n1. summarize the common challenges in the three use cases\n2. give a short but insightful elaboration that the existing works have limitations, so cannot solve this\n3. explain why our work can solve this"
},
{
"type": "text",
"text": "main.pdf\nPASS: A Provenanced Access Subaccount\nSystem\nfor Blockchain Wallets\nJay Yu\n1,2\n1\nStanford University [email protected]\n2\nPantera Capital [email protected]\nAbstract. Blockchain wallets still follow a single-entity ownership model:\npossession of a private key grants unilateral control. This assumption is\nbrittle for emerging settings such as organizational custody, shared gov-\nernance, and AI agent wallets, where multiple actors must coordinate\nwithout exposing secrets or leaking internal activity.\nWe present PASS, a Provenanced Access Subaccount System\nthat replaces role or identity-based control with provenance-based con-\ntrol: assets can only be used by subaccounts that can trace custody back\nto a valid deposit. A simple Inbox–Outbox mechanism ensures all exter-\nnal actions have verifiable lineage, while internal transfers remain private\nand indistinguishable from ordinary EOAs.\nWe formalize PASS in Lean 4 and prove core invariants, including\nprivacy of internal transfers, asset accessibility, and provenance integrity.\nWe implement a prototype with enclave backends on AWS Nitro Enclaves\nand dstack Intel TDX, integrate with WalletConnect, and benchmark\nthroughput across wallet operations. These results show that provenance-\nbased wallets are both implementable and efficient. PASS bridges today’s\ngap between strict self-custody and flexible shared access, advancing the\ndesign space for practical, privacy-preserving custody.\n1 Introduction\nCryptocurrency wallets conventionally assume one key, one owner. In this single-\nentity ownership (SEAO) model, whoever holds the private key gains permanent\nand total control of the address, and casts publicly readable, gas-consuming\nblockchain transactions. However, this model struggles to adapt to emerging\nblockchain scenarios:\n1. AI and Smart Agent Transactions. AI agents increasingly manage crypto\nassets [?,?] and require bounded authority and access guardrails for users’\nasset security.\n2. Enterprise Payroll Privacy. Organizations need to distribute salaries and\ndepartmental budgets to employee accounts without revealing sensitive de-\ntails on-chain [?,?,?].\n2J. Yu\n3. Consumer-grade Central Limit Order Books. On-chain order books\nface high gas costs and latency that prevent real-time trading at scale [?,?],\nand many consumers prefer not to manage their own keys [?,?].\nIn practice, many organizations confronted with these challenges default to\ncustodians or policy engines that wrap access logic in Role-Based Access Con-\ntrol (RBAC) or Attribute-Based Access Control (ABAC) [?,?]. These systems\nintroduce a proliferation of bespoke policy languages and APIs to specify who\nmay sign or transfer under which conditions [?,?]. While workable as a stopgap,\nthey inherit identity and role assumptions from traditional IT settings that limit\ntheir flexibility and scalability in blockchain contexts.\nThe limitation stems from a mismatch of models. Traditional access-control\nframeworks such as RBAC and ABAC assume an endogenous setting: users\ncreate and manage their own files, objects, or services, and policies are attached\nto these identities or roles. Blockchains are fundamentally exogenous: assets are\ncreated outside the wallet by smart contracts and transferred permissionlessly\nin. In this setting, identity or role-based rules are awkward to express and brittle\nto enforce. What matters instead is provenance: who deposited an asset, and how\nit flowed within the wallet.\nWe propose PASS, a Provenanced Access Subaccount System that enforces\ncontrol directly by provenance. The core mechanism is simple: an Inbox records\nexternal deposits, an Outbox signs and broadcasts withdrawals, and all internal\nmovements remain private and fee-less. Every unit of value inside the wallet has\na verifiable lineage to an on-chain deposit, while externally a PASS wallet is\nindistinguishable from a standard EOA. Our contributions include:\n– A provenance-based access model aligned with blockchain’s exogenous asset\ncreation, enforced through an Inbox–Outbox design.\n– A formal model in Lean 4 proving privacy, accessibility, and provenance\nintegrity.\n– A prototype with multi-vendor enclave backends (AWS Nitro, Intel TDX via\ndstack), a web app frontend integrated with WalletConnect, together with\nthroughput benchmarks.\n– Application scenarios, including organizational custody, privacy-preserving\ntransfers, and safe delegation to AI agents.\nPASS thus bridges the gap between strict self-custody and flexible shared\naccess, combining strong privacy guarantees with practical deployability.\n2 Background and Related Work\nGrowing retail and institutional adoption of digital assets [?] has driven diverse\nwallet designs [?]. We summarize mainstream Ethereum Virtual Machine (EVM)\nwallet designs in Figure ??.\nEOAs and Multisigs. Externally Owned Accounts (EOAs) give unilateral,\npermanent control to whoever holds the private key [?]. Multisignature wallets\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets3\nModelControl basisOn-chain\noverhead\nInternal\nPrivacy\nCompatibility\nEOASingle private keyNoneNoneNative EOA\nMultisigt-of-n co-signersHigh; quorum per\naction\nNone; logic\npublic\nSmart\ncontract based\nERC-4337\nSmart\nAccounts\nOn-chain policy\nlogic\nMedium to high;\ncustom logic and\ngas\nNone; logic\npublic\nRequires\nERC-4337\nchain support\nCustodiansCustom RBAC or\nABAC languages\nNone; Off-chain\nenforcement\nCustodian sees\nall activity\nAPI mediated\nLiquefactionTEE key\nencumbrance;\npolicy trees\nMedium; Oasis\ncontracts and gas\nStrong; TEE\nhides\nsubpolicies\nRequires Oasis\ndeployment\nPASS\n(ours)\nProvenance via\nInbox-Outbox\nNone; EOA\ncompatible\nStrong;\ninternal\ntransfers\ninvisible\nNative EOA\nplus off the\nshelf TEEs\nFig. 1. Comparison of wallet architectures. PASS features provenance-based control,\noff-chain privacy, and native EOA compatibility.\n(eg., Safe) distribute trust via t-of-n approvals [?], common for treasuries and\nbridges [?,?,?]. Drawbacks include quorum overhead, symmetric authority, and\npublic logic with attackable frontends [?]. In contrast, PASS offers fine-grained,\nscoped permissioning without new contracts.\nSmart Contract Wallets and Account Abstraction. Wallets like Ar-\ngent and Loopring add programmability (social recovery, spend limits) via on-\nchain logic [?,?,?]. ERC-4337 enables custom validation through UserOperation\ncontracts [?], and EIP-7702 lets EOAs invoke this logic [?]. These increase flex-\nibility but expose policies publicly and incur gas costs, limiting use cases like\npayroll. PASS instead enforces policy privately in a TEE, minimizing on-chain\nfootprint.\nCustodial Policies. Custody providers (Fireblocks, Turnkey, Privy) use\nRBAC/ABAC engines with custom policy languages [?,?]. PASS replaces these\nwith provenance: authority follows asset origin and history, akin to a UTXO\nmodel. This reduces policy-surface complexity while remaining composable with\nconstraints like whitelists and blacklists.\nTEEs and Liquefaction. Trusted Execution Environments (TEEs) provide\nhardware-isolated contexts with remote attestation [?,?]. Liquefaction [?] keeps\nwallet keys in a TEE and enforces sub-policies via key encumbrance, ensuring\nprivacy. PASS advances this model by (i) proving invariants in Lean 4, (ii) sim-\nplifying enforcement to a provenance rule with Inbox/Outbox subaccounts, and\n(iii) working with a standard EOA without relying on Oasis smart contracts\n[?]. We further validate by implementing PASS on AWS Nitro Enclaves and In-\ntel TDX (via dStack), and showcase applications including AI wallets, payroll,\nsupply chains, and DAO voting.\nOther Models. Exchanges pool funds in omnibus addresses with off-chain\nledgers [?]; mixers like Tornado Cash hide deposit–withdrawal links [?]. PASS\n4J. Yu\nsimilarly hides internal transfers while retaining a provenance log for auditability;\noutsiders see only deposits and withdrawals.\n3 System Model and Design\nFig. 2. Overview of PASS. External deposits enter the Inbox and are claimed by sub-\naccounts. Internal transfers are private and off-chain. Egress occurs via the Outbox,\nwhich signs and broadcasts on-chain transactions. All on-chain activity has clear prove-\nnance; internal movements remain private.\n3.1 High level system model\nPASS is a multi-user wallet on a single EOA (sk, pk). The wallet maintains a\nfinite set of subaccounts U ={u\n1\n,...,u\nn\n} and a set of assets A (e.g., ERC-20).\nA subaccount u ∈ U has authority over an amount x of asset α ∈ A iff it can\nobtain a signature from the global sk via the enclave; sk resides only inside a TEE\nand is never directly accessible. We give the intuitive model here and formalize\nit in Section ??.\nInternally, PASS tracks balances with a map L : U ×A →Z\n≥0\n(accessed\nvia L[u][α]), an Inbox multiset I of unclaimed deposits (α,x,m), an Outbox\nFIFO queueO of pending on-chain actions (α,x, extDst,ν) together with a global\nnonce ν ∈N, and an append-only provenance logH. The core principles of PASS,\nas shown in Figure ?? are as follows:\n1. Access follows provenance. A unit of value is usable by u only if there\nexists a custody chain in H from an external deposit to u. Informally,\nAllow(u,α,x) means balance x is reachable for u via provenance in H. This\nimplies consistency : for every α, the total internal balance equals the on-\nchain balance at pk, i.e.,\nP\nu∈U\nL[u][α] = B\non\n(α). Incoming deposits (α,x,m)∈\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets5\nI are “wrapped” and must be explicitly claimed before use by the sender\naddress.\n2. Off-chain privacy. Internal transfers u→ v update only L and H; they do\nnot touch O or the on-chain balance B\non\n, so internal flow is invisible and\nfee-less.\n3. First-come, first-served. Outbox transactions are sequenced by a FIFO queue,\nwhich maintains and increments a global nonce ν and directly sends enclave-\nsigned transactions to a RPC node to prevent nonce conflicts and replay\nattacks.\n3\nOrganizational Ownership Model. PASS operates under an organiza-\ntional ownership model, where an entity such as a company, individual, or DAO\nmanages shared control over blockchain assets. We detail the threat model in\nSection ??.\nInbox-Outbox Gateway External senders transfer assets to pk, creating\nInbox entries (α,x,m) ∈ I. A user performs claim(u,α,x,m) to move value\nintoL[u][α], conceptually “wrapping” the deposit. To withdraw or interact with\na contract, a subaccount first performs an internal transfer to the Outbox,\nwhich enqueues (α,x, extDst,ν); the enclave then signs the concrete transaction\nwith sk and immediately broadcasts it, incrementing ν. The FIFO discipline and\nglobal nonce serialize actions and prevent races and double-spends. Because sub-\naccounts never receive pre-signed transactions, pre-signing misuse is mitigated.\nComposable policy scheme. Deposits are claims fromI; internal transfers\nrequire Allow(u,α,x) and update (L,H); withdrawals are internal transfers to\nO followed by submission. Additional constraints (eg., RBAC or ABAC checks,\nwhitelists and blacklists) can be incorporated as conjuncts to Allow without\nchanging the provenance-centric rule or its consistency and privacy effects.\n3.2 Formal Model\nWe formalize PASS as a transition system in Lean 4\n4\n, an interactive theorem\nprover with a rich dependent type system [?], suitable for policy verification (eg.,\nAWS Cedar [?]). In this section, we introduce the formal system we modeled in\nlean, and in Section ?? we will discuss security invariants modeled. An extended\ndiscussion of our formal verification system can be found in Appendix ??.\nState. A wallet state is S =\n\u0000\npk, sk,ν,I,O,L,H\n\u0001\nwhere (pk, sk,ν) are the\nEOA public key, private key (generated and held in the TEE), and global nonce;\nI and O are Inbox and Outbox; L is the internal balance map L[u][α] ∈Z\n≥0\n;\nandH is the provenance history. For privacy arguments we also use the external\nview W\npub\n= (pk,O,A), where O contains the Outbox queue and nonce and A\nrecords total on-chain balances by asset.\n3\nWe assume that the TEE is able to run a Helios light client, as is the case in dstack\nIntel TDX, discussed and implemented in Section ??\n4\nLean 4 model: https://github.com/pass-wallet/pass-lean4-proofs\n6J. Yu\nPASS Wallet Management Functionality F\nΣ\nPASS\nfor wallet W\nGlobal State:\npk : public address (EOA)\nsk : private key (in TEE)\nν: global nonce for on-chain transactions\nI (Inbox): set of unclaimed deposits (α : asset,x : amount,m : depositId)\nO (Outbox): FIFO queue (α,x, extDst,ν)\nL (Asset Ledger): internal map L[u][α]∈ Z\n≥0\n, where u is each user’s ID in the system\nH (Provenance History): a list of transaction records appended whenever ClaimInbox,\nInternalTransfer, or Withdraw is invoked\nCreatePassWallet (creator ):\nI← ∅, O← ∅, L←{}; ν← 0\n(pk, sk )← TEE\nKeyGen()\nReturn new W with S =\n\u0000\npk, sk,ν,I,O,L,H\n\u0001\nand reference to creator\nInboxDeposit (α,x,m) from external P :\nI ← I ∪ {(α,x,m)}\nReturn success\nClaimInbox (α,x, depositId) from u:\nIf no (α,x,m) with depositId in I, return ⊥\nRemove (α,x,m) from I\nL[u][α]←L[u][α] + x\nH←H| (op = claim,α,x, depositId,u)\nReturn success\nCheckAllow (u\nsend\n,α,x,H):\nIf H.GetProvenance(α, u\nsend\n)≥ x,\nreturn true; else return false\nInternalTransfer (α,x,u\nsend\n,u\nrecv\n):\nIf L[u\nsend\n][α] < x or ¬checkAllow(u\nsend\n,α,x,H), return ⊥\nL[u\nsend\n][α]←L[u\nsend\n][α]− x\nL[u\nrecv\n][α]←L[u\nrecv\n][α] + x\nH←H\n\f\n\f\n\u0000\nop = transfer,α,x,u\nsend\n,u\nrecv\n\u0001\nReturn success\nWithdraw (α,x,u\nsend\n, extDst):\nIf L[u\nsend\n][α] < x or ¬checkAllow(u\nsend\n,α,x,H), return ⊥\nL[u\nsend\n][α]←L[u\nsend\n][α]− x\nO ←O∪{(α,x, extDst,ν)}\nH←H | (op = withdraw,α,x,u\nsend\n, extDst)\nReturn success\nSignGSM (dom, msg,u):\nIf u lacks sign-right for (dom, msg), return ⊥\nσ ← (sk, msg)\nReturn σ\n(Outbox Processing) (periodic or on demand):\nIf O ̸= ∅, dequeue (α,x, extDst,ν)\nBuild tx τ : transfer x of α to extDst, nonce = ν\nσ ← (sk, τ ); broadcast (τ,σ)\nν←ν + 1\nReturn broadcasted + txHash\nFig. 3. Formal Model of PASS wallet functionality, including CreatePassWallet for\ninitializing a fresh instance. On creation, pk is set to a chosen EOA address eoa, the\nTEE generates a hidden private key sk , and global data structures are initialized.\nExternal deposits enter I (Inbox), while subaccount transfers update L (Ledger) off-\nchain. Withdrawals queue items in O (Outbox), and GSM operations are signed using\nsk .\nTransitions. Operations op∈ T update S with type-checked rules: InboxDe-\nposit adds an unclaimed (α,x,m) to I; ClaimInbox moves (α,x,m) from I to\nL[u][α] and appends to H; InternalTransfer moves value between subaccounts;\nWithdraw debits L[u][α], enqueues (α,x, extDst,ν) in O, and logs; SignGSM\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets7\nauthorizes domain-scoped signable messages. A representative rule is:\n\u0000\npk, sk,ν,I,O,L,H\n\u0001\ntransfer(α,x,u\ns\n,u\nr\n)\n−−−−−−−−−−−→\n\u0000\npk, sk,ν,I,O,L\n′\n,H\n′\n\u0001\nwith\nif L[u\ns\n][α] < x or ¬checkAllow(u\ns\n,α,x,H) then ⊥;\nL\n′\n[u\ns\n][α] =L[u\ns\n][α]− x, L\n′\n[u\nr\n][α] =L[u\nr\n][α] + x;\nH\n′\n=H\n\f\n\f\n\u0000\nop = transfer,α,x,u\ns\n,u\nr\n\u0001\n.\nHere checkAllow queries provenance inH and can be extended with auxiliary\nconstraints such as user whitelists or blacklists, without changing the core rule.\nFigure ?? provides a formal specification of the methods in a PASS wallet.\n3.3 Asset Model and General Signable Messages\nPASS provides an authorization scheme over a heterogenous set of assets A, in-\ncluding fungible tokens, such as ether and ERC-20 tokens, ERC-721 non-fungible\ntokens, and “general signable messages” across a variety of DApps for sign-in\nand identity verification. Each asset α ∈ A has a well-defined custody path in\nthe provenance log H, and a subaccount u ∈ U has usable balance x of α iff\nAllow(u,α,x) holds.\nToken assets. For token assets such as ether, ERC-20, and ERC-721, de-\nposits are captured as Inbox entries (α,x,m) ∈ I. Claims allocate balance into\nL[u][α], internal transfers update L and H privately, and withdrawals enqueue\n(α,x, extDst,ν) intoO for enclave signing and on-chain broadcast, ensuring con-\nsistency where:\n∀α∈A\ntokens\n:\nX\nu∈U\nL[u][α] = B\non\n(α, pk).\nIn particular, ERC-721 tokens are modeled as unitary balances (x ∈ {0, 1})\nwhose transfers preserve uniqueness under provenance.\nGeneral Signable Messages (GSMs). In addition to on-chain assets,\nwallets often sign arbitrary messages, such as for EIP-4361 [?] logins and off-\nchain DAO votes [?]. PASS models these as a special classA\nGSM\nof virtual assets.\nEach GSM asset is scoped to a domain dom, so holding α = (dom) represents\nauthority to sign messages from that domain. A signature operation:\nSignGSM(u, dom,m)7→ σ\nis permitted iff Allow(u, dom, 1) holds in H. At key generation, the wallet\ncreator is endowed with default signing authority over all domains, represented\nas an initial allocation of every α = (dom)∈A\nGSM\nto the root subaccount. These\ndomain assets can be internally transferred to delegate signing authority. Thus\nprovenance of GSMs begins at the owner and flows through transfers, providing\na well defined provenance path in H as with token assets.\n8J. Yu\nBy treating both tokens and GSMs as types of elements ofA, PASS provides\na unified provenance rule for subaccount authorization. A subaccount cannot\nspend an ERC-20 token, transfer an NFT, or sign a domain message unless it\npossesses the corresponding asset under L and H. This unified authorization\nscheme allows for fine-grained delegation, (eg., giving u rights over example.com\nwhile withholding ERC–20 funds) and consistent enforcement across on-chain\nand off-chain actions.\n4 Properties of PASS\n4.1 Threat Model\nPASS assumes an organizational ownership model, where a single entity, such\nas a company, individual, or DAO manages the EOA (pk,sk), brokers access\nbetween many users in that entity, and chooses the TEE infrastructure vendor\n(eg. AWS Nitro, dstack Intel TDX, self-hosted hardware). This model is typical\nfor use cases such as private payroll, supply chains, and AI delegation described\nin Section ??. Protected assets in PASS include the private key sk, the balance\nledger L and provenance log H, and the correctness of Allow(u,α,x) for all\nu∈ U,α∈A,x. In our model, we make the following trust assumptions:\n1. TEE integrity. Hardware isolation is sound; sk never leaves the enclave.\nRemote attestation guarantees that the enclave runs the genuine PASS bi-\nnary.\n2. Cryptography. Standard primitives (signatures, hash functions, PRFs) are\nsecure against polynomial-time adversaries.\n3. Governance majority. The deploying entity holds majority control in the\ngovernance mechanism (via DAO vote or admin privileges), ensuring it can\ninvoke the blockchain-governed KMS for MPC-based key recovery and trig-\nger fallback contracts when needed.\nAdversary Model. An adversary A may control the host OS and network,\nobserve or modify all communication with enclaves, and submit arbitrary trans-\naction requests. In particular, A may attempt to:\n– Exploit software bugs in the PASS implementation or TEE runtime,\n– Forge or replay transactions to break consistency of H,\n– Subvert provenance by violating Allow(u,α,x)\nThreats Out of Scope. On the other hand, PASS does not protect against:\n– Physical compromise of TEE hardware (tampering, microarchitectural side-\nchannels, chip decapsulation),\n– Supply-chain backdoors in TEE manufacturing,\n– Fully malicious operators with unrestricted physical access.\nThese are excluded because the organizational model assumes controlled facilities\nand vetted hardware.\nSecurity Goals. Given the assumptions above, PASS guarantees:\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets9\n1. Integrity:\nP\nu∈U\nL[u][α]≤ extDep(α) for all α, i.e., no assets can be created\nor double-spent internally.\n2. Correctness: If Allow(u,α,x) holds, then u can eventually realize x via\nWithdraw.\n3. Privacy on-chain: InternalTransfer operations do not affect externalTrace(W ),\nand to external observers, a PASS wallet is indistinguishable from an EOA.\n4. Liveness: For any authorized op ∈ Ops, if one enclave and quorum remain\nhonest, then ∃τ s.t. Exec(c, op) =⊤ within τ\n4.2 Privacy and Safety\nAfter establishing the threat model of PASS, we will address the central privacy\nand safety guarantees in our formal verification model. We sketch three central\nlemmas here, and create mechanized proofs in Lean, discussed in Appendix ??.\nProposition 1 (Internal Transfer Privacy). If two public states W\n1\n,W\n2\nshare the same pk, identical Outbox (T,ν), and equal per-asset totals in A, then\nexternalTrace(W\n1\n) = externalTrace(W\n2\n).\nProof Sketch. InternalTransfer updates only (L,H), never O or total on-chain\nbalances. OutboxProcessing in Figure ?? emits on-chain actions solely from O\n(lines 2–4), hence the trace depends only on O.\nCorollary: EOA indistinguishability. If W\npass\nand W\neoa\nshare the same pk,\nOutbox, and per-asset totals, then\nexternalTrace(W\npass\n) = externalTrace(W\neoa\n).\nThus, from an external observer’s perspective, a PASS account is indistinguish-\nable from a standard EOA: internal transfers leave no observable footprint.\nProposition 2 (Asset Accessibility). For any asset α, letting L = {u |\nL[u][α] > 0},\nX\nu∈L\nL[u][α] = totalBalance(α),\nand each u∈ L can spend its full balance subject to checkAllow.\nProof Sketch. ClaimInbox creditsL; InternalTransfer preserves the sum over u;\nWithdraw debitsL and enqueues toO, which OutboxProcessing realizes on-chain.\ncheckAllow enforces reachability from provenance in H.\nProposition 3 (Provenance Integrity). Let extDep(α) be net external de-\nposits (deposits minus realized withdrawals). For all reachable states,\nX\nu\nL[u][α] ≤ extDep(α).\n10J. Yu\nProof Sketch. Induct on transitions. InboxDeposit increases extDep only; Claim-\nInbox moves already-deposited value into L; InternalTransfer conserves the sum\nover u; Withdraw decreases the sum, and after OutboxProcessing broadcasts,\nextDep is reduced accordingly.\nGeneral signable messages (GSM). Model GSM rights as a domain-\nscoped virtual asset class A\nGSM\n. Let α = (dom)∈A\nGSM\nand permit\nSignGSM(u, dom,m) iff Allow(u,α, 1).\nThen (P2)–(P3) lift to GSM: there is always at least one domain signer, and\nGSM “balances” obey provenance conservation under transfers in H.\n4.3 Liveness\nWe define liveness as the property that any authorized operation remains even-\ntually executable, despite enclave crashes, vendor compromise, or partial gover-\nnance failure. Our model assumes deployment of PASS access logic on dstack,\nimplemented in Section ?? and detailed in Appendix ??.\nLet E denote active enclaves, C containerized wallet backends, and P gover-\nnance policies. Each container c∈C stores sealed state\nσ\nc\n=⟨S,k\nc\n, meta⟩ with S = (pk, sk,ν,I,O,L,H),\nwhere k\nc\n= Derive(K,c) is derived from an MPC-managed KMS and meta records\nattestation. An operation op ∈ Ops (deposit claim, transfer, withdrawal) ex-\necutes as: Exec(c, op) = ⊤ iff Attested(c)∧ Γ (S), where Attested(c) checks σ\nc\nagainst registry R and Γ is the quorum predicate over P. To ensure vendor-\nagnostic portability, state migration μ :E →E satisfies\n∀e\ni\n,e\nj\n∈E, e\nj\n.decrypt(σ\nc,e\ni\n,k\nc\n) = σ\nc,e\ni\n,\nTheorem 1 (Liveness Theorem). If (i) the MPC KMS tolerates f\nKMS\nfaults\nin a t-of-n threshold, (ii) governance quorums are f\ngov\n-resilient, and (iii) at least\none enclave is uncompromised, then every op∈ Ops executes within bounded time\nτ :\n∀op∈ Ops, ∃τ ≥ 0 : Exec(c, op) =⊤.\nProof Sketch. Progress follows from three guarantees: (1) the MPC KMS\nensures k\nc\nis always recoverable under threshold availability; (2) Γ encodes quo-\nrum rules that eventually relax after timeout ∆t, ensuring some subset S satisfies\nΓ (S) = ⊤; (3) migration μ allows any enclave to re-host σ\nc\n, preventing vendor\nlock-in or enclave failure from blocking execution. Algorithm ?? formalizes re-\ncovery and execution under these assumptions.\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets11\nAlgorithm 1 RecoverAndExecute(c, op)\n1: Verify enclave e attestation Q\ne\nagainst R.\n2: Derive k\nc\n← Derive(K,c); decrypt σ\nc\n.\n3: if CompromiseDetected(e\n′\n) then\n4:Rotate k\nc\nand re-encrypt σ\nc\n.\n5: end if\n6: Ensure Γ (S) =⊤ for S ⊆P(c).\n7: Execute op; append to H.\nKey Properties. (1) Portability: any attested enclave can recover σ\nc\n, in-\ndependent of vendor; (2) Monotonic Recovery: recovery steps form ρ : S → S\nwith ρ(s)⪰ s; (3) Domain Continuity: certificates remain bound to R(c) under\nmigration μ(c), preventing hijack or replay.\nImplementation details of container orchestration, attestation, and KMS pro-\ntocols are given in Appendix ??.\n5 Practical Implementations\n5.1 Prototype Implementations\nTo demonstrate feasibility, we have implemented a prototype of PASS that cap-\ntures the core architectural components.\n5\nThe prototype consists of:\n– Provenanced Access Model, the core PASS architecture outlined in Sec-\ntion ?? with the Inbox-Outbox structure, asset ledgers, and provenanced\nrule as a Rust executable.\n– Web Application Frontend, an AWS-hosted Typescript interface that\nallows users to deposit assets, initiate internal transfers, generate on-chain\ntransactions, and sign arbitrary messages on Ethereum Sepolia testnet.\n6\n– Multi-vendor TEE deployment, we deploy the PASS enclave executable\nin both AWS Nitro Enclaves and Intel TDX with the dstack framework.\nWe evaluate these two enclave deployments as complementary deployment\npaths, each with distinct tradeoffs.\nAWS Nitro Enclaves. In this design, PASS runs inside a Nitro enclave in the\nAWS cloud. The enclave executes the Inbox–Outbox logic, enforces provenance\nchecks, and signs transactions, while the provenance ledger is stored externally.\nNitro’s attestation and AWS integration simplify deployment, but reliance on a\nsingle vendor limits portability and concentrates trust. As a result, some guaran-\ntees of PASS, particularly liveness and asset accessibility, may be weaker under\nthis model.\n5\nPrototype can be found here: https://github.com/jayyu23/pass-wallet-app\n6\nWeb application: https://pass-wallet.jayyu.xyz/\n12J. Yu\nIntel TDX with dstack. dstack provides a portable, open-source runtime for\nTEEs across diverse hardware. PASS can be deployed on enclaves run by decen-\ntralized operators, with key material secured via MPC-based key management.\nBoth Inbox–Outbox logic and the provenance ledger execute inside dstack, pre-\nserving the full security properties of Section ?? and reducing vendor lock-in.\nThe tradeoff is added governance complexity over operator authorization and\npolicy enforcement.\nBlockchain Connectivity. To ensure reliable blockchain interaction, PASS inte-\ngrates Helios [?], a consensus-verified light client, within the TEE. Rather than\ntrusting external RPC endpoints, Helios cryptographically verifies all blockchain\ndata against consensus layer proofs before serving it locally. This approach elimi-\nnates the trust assumptions typically associated with centralized RPC providers\nwhile maintaining the performance characteristics necessary for real-time wallet\noperations. The light client architecture ensures that PASS’s Outbox mecha-\nnism operates on verified blockchain state, preserving the security guarantees\neven when external network providers are compromised or unreliable.\n5.2 Performance Benchmarks\nTo evaluate PASS, we benchmarked both AWS Nitro Enclaves and Intel TDX\nbackends across common operations: balance queries, transfers, withdrawals,\nclaims, wallet creation, provenance queries, and an end-to-end workflow. Each\noperation was run 100 times over 10 trials per environment, measuring through-\nput in ops/sec. Both environments used identical 4-core, 2.5 GHz, 16 GB VMs\nto ensure fair comparison. Table ?? summarizes our results, with full details\navailable in Appendix ??.\nFig. 4. Internal PASS operation throughput (ops/sec) across AWS Nitro Enclaves\nand Intel TDX. All operations are in-memory state changes within the TEE with no\nblockchain interaction. Each value represents the average of 100 operations repeated\n10 times per environment.\nOperationAWS Nitro Intel TDX\nWallet Creation6,53114,970\nAccount Balance Queries530,943935,428\nInbox-to-Subaccount Claims14,85633,064\nInternal Subaccount Transfers32,95371,292\nWithdrawal Request Creation18,29139,702\nEnd-to-End Workflow\n7\n35,66378,433\nTransaction History Queries3,7577,685\nMulti-threaded Operations (5 threads)32,18955,124\nLarge Dataset Processing481724\nThe observed performance differences between AWS Nitro Enclaves and In-\ntel TDX primarily stem from their distinct hardware architectures. AWS Nitro\nEnclaves employ a disaggregated system design, where the host server and the\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets13\nTEE hardware are physically separated. Communication between the host and\nthe enclave occurs via vsock, and the enclave itself runs on a dedicated, lower-\nperformance coprocessor. In contrast, Intel TDX leverages a special instruction\nset to provide enclave functionality directly on the main processor, eliminating\nthe need for a separate coprocessor and avoiding the overhead of data transfer\nbetween disparate components. As a result, Intel TDX is able to deliver sig-\nnificantly higher throughput for in-enclave operations compared to AWS Nitro\nEnclaves, as reflected in our benchmark results.\nThese preliminary benchmarks show that both Nitro and TDX backends can\nsustain high throughput for critical wallet operations, confirming that PASS is\npractical for real-world deployment.\nComparison with Related Work. To contextualize our performance results, we\ncompare PASS with other TEE-based blockchain systems and traditional custo-\ndial solutions.\nLiquefaction. The Liquefaction system [?] demonstrates significantly higher\nlatencies than PASS due to its reliance on blockchain oracles for transaction\nvalidation. Liquefaction exhibits mean latencies of 49 seconds for latest block\nconfirmation, 648.7 seconds ( 11 minutes) for justified confirmation, and 1,036.9\nseconds ( 17 minutes) for finalized confirmation. These delays stem from Liq-\nuefaction’s architectural requirement to wait for block confirmations on an ex-\nternal TEE-blockchain oracle before authorizing subsequent operations. In con-\ntrast, PASS performs all operations within the off-chain TEE worker without\nblockchain dependencies, achieving sub-millisecond latencies for internal opera-\ntions (e.g., 14,856-33,064 ops/sec for claims, 32,953-71,292 ops/sec for transfers).\nThis fundamental architectural difference—off-chain TEE computation versus\nblockchain-dependent validation—enables PASS to provide near-instantaneous\nuser experiences while maintaining strong security guarantees.\nTraditional Custodians. While custodial solutions do not publish detailed\nperformance benchmarks, prior work demonstrates that TEE overhead typically\nintroduces only 5-7% performance degradation compared to native execution [?].\nGiven that modern custodial systems can process thousands of operations per\nsecond, TEE-based solutions like PASS should achieve comparable throughput\nwhile providing significantly stronger security properties. Our benchmark results\nsupport this expectation, with PASS demonstrating high-throughput operation\nprocessing that would be suitable for production custodial workloads, while offer-\ning the additional benefits of cryptographic auditability, decentralized operation,\nand reduced single points of failure.\nFurther evaluation of latency distributions, concurrency scaling, and memory\nfootprint is left for future work.\n6 Applications\nPASS is a powerful primitive that enables several classes of applications across\nidentity scoping, enterprise settings, and scalability concerns.\n14J. Yu\nCategoryApplicationContextPASS Enables\nIdentities\nAI Agent\nWallets\nAutonomous agents\ninteracting with crypto\nassets [?] need signing\naccess guardrails.\nScoped subaccounts grant limited\nbalances and domain signing rights,\nenabling safe delegation without\nexposing the root key\nDAO Voting\nDelegation\nDAOs depend on\naddress-based voting and\nproxy delegation [?].\nFine-grained voting rights delegation\nthat remains auditable via provenance;\ndelegation can be restricted to specific\nDApps or domains.\nSubdomain\nProfile Pages\nOrganizations delegate\ncontrol over web or\norganizational\nsubdomains (e.g.,\nmyprofile.company.com) to\nindividuals or teams.\nEach subaccount holds scoped signing\nrights for its assigned subdomain, with\nbalances and authorities tracked in\nprovenance under a shared\norganizational identity.\nEnterprise\nPrivate PayrollOn-chain payrolls reveal\nsensitive salary\ninformation [?].\nSalary distribution through internal\ngasless transfers with audit logs;\nexternal payouts are periodically\nbatched via the Outbox.\nCompliant Org\nWallets\nFirms must maintain\ninternal accountability\nand BSA\nrecordkeeping [?].\nDepartmental and individual\nsubaccounts with explicit budgets;\nprovenance ensures regulator-grade\nauditability without exposing internal\nflows.\nPrivate B2B\nNetting\nSupply-chain and\nrecurring multi-party\npayments require\nconfidentiality.\nVendor subaccounts allow internal\nnetting of obligations, with PASS\nacting as a temporary clearing house.\nOnly net settlements exit via the\nOutbox, reducing leakage while\nretaining auditability.\nAudit / Proof\nExplorer\nRegulators and auditors\nrequire verifiable yet\nprivacy-preserving\ntransparency.\nPublic proofs derived from the\nprovenance log H, enabling compliance\nchecks and audits without disclosing\ninternal ledger state.\nScalability\nGasless\nAppchain\nHigh-throughput\napplications (e.g., trading\nengines) face prohibitive\ngas costs on-chain.\nInternalize application logic as\nsubaccount transitions; Outbox emits\nverifiable batch settlements, ensuring\ncorrectness with minimal gas.\nCross-chain\nBridges\nBridges require strong\ncustody and coordination\nof operators [?].\nInbox-Outbox abstractions enforce\nprovenance across domains; FIFO\nnonce handling prevents replay or race\nconditions.\nL2 ComposabilityRollups and L2s fragment\nassets and user\nexperience [?].\nTreat each L2 as a scoped subaccount;\nmaintain private balance transfers\ninternally, and settle externally only\nwhen crossing domains.\nFig. 5. Applications of PASS across identities, enterprise settings, and scalability so-\nlutions. We highlight a flagship application in each category.\nIdentities and Agent Delegation. PASS’s multi-user subaccount model\nallows for flexible permission scopes. As AI agents start managing crypto as-\nsets, there is a need to constrain their access. An AI agent could be given a\nsub-account that only holds limited funds or certain asset types. The AI can op-\nerate freely within those bounds, but cannot exceed its allotted assets or misuse\nother wallet assets. If compromised, damage is capped to its sub-account. This\nis much safer than giving AI the keys to an entire wallet. Similarly, PASS can\nallow for delegation-based DAO voting by giving the delegate signature rights\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets15\nover particular voting DApps, without giving access to actually transfer the as-\nsets. Subaccounts can also get scoped signing rights over particular enterprise\nsubdomains.\nEnterprise Applications. PASS’s features of internal privacy, in-built per-\nmissioning, and provenance auditability make it uniquely suited for enterprise\napplciations. A flagship use case for PASS is private payroll. On-chain salary pay-\nments today risk exposing sensitive information such as individual compensation,\ndepartmental budgets, or timing patterns. With PASS, salaries are distributed\ninternally through gasless subaccount transfers, leaving a clear provenance log for\nauditability, but without revealing per-employee details on-chain. Only periodic,\non-demand payouts exit via the Outbox, ensuring both regulatory accountability\nand privacy for internal flows. Beyond payroll, PASS supports other enterprise\nneeds: compliant organizational wallets with departmental subaccounts that en-\nforce explicit budgets, private B2B netting where vendors settle obligations inter-\nnally and only net payments leave the wallet, and auditable proof explorers that\nprovide regulators with verifiable, privacy-preserving compliance proofs derived\nfrom the provenance log.\nScalability Solutions. PASS also supports scaling use cases where on-chain\ncosts or coordination overhead make existing approaches impractical. A flagship\nexample is gasless appchains, such as for Central Limit Orderbooks (CLOBs).\nHigh-throughput applications such as CLOBs cannot afford per-transaction gas\nfees, but PASS internalizes application logic as private subaccount transitions.\nThe Outbox then emits verifiable batch settlements with minimal gas, preserv-\ning correctness while keeping costs predictable. Beyond appchains, PASS enables\ncross-chain bridges by enforcing provenance across domains and sequencing with-\ndrawals via a FIFO nonce to prevent replay or race conditions, and supports L2\ncomposability by treating each rollup or sidechain as a scoped subaccount, main-\ntaining private balance transfers internally and settling externally only when\ncrossing domains.\n7 Discussion and Future Work\n7.1 Composability and InterPASS Transactions\nWhile PASS provides privacy and provenance guarantees for a single wallet in-\nstance, an important question is how multiple PASS wallets may interact. This\nis important in supply-chain use cases where each PASS represents a single com-\npany in the supply chain.\nTrivially, PASS A can send an on-chain transaction from its Outbox to PASS\nB’s EOA account, and this will land in the Inbox of PASS B, ready to claim.\nHowever, this undermines the privacy guarantees that PASS offers at the EOA\nlevel, and is undesirable in cases where inter-organizational asset transfers con-\ntain sensitive information, such as order details.\nWe propose a non-trivial approach inspired by cross-Payment Channel Net-\nwork (PCN) protocols such as XTransfer [?]. We can treat each PASS instance\n16J. Yu\nakin to a PCN hub node, with state L and transaction history H. As with\nXTransfer, we can assume a star topology of PASS nodes, with a central PASS\nHub in communciation with all PASS nodes. The PASS Hub will aggregate all\nInterPASS transactions T := {(a\ni\n,x\ni\n,s\ni\n,r\ni\n)}\nn\ni=1\n, where (a\ni\n,x\ni\n,s\ni\n,r\ni\n) represent\nthe asset, amount, sender, and receiver, each signed by the s\ni\nOutbox.\nThe Hub aggregates these signed payment intents, computes a netted settle-\nment plan S, and coordinates a secure multi-party update protocol to commit\nthe resulting balances, similar to Thora [?]. In the optimistic case, this process\ncompletes entirely off-chain, and each participant’s balance is updated in the\nPASS ledger without revealing the underlying transaction graph. If a dispute or\nfailure occurs, any participant may trigger an on-chain enforcement transaction\nthat finalizes S atomically via the direct transfer mechanism, thus guaranteeing\nsafety.\nThis approach leverages PASS ’s provenance and state design to make each\ninstance an atomic node in PCN-style systems like X-Transfer. Here, we outline\nhow PASS Hubs can enable confidential, auditable cross-organization transfers,\nwhile full formal specification and protocol implementation is deferred for future\nwork.\n7.2 Instantiation on zkVM\nThe PASS design presented in this paper relies primarily on trusted execution\nenvironments (TEEs) to enforce provenance rules, where the enclave isolates the\nglobal secret key and mediates all access through the Inbox–Outbox mechanism.\nWhile TEEs provide strong privacy and efficiency guarantees, their trust model\ndepends on hardware attestation and vendor integrity, which may be insufficient\nin regulatory or adversarial settings that demand independent verification.\nzkVMs provide a natural next step by enabling provenance-based control to\nbe verified through succinct cryptographic proofs rather than trusted hardware.\nBy batching transitions over L, H, I, and O and producing a proof π, a mini-\nmalist verifier contract can update commitments and enforce outbox execution\nwhile preserving privacy. This direction complements the Chainless stack ar-\nchitecture [?], suggesting a path toward modular, interoperable deployments of\nPASS with stronger external verifiability and broader applicability.\n8 Conclusion\nWe presented PASS, a Provenanced Access Subaccount System, as a new wallet\narchitecture that enforces access by provenance rather than by identity or role.\nThe Inbox–Outbox mechanism ensures all assets have a verifiable lineage, while\ninternal transfers remain private and indistinguishable from a standard EOA\naccount.\nOur contributions are threefold: (i) a formal model in Lean 4 proving pri-\nvacy, accessibility, and provenance integrity; (ii) a working prototype with en-\nclave backends on AWS Nitro Enclaves and Intel TDX via dstack, integrated\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets17\nwith WalletConnect; and (iii) initial benchmarks showing the feasibility of high-\nthroughput operation. These results demonstrate that provenance-based control\ncan be realized today with mainstream blockchain tools.\nLooking forward, richer evaluations across multi-vendor TEEs, integration\nwith zero-knowledge VMs, and exploration of organizational and agent-based\ncustody are promising directions. By combining rigorous formal guarantees with\ndeployable prototypes, PASS advances the design space between strict self-\ncustody and flexible shared access, offering a path toward practical, privacy-\npreserving wallet security.\nA Formal Verification\nWe consider the formal model introduced in Section ?? of PASS as a state\nmachine in Lean4. Our goal is to prove that, under the PASS design, several\ncritical security properties always hold. We outline these properties and our\napproach to verifying them.\nA.1 Property: Privacy of Internal Transfers\nIn the PASS design, the InternalTransfer operation updates only the off-chain\nledgerL and the provenance historyH. It never modifies the OutboxO, meaning\nthere is no on-chain transaction triggered by an internal transfer. Consequently,\nexternal observers see no change in on-chain state. We formalize this by consid-\nering the on-chain view that an external party has for a given PASS Wallet. We\ncan model this visible on-chain state as a triple:\nW\npub\n=\n\u0000\npk, O, A\n\u0001\n,\nwhere:\npk is the externally owned account (EOA) address,\nO = (T,ν) is the external view of the outbox, where T is a list of enqueued\ntransactions and ν is a nonce,\nA is the external view of the Asset ledgerL, containing a list of asset entries,\neach of the form (α,x) with a unique identifier α and total balance x.\nExternal Trace. The external trace of a PassAccount state W\npub\nis the list of\nexternally visible actions, obtained by mapping each transaction in the outbox\nT to an on-chain action:\nexternalTrace(W\npub\n) =\n\b\noutboxTx(t) | t∈ T\n\t\n.\nNo internal transfers appear in externalTrace(·).\n18J. Yu\nStates That Differ Only by Internal Transfers. We say that two PassAccount\nstates W\n1\n= (pk\n1\n,O\n1\n,A\n1\n) and W\n2\n= (pk\n2\n,O\n2\n,A\n2\n) differ only by internal trans-\nfers if:\n1. pk\n1\n= pk\n2\n,\n2. O\n1\n= O\n2\n(i.e. both the list of outbox transactions and the nonce are the\nsame),\n3. For every asset identifier α, the total balance of that asset in A\n1\nequals the\ntotal balance of the same asset in A\n2\n.\nLetting getAsset(W,α) return the asset α within state W or ⊥, we require ∀α:\ntotalBalance\n\u0000\ngetAsset(W\n1\n,α)\n\u0001\n= totalBalance\n\u0000\ngetAsset(W\n2\n,α)\n\u0001\n.\nTheorem 2 (Privacy of Internal Transfers). If two PassAccount states W\n1\nand W\n2\ndiffer only by internal transfers, then their externally visible traces are\nidentical:\nexternalTrace(W\n1\n) = externalTrace(W\n2\n).\nProof. By assumption, O\n1\n= O\n2\n. Hence both states have the same outbox trans-\naction list T . Since\nexternalTrace(W\ni\n) = map\n\u0000\noutboxTx, T\ni\n\u0001\nfor i∈{1, 2},\nand T\n1\n= T\n2\n, it follows that externalTrace(W\n1\n) and externalTrace(W\n2\n) are iden-\ntical.\nThus, any sequence of purely internal transfers, changing only the private ledger\nL in PASS, is invisible to an external observer, preserving the privacy of how\nassets move within the wallet.\nA corollary of this Internal Transfer property is that a PASS account is\nindistinguishable from a regular EOA account.\nCorollary 1 (Indistinguishability from EOA). Let W\npass\nbe a PASS state\nthat (i) has the same public key pk, (ii) the same outbox, including nonce and\ntransaction list, and (iii) the same total balances of each asset as a reference\nEOA state W\neoa\n. Then\nexternalTrace(W\npass\n) = externalTrace(W\neoa\n).\nIn particular, an external observer cannot distinguish W\npass\nfrom W\neoa\n.\nProof. By assumption, the only potential differences betweenW\npass\nandW\neoa\nlie\nin internal ledger details. From Theorem 1, such internal transfers do not affect\nthe externally visible outbox transactions or total on-chain balances. Thus, their\nexternal traces coincide, and W\npass\nis indistinguishable from W\neoa\n.\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets19\nA.2 Property: Asset Accessibility\nIn addition to keeping internal transactions private, PASS should ensure that for\nevery asset in the system, there exists some sub-account that can access it and\nwithdraw it from the system. This prevents a situation where funds get ”stuck”\nwithout any reachable key or policy to move them. We define asset accessibility\nas follows:\nTheorem 3 (Asset Accessibility). For any PASS account W and asset iden-\ntified by α, there exists a list of addresses L such that:\n1. For every address u∈ L, the user can access their full balance:\ncheckBalance(s,α,u, balance(u)) = true\n2. The sum of all accessible balances equals the total balance of the asset:\nX\nu∈L\nL[u][α] = totalBalance(α)\nProof. We construct L as the set of all addresses with non-zero balances in the\nbalance map for α:\nL ={u|L[u][α] > 0}\nFor the first property, given any u∈ L, the definition of checkBalance verifies\nif the user has sufficient balance for the specified amount. When checking against\nthe user’s own balance, this is trivially satisfied since L[u][α]≥L[u][α] for all u.\nFor the second property, we observe that totalBalance is defined as the sum\nof all balances in the asset’s balance map:\ntotalBalance(α) =\nX\nu∈L\nL[u][α]\nBy construction, L contains the only nonzero values u∈L, so:\nX\nu∈L\nL[u][α] = totalBalance(α)\nTherefore, both properties hold for our constructed list L.\nWe can prove a similar trait for General Signable Messages, showing that for\nany inbound GSM, there is some subaccount signer that has access to it.\nTheorem 4 (GSM Accessibility). For any GSM and domain, there exists a\nuser with signing access to that domain.\nProof. For any domain d, we can directly construct a user u who has signing\naccess to d as follows:\nu = getSigner(d)\nBy definition, getSigner returns either:\n– A specifically assigned signer if one exists in the domain-address map, or\n– The default signer otherwise\nTherefore, every domain is guaranteed to have at least one user with signing\naccess, ensuring no GSM domain becomes inaccessible.\n20J. Yu\nA.3 Property: Provenance Integrity\nProvenance integrity specifies that every asset held by any sub-account in PASS\nmust have an origin traceable to an external deposit into the Inbox. At any\nstate of the system, for each asset entry in a sub-account’s balance, we can find\na sequence of internal transfers that leads back to an Inbox deposit from an\nexternal address. This property ensures no sub-account can conjure funds from\nnothing, such as through double-spending or inflation within the system, and\nthat the internal ledger is consistent with on-chain reality. In Lean, we model\nthe state of the PASS wallet including Inbox, Outbox, and all sub-accounts and\nprove an invariant that whenever a sub-account has x units of asset α, the global\nstate contains a record of at least x units of α having been deposited, minus any\nthat have been withdrawn.\nTheorem 5 (Provenance Integrity).\nFor any PASS account S =\n\u0000\npk, sk,ν,I,O,L,H\n\u0001\nand any asset α, the total\namount of α held across all subaccounts can never exceed the total amount of\nexternal deposits (minus any that have already been withdrawn). Formally,\nX\nu∈U\nL[u][α] ≤ externalDeposits(α),\nwhere U is the set of subaccounts in the system, and externalDeposits(α) is\nthe net total of asset α that has been introduced into the wallet from outside\naddresses, recorded in the inbox I.\nProof. We model the system’s state (pk, sk,ν,I,O,L,H) as in Figure ??, includ-\ning the Inbox I, Outbox O, and the internal ledger L. We define a provenance\nrecord P (α,u) that captures the total amount of asset α subaccount u is autho-\nrized to hold, based on Inbox claims and internal transfers.\nBase Case: Immediately after CreatePassWallet, no assets have been de-\nposited, and no subaccount balances exist:\n∀u, L[u][α] = 0, ∀α, externalDeposits(α) = 0.\nHence,\nX\nu∈U\nL[u][α] = 0 ≤ 0 = externalDeposits(α).\nInductive Step: Assume the invariant holds after n− 1 operations. We prove it\nremains valid after the nth operation, for each possible type of operation:\n(1) External Deposit: Suppose an amount x of asset α is deposited into the\nwallet:\nexternalDeposits(α) ← externalDeposits(α) + x.\nNo subaccount balances L[u][α] change. Thus, the left side of our inequality\n(sum of subaccount balances) is unchanged, while the right side strictly\nincreases by x, so the invariant continues to hold.\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets21\n(2) Inbox Claim: If subaccount u claims amount x of asset α from the Inbox\nI:\nL[u][α] ← L[u][α] + x, P (α,u) ← P (α,u) + x.\nSince x was already accounted for in externalDeposits(α) (but not yet allo-\ncated to any subaccount), the total subaccount balances remain≤ externalDeposits(α).\n(3) Internal Transfer: If subaccount u\n1\ntransfers x of α to subaccount u\n2\n:\nL[u\n1\n][α] ← L[u\n1\n][α]− x, L[u\n2\n][α] ← L[u\n2\n][α] + x,\nand P (α,u\n2\n) increases by x. Because the sum of all subaccount balances\ndoes not change, our invariant is preserved.\n(4) Withdrawal: If subaccount u withdraws x of α:\nL[u][α] ← L[u][α]− x,\nwhich reduces the total subaccount balances. Since externalDeposits(α)\nremains unchanged (assets have simply exited the wallet), the inequality still\nholds.\nThus, by induction over all possible operations,\nX\nu∈U\nL[u][α] ≤ externalDeposits(α)\nfor every reachable state. No subaccount can create new assets out of nothing,\nand all assets in the system are fully accounted for by provenanced deposits.\nB Dstack Architecture and Execution Model\nB.1 Component Overview\n– Dstack-OS: Minimal Linux-based VM image with a verifiable boot chain.\nMeasures bootloader, kernel, root filesystem (RootFs) via RTMR registers.\nIntegrates dm-verity for data integrity and monotonic counters for anti-\nrollback.\n– Dstack-KMS: Blockchain-governed MPC network for key derivation and\nrotation. Provides:\nk\nc\n= HMAC\nk\nroot\n(c\nid\n),\nk\nTLS\n= ECDSA(k\nroot\n).\nRotation is triggered via governance (t-of-n threshold).\n– Dstack-Gateway/Ingress: TLS termination inside TEEs, ZT-TLS bind-\ning X\nc\nto R(c), enabling verifiable HTTPS ingress.\n22J. Yu\nB.2 Governance Layer\nTwo contracts form the trust base:\n– KmsAuth: Global registry of KMS nodes and application digests.\n– AppAuth: Per-application contract specifying quorum rules, allowed image\nhashes, and authorized enclaves.\nB.3 Workflow Phases\n1. Attestation: Enclave e produces quote Q\ne\n; verified against R.\n2. Secret Provisioning: MPC nodes compute k\nc\n, release to e if Q\ne\nis valid.\n3. Container Launch: Dstack-OS mounts RootFs, decrypts state σ\nc\nwith k\nc\n.\n4. Ingress Binding: TLS certificate X\nc\ngenerated inside e; bound to R(c).\n5. Audit Logging: Migration, key rotation, and governance events appended\nto H.\nB.4 Fault Tolerance\n– Vendor failure: μ enables re-deployment across Intel/AMD TEEs.\n– KMS compromise: key rotation via MPC thresholds restores forward/backward\nsecrecy.\n– Governance deadlock: ∆t fallback in Γ ensures quorum reduction and progress.\nB.5 Liveness Proof Sketch\nCombining MPC-based key recovery, quorum fallback, and portable containers\nyields:\n∀op∈O\nc\n,Pr[Exec(c, op) =⊤] = 1\nunder assumptions of f -resilient MPC nodes and at least one uncompromised\nTEE instance.\nC Detailed Benchmark Results\nThis appendix provides comprehensive benchmark statistics for both AWS Nitro\nEnclaves and Intel TDX environments. All operations are internal PASS state\nchanges that occur within the TEE with no blockchain network interaction.\nEach operation was executed 100 times per trial, with 10 independent trials\nper environment. The tables below show summary statistics including mean,\nstandard deviation, and range.\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets23\nTable 1. AWS Nitro Enclaves benchmark statistics (ops/sec) across 10 trials\nOperationMean Std Dev Min Max\nWallet Creation6,5315315,4467,042\nAccount Balance Queries530,943675 530,216 531,915\nInbox-to-Subaccount Claims14,856476 14,326 15,504\nInternal Subaccount Transfers32,9531,322 31,447 35,088\nWithdrawal Request Creation18,2911,254 15,873 19,608\nEnd-to-End Workflow35,6636,234 21,739 40,650\nTransaction History Queries3,757453,6503,802\nMulti-threaded Operations (5 threads) 32,189884 31,200 34,364\nLarge Dataset Processing48113467497\nTable 2. Phala dStack benchmark statistics (ops/sec) across 10 trials\nOperationMean Std Dev Min Max\nWallet Creation14,9704,6528,69624,390\nAccount Balance Queries935,428338,450 383,142 1,470,588\nInbox-to-Subaccount Claims33,0645,197 25,44541,667\nInternal Subaccount Transfers71,29217,623 47,170 101,010\nWithdrawal Request Creation39,7027,434 29,15551,813\nEnd-to-End Workflow78,43317,403 59,524 110,497\nTransaction History Queries7,6858726,4528,929\nMulti-threaded Operations (5 threads) 55,12416,744 28,32981,301\nLarge Dataset Processing72481636893\nC.1 AWS Nitro Enclaves Results\nC.2 Intel TDX Results\nC.3 Performance Analysis\nThe statistical analysis reveals several key insights about PASS’s internal oper-\nation performance:\n– Performance Consistency: AWS Nitro Enclaves demonstrate superior\nconsistency with lower standard deviations across all operations. The co-\nefficient of variation ranges from 0.1% (Account Balance Queries) to 17.5%\n(End-to-End Workflow).\n– Peak Performance: Intel TDX achieves higher mean throughput but with\nsignificantly greater variance. Standard deviations are 10-500x larger than\nNitro, indicating less predictable performance.\n– Production Considerations: These internal operation benchmarks demon-\nstrate PASS’s ability to handle thousands of wallet operations per second\nwithin the TEE, with the actual deployment bottleneck being blockchain\ntransaction submission rather than internal processing.\nThe statistical summary confirms that both platforms support practical PASS\ndeployment, with Nitro offering predictable performance and Intel TDX provid-\ning higher peak throughput at the cost of consistency.\n24J. Yu\nD Design Extensions\nD.1 Composability and InterPASS Transactions\nWhile PASS provides privacy and provenance guarantees for a single wallet in-\nstance, an important question is how multiple PASS wallets may interact. This\nis important in supply-chain use cases where each PASS represents a single com-\npany in the supply chain.\nTrivially, PASS A can send an on-chain transaction from its Outbox to PASS\nB’s EOA account, and this will land in the Inbox of PASS B, ready to claim.\nHowever, this undermines the privacy guarantees that PASS offers at the EOA\nlevel, and is undesirable in cases where inter-organizational asset transfers con-\ntain sensitive information, such as order details.\nWe propose a non-trivial approach inspired by cross-Payment Channel Net-\nwork (PCN) protocols such as XTransfer [?]. We can treat each PASS instance\nakin to a PCN hub node, with state L and transaction history H. As with\nXTransfer, we can assume a star topology of PASS nodes, with a central PASS\nHub in communciation with all PASS nodes. The PASS Hub will aggregate all\nInterPASS transactions T := {(a\ni\n,x\ni\n,s\ni\n,r\ni\n)}\nn\ni=1\n, where (a\ni\n,x\ni\n,s\ni\n,r\ni\n) represent\nthe asset, amount, sender, and receiver, each signed by the s\ni\nOutbox.\nThe Hub aggregates these signed payment intents, computes a netted settle-\nment plan S, and coordinates a secure multi-party update protocol to commit\nthe resulting balances, similar to Thora [?]. In the optimistic case, this process\ncompletes entirely off-chain, and each participant’s balance is updated in the\nPASS ledger without revealing the underlying transaction graph. If a dispute or\nfailure occurs, any participant may trigger an on-chain enforcement transaction\nthat finalizes S atomically via the direct transfer mechanism, thus guaranteeing\nsafety.\nThis approach leverages PASS ’s provenance and state design to make each\ninstance an atomic node in PCN-style systems like X-Transfer. Here, we outline\nhow PASS Hubs can enable confidential, auditable cross-organization transfers,\nwhile full formal specification and protocol implementation is deferred for future\nwork.\nD.2 Instantiation on zkVM\nThe design of PASS presented thus far relies on trusted execution environments\n(TEEs) such as AWS Nitro or Intel TDX to enforce provenance-based control.\nTEEs provide strong isolation and efficient execution, allowing internal transfers\nto remain private while ensuring that every outbox action has a verifiable lin-\neage. However, the trust model is anchored in hardware attestation: users and\nregulators must accept that the enclave executes the correct code as claimed.\nWhile sufficient for many organizational custody scenarios, this assumption lim-\nits transparency and long-term auditability. To address this limitation, we ex-\nplore an alternative instantiation of PASS in a zero-knowledge virtual machine\n(zkVM), replacing hardware trust with cryptographic proofs of correctness.\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets25\nZero-knowledge virtual machines (zkVMs) provide a proving environment in\nwhich arbitrary state machines can run with strong correctness guarantees [?].\nBy producing a succinct proof π of execution, zkVMs offer integrity assurances\nsimilar to TEEs but without reliance on vendor-specific hardware. This shift\nmakes zkVMs particularly suitable for contexts such as institutional custody,\nmulti-party supply chains, or inter-organizational accounting where external ver-\nifiability and regulator-grade auditability are paramount.\nIn a zkVM instantiation of PASS, the execution pipeline mirrors the enclave-\nbased design but replaces attestation with cryptographic proofs. The process\nproceeds in four stages:\n1. Batch formation. Transaction requests (claims, transfers, withdrawals) are\nfirst queued off-chain into a batch.\n2. zkVM execution. The zkVM program takes as private inputs: (i) the prior\nbatch’s commitments of the ledger L and provenance log H, (ii) the queued\ntransitions, including inbox I deposits and outbox O withdrawals, and (iii)\nthe proposed new commitments (L\n′\n,H\n′\n). Inside the zkVM, the transition\nfunction is replayed deterministically: starting from the previous roots, ap-\nplying all operations in sequence, updating balances and provenance entries,\nand checking consistency constraints.\n3. Proof generation. The zkVM outputs a succinct proof π certifying that the\nclaimed new roots (L\n′\n,H\n′\n) are correct with respect to the given transition\nset.\n4. On-chain verification. A minimalist verifier contract validates π, updates\nthe recorded commitments, and enforces any pending outbox operations.\nThis ensures that every external action has a verifiable provenance path\nwhile internal transfers remain private.\nCompared to TEEs, zkVMs strengthen the verifiability model by eliminat-\ning hardware trust assumptions, but incur higher computational and financial\ncosts due to proof generation and on-chain verification. Batching amortizes these\ncosts, raising open research questions about optimal batch sizes, data availabil-\nity strategies, and proof system selection. zkVM backends such as Risc0, SP1,\nor Plonky3 offer different tradeoffs in proof size, verification cost, and latency.\nHybrid deployments are also possible: TEEs can serve as fast-path executors for\nintra-day operations, with zkVM proofs generated periodically to provide cryp-\ntographic audit trails. This hybrid pattern resembles optimistic rollups, where\nfast execution is combined with verifiable settlement.\nFinally, this instantiation aligns closely with the Chainless stack architec-\nture [?], which emphasizes the separation of execution, trust, bridging, and set-\ntlement. In this view, zkVM proofs naturally inhabit the execution and trust\nlayers, Inbox/Outbox commitments integrate with bridging, and the verifier\ncontract finalizes settlement. This layered design opens the door to modular,\ninteroperable deployments of PASS across heterogeneous chains and domains.\nFull formal specification, performance benchmarking, and exploration of hybrid\nzkVM–TEE implementations remain important avenues for future work.\n26J. Yu\nFig. 6. PASS instantiation inside a zkVM: Inbox I and Outbox O transitions are\napplied to the Ledger L and Provenance H, producing new state commitments. The\nzkVM outputs a proof π, which the on-chain verifier checks before updating roots and\nenforcing outbox operations."
}
]
},
{
"role": "assistant",
"content": "To convincingly argue that existing wallet architectures cannot satisfy the three use cases described in the Introduction—and to establish why provenance- and TEE-based solutions (like PASS) are superior—we must proceed with analytical rigor. Let us structure the argument as follows:\n\n---\n\n### 1. Common Challenges Across the Three Use Cases\n\nThe three use cases—(1) AI and smart agent transactions, (2) enterprise payroll privacy, and (3) consumer-grade central limit order books (CLOBs)—share several foundational requirements:\n\n- **Fine-grained, context-aware access control**: Multiple actors or agents (human or AI) require scoped permissions, often with dynamic delegation and revocation.\n- **Privacy of internal operations**: Sensitive details (e.g., salary distribution, trading strategies) must be shielded from public blockchain visibility.\n- **Auditability and provenance**: All asset movements must be traceable for accountability, compliance, and operational safety, without leaking internal business logic.\n- **Compatibility and deployability**: Solutions must integrate with existing blockchain infrastructure (native EOA compatibility) and avoid introducing prohibitive costs or deployment friction.\n- **Minimized trust assumptions**: Reliance on centralized custodians, bespoke policy engines, or opaque hardware should be mitigated, and the system should be robust against compromised infrastructure.\n\n---\n\n### 2. Limitations of Existing Approaches\n\n**a. EOAs and Multisig Wallets**\n\n- **Lack of Granular Control**: EOAs offer no internal permissioning; whoever holds the key controls all assets. Multisigs provide only symmetric, static authority (t-of-n), which is coarse-grained and unsuitable for dynamic or hierarchical delegation (e.g., AI agents with limited spending rights, or departmental payroll).\n- **No Internal Privacy**: All multisig logic and transactions are public. Internal movements (e.g., salary splits, order routing) are visible on-chain, leaking sensitive information.\n- **Operational Overhead**: Multisigs require on-chain coordination for every action, incurring gas and latency that are prohibitive for real-time trading (CLOBs) or high-frequency payroll.\n\n**b. Smart Contract Wallets (Account Abstraction, ERC-4337, etc.)**\n\n- **Public Policy Exposure**: Custom validation logic is encoded on-chain, making access rules and internal flows transparent to adversaries and competitors.\n- **Gas and Complexity Costs**: Every policy check or transfer is a smart contract operation, increasing gas expense and limiting throughput—untenable for high-frequency or privacy-sensitive use cases.\n- **Compatibility Constraints**: Many solutions require specific chain support (e.g., ERC-4337), reducing portability and increasing integration friction.\n\n**c. Custodial Wallets with RBAC/ABAC Engines**\n\n- **Off-chain Enforcement and Trust**: Policies are enforced off-chain by custodians, who have full visibility into internal activity. This introduces a single point of failure and privacy risk, as well as regulatory and operational dependency on the custodian.\n- **Policy Language Proliferation**: Each custodian implements bespoke policy APIs, leading to fragmentation, lack of composability, and brittle access semantics.\n- **No Asset Provenance**: Authority is attached to identities or roles, not to the origin or flow of assets, making it awkward to enforce chain-of-custody or audit trails directly tied to deposits.\n\n**d. TEE-based Wallets (e.g., Liquefaction)**\n\n- **Limited Formal Guarantees**: Prior TEE-based approaches (like Liquefaction) rely on key encumbrance and policy trees, but lack formal proofs of privacy, accessibility, and provenance integrity.\n- **Deployment Friction**: Some require specialized smart contract platforms (e.g., Oasis), reducing compatibility with standard EOAs and increasing vendor lock-in.\n- **Performance Bottlenecks**: Reliance on blockchain oracles for every operation (as in Liquefaction) introduces high latency, unsuitable for real-time or high-throughput scenarios.\n\n---\n\n### 3. Why Provenance- and TEE-Based Solutions (PASS) Are Superior\n\n**a. Alignment with Blockchain’s Exogenous Asset Model**\n\n- **Provenance-Centric Control**: PASS enforces access not by static roles or identities, but by the chain of custody—who deposited an asset, and how it flowed internally. This matches the exogenous way assets enter wallets on blockchains and supports fine-grained, composable access rules.\n\n**b. Privacy by Design**\n\n- **Internal Privacy**: Internal (off-chain) transfers update only the private ledger and provenance log; they are invisible externally. To outsiders, the wallet is indistinguishable from a standard EOA. This directly addresses enterprise payroll and trading privacy requirements.\n- **TEE Isolation**: Private keys and all sensitive logic reside in TEEs, ensuring that even infrastructure operators cannot access or leak internal flows.\n\n**c. Formal Security and Auditability**\n\n- **Proven Invariants**: PASS is formally modeled and verified (in Lean 4) to guarantee privacy, accessibility (no stuck funds), and provenance integrity (no double-spending or unauthorized asset creation).\n- **Audit-Ready Provenance**: All asset movements have a verifiable lineage, supporting regulatory audits and internal compliance without exposing business-sensitive details.\n\n**d. Deployability and Performance**\n\n- **Native EOA Compatibility**: PASS operates on standard EOAs, requiring no contract upgrades or specialized chain support. Deployments are possible on mainstream TEE platforms (AWS Nitro, Intel TDX).\n- **High Throughput, Low Latency**: Internal operations are off-chain and in-TEE, achieving sub-millisecond performance, as shown in benchmarks. Unlike prior TEE or smart contract solutions, PASS is suitable for real-time and high-frequency applications (e.g., CLOBs).\n- **Composable Policy**: While the core is provenance-based, additional constraints (e.g., RBAC/ABAC, whitelists) can be layered as conjuncts, without sacrificing the core privacy and consistency guarantees.\n\n---\n\n**Conclusion**\n\nIn sum, existing solutions either (i) fail to provide the necessary granularity, privacy, and auditability (EOAs, multisigs, custodians), (ii) leak sensitive policy and incur operational overhead (smart contract wallets), or (iii) lack formal guarantees and performance (prior TEE wallets). Provenance- and TEE-based solutions like PASS uniquely satisfy all requirements: they enable privacy-preserving, finely-scoped, and auditable access for multi-actor wallets across all three target use cases, with formal security guarantees and practical deployability. This architectural shift is not incremental but foundational, bridging the gap between strict self-custody and flexible, privacy-preserving shared access."
},
{
"role": "user",
"content": "this is too long to fit in the introduction, directly write them for me"
}
]Response:
Certainly. Here is a concise, logically structured passage suitable for the introduction, directly addressing your goals:
---
The three motivating use cases—AI agent wallets, private enterprise payroll, and consumer-grade on-chain order books—share core requirements: fine-grained access control among multiple actors, internal privacy for sensitive operations, and verifiable audit trails for asset movements. Existing wallet architectures cannot jointly satisfy these needs. EOAs and multisigs lack internal privacy and offer only coarse, public control; smart contract wallets expose all policy logic and internal flows on-chain, incurring prohibitive gas costs and leaking confidential details; custodial solutions rely on off-chain enforcement and centralized trust, sacrificing transparency and provenance. Prior TEE-based approaches either lack formal guarantees or require non-standard infrastructure, limiting flexibility and performance.
In contrast, provenance- and TEE-based solutions such as PASS directly align with blockchain’s asset model, enforcing access by verifiable custody chains rather than static roles or on-chain logic. This enables internal, gasless, and private transfers with auditable provenance, while the TEE isolates sensitive keys and policies from external exposure. Our approach thus uniquely achieves privacy, auditability, and flexible access at scale, bridging the gap between strict self-custody and practical, privacy-preserving shared wallets.
Model: gpt-4.1-2025-04-142025-09-15 12:29:54
Context:
[
{
"role": "system",
"content": "You are a research paper writer. You focus on:\n1. logical consistency\n2. whether the story is persuasive\nDon't try to be friendly on purpose, judge everything based on the logic and expressiveness."
},
{
"role": "user",
"content": [
{
"type": "text",
"text": "Use the contents of Introduction and Background, answer my question.\n\nMy target is to demonstrate that the existing works cannot satisfy the three use cases in Introduction, and also explain why provenance- and TEE-based solution is a better solution for this.\n\nI think a good way to write about this is \n\n1. summarize the common challenges in the three use cases\n2. give a short but insightful elaboration that the existing works have limitations, so cannot solve this\n3. explain why our work can solve this"
},
{
"type": "text",
"text": "main.pdf\nPASS: A Provenanced Access Subaccount\nSystem\nfor Blockchain Wallets\nJay Yu\n1,2\n1\nStanford University [email protected]\n2\nPantera Capital [email protected]\nAbstract. Blockchain wallets still follow a single-entity ownership model:\npossession of a private key grants unilateral control. This assumption is\nbrittle for emerging settings such as organizational custody, shared gov-\nernance, and AI agent wallets, where multiple actors must coordinate\nwithout exposing secrets or leaking internal activity.\nWe present PASS, a Provenanced Access Subaccount System\nthat replaces role or identity-based control with provenance-based con-\ntrol: assets can only be used by subaccounts that can trace custody back\nto a valid deposit. A simple Inbox–Outbox mechanism ensures all exter-\nnal actions have verifiable lineage, while internal transfers remain private\nand indistinguishable from ordinary EOAs.\nWe formalize PASS in Lean 4 and prove core invariants, including\nprivacy of internal transfers, asset accessibility, and provenance integrity.\nWe implement a prototype with enclave backends on AWS Nitro Enclaves\nand dstack Intel TDX, integrate with WalletConnect, and benchmark\nthroughput across wallet operations. These results show that provenance-\nbased wallets are both implementable and efficient. PASS bridges today’s\ngap between strict self-custody and flexible shared access, advancing the\ndesign space for practical, privacy-preserving custody.\n1 Introduction\nCryptocurrency wallets conventionally assume one key, one owner. In this single-\nentity ownership (SEAO) model, whoever holds the private key gains permanent\nand total control of the address, and casts publicly readable, gas-consuming\nblockchain transactions. However, this model struggles to adapt to emerging\nblockchain scenarios:\n1. AI and Smart Agent Transactions. AI agents increasingly manage crypto\nassets [?,?] and require bounded authority and access guardrails for users’\nasset security.\n2. Enterprise Payroll Privacy. Organizations need to distribute salaries and\ndepartmental budgets to employee accounts without revealing sensitive de-\ntails on-chain [?,?,?].\n2J. Yu\n3. Consumer-grade Central Limit Order Books. On-chain order books\nface high gas costs and latency that prevent real-time trading at scale [?,?],\nand many consumers prefer not to manage their own keys [?,?].\nIn practice, many organizations confronted with these challenges default to\ncustodians or policy engines that wrap access logic in Role-Based Access Con-\ntrol (RBAC) or Attribute-Based Access Control (ABAC) [?,?]. These systems\nintroduce a proliferation of bespoke policy languages and APIs to specify who\nmay sign or transfer under which conditions [?,?]. While workable as a stopgap,\nthey inherit identity and role assumptions from traditional IT settings that limit\ntheir flexibility and scalability in blockchain contexts.\nThe limitation stems from a mismatch of models. Traditional access-control\nframeworks such as RBAC and ABAC assume an endogenous setting: users\ncreate and manage their own files, objects, or services, and policies are attached\nto these identities or roles. Blockchains are fundamentally exogenous: assets are\ncreated outside the wallet by smart contracts and transferred permissionlessly\nin. In this setting, identity or role-based rules are awkward to express and brittle\nto enforce. What matters instead is provenance: who deposited an asset, and how\nit flowed within the wallet.\nWe propose PASS, a Provenanced Access Subaccount System that enforces\ncontrol directly by provenance. The core mechanism is simple: an Inbox records\nexternal deposits, an Outbox signs and broadcasts withdrawals, and all internal\nmovements remain private and fee-less. Every unit of value inside the wallet has\na verifiable lineage to an on-chain deposit, while externally a PASS wallet is\nindistinguishable from a standard EOA. Our contributions include:\n– A provenance-based access model aligned with blockchain’s exogenous asset\ncreation, enforced through an Inbox–Outbox design.\n– A formal model in Lean 4 proving privacy, accessibility, and provenance\nintegrity.\n– A prototype with multi-vendor enclave backends (AWS Nitro, Intel TDX via\ndstack), a web app frontend integrated with WalletConnect, together with\nthroughput benchmarks.\n– Application scenarios, including organizational custody, privacy-preserving\ntransfers, and safe delegation to AI agents.\nPASS thus bridges the gap between strict self-custody and flexible shared\naccess, combining strong privacy guarantees with practical deployability.\n2 Background and Related Work\nGrowing retail and institutional adoption of digital assets [?] has driven diverse\nwallet designs [?]. We summarize mainstream Ethereum Virtual Machine (EVM)\nwallet designs in Figure ??.\nEOAs and Multisigs. Externally Owned Accounts (EOAs) give unilateral,\npermanent control to whoever holds the private key [?]. Multisignature wallets\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets3\nModelControl basisOn-chain\noverhead\nInternal\nPrivacy\nCompatibility\nEOASingle private keyNoneNoneNative EOA\nMultisigt-of-n co-signersHigh; quorum per\naction\nNone; logic\npublic\nSmart\ncontract based\nERC-4337\nSmart\nAccounts\nOn-chain policy\nlogic\nMedium to high;\ncustom logic and\ngas\nNone; logic\npublic\nRequires\nERC-4337\nchain support\nCustodiansCustom RBAC or\nABAC languages\nNone; Off-chain\nenforcement\nCustodian sees\nall activity\nAPI mediated\nLiquefactionTEE key\nencumbrance;\npolicy trees\nMedium; Oasis\ncontracts and gas\nStrong; TEE\nhides\nsubpolicies\nRequires Oasis\ndeployment\nPASS\n(ours)\nProvenance via\nInbox-Outbox\nNone; EOA\ncompatible\nStrong;\ninternal\ntransfers\ninvisible\nNative EOA\nplus off the\nshelf TEEs\nFig. 1. Comparison of wallet architectures. PASS features provenance-based control,\noff-chain privacy, and native EOA compatibility.\n(eg., Safe) distribute trust via t-of-n approvals [?], common for treasuries and\nbridges [?,?,?]. Drawbacks include quorum overhead, symmetric authority, and\npublic logic with attackable frontends [?]. In contrast, PASS offers fine-grained,\nscoped permissioning without new contracts.\nSmart Contract Wallets and Account Abstraction. Wallets like Ar-\ngent and Loopring add programmability (social recovery, spend limits) via on-\nchain logic [?,?,?]. ERC-4337 enables custom validation through UserOperation\ncontracts [?], and EIP-7702 lets EOAs invoke this logic [?]. These increase flex-\nibility but expose policies publicly and incur gas costs, limiting use cases like\npayroll. PASS instead enforces policy privately in a TEE, minimizing on-chain\nfootprint.\nCustodial Policies. Custody providers (Fireblocks, Turnkey, Privy) use\nRBAC/ABAC engines with custom policy languages [?,?]. PASS replaces these\nwith provenance: authority follows asset origin and history, akin to a UTXO\nmodel. This reduces policy-surface complexity while remaining composable with\nconstraints like whitelists and blacklists.\nTEEs and Liquefaction. Trusted Execution Environments (TEEs) provide\nhardware-isolated contexts with remote attestation [?,?]. Liquefaction [?] keeps\nwallet keys in a TEE and enforces sub-policies via key encumbrance, ensuring\nprivacy. PASS advances this model by (i) proving invariants in Lean 4, (ii) sim-\nplifying enforcement to a provenance rule with Inbox/Outbox subaccounts, and\n(iii) working with a standard EOA without relying on Oasis smart contracts\n[?]. We further validate by implementing PASS on AWS Nitro Enclaves and In-\ntel TDX (via dStack), and showcase applications including AI wallets, payroll,\nsupply chains, and DAO voting.\nOther Models. Exchanges pool funds in omnibus addresses with off-chain\nledgers [?]; mixers like Tornado Cash hide deposit–withdrawal links [?]. PASS\n4J. Yu\nsimilarly hides internal transfers while retaining a provenance log for auditability;\noutsiders see only deposits and withdrawals.\n3 System Model and Design\nFig. 2. Overview of PASS. External deposits enter the Inbox and are claimed by sub-\naccounts. Internal transfers are private and off-chain. Egress occurs via the Outbox,\nwhich signs and broadcasts on-chain transactions. All on-chain activity has clear prove-\nnance; internal movements remain private.\n3.1 High level system model\nPASS is a multi-user wallet on a single EOA (sk, pk). The wallet maintains a\nfinite set of subaccounts U ={u\n1\n,...,u\nn\n} and a set of assets A (e.g., ERC-20).\nA subaccount u ∈ U has authority over an amount x of asset α ∈ A iff it can\nobtain a signature from the global sk via the enclave; sk resides only inside a TEE\nand is never directly accessible. We give the intuitive model here and formalize\nit in Section ??.\nInternally, PASS tracks balances with a map L : U ×A →Z\n≥0\n(accessed\nvia L[u][α]), an Inbox multiset I of unclaimed deposits (α,x,m), an Outbox\nFIFO queueO of pending on-chain actions (α,x, extDst,ν) together with a global\nnonce ν ∈N, and an append-only provenance logH. The core principles of PASS,\nas shown in Figure ?? are as follows:\n1. Access follows provenance. A unit of value is usable by u only if there\nexists a custody chain in H from an external deposit to u. Informally,\nAllow(u,α,x) means balance x is reachable for u via provenance in H. This\nimplies consistency : for every α, the total internal balance equals the on-\nchain balance at pk, i.e.,\nP\nu∈U\nL[u][α] = B\non\n(α). Incoming deposits (α,x,m)∈\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets5\nI are “wrapped” and must be explicitly claimed before use by the sender\naddress.\n2. Off-chain privacy. Internal transfers u→ v update only L and H; they do\nnot touch O or the on-chain balance B\non\n, so internal flow is invisible and\nfee-less.\n3. First-come, first-served. Outbox transactions are sequenced by a FIFO queue,\nwhich maintains and increments a global nonce ν and directly sends enclave-\nsigned transactions to a RPC node to prevent nonce conflicts and replay\nattacks.\n3\nOrganizational Ownership Model. PASS operates under an organiza-\ntional ownership model, where an entity such as a company, individual, or DAO\nmanages shared control over blockchain assets. We detail the threat model in\nSection ??.\nInbox-Outbox Gateway External senders transfer assets to pk, creating\nInbox entries (α,x,m) ∈ I. A user performs claim(u,α,x,m) to move value\nintoL[u][α], conceptually “wrapping” the deposit. To withdraw or interact with\na contract, a subaccount first performs an internal transfer to the Outbox,\nwhich enqueues (α,x, extDst,ν); the enclave then signs the concrete transaction\nwith sk and immediately broadcasts it, incrementing ν. The FIFO discipline and\nglobal nonce serialize actions and prevent races and double-spends. Because sub-\naccounts never receive pre-signed transactions, pre-signing misuse is mitigated.\nComposable policy scheme. Deposits are claims fromI; internal transfers\nrequire Allow(u,α,x) and update (L,H); withdrawals are internal transfers to\nO followed by submission. Additional constraints (eg., RBAC or ABAC checks,\nwhitelists and blacklists) can be incorporated as conjuncts to Allow without\nchanging the provenance-centric rule or its consistency and privacy effects.\n3.2 Formal Model\nWe formalize PASS as a transition system in Lean 4\n4\n, an interactive theorem\nprover with a rich dependent type system [?], suitable for policy verification (eg.,\nAWS Cedar [?]). In this section, we introduce the formal system we modeled in\nlean, and in Section ?? we will discuss security invariants modeled. An extended\ndiscussion of our formal verification system can be found in Appendix ??.\nState. A wallet state is S =\n\u0000\npk, sk,ν,I,O,L,H\n\u0001\nwhere (pk, sk,ν) are the\nEOA public key, private key (generated and held in the TEE), and global nonce;\nI and O are Inbox and Outbox; L is the internal balance map L[u][α] ∈Z\n≥0\n;\nandH is the provenance history. For privacy arguments we also use the external\nview W\npub\n= (pk,O,A), where O contains the Outbox queue and nonce and A\nrecords total on-chain balances by asset.\n3\nWe assume that the TEE is able to run a Helios light client, as is the case in dstack\nIntel TDX, discussed and implemented in Section ??\n4\nLean 4 model: https://github.com/pass-wallet/pass-lean4-proofs\n6J. Yu\nPASS Wallet Management Functionality F\nΣ\nPASS\nfor wallet W\nGlobal State:\npk : public address (EOA)\nsk : private key (in TEE)\nν: global nonce for on-chain transactions\nI (Inbox): set of unclaimed deposits (α : asset,x : amount,m : depositId)\nO (Outbox): FIFO queue (α,x, extDst,ν)\nL (Asset Ledger): internal map L[u][α]∈ Z\n≥0\n, where u is each user’s ID in the system\nH (Provenance History): a list of transaction records appended whenever ClaimInbox,\nInternalTransfer, or Withdraw is invoked\nCreatePassWallet (creator ):\nI← ∅, O← ∅, L←{}; ν← 0\n(pk, sk )← TEE\nKeyGen()\nReturn new W with S =\n\u0000\npk, sk,ν,I,O,L,H\n\u0001\nand reference to creator\nInboxDeposit (α,x,m) from external P :\nI ← I ∪ {(α,x,m)}\nReturn success\nClaimInbox (α,x, depositId) from u:\nIf no (α,x,m) with depositId in I, return ⊥\nRemove (α,x,m) from I\nL[u][α]←L[u][α] + x\nH←H| (op = claim,α,x, depositId,u)\nReturn success\nCheckAllow (u\nsend\n,α,x,H):\nIf H.GetProvenance(α, u\nsend\n)≥ x,\nreturn true; else return false\nInternalTransfer (α,x,u\nsend\n,u\nrecv\n):\nIf L[u\nsend\n][α] < x or ¬checkAllow(u\nsend\n,α,x,H), return ⊥\nL[u\nsend\n][α]←L[u\nsend\n][α]− x\nL[u\nrecv\n][α]←L[u\nrecv\n][α] + x\nH←H\n\f\n\f\n\u0000\nop = transfer,α,x,u\nsend\n,u\nrecv\n\u0001\nReturn success\nWithdraw (α,x,u\nsend\n, extDst):\nIf L[u\nsend\n][α] < x or ¬checkAllow(u\nsend\n,α,x,H), return ⊥\nL[u\nsend\n][α]←L[u\nsend\n][α]− x\nO ←O∪{(α,x, extDst,ν)}\nH←H | (op = withdraw,α,x,u\nsend\n, extDst)\nReturn success\nSignGSM (dom, msg,u):\nIf u lacks sign-right for (dom, msg), return ⊥\nσ ← (sk, msg)\nReturn σ\n(Outbox Processing) (periodic or on demand):\nIf O ̸= ∅, dequeue (α,x, extDst,ν)\nBuild tx τ : transfer x of α to extDst, nonce = ν\nσ ← (sk, τ ); broadcast (τ,σ)\nν←ν + 1\nReturn broadcasted + txHash\nFig. 3. Formal Model of PASS wallet functionality, including CreatePassWallet for\ninitializing a fresh instance. On creation, pk is set to a chosen EOA address eoa, the\nTEE generates a hidden private key sk , and global data structures are initialized.\nExternal deposits enter I (Inbox), while subaccount transfers update L (Ledger) off-\nchain. Withdrawals queue items in O (Outbox), and GSM operations are signed using\nsk .\nTransitions. Operations op∈ T update S with type-checked rules: InboxDe-\nposit adds an unclaimed (α,x,m) to I; ClaimInbox moves (α,x,m) from I to\nL[u][α] and appends to H; InternalTransfer moves value between subaccounts;\nWithdraw debits L[u][α], enqueues (α,x, extDst,ν) in O, and logs; SignGSM\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets7\nauthorizes domain-scoped signable messages. A representative rule is:\n\u0000\npk, sk,ν,I,O,L,H\n\u0001\ntransfer(α,x,u\ns\n,u\nr\n)\n−−−−−−−−−−−→\n\u0000\npk, sk,ν,I,O,L\n′\n,H\n′\n\u0001\nwith\nif L[u\ns\n][α] < x or ¬checkAllow(u\ns\n,α,x,H) then ⊥;\nL\n′\n[u\ns\n][α] =L[u\ns\n][α]− x, L\n′\n[u\nr\n][α] =L[u\nr\n][α] + x;\nH\n′\n=H\n\f\n\f\n\u0000\nop = transfer,α,x,u\ns\n,u\nr\n\u0001\n.\nHere checkAllow queries provenance inH and can be extended with auxiliary\nconstraints such as user whitelists or blacklists, without changing the core rule.\nFigure ?? provides a formal specification of the methods in a PASS wallet.\n3.3 Asset Model and General Signable Messages\nPASS provides an authorization scheme over a heterogenous set of assets A, in-\ncluding fungible tokens, such as ether and ERC-20 tokens, ERC-721 non-fungible\ntokens, and “general signable messages” across a variety of DApps for sign-in\nand identity verification. Each asset α ∈ A has a well-defined custody path in\nthe provenance log H, and a subaccount u ∈ U has usable balance x of α iff\nAllow(u,α,x) holds.\nToken assets. For token assets such as ether, ERC-20, and ERC-721, de-\nposits are captured as Inbox entries (α,x,m) ∈ I. Claims allocate balance into\nL[u][α], internal transfers update L and H privately, and withdrawals enqueue\n(α,x, extDst,ν) intoO for enclave signing and on-chain broadcast, ensuring con-\nsistency where:\n∀α∈A\ntokens\n:\nX\nu∈U\nL[u][α] = B\non\n(α, pk).\nIn particular, ERC-721 tokens are modeled as unitary balances (x ∈ {0, 1})\nwhose transfers preserve uniqueness under provenance.\nGeneral Signable Messages (GSMs). In addition to on-chain assets,\nwallets often sign arbitrary messages, such as for EIP-4361 [?] logins and off-\nchain DAO votes [?]. PASS models these as a special classA\nGSM\nof virtual assets.\nEach GSM asset is scoped to a domain dom, so holding α = (dom) represents\nauthority to sign messages from that domain. A signature operation:\nSignGSM(u, dom,m)7→ σ\nis permitted iff Allow(u, dom, 1) holds in H. At key generation, the wallet\ncreator is endowed with default signing authority over all domains, represented\nas an initial allocation of every α = (dom)∈A\nGSM\nto the root subaccount. These\ndomain assets can be internally transferred to delegate signing authority. Thus\nprovenance of GSMs begins at the owner and flows through transfers, providing\na well defined provenance path in H as with token assets.\n8J. Yu\nBy treating both tokens and GSMs as types of elements ofA, PASS provides\na unified provenance rule for subaccount authorization. A subaccount cannot\nspend an ERC-20 token, transfer an NFT, or sign a domain message unless it\npossesses the corresponding asset under L and H. This unified authorization\nscheme allows for fine-grained delegation, (eg., giving u rights over example.com\nwhile withholding ERC–20 funds) and consistent enforcement across on-chain\nand off-chain actions.\n4 Properties of PASS\n4.1 Threat Model\nPASS assumes an organizational ownership model, where a single entity, such\nas a company, individual, or DAO manages the EOA (pk,sk), brokers access\nbetween many users in that entity, and chooses the TEE infrastructure vendor\n(eg. AWS Nitro, dstack Intel TDX, self-hosted hardware). This model is typical\nfor use cases such as private payroll, supply chains, and AI delegation described\nin Section ??. Protected assets in PASS include the private key sk, the balance\nledger L and provenance log H, and the correctness of Allow(u,α,x) for all\nu∈ U,α∈A,x. In our model, we make the following trust assumptions:\n1. TEE integrity. Hardware isolation is sound; sk never leaves the enclave.\nRemote attestation guarantees that the enclave runs the genuine PASS bi-\nnary.\n2. Cryptography. Standard primitives (signatures, hash functions, PRFs) are\nsecure against polynomial-time adversaries.\n3. Governance majority. The deploying entity holds majority control in the\ngovernance mechanism (via DAO vote or admin privileges), ensuring it can\ninvoke the blockchain-governed KMS for MPC-based key recovery and trig-\nger fallback contracts when needed.\nAdversary Model. An adversary A may control the host OS and network,\nobserve or modify all communication with enclaves, and submit arbitrary trans-\naction requests. In particular, A may attempt to:\n– Exploit software bugs in the PASS implementation or TEE runtime,\n– Forge or replay transactions to break consistency of H,\n– Subvert provenance by violating Allow(u,α,x)\nThreats Out of Scope. On the other hand, PASS does not protect against:\n– Physical compromise of TEE hardware (tampering, microarchitectural side-\nchannels, chip decapsulation),\n– Supply-chain backdoors in TEE manufacturing,\n– Fully malicious operators with unrestricted physical access.\nThese are excluded because the organizational model assumes controlled facilities\nand vetted hardware.\nSecurity Goals. Given the assumptions above, PASS guarantees:\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets9\n1. Integrity:\nP\nu∈U\nL[u][α]≤ extDep(α) for all α, i.e., no assets can be created\nor double-spent internally.\n2. Correctness: If Allow(u,α,x) holds, then u can eventually realize x via\nWithdraw.\n3. Privacy on-chain: InternalTransfer operations do not affect externalTrace(W ),\nand to external observers, a PASS wallet is indistinguishable from an EOA.\n4. Liveness: For any authorized op ∈ Ops, if one enclave and quorum remain\nhonest, then ∃τ s.t. Exec(c, op) =⊤ within τ\n4.2 Privacy and Safety\nAfter establishing the threat model of PASS, we will address the central privacy\nand safety guarantees in our formal verification model. We sketch three central\nlemmas here, and create mechanized proofs in Lean, discussed in Appendix ??.\nProposition 1 (Internal Transfer Privacy). If two public states W\n1\n,W\n2\nshare the same pk, identical Outbox (T,ν), and equal per-asset totals in A, then\nexternalTrace(W\n1\n) = externalTrace(W\n2\n).\nProof Sketch. InternalTransfer updates only (L,H), never O or total on-chain\nbalances. OutboxProcessing in Figure ?? emits on-chain actions solely from O\n(lines 2–4), hence the trace depends only on O.\nCorollary: EOA indistinguishability. If W\npass\nand W\neoa\nshare the same pk,\nOutbox, and per-asset totals, then\nexternalTrace(W\npass\n) = externalTrace(W\neoa\n).\nThus, from an external observer’s perspective, a PASS account is indistinguish-\nable from a standard EOA: internal transfers leave no observable footprint.\nProposition 2 (Asset Accessibility). For any asset α, letting L = {u |\nL[u][α] > 0},\nX\nu∈L\nL[u][α] = totalBalance(α),\nand each u∈ L can spend its full balance subject to checkAllow.\nProof Sketch. ClaimInbox creditsL; InternalTransfer preserves the sum over u;\nWithdraw debitsL and enqueues toO, which OutboxProcessing realizes on-chain.\ncheckAllow enforces reachability from provenance in H.\nProposition 3 (Provenance Integrity). Let extDep(α) be net external de-\nposits (deposits minus realized withdrawals). For all reachable states,\nX\nu\nL[u][α] ≤ extDep(α).\n10J. Yu\nProof Sketch. Induct on transitions. InboxDeposit increases extDep only; Claim-\nInbox moves already-deposited value into L; InternalTransfer conserves the sum\nover u; Withdraw decreases the sum, and after OutboxProcessing broadcasts,\nextDep is reduced accordingly.\nGeneral signable messages (GSM). Model GSM rights as a domain-\nscoped virtual asset class A\nGSM\n. Let α = (dom)∈A\nGSM\nand permit\nSignGSM(u, dom,m) iff Allow(u,α, 1).\nThen (P2)–(P3) lift to GSM: there is always at least one domain signer, and\nGSM “balances” obey provenance conservation under transfers in H.\n4.3 Liveness\nWe define liveness as the property that any authorized operation remains even-\ntually executable, despite enclave crashes, vendor compromise, or partial gover-\nnance failure. Our model assumes deployment of PASS access logic on dstack,\nimplemented in Section ?? and detailed in Appendix ??.\nLet E denote active enclaves, C containerized wallet backends, and P gover-\nnance policies. Each container c∈C stores sealed state\nσ\nc\n=⟨S,k\nc\n, meta⟩ with S = (pk, sk,ν,I,O,L,H),\nwhere k\nc\n= Derive(K,c) is derived from an MPC-managed KMS and meta records\nattestation. An operation op ∈ Ops (deposit claim, transfer, withdrawal) ex-\necutes as: Exec(c, op) = ⊤ iff Attested(c)∧ Γ (S), where Attested(c) checks σ\nc\nagainst registry R and Γ is the quorum predicate over P. To ensure vendor-\nagnostic portability, state migration μ :E →E satisfies\n∀e\ni\n,e\nj\n∈E, e\nj\n.decrypt(σ\nc,e\ni\n,k\nc\n) = σ\nc,e\ni\n,\nTheorem 1 (Liveness Theorem). If (i) the MPC KMS tolerates f\nKMS\nfaults\nin a t-of-n threshold, (ii) governance quorums are f\ngov\n-resilient, and (iii) at least\none enclave is uncompromised, then every op∈ Ops executes within bounded time\nτ :\n∀op∈ Ops, ∃τ ≥ 0 : Exec(c, op) =⊤.\nProof Sketch. Progress follows from three guarantees: (1) the MPC KMS\nensures k\nc\nis always recoverable under threshold availability; (2) Γ encodes quo-\nrum rules that eventually relax after timeout ∆t, ensuring some subset S satisfies\nΓ (S) = ⊤; (3) migration μ allows any enclave to re-host σ\nc\n, preventing vendor\nlock-in or enclave failure from blocking execution. Algorithm ?? formalizes re-\ncovery and execution under these assumptions.\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets11\nAlgorithm 1 RecoverAndExecute(c, op)\n1: Verify enclave e attestation Q\ne\nagainst R.\n2: Derive k\nc\n← Derive(K,c); decrypt σ\nc\n.\n3: if CompromiseDetected(e\n′\n) then\n4:Rotate k\nc\nand re-encrypt σ\nc\n.\n5: end if\n6: Ensure Γ (S) =⊤ for S ⊆P(c).\n7: Execute op; append to H.\nKey Properties. (1) Portability: any attested enclave can recover σ\nc\n, in-\ndependent of vendor; (2) Monotonic Recovery: recovery steps form ρ : S → S\nwith ρ(s)⪰ s; (3) Domain Continuity: certificates remain bound to R(c) under\nmigration μ(c), preventing hijack or replay.\nImplementation details of container orchestration, attestation, and KMS pro-\ntocols are given in Appendix ??.\n5 Practical Implementations\n5.1 Prototype Implementations\nTo demonstrate feasibility, we have implemented a prototype of PASS that cap-\ntures the core architectural components.\n5\nThe prototype consists of:\n– Provenanced Access Model, the core PASS architecture outlined in Sec-\ntion ?? with the Inbox-Outbox structure, asset ledgers, and provenanced\nrule as a Rust executable.\n– Web Application Frontend, an AWS-hosted Typescript interface that\nallows users to deposit assets, initiate internal transfers, generate on-chain\ntransactions, and sign arbitrary messages on Ethereum Sepolia testnet.\n6\n– Multi-vendor TEE deployment, we deploy the PASS enclave executable\nin both AWS Nitro Enclaves and Intel TDX with the dstack framework.\nWe evaluate these two enclave deployments as complementary deployment\npaths, each with distinct tradeoffs.\nAWS Nitro Enclaves. In this design, PASS runs inside a Nitro enclave in the\nAWS cloud. The enclave executes the Inbox–Outbox logic, enforces provenance\nchecks, and signs transactions, while the provenance ledger is stored externally.\nNitro’s attestation and AWS integration simplify deployment, but reliance on a\nsingle vendor limits portability and concentrates trust. As a result, some guaran-\ntees of PASS, particularly liveness and asset accessibility, may be weaker under\nthis model.\n5\nPrototype can be found here: https://github.com/jayyu23/pass-wallet-app\n6\nWeb application: https://pass-wallet.jayyu.xyz/\n12J. Yu\nIntel TDX with dstack. dstack provides a portable, open-source runtime for\nTEEs across diverse hardware. PASS can be deployed on enclaves run by decen-\ntralized operators, with key material secured via MPC-based key management.\nBoth Inbox–Outbox logic and the provenance ledger execute inside dstack, pre-\nserving the full security properties of Section ?? and reducing vendor lock-in.\nThe tradeoff is added governance complexity over operator authorization and\npolicy enforcement.\nBlockchain Connectivity. To ensure reliable blockchain interaction, PASS inte-\ngrates Helios [?], a consensus-verified light client, within the TEE. Rather than\ntrusting external RPC endpoints, Helios cryptographically verifies all blockchain\ndata against consensus layer proofs before serving it locally. This approach elimi-\nnates the trust assumptions typically associated with centralized RPC providers\nwhile maintaining the performance characteristics necessary for real-time wallet\noperations. The light client architecture ensures that PASS’s Outbox mecha-\nnism operates on verified blockchain state, preserving the security guarantees\neven when external network providers are compromised or unreliable.\n5.2 Performance Benchmarks\nTo evaluate PASS, we benchmarked both AWS Nitro Enclaves and Intel TDX\nbackends across common operations: balance queries, transfers, withdrawals,\nclaims, wallet creation, provenance queries, and an end-to-end workflow. Each\noperation was run 100 times over 10 trials per environment, measuring through-\nput in ops/sec. Both environments used identical 4-core, 2.5 GHz, 16 GB VMs\nto ensure fair comparison. Table ?? summarizes our results, with full details\navailable in Appendix ??.\nFig. 4. Internal PASS operation throughput (ops/sec) across AWS Nitro Enclaves\nand Intel TDX. All operations are in-memory state changes within the TEE with no\nblockchain interaction. Each value represents the average of 100 operations repeated\n10 times per environment.\nOperationAWS Nitro Intel TDX\nWallet Creation6,53114,970\nAccount Balance Queries530,943935,428\nInbox-to-Subaccount Claims14,85633,064\nInternal Subaccount Transfers32,95371,292\nWithdrawal Request Creation18,29139,702\nEnd-to-End Workflow\n7\n35,66378,433\nTransaction History Queries3,7577,685\nMulti-threaded Operations (5 threads)32,18955,124\nLarge Dataset Processing481724\nThe observed performance differences between AWS Nitro Enclaves and In-\ntel TDX primarily stem from their distinct hardware architectures. AWS Nitro\nEnclaves employ a disaggregated system design, where the host server and the\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets13\nTEE hardware are physically separated. Communication between the host and\nthe enclave occurs via vsock, and the enclave itself runs on a dedicated, lower-\nperformance coprocessor. In contrast, Intel TDX leverages a special instruction\nset to provide enclave functionality directly on the main processor, eliminating\nthe need for a separate coprocessor and avoiding the overhead of data transfer\nbetween disparate components. As a result, Intel TDX is able to deliver sig-\nnificantly higher throughput for in-enclave operations compared to AWS Nitro\nEnclaves, as reflected in our benchmark results.\nThese preliminary benchmarks show that both Nitro and TDX backends can\nsustain high throughput for critical wallet operations, confirming that PASS is\npractical for real-world deployment.\nComparison with Related Work. To contextualize our performance results, we\ncompare PASS with other TEE-based blockchain systems and traditional custo-\ndial solutions.\nLiquefaction. The Liquefaction system [?] demonstrates significantly higher\nlatencies than PASS due to its reliance on blockchain oracles for transaction\nvalidation. Liquefaction exhibits mean latencies of 49 seconds for latest block\nconfirmation, 648.7 seconds ( 11 minutes) for justified confirmation, and 1,036.9\nseconds ( 17 minutes) for finalized confirmation. These delays stem from Liq-\nuefaction’s architectural requirement to wait for block confirmations on an ex-\nternal TEE-blockchain oracle before authorizing subsequent operations. In con-\ntrast, PASS performs all operations within the off-chain TEE worker without\nblockchain dependencies, achieving sub-millisecond latencies for internal opera-\ntions (e.g., 14,856-33,064 ops/sec for claims, 32,953-71,292 ops/sec for transfers).\nThis fundamental architectural difference—off-chain TEE computation versus\nblockchain-dependent validation—enables PASS to provide near-instantaneous\nuser experiences while maintaining strong security guarantees.\nTraditional Custodians. While custodial solutions do not publish detailed\nperformance benchmarks, prior work demonstrates that TEE overhead typically\nintroduces only 5-7% performance degradation compared to native execution [?].\nGiven that modern custodial systems can process thousands of operations per\nsecond, TEE-based solutions like PASS should achieve comparable throughput\nwhile providing significantly stronger security properties. Our benchmark results\nsupport this expectation, with PASS demonstrating high-throughput operation\nprocessing that would be suitable for production custodial workloads, while offer-\ning the additional benefits of cryptographic auditability, decentralized operation,\nand reduced single points of failure.\nFurther evaluation of latency distributions, concurrency scaling, and memory\nfootprint is left for future work.\n6 Applications\nPASS is a powerful primitive that enables several classes of applications across\nidentity scoping, enterprise settings, and scalability concerns.\n14J. Yu\nCategoryApplicationContextPASS Enables\nIdentities\nAI Agent\nWallets\nAutonomous agents\ninteracting with crypto\nassets [?] need signing\naccess guardrails.\nScoped subaccounts grant limited\nbalances and domain signing rights,\nenabling safe delegation without\nexposing the root key\nDAO Voting\nDelegation\nDAOs depend on\naddress-based voting and\nproxy delegation [?].\nFine-grained voting rights delegation\nthat remains auditable via provenance;\ndelegation can be restricted to specific\nDApps or domains.\nSubdomain\nProfile Pages\nOrganizations delegate\ncontrol over web or\norganizational\nsubdomains (e.g.,\nmyprofile.company.com) to\nindividuals or teams.\nEach subaccount holds scoped signing\nrights for its assigned subdomain, with\nbalances and authorities tracked in\nprovenance under a shared\norganizational identity.\nEnterprise\nPrivate PayrollOn-chain payrolls reveal\nsensitive salary\ninformation [?].\nSalary distribution through internal\ngasless transfers with audit logs;\nexternal payouts are periodically\nbatched via the Outbox.\nCompliant Org\nWallets\nFirms must maintain\ninternal accountability\nand BSA\nrecordkeeping [?].\nDepartmental and individual\nsubaccounts with explicit budgets;\nprovenance ensures regulator-grade\nauditability without exposing internal\nflows.\nPrivate B2B\nNetting\nSupply-chain and\nrecurring multi-party\npayments require\nconfidentiality.\nVendor subaccounts allow internal\nnetting of obligations, with PASS\nacting as a temporary clearing house.\nOnly net settlements exit via the\nOutbox, reducing leakage while\nretaining auditability.\nAudit / Proof\nExplorer\nRegulators and auditors\nrequire verifiable yet\nprivacy-preserving\ntransparency.\nPublic proofs derived from the\nprovenance log H, enabling compliance\nchecks and audits without disclosing\ninternal ledger state.\nScalability\nGasless\nAppchain\nHigh-throughput\napplications (e.g., trading\nengines) face prohibitive\ngas costs on-chain.\nInternalize application logic as\nsubaccount transitions; Outbox emits\nverifiable batch settlements, ensuring\ncorrectness with minimal gas.\nCross-chain\nBridges\nBridges require strong\ncustody and coordination\nof operators [?].\nInbox-Outbox abstractions enforce\nprovenance across domains; FIFO\nnonce handling prevents replay or race\nconditions.\nL2 ComposabilityRollups and L2s fragment\nassets and user\nexperience [?].\nTreat each L2 as a scoped subaccount;\nmaintain private balance transfers\ninternally, and settle externally only\nwhen crossing domains.\nFig. 5. Applications of PASS across identities, enterprise settings, and scalability so-\nlutions. We highlight a flagship application in each category.\nIdentities and Agent Delegation. PASS’s multi-user subaccount model\nallows for flexible permission scopes. As AI agents start managing crypto as-\nsets, there is a need to constrain their access. An AI agent could be given a\nsub-account that only holds limited funds or certain asset types. The AI can op-\nerate freely within those bounds, but cannot exceed its allotted assets or misuse\nother wallet assets. If compromised, damage is capped to its sub-account. This\nis much safer than giving AI the keys to an entire wallet. Similarly, PASS can\nallow for delegation-based DAO voting by giving the delegate signature rights\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets15\nover particular voting DApps, without giving access to actually transfer the as-\nsets. Subaccounts can also get scoped signing rights over particular enterprise\nsubdomains.\nEnterprise Applications. PASS’s features of internal privacy, in-built per-\nmissioning, and provenance auditability make it uniquely suited for enterprise\napplciations. A flagship use case for PASS is private payroll. On-chain salary pay-\nments today risk exposing sensitive information such as individual compensation,\ndepartmental budgets, or timing patterns. With PASS, salaries are distributed\ninternally through gasless subaccount transfers, leaving a clear provenance log for\nauditability, but without revealing per-employee details on-chain. Only periodic,\non-demand payouts exit via the Outbox, ensuring both regulatory accountability\nand privacy for internal flows. Beyond payroll, PASS supports other enterprise\nneeds: compliant organizational wallets with departmental subaccounts that en-\nforce explicit budgets, private B2B netting where vendors settle obligations inter-\nnally and only net payments leave the wallet, and auditable proof explorers that\nprovide regulators with verifiable, privacy-preserving compliance proofs derived\nfrom the provenance log.\nScalability Solutions. PASS also supports scaling use cases where on-chain\ncosts or coordination overhead make existing approaches impractical. A flagship\nexample is gasless appchains, such as for Central Limit Orderbooks (CLOBs).\nHigh-throughput applications such as CLOBs cannot afford per-transaction gas\nfees, but PASS internalizes application logic as private subaccount transitions.\nThe Outbox then emits verifiable batch settlements with minimal gas, preserv-\ning correctness while keeping costs predictable. Beyond appchains, PASS enables\ncross-chain bridges by enforcing provenance across domains and sequencing with-\ndrawals via a FIFO nonce to prevent replay or race conditions, and supports L2\ncomposability by treating each rollup or sidechain as a scoped subaccount, main-\ntaining private balance transfers internally and settling externally only when\ncrossing domains.\n7 Discussion and Future Work\n7.1 Composability and InterPASS Transactions\nWhile PASS provides privacy and provenance guarantees for a single wallet in-\nstance, an important question is how multiple PASS wallets may interact. This\nis important in supply-chain use cases where each PASS represents a single com-\npany in the supply chain.\nTrivially, PASS A can send an on-chain transaction from its Outbox to PASS\nB’s EOA account, and this will land in the Inbox of PASS B, ready to claim.\nHowever, this undermines the privacy guarantees that PASS offers at the EOA\nlevel, and is undesirable in cases where inter-organizational asset transfers con-\ntain sensitive information, such as order details.\nWe propose a non-trivial approach inspired by cross-Payment Channel Net-\nwork (PCN) protocols such as XTransfer [?]. We can treat each PASS instance\n16J. Yu\nakin to a PCN hub node, with state L and transaction history H. As with\nXTransfer, we can assume a star topology of PASS nodes, with a central PASS\nHub in communciation with all PASS nodes. The PASS Hub will aggregate all\nInterPASS transactions T := {(a\ni\n,x\ni\n,s\ni\n,r\ni\n)}\nn\ni=1\n, where (a\ni\n,x\ni\n,s\ni\n,r\ni\n) represent\nthe asset, amount, sender, and receiver, each signed by the s\ni\nOutbox.\nThe Hub aggregates these signed payment intents, computes a netted settle-\nment plan S, and coordinates a secure multi-party update protocol to commit\nthe resulting balances, similar to Thora [?]. In the optimistic case, this process\ncompletes entirely off-chain, and each participant’s balance is updated in the\nPASS ledger without revealing the underlying transaction graph. If a dispute or\nfailure occurs, any participant may trigger an on-chain enforcement transaction\nthat finalizes S atomically via the direct transfer mechanism, thus guaranteeing\nsafety.\nThis approach leverages PASS ’s provenance and state design to make each\ninstance an atomic node in PCN-style systems like X-Transfer. Here, we outline\nhow PASS Hubs can enable confidential, auditable cross-organization transfers,\nwhile full formal specification and protocol implementation is deferred for future\nwork.\n7.2 Instantiation on zkVM\nThe PASS design presented in this paper relies primarily on trusted execution\nenvironments (TEEs) to enforce provenance rules, where the enclave isolates the\nglobal secret key and mediates all access through the Inbox–Outbox mechanism.\nWhile TEEs provide strong privacy and efficiency guarantees, their trust model\ndepends on hardware attestation and vendor integrity, which may be insufficient\nin regulatory or adversarial settings that demand independent verification.\nzkVMs provide a natural next step by enabling provenance-based control to\nbe verified through succinct cryptographic proofs rather than trusted hardware.\nBy batching transitions over L, H, I, and O and producing a proof π, a mini-\nmalist verifier contract can update commitments and enforce outbox execution\nwhile preserving privacy. This direction complements the Chainless stack ar-\nchitecture [?], suggesting a path toward modular, interoperable deployments of\nPASS with stronger external verifiability and broader applicability.\n8 Conclusion\nWe presented PASS, a Provenanced Access Subaccount System, as a new wallet\narchitecture that enforces access by provenance rather than by identity or role.\nThe Inbox–Outbox mechanism ensures all assets have a verifiable lineage, while\ninternal transfers remain private and indistinguishable from a standard EOA\naccount.\nOur contributions are threefold: (i) a formal model in Lean 4 proving pri-\nvacy, accessibility, and provenance integrity; (ii) a working prototype with en-\nclave backends on AWS Nitro Enclaves and Intel TDX via dstack, integrated\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets17\nwith WalletConnect; and (iii) initial benchmarks showing the feasibility of high-\nthroughput operation. These results demonstrate that provenance-based control\ncan be realized today with mainstream blockchain tools.\nLooking forward, richer evaluations across multi-vendor TEEs, integration\nwith zero-knowledge VMs, and exploration of organizational and agent-based\ncustody are promising directions. By combining rigorous formal guarantees with\ndeployable prototypes, PASS advances the design space between strict self-\ncustody and flexible shared access, offering a path toward practical, privacy-\npreserving wallet security.\nA Formal Verification\nWe consider the formal model introduced in Section ?? of PASS as a state\nmachine in Lean4. Our goal is to prove that, under the PASS design, several\ncritical security properties always hold. We outline these properties and our\napproach to verifying them.\nA.1 Property: Privacy of Internal Transfers\nIn the PASS design, the InternalTransfer operation updates only the off-chain\nledgerL and the provenance historyH. It never modifies the OutboxO, meaning\nthere is no on-chain transaction triggered by an internal transfer. Consequently,\nexternal observers see no change in on-chain state. We formalize this by consid-\nering the on-chain view that an external party has for a given PASS Wallet. We\ncan model this visible on-chain state as a triple:\nW\npub\n=\n\u0000\npk, O, A\n\u0001\n,\nwhere:\npk is the externally owned account (EOA) address,\nO = (T,ν) is the external view of the outbox, where T is a list of enqueued\ntransactions and ν is a nonce,\nA is the external view of the Asset ledgerL, containing a list of asset entries,\neach of the form (α,x) with a unique identifier α and total balance x.\nExternal Trace. The external trace of a PassAccount state W\npub\nis the list of\nexternally visible actions, obtained by mapping each transaction in the outbox\nT to an on-chain action:\nexternalTrace(W\npub\n) =\n\b\noutboxTx(t) | t∈ T\n\t\n.\nNo internal transfers appear in externalTrace(·).\n18J. Yu\nStates That Differ Only by Internal Transfers. We say that two PassAccount\nstates W\n1\n= (pk\n1\n,O\n1\n,A\n1\n) and W\n2\n= (pk\n2\n,O\n2\n,A\n2\n) differ only by internal trans-\nfers if:\n1. pk\n1\n= pk\n2\n,\n2. O\n1\n= O\n2\n(i.e. both the list of outbox transactions and the nonce are the\nsame),\n3. For every asset identifier α, the total balance of that asset in A\n1\nequals the\ntotal balance of the same asset in A\n2\n.\nLetting getAsset(W,α) return the asset α within state W or ⊥, we require ∀α:\ntotalBalance\n\u0000\ngetAsset(W\n1\n,α)\n\u0001\n= totalBalance\n\u0000\ngetAsset(W\n2\n,α)\n\u0001\n.\nTheorem 2 (Privacy of Internal Transfers). If two PassAccount states W\n1\nand W\n2\ndiffer only by internal transfers, then their externally visible traces are\nidentical:\nexternalTrace(W\n1\n) = externalTrace(W\n2\n).\nProof. By assumption, O\n1\n= O\n2\n. Hence both states have the same outbox trans-\naction list T . Since\nexternalTrace(W\ni\n) = map\n\u0000\noutboxTx, T\ni\n\u0001\nfor i∈{1, 2},\nand T\n1\n= T\n2\n, it follows that externalTrace(W\n1\n) and externalTrace(W\n2\n) are iden-\ntical.\nThus, any sequence of purely internal transfers, changing only the private ledger\nL in PASS, is invisible to an external observer, preserving the privacy of how\nassets move within the wallet.\nA corollary of this Internal Transfer property is that a PASS account is\nindistinguishable from a regular EOA account.\nCorollary 1 (Indistinguishability from EOA). Let W\npass\nbe a PASS state\nthat (i) has the same public key pk, (ii) the same outbox, including nonce and\ntransaction list, and (iii) the same total balances of each asset as a reference\nEOA state W\neoa\n. Then\nexternalTrace(W\npass\n) = externalTrace(W\neoa\n).\nIn particular, an external observer cannot distinguish W\npass\nfrom W\neoa\n.\nProof. By assumption, the only potential differences betweenW\npass\nandW\neoa\nlie\nin internal ledger details. From Theorem 1, such internal transfers do not affect\nthe externally visible outbox transactions or total on-chain balances. Thus, their\nexternal traces coincide, and W\npass\nis indistinguishable from W\neoa\n.\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets19\nA.2 Property: Asset Accessibility\nIn addition to keeping internal transactions private, PASS should ensure that for\nevery asset in the system, there exists some sub-account that can access it and\nwithdraw it from the system. This prevents a situation where funds get ”stuck”\nwithout any reachable key or policy to move them. We define asset accessibility\nas follows:\nTheorem 3 (Asset Accessibility). For any PASS account W and asset iden-\ntified by α, there exists a list of addresses L such that:\n1. For every address u∈ L, the user can access their full balance:\ncheckBalance(s,α,u, balance(u)) = true\n2. The sum of all accessible balances equals the total balance of the asset:\nX\nu∈L\nL[u][α] = totalBalance(α)\nProof. We construct L as the set of all addresses with non-zero balances in the\nbalance map for α:\nL ={u|L[u][α] > 0}\nFor the first property, given any u∈ L, the definition of checkBalance verifies\nif the user has sufficient balance for the specified amount. When checking against\nthe user’s own balance, this is trivially satisfied since L[u][α]≥L[u][α] for all u.\nFor the second property, we observe that totalBalance is defined as the sum\nof all balances in the asset’s balance map:\ntotalBalance(α) =\nX\nu∈L\nL[u][α]\nBy construction, L contains the only nonzero values u∈L, so:\nX\nu∈L\nL[u][α] = totalBalance(α)\nTherefore, both properties hold for our constructed list L.\nWe can prove a similar trait for General Signable Messages, showing that for\nany inbound GSM, there is some subaccount signer that has access to it.\nTheorem 4 (GSM Accessibility). For any GSM and domain, there exists a\nuser with signing access to that domain.\nProof. For any domain d, we can directly construct a user u who has signing\naccess to d as follows:\nu = getSigner(d)\nBy definition, getSigner returns either:\n– A specifically assigned signer if one exists in the domain-address map, or\n– The default signer otherwise\nTherefore, every domain is guaranteed to have at least one user with signing\naccess, ensuring no GSM domain becomes inaccessible.\n20J. Yu\nA.3 Property: Provenance Integrity\nProvenance integrity specifies that every asset held by any sub-account in PASS\nmust have an origin traceable to an external deposit into the Inbox. At any\nstate of the system, for each asset entry in a sub-account’s balance, we can find\na sequence of internal transfers that leads back to an Inbox deposit from an\nexternal address. This property ensures no sub-account can conjure funds from\nnothing, such as through double-spending or inflation within the system, and\nthat the internal ledger is consistent with on-chain reality. In Lean, we model\nthe state of the PASS wallet including Inbox, Outbox, and all sub-accounts and\nprove an invariant that whenever a sub-account has x units of asset α, the global\nstate contains a record of at least x units of α having been deposited, minus any\nthat have been withdrawn.\nTheorem 5 (Provenance Integrity).\nFor any PASS account S =\n\u0000\npk, sk,ν,I,O,L,H\n\u0001\nand any asset α, the total\namount of α held across all subaccounts can never exceed the total amount of\nexternal deposits (minus any that have already been withdrawn). Formally,\nX\nu∈U\nL[u][α] ≤ externalDeposits(α),\nwhere U is the set of subaccounts in the system, and externalDeposits(α) is\nthe net total of asset α that has been introduced into the wallet from outside\naddresses, recorded in the inbox I.\nProof. We model the system’s state (pk, sk,ν,I,O,L,H) as in Figure ??, includ-\ning the Inbox I, Outbox O, and the internal ledger L. We define a provenance\nrecord P (α,u) that captures the total amount of asset α subaccount u is autho-\nrized to hold, based on Inbox claims and internal transfers.\nBase Case: Immediately after CreatePassWallet, no assets have been de-\nposited, and no subaccount balances exist:\n∀u, L[u][α] = 0, ∀α, externalDeposits(α) = 0.\nHence,\nX\nu∈U\nL[u][α] = 0 ≤ 0 = externalDeposits(α).\nInductive Step: Assume the invariant holds after n− 1 operations. We prove it\nremains valid after the nth operation, for each possible type of operation:\n(1) External Deposit: Suppose an amount x of asset α is deposited into the\nwallet:\nexternalDeposits(α) ← externalDeposits(α) + x.\nNo subaccount balances L[u][α] change. Thus, the left side of our inequality\n(sum of subaccount balances) is unchanged, while the right side strictly\nincreases by x, so the invariant continues to hold.\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets21\n(2) Inbox Claim: If subaccount u claims amount x of asset α from the Inbox\nI:\nL[u][α] ← L[u][α] + x, P (α,u) ← P (α,u) + x.\nSince x was already accounted for in externalDeposits(α) (but not yet allo-\ncated to any subaccount), the total subaccount balances remain≤ externalDeposits(α).\n(3) Internal Transfer: If subaccount u\n1\ntransfers x of α to subaccount u\n2\n:\nL[u\n1\n][α] ← L[u\n1\n][α]− x, L[u\n2\n][α] ← L[u\n2\n][α] + x,\nand P (α,u\n2\n) increases by x. Because the sum of all subaccount balances\ndoes not change, our invariant is preserved.\n(4) Withdrawal: If subaccount u withdraws x of α:\nL[u][α] ← L[u][α]− x,\nwhich reduces the total subaccount balances. Since externalDeposits(α)\nremains unchanged (assets have simply exited the wallet), the inequality still\nholds.\nThus, by induction over all possible operations,\nX\nu∈U\nL[u][α] ≤ externalDeposits(α)\nfor every reachable state. No subaccount can create new assets out of nothing,\nand all assets in the system are fully accounted for by provenanced deposits.\nB Dstack Architecture and Execution Model\nB.1 Component Overview\n– Dstack-OS: Minimal Linux-based VM image with a verifiable boot chain.\nMeasures bootloader, kernel, root filesystem (RootFs) via RTMR registers.\nIntegrates dm-verity for data integrity and monotonic counters for anti-\nrollback.\n– Dstack-KMS: Blockchain-governed MPC network for key derivation and\nrotation. Provides:\nk\nc\n= HMAC\nk\nroot\n(c\nid\n),\nk\nTLS\n= ECDSA(k\nroot\n).\nRotation is triggered via governance (t-of-n threshold).\n– Dstack-Gateway/Ingress: TLS termination inside TEEs, ZT-TLS bind-\ning X\nc\nto R(c), enabling verifiable HTTPS ingress.\n22J. Yu\nB.2 Governance Layer\nTwo contracts form the trust base:\n– KmsAuth: Global registry of KMS nodes and application digests.\n– AppAuth: Per-application contract specifying quorum rules, allowed image\nhashes, and authorized enclaves.\nB.3 Workflow Phases\n1. Attestation: Enclave e produces quote Q\ne\n; verified against R.\n2. Secret Provisioning: MPC nodes compute k\nc\n, release to e if Q\ne\nis valid.\n3. Container Launch: Dstack-OS mounts RootFs, decrypts state σ\nc\nwith k\nc\n.\n4. Ingress Binding: TLS certificate X\nc\ngenerated inside e; bound to R(c).\n5. Audit Logging: Migration, key rotation, and governance events appended\nto H.\nB.4 Fault Tolerance\n– Vendor failure: μ enables re-deployment across Intel/AMD TEEs.\n– KMS compromise: key rotation via MPC thresholds restores forward/backward\nsecrecy.\n– Governance deadlock: ∆t fallback in Γ ensures quorum reduction and progress.\nB.5 Liveness Proof Sketch\nCombining MPC-based key recovery, quorum fallback, and portable containers\nyields:\n∀op∈O\nc\n,Pr[Exec(c, op) =⊤] = 1\nunder assumptions of f -resilient MPC nodes and at least one uncompromised\nTEE instance.\nC Detailed Benchmark Results\nThis appendix provides comprehensive benchmark statistics for both AWS Nitro\nEnclaves and Intel TDX environments. All operations are internal PASS state\nchanges that occur within the TEE with no blockchain network interaction.\nEach operation was executed 100 times per trial, with 10 independent trials\nper environment. The tables below show summary statistics including mean,\nstandard deviation, and range.\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets23\nTable 1. AWS Nitro Enclaves benchmark statistics (ops/sec) across 10 trials\nOperationMean Std Dev Min Max\nWallet Creation6,5315315,4467,042\nAccount Balance Queries530,943675 530,216 531,915\nInbox-to-Subaccount Claims14,856476 14,326 15,504\nInternal Subaccount Transfers32,9531,322 31,447 35,088\nWithdrawal Request Creation18,2911,254 15,873 19,608\nEnd-to-End Workflow35,6636,234 21,739 40,650\nTransaction History Queries3,757453,6503,802\nMulti-threaded Operations (5 threads) 32,189884 31,200 34,364\nLarge Dataset Processing48113467497\nTable 2. Phala dStack benchmark statistics (ops/sec) across 10 trials\nOperationMean Std Dev Min Max\nWallet Creation14,9704,6528,69624,390\nAccount Balance Queries935,428338,450 383,142 1,470,588\nInbox-to-Subaccount Claims33,0645,197 25,44541,667\nInternal Subaccount Transfers71,29217,623 47,170 101,010\nWithdrawal Request Creation39,7027,434 29,15551,813\nEnd-to-End Workflow78,43317,403 59,524 110,497\nTransaction History Queries7,6858726,4528,929\nMulti-threaded Operations (5 threads) 55,12416,744 28,32981,301\nLarge Dataset Processing72481636893\nC.1 AWS Nitro Enclaves Results\nC.2 Intel TDX Results\nC.3 Performance Analysis\nThe statistical analysis reveals several key insights about PASS’s internal oper-\nation performance:\n– Performance Consistency: AWS Nitro Enclaves demonstrate superior\nconsistency with lower standard deviations across all operations. The co-\nefficient of variation ranges from 0.1% (Account Balance Queries) to 17.5%\n(End-to-End Workflow).\n– Peak Performance: Intel TDX achieves higher mean throughput but with\nsignificantly greater variance. Standard deviations are 10-500x larger than\nNitro, indicating less predictable performance.\n– Production Considerations: These internal operation benchmarks demon-\nstrate PASS’s ability to handle thousands of wallet operations per second\nwithin the TEE, with the actual deployment bottleneck being blockchain\ntransaction submission rather than internal processing.\nThe statistical summary confirms that both platforms support practical PASS\ndeployment, with Nitro offering predictable performance and Intel TDX provid-\ning higher peak throughput at the cost of consistency.\n24J. Yu\nD Design Extensions\nD.1 Composability and InterPASS Transactions\nWhile PASS provides privacy and provenance guarantees for a single wallet in-\nstance, an important question is how multiple PASS wallets may interact. This\nis important in supply-chain use cases where each PASS represents a single com-\npany in the supply chain.\nTrivially, PASS A can send an on-chain transaction from its Outbox to PASS\nB’s EOA account, and this will land in the Inbox of PASS B, ready to claim.\nHowever, this undermines the privacy guarantees that PASS offers at the EOA\nlevel, and is undesirable in cases where inter-organizational asset transfers con-\ntain sensitive information, such as order details.\nWe propose a non-trivial approach inspired by cross-Payment Channel Net-\nwork (PCN) protocols such as XTransfer [?]. We can treat each PASS instance\nakin to a PCN hub node, with state L and transaction history H. As with\nXTransfer, we can assume a star topology of PASS nodes, with a central PASS\nHub in communciation with all PASS nodes. The PASS Hub will aggregate all\nInterPASS transactions T := {(a\ni\n,x\ni\n,s\ni\n,r\ni\n)}\nn\ni=1\n, where (a\ni\n,x\ni\n,s\ni\n,r\ni\n) represent\nthe asset, amount, sender, and receiver, each signed by the s\ni\nOutbox.\nThe Hub aggregates these signed payment intents, computes a netted settle-\nment plan S, and coordinates a secure multi-party update protocol to commit\nthe resulting balances, similar to Thora [?]. In the optimistic case, this process\ncompletes entirely off-chain, and each participant’s balance is updated in the\nPASS ledger without revealing the underlying transaction graph. If a dispute or\nfailure occurs, any participant may trigger an on-chain enforcement transaction\nthat finalizes S atomically via the direct transfer mechanism, thus guaranteeing\nsafety.\nThis approach leverages PASS ’s provenance and state design to make each\ninstance an atomic node in PCN-style systems like X-Transfer. Here, we outline\nhow PASS Hubs can enable confidential, auditable cross-organization transfers,\nwhile full formal specification and protocol implementation is deferred for future\nwork.\nD.2 Instantiation on zkVM\nThe design of PASS presented thus far relies on trusted execution environments\n(TEEs) such as AWS Nitro or Intel TDX to enforce provenance-based control.\nTEEs provide strong isolation and efficient execution, allowing internal transfers\nto remain private while ensuring that every outbox action has a verifiable lin-\neage. However, the trust model is anchored in hardware attestation: users and\nregulators must accept that the enclave executes the correct code as claimed.\nWhile sufficient for many organizational custody scenarios, this assumption lim-\nits transparency and long-term auditability. To address this limitation, we ex-\nplore an alternative instantiation of PASS in a zero-knowledge virtual machine\n(zkVM), replacing hardware trust with cryptographic proofs of correctness.\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets25\nZero-knowledge virtual machines (zkVMs) provide a proving environment in\nwhich arbitrary state machines can run with strong correctness guarantees [?].\nBy producing a succinct proof π of execution, zkVMs offer integrity assurances\nsimilar to TEEs but without reliance on vendor-specific hardware. This shift\nmakes zkVMs particularly suitable for contexts such as institutional custody,\nmulti-party supply chains, or inter-organizational accounting where external ver-\nifiability and regulator-grade auditability are paramount.\nIn a zkVM instantiation of PASS, the execution pipeline mirrors the enclave-\nbased design but replaces attestation with cryptographic proofs. The process\nproceeds in four stages:\n1. Batch formation. Transaction requests (claims, transfers, withdrawals) are\nfirst queued off-chain into a batch.\n2. zkVM execution. The zkVM program takes as private inputs: (i) the prior\nbatch’s commitments of the ledger L and provenance log H, (ii) the queued\ntransitions, including inbox I deposits and outbox O withdrawals, and (iii)\nthe proposed new commitments (L\n′\n,H\n′\n). Inside the zkVM, the transition\nfunction is replayed deterministically: starting from the previous roots, ap-\nplying all operations in sequence, updating balances and provenance entries,\nand checking consistency constraints.\n3. Proof generation. The zkVM outputs a succinct proof π certifying that the\nclaimed new roots (L\n′\n,H\n′\n) are correct with respect to the given transition\nset.\n4. On-chain verification. A minimalist verifier contract validates π, updates\nthe recorded commitments, and enforces any pending outbox operations.\nThis ensures that every external action has a verifiable provenance path\nwhile internal transfers remain private.\nCompared to TEEs, zkVMs strengthen the verifiability model by eliminat-\ning hardware trust assumptions, but incur higher computational and financial\ncosts due to proof generation and on-chain verification. Batching amortizes these\ncosts, raising open research questions about optimal batch sizes, data availabil-\nity strategies, and proof system selection. zkVM backends such as Risc0, SP1,\nor Plonky3 offer different tradeoffs in proof size, verification cost, and latency.\nHybrid deployments are also possible: TEEs can serve as fast-path executors for\nintra-day operations, with zkVM proofs generated periodically to provide cryp-\ntographic audit trails. This hybrid pattern resembles optimistic rollups, where\nfast execution is combined with verifiable settlement.\nFinally, this instantiation aligns closely with the Chainless stack architec-\nture [?], which emphasizes the separation of execution, trust, bridging, and set-\ntlement. In this view, zkVM proofs naturally inhabit the execution and trust\nlayers, Inbox/Outbox commitments integrate with bridging, and the verifier\ncontract finalizes settlement. This layered design opens the door to modular,\ninteroperable deployments of PASS across heterogeneous chains and domains.\nFull formal specification, performance benchmarking, and exploration of hybrid\nzkVM–TEE implementations remain important avenues for future work.\n26J. Yu\nFig. 6. PASS instantiation inside a zkVM: Inbox I and Outbox O transitions are\napplied to the Ledger L and Provenance H, producing new state commitments. The\nzkVM outputs a proof π, which the on-chain verifier checks before updating roots and\nenforcing outbox operations."
}
]
}
]Response:
To convincingly argue that existing wallet architectures cannot satisfy the three use cases described in the Introduction—and to establish why provenance- and TEE-based solutions (like PASS) are superior—we must proceed with analytical rigor. Let us structure the argument as follows:
---
### 1. Common Challenges Across the Three Use Cases
The three use cases—(1) AI and smart agent transactions, (2) enterprise payroll privacy, and (3) consumer-grade central limit order books (CLOBs)—share several foundational requirements:
- **Fine-grained, context-aware access control**: Multiple actors or agents (human or AI) require scoped permissions, often with dynamic delegation and revocation.
- **Privacy of internal operations**: Sensitive details (e.g., salary distribution, trading strategies) must be shielded from public blockchain visibility.
- **Auditability and provenance**: All asset movements must be traceable for accountability, compliance, and operational safety, without leaking internal business logic.
- **Compatibility and deployability**: Solutions must integrate with existing blockchain infrastructure (native EOA compatibility) and avoid introducing prohibitive costs or deployment friction.
- **Minimized trust assumptions**: Reliance on centralized custodians, bespoke policy engines, or opaque hardware should be mitigated, and the system should be robust against compromised infrastructure.
---
### 2. Limitations of Existing Approaches
**a. EOAs and Multisig Wallets**
- **Lack of Granular Control**: EOAs offer no internal permissioning; whoever holds the key controls all assets. Multisigs provide only symmetric, static authority (t-of-n), which is coarse-grained and unsuitable for dynamic or hierarchical delegation (e.g., AI agents with limited spending rights, or departmental payroll).
- **No Internal Privacy**: All multisig logic and transactions are public. Internal movements (e.g., salary splits, order routing) are visible on-chain, leaking sensitive information.
- **Operational Overhead**: Multisigs require on-chain coordination for every action, incurring gas and latency that are prohibitive for real-time trading (CLOBs) or high-frequency payroll.
**b. Smart Contract Wallets (Account Abstraction, ERC-4337, etc.)**
- **Public Policy Exposure**: Custom validation logic is encoded on-chain, making access rules and internal flows transparent to adversaries and competitors.
- **Gas and Complexity Costs**: Every policy check or transfer is a smart contract operation, increasing gas expense and limiting throughput—untenable for high-frequency or privacy-sensitive use cases.
- **Compatibility Constraints**: Many solutions require specific chain support (e.g., ERC-4337), reducing portability and increasing integration friction.
**c. Custodial Wallets with RBAC/ABAC Engines**
- **Off-chain Enforcement and Trust**: Policies are enforced off-chain by custodians, who have full visibility into internal activity. This introduces a single point of failure and privacy risk, as well as regulatory and operational dependency on the custodian.
- **Policy Language Proliferation**: Each custodian implements bespoke policy APIs, leading to fragmentation, lack of composability, and brittle access semantics.
- **No Asset Provenance**: Authority is attached to identities or roles, not to the origin or flow of assets, making it awkward to enforce chain-of-custody or audit trails directly tied to deposits.
**d. TEE-based Wallets (e.g., Liquefaction)**
- **Limited Formal Guarantees**: Prior TEE-based approaches (like Liquefaction) rely on key encumbrance and policy trees, but lack formal proofs of privacy, accessibility, and provenance integrity.
- **Deployment Friction**: Some require specialized smart contract platforms (e.g., Oasis), reducing compatibility with standard EOAs and increasing vendor lock-in.
- **Performance Bottlenecks**: Reliance on blockchain oracles for every operation (as in Liquefaction) introduces high latency, unsuitable for real-time or high-throughput scenarios.
---
### 3. Why Provenance- and TEE-Based Solutions (PASS) Are Superior
**a. Alignment with Blockchain’s Exogenous Asset Model**
- **Provenance-Centric Control**: PASS enforces access not by static roles or identities, but by the chain of custody—who deposited an asset, and how it flowed internally. This matches the exogenous way assets enter wallets on blockchains and supports fine-grained, composable access rules.
**b. Privacy by Design**
- **Internal Privacy**: Internal (off-chain) transfers update only the private ledger and provenance log; they are invisible externally. To outsiders, the wallet is indistinguishable from a standard EOA. This directly addresses enterprise payroll and trading privacy requirements.
- **TEE Isolation**: Private keys and all sensitive logic reside in TEEs, ensuring that even infrastructure operators cannot access or leak internal flows.
**c. Formal Security and Auditability**
- **Proven Invariants**: PASS is formally modeled and verified (in Lean 4) to guarantee privacy, accessibility (no stuck funds), and provenance integrity (no double-spending or unauthorized asset creation).
- **Audit-Ready Provenance**: All asset movements have a verifiable lineage, supporting regulatory audits and internal compliance without exposing business-sensitive details.
**d. Deployability and Performance**
- **Native EOA Compatibility**: PASS operates on standard EOAs, requiring no contract upgrades or specialized chain support. Deployments are possible on mainstream TEE platforms (AWS Nitro, Intel TDX).
- **High Throughput, Low Latency**: Internal operations are off-chain and in-TEE, achieving sub-millisecond performance, as shown in benchmarks. Unlike prior TEE or smart contract solutions, PASS is suitable for real-time and high-frequency applications (e.g., CLOBs).
- **Composable Policy**: While the core is provenance-based, additional constraints (e.g., RBAC/ABAC, whitelists) can be layered as conjuncts, without sacrificing the core privacy and consistency guarantees.
---
**Conclusion**
In sum, existing solutions either (i) fail to provide the necessary granularity, privacy, and auditability (EOAs, multisigs, custodians), (ii) leak sensitive policy and incur operational overhead (smart contract wallets), or (iii) lack formal guarantees and performance (prior TEE wallets). Provenance- and TEE-based solutions like PASS uniquely satisfy all requirements: they enable privacy-preserving, finely-scoped, and auditable access for multi-actor wallets across all three target use cases, with formal security guarantees and practical deployability. This architectural shift is not incremental but foundational, bridging the gap between strict self-custody and flexible, privacy-preserving shared access.
Model: gpt-4.1-2025-04-142025-09-15 12:25:30
Context:
[
{
"role": "system",
"content": "You are a research paper writer. You focus on:\n1. logical consistency\n2. whether the story is persuasive\nDon't try to be friendly on purpose, judge everything based on the logic and expressiveness."
},
{
"role": "user",
"content": [
{
"type": "text",
"text": "根据introduction和background的内容作为背景，和我讨论问题。\n\n我想说明对introduction中提到的三个场景，现有的方法都没办法有效的解决。同时希望引导出provanance和基于TEE的方案能够解决这个问题。你觉得怎么说比较好。"
},
{
"type": "text",
"text": "main.pdf\nPASS: A Provenanced Access Subaccount\nSystem\nfor Blockchain Wallets\nJay Yu\n1,2\n1\nStanford University [email protected]\n2\nPantera Capital [email protected]\nAbstract. Blockchain wallets still follow a single-entity ownership model:\npossession of a private key grants unilateral control. This assumption is\nbrittle for emerging settings such as organizational custody, shared gov-\nernance, and AI agent wallets, where multiple actors must coordinate\nwithout exposing secrets or leaking internal activity.\nWe present PASS, a Provenanced Access Subaccount System\nthat replaces role or identity-based control with provenance-based con-\ntrol: assets can only be used by subaccounts that can trace custody back\nto a valid deposit. A simple Inbox–Outbox mechanism ensures all exter-\nnal actions have verifiable lineage, while internal transfers remain private\nand indistinguishable from ordinary EOAs.\nWe formalize PASS in Lean 4 and prove core invariants, including\nprivacy of internal transfers, asset accessibility, and provenance integrity.\nWe implement a prototype with enclave backends on AWS Nitro Enclaves\nand dstack Intel TDX, integrate with WalletConnect, and benchmark\nthroughput across wallet operations. These results show that provenance-\nbased wallets are both implementable and efficient. PASS bridges today’s\ngap between strict self-custody and flexible shared access, advancing the\ndesign space for practical, privacy-preserving custody.\n1 Introduction\nCryptocurrency wallets conventionally assume one key, one owner. In this single-\nentity ownership (SEAO) model, whoever holds the private key gains permanent\nand total control of the address, and casts publicly readable, gas-consuming\nblockchain transactions. However, this model struggles to adapt to emerging\nblockchain scenarios:\n1. AI and Smart Agent Transactions. AI agents increasingly manage crypto\nassets [?,?] and require bounded authority and access guardrails for users’\nasset security.\n2. Enterprise Payroll Privacy. Organizations need to distribute salaries and\ndepartmental budgets to employee accounts without revealing sensitive de-\ntails on-chain [?,?,?].\n2J. Yu\n3. Consumer-grade Central Limit Order Books. On-chain order books\nface high gas costs and latency that prevent real-time trading at scale [?,?],\nand many consumers prefer not to manage their own keys [?,?].\nIn practice, many organizations confronted with these challenges default to\ncustodians or policy engines that wrap access logic in Role-Based Access Con-\ntrol (RBAC) or Attribute-Based Access Control (ABAC) [?,?]. These systems\nintroduce a proliferation of bespoke policy languages and APIs to specify who\nmay sign or transfer under which conditions [?,?]. While workable as a stopgap,\nthey inherit identity and role assumptions from traditional IT settings that limit\ntheir flexibility and scalability in blockchain contexts.\nThe limitation stems from a mismatch of models. Traditional access-control\nframeworks such as RBAC and ABAC assume an endogenous setting: users\ncreate and manage their own files, objects, or services, and policies are attached\nto these identities or roles. Blockchains are fundamentally exogenous: assets are\ncreated outside the wallet by smart contracts and transferred permissionlessly\nin. In this setting, identity or role-based rules are awkward to express and brittle\nto enforce. What matters instead is provenance: who deposited an asset, and how\nit flowed within the wallet.\nWe propose PASS, a Provenanced Access Subaccount System that enforces\ncontrol directly by provenance. The core mechanism is simple: an Inbox records\nexternal deposits, an Outbox signs and broadcasts withdrawals, and all internal\nmovements remain private and fee-less. Every unit of value inside the wallet has\na verifiable lineage to an on-chain deposit, while externally a PASS wallet is\nindistinguishable from a standard EOA. Our contributions include:\n– A provenance-based access model aligned with blockchain’s exogenous asset\ncreation, enforced through an Inbox–Outbox design.\n– A formal model in Lean 4 proving privacy, accessibility, and provenance\nintegrity.\n– A prototype with multi-vendor enclave backends (AWS Nitro, Intel TDX via\ndstack), a web app frontend integrated with WalletConnect, together with\nthroughput benchmarks.\n– Application scenarios, including organizational custody, privacy-preserving\ntransfers, and safe delegation to AI agents.\nPASS thus bridges the gap between strict self-custody and flexible shared\naccess, combining strong privacy guarantees with practical deployability.\n2 Background and Related Work\nGrowing retail and institutional adoption of digital assets [?] has driven diverse\nwallet designs [?]. We summarize mainstream Ethereum Virtual Machine (EVM)\nwallet designs in Figure ??.\nEOAs and Multisigs. Externally Owned Accounts (EOAs) give unilateral,\npermanent control to whoever holds the private key [?]. Multisignature wallets\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets3\nModelControl basisOn-chain\noverhead\nInternal\nPrivacy\nCompatibility\nEOASingle private keyNoneNoneNative EOA\nMultisigt-of-n co-signersHigh; quorum per\naction\nNone; logic\npublic\nSmart\ncontract based\nERC-4337\nSmart\nAccounts\nOn-chain policy\nlogic\nMedium to high;\ncustom logic and\ngas\nNone; logic\npublic\nRequires\nERC-4337\nchain support\nCustodiansCustom RBAC or\nABAC languages\nNone; Off-chain\nenforcement\nCustodian sees\nall activity\nAPI mediated\nLiquefactionTEE key\nencumbrance;\npolicy trees\nMedium; Oasis\ncontracts and gas\nStrong; TEE\nhides\nsubpolicies\nRequires Oasis\ndeployment\nPASS\n(ours)\nProvenance via\nInbox-Outbox\nNone; EOA\ncompatible\nStrong;\ninternal\ntransfers\ninvisible\nNative EOA\nplus off the\nshelf TEEs\nFig. 1. Comparison of wallet architectures. PASS features provenance-based control,\noff-chain privacy, and native EOA compatibility.\n(eg., Safe) distribute trust via t-of-n approvals [?], common for treasuries and\nbridges [?,?,?]. Drawbacks include quorum overhead, symmetric authority, and\npublic logic with attackable frontends [?]. In contrast, PASS offers fine-grained,\nscoped permissioning without new contracts.\nSmart Contract Wallets and Account Abstraction. Wallets like Ar-\ngent and Loopring add programmability (social recovery, spend limits) via on-\nchain logic [?,?,?]. ERC-4337 enables custom validation through UserOperation\ncontracts [?], and EIP-7702 lets EOAs invoke this logic [?]. These increase flex-\nibility but expose policies publicly and incur gas costs, limiting use cases like\npayroll. PASS instead enforces policy privately in a TEE, minimizing on-chain\nfootprint.\nCustodial Policies. Custody providers (Fireblocks, Turnkey, Privy) use\nRBAC/ABAC engines with custom policy languages [?,?]. PASS replaces these\nwith provenance: authority follows asset origin and history, akin to a UTXO\nmodel. This reduces policy-surface complexity while remaining composable with\nconstraints like whitelists and blacklists.\nTEEs and Liquefaction. Trusted Execution Environments (TEEs) provide\nhardware-isolated contexts with remote attestation [?,?]. Liquefaction [?] keeps\nwallet keys in a TEE and enforces sub-policies via key encumbrance, ensuring\nprivacy. PASS advances this model by (i) proving invariants in Lean 4, (ii) sim-\nplifying enforcement to a provenance rule with Inbox/Outbox subaccounts, and\n(iii) working with a standard EOA without relying on Oasis smart contracts\n[?]. We further validate by implementing PASS on AWS Nitro Enclaves and In-\ntel TDX (via dStack), and showcase applications including AI wallets, payroll,\nsupply chains, and DAO voting.\nOther Models. Exchanges pool funds in omnibus addresses with off-chain\nledgers [?]; mixers like Tornado Cash hide deposit–withdrawal links [?]. PASS\n4J. Yu\nsimilarly hides internal transfers while retaining a provenance log for auditability;\noutsiders see only deposits and withdrawals.\n3 System Model and Design\nFig. 2. Overview of PASS. External deposits enter the Inbox and are claimed by sub-\naccounts. Internal transfers are private and off-chain. Egress occurs via the Outbox,\nwhich signs and broadcasts on-chain transactions. All on-chain activity has clear prove-\nnance; internal movements remain private.\n3.1 High level system model\nPASS is a multi-user wallet on a single EOA (sk, pk). The wallet maintains a\nfinite set of subaccounts U ={u\n1\n,...,u\nn\n} and a set of assets A (e.g., ERC-20).\nA subaccount u ∈ U has authority over an amount x of asset α ∈ A iff it can\nobtain a signature from the global sk via the enclave; sk resides only inside a TEE\nand is never directly accessible. We give the intuitive model here and formalize\nit in Section ??.\nInternally, PASS tracks balances with a map L : U ×A →Z\n≥0\n(accessed\nvia L[u][α]), an Inbox multiset I of unclaimed deposits (α,x,m), an Outbox\nFIFO queueO of pending on-chain actions (α,x, extDst,ν) together with a global\nnonce ν ∈N, and an append-only provenance logH. The core principles of PASS,\nas shown in Figure ?? are as follows:\n1. Access follows provenance. A unit of value is usable by u only if there\nexists a custody chain in H from an external deposit to u. Informally,\nAllow(u,α,x) means balance x is reachable for u via provenance in H. This\nimplies consistency : for every α, the total internal balance equals the on-\nchain balance at pk, i.e.,\nP\nu∈U\nL[u][α] = B\non\n(α). Incoming deposits (α,x,m)∈\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets5\nI are “wrapped” and must be explicitly claimed before use by the sender\naddress.\n2. Off-chain privacy. Internal transfers u→ v update only L and H; they do\nnot touch O or the on-chain balance B\non\n, so internal flow is invisible and\nfee-less.\n3. First-come, first-served. Outbox transactions are sequenced by a FIFO queue,\nwhich maintains and increments a global nonce ν and directly sends enclave-\nsigned transactions to a RPC node to prevent nonce conflicts and replay\nattacks.\n3\nOrganizational Ownership Model. PASS operates under an organiza-\ntional ownership model, where an entity such as a company, individual, or DAO\nmanages shared control over blockchain assets. We detail the threat model in\nSection ??.\nInbox-Outbox Gateway External senders transfer assets to pk, creating\nInbox entries (α,x,m) ∈ I. A user performs claim(u,α,x,m) to move value\nintoL[u][α], conceptually “wrapping” the deposit. To withdraw or interact with\na contract, a subaccount first performs an internal transfer to the Outbox,\nwhich enqueues (α,x, extDst,ν); the enclave then signs the concrete transaction\nwith sk and immediately broadcasts it, incrementing ν. The FIFO discipline and\nglobal nonce serialize actions and prevent races and double-spends. Because sub-\naccounts never receive pre-signed transactions, pre-signing misuse is mitigated.\nComposable policy scheme. Deposits are claims fromI; internal transfers\nrequire Allow(u,α,x) and update (L,H); withdrawals are internal transfers to\nO followed by submission. Additional constraints (eg., RBAC or ABAC checks,\nwhitelists and blacklists) can be incorporated as conjuncts to Allow without\nchanging the provenance-centric rule or its consistency and privacy effects.\n3.2 Formal Model\nWe formalize PASS as a transition system in Lean 4\n4\n, an interactive theorem\nprover with a rich dependent type system [?], suitable for policy verification (eg.,\nAWS Cedar [?]). In this section, we introduce the formal system we modeled in\nlean, and in Section ?? we will discuss security invariants modeled. An extended\ndiscussion of our formal verification system can be found in Appendix ??.\nState. A wallet state is S =\n\u0000\npk, sk,ν,I,O,L,H\n\u0001\nwhere (pk, sk,ν) are the\nEOA public key, private key (generated and held in the TEE), and global nonce;\nI and O are Inbox and Outbox; L is the internal balance map L[u][α] ∈Z\n≥0\n;\nandH is the provenance history. For privacy arguments we also use the external\nview W\npub\n= (pk,O,A), where O contains the Outbox queue and nonce and A\nrecords total on-chain balances by asset.\n3\nWe assume that the TEE is able to run a Helios light client, as is the case in dstack\nIntel TDX, discussed and implemented in Section ??\n4\nLean 4 model: https://github.com/pass-wallet/pass-lean4-proofs\n6J. Yu\nPASS Wallet Management Functionality F\nΣ\nPASS\nfor wallet W\nGlobal State:\npk : public address (EOA)\nsk : private key (in TEE)\nν: global nonce for on-chain transactions\nI (Inbox): set of unclaimed deposits (α : asset,x : amount,m : depositId)\nO (Outbox): FIFO queue (α,x, extDst,ν)\nL (Asset Ledger): internal map L[u][α]∈ Z\n≥0\n, where u is each user’s ID in the system\nH (Provenance History): a list of transaction records appended whenever ClaimInbox,\nInternalTransfer, or Withdraw is invoked\nCreatePassWallet (creator ):\nI← ∅, O← ∅, L←{}; ν← 0\n(pk, sk )← TEE\nKeyGen()\nReturn new W with S =\n\u0000\npk, sk,ν,I,O,L,H\n\u0001\nand reference to creator\nInboxDeposit (α,x,m) from external P :\nI ← I ∪ {(α,x,m)}\nReturn success\nClaimInbox (α,x, depositId) from u:\nIf no (α,x,m) with depositId in I, return ⊥\nRemove (α,x,m) from I\nL[u][α]←L[u][α] + x\nH←H| (op = claim,α,x, depositId,u)\nReturn success\nCheckAllow (u\nsend\n,α,x,H):\nIf H.GetProvenance(α, u\nsend\n)≥ x,\nreturn true; else return false\nInternalTransfer (α,x,u\nsend\n,u\nrecv\n):\nIf L[u\nsend\n][α] < x or ¬checkAllow(u\nsend\n,α,x,H), return ⊥\nL[u\nsend\n][α]←L[u\nsend\n][α]− x\nL[u\nrecv\n][α]←L[u\nrecv\n][α] + x\nH←H\n\f\n\f\n\u0000\nop = transfer,α,x,u\nsend\n,u\nrecv\n\u0001\nReturn success\nWithdraw (α,x,u\nsend\n, extDst):\nIf L[u\nsend\n][α] < x or ¬checkAllow(u\nsend\n,α,x,H), return ⊥\nL[u\nsend\n][α]←L[u\nsend\n][α]− x\nO ←O∪{(α,x, extDst,ν)}\nH←H | (op = withdraw,α,x,u\nsend\n, extDst)\nReturn success\nSignGSM (dom, msg,u):\nIf u lacks sign-right for (dom, msg), return ⊥\nσ ← (sk, msg)\nReturn σ\n(Outbox Processing) (periodic or on demand):\nIf O ̸= ∅, dequeue (α,x, extDst,ν)\nBuild tx τ : transfer x of α to extDst, nonce = ν\nσ ← (sk, τ ); broadcast (τ,σ)\nν←ν + 1\nReturn broadcasted + txHash\nFig. 3. Formal Model of PASS wallet functionality, including CreatePassWallet for\ninitializing a fresh instance. On creation, pk is set to a chosen EOA address eoa, the\nTEE generates a hidden private key sk , and global data structures are initialized.\nExternal deposits enter I (Inbox), while subaccount transfers update L (Ledger) off-\nchain. Withdrawals queue items in O (Outbox), and GSM operations are signed using\nsk .\nTransitions. Operations op∈ T update S with type-checked rules: InboxDe-\nposit adds an unclaimed (α,x,m) to I; ClaimInbox moves (α,x,m) from I to\nL[u][α] and appends to H; InternalTransfer moves value between subaccounts;\nWithdraw debits L[u][α], enqueues (α,x, extDst,ν) in O, and logs; SignGSM\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets7\nauthorizes domain-scoped signable messages. A representative rule is:\n\u0000\npk, sk,ν,I,O,L,H\n\u0001\ntransfer(α,x,u\ns\n,u\nr\n)\n−−−−−−−−−−−→\n\u0000\npk, sk,ν,I,O,L\n′\n,H\n′\n\u0001\nwith\nif L[u\ns\n][α] < x or ¬checkAllow(u\ns\n,α,x,H) then ⊥;\nL\n′\n[u\ns\n][α] =L[u\ns\n][α]− x, L\n′\n[u\nr\n][α] =L[u\nr\n][α] + x;\nH\n′\n=H\n\f\n\f\n\u0000\nop = transfer,α,x,u\ns\n,u\nr\n\u0001\n.\nHere checkAllow queries provenance inH and can be extended with auxiliary\nconstraints such as user whitelists or blacklists, without changing the core rule.\nFigure ?? provides a formal specification of the methods in a PASS wallet.\n3.3 Asset Model and General Signable Messages\nPASS provides an authorization scheme over a heterogenous set of assets A, in-\ncluding fungible tokens, such as ether and ERC-20 tokens, ERC-721 non-fungible\ntokens, and “general signable messages” across a variety of DApps for sign-in\nand identity verification. Each asset α ∈ A has a well-defined custody path in\nthe provenance log H, and a subaccount u ∈ U has usable balance x of α iff\nAllow(u,α,x) holds.\nToken assets. For token assets such as ether, ERC-20, and ERC-721, de-\nposits are captured as Inbox entries (α,x,m) ∈ I. Claims allocate balance into\nL[u][α], internal transfers update L and H privately, and withdrawals enqueue\n(α,x, extDst,ν) intoO for enclave signing and on-chain broadcast, ensuring con-\nsistency where:\n∀α∈A\ntokens\n:\nX\nu∈U\nL[u][α] = B\non\n(α, pk).\nIn particular, ERC-721 tokens are modeled as unitary balances (x ∈ {0, 1})\nwhose transfers preserve uniqueness under provenance.\nGeneral Signable Messages (GSMs). In addition to on-chain assets,\nwallets often sign arbitrary messages, such as for EIP-4361 [?] logins and off-\nchain DAO votes [?]. PASS models these as a special classA\nGSM\nof virtual assets.\nEach GSM asset is scoped to a domain dom, so holding α = (dom) represents\nauthority to sign messages from that domain. A signature operation:\nSignGSM(u, dom,m)7→ σ\nis permitted iff Allow(u, dom, 1) holds in H. At key generation, the wallet\ncreator is endowed with default signing authority over all domains, represented\nas an initial allocation of every α = (dom)∈A\nGSM\nto the root subaccount. These\ndomain assets can be internally transferred to delegate signing authority. Thus\nprovenance of GSMs begins at the owner and flows through transfers, providing\na well defined provenance path in H as with token assets.\n8J. Yu\nBy treating both tokens and GSMs as types of elements ofA, PASS provides\na unified provenance rule for subaccount authorization. A subaccount cannot\nspend an ERC-20 token, transfer an NFT, or sign a domain message unless it\npossesses the corresponding asset under L and H. This unified authorization\nscheme allows for fine-grained delegation, (eg., giving u rights over example.com\nwhile withholding ERC–20 funds) and consistent enforcement across on-chain\nand off-chain actions.\n4 Properties of PASS\n4.1 Threat Model\nPASS assumes an organizational ownership model, where a single entity, such\nas a company, individual, or DAO manages the EOA (pk,sk), brokers access\nbetween many users in that entity, and chooses the TEE infrastructure vendor\n(eg. AWS Nitro, dstack Intel TDX, self-hosted hardware). This model is typical\nfor use cases such as private payroll, supply chains, and AI delegation described\nin Section ??. Protected assets in PASS include the private key sk, the balance\nledger L and provenance log H, and the correctness of Allow(u,α,x) for all\nu∈ U,α∈A,x. In our model, we make the following trust assumptions:\n1. TEE integrity. Hardware isolation is sound; sk never leaves the enclave.\nRemote attestation guarantees that the enclave runs the genuine PASS bi-\nnary.\n2. Cryptography. Standard primitives (signatures, hash functions, PRFs) are\nsecure against polynomial-time adversaries.\n3. Governance majority. The deploying entity holds majority control in the\ngovernance mechanism (via DAO vote or admin privileges), ensuring it can\ninvoke the blockchain-governed KMS for MPC-based key recovery and trig-\nger fallback contracts when needed.\nAdversary Model. An adversary A may control the host OS and network,\nobserve or modify all communication with enclaves, and submit arbitrary trans-\naction requests. In particular, A may attempt to:\n– Exploit software bugs in the PASS implementation or TEE runtime,\n– Forge or replay transactions to break consistency of H,\n– Subvert provenance by violating Allow(u,α,x)\nThreats Out of Scope. On the other hand, PASS does not protect against:\n– Physical compromise of TEE hardware (tampering, microarchitectural side-\nchannels, chip decapsulation),\n– Supply-chain backdoors in TEE manufacturing,\n– Fully malicious operators with unrestricted physical access.\nThese are excluded because the organizational model assumes controlled facilities\nand vetted hardware.\nSecurity Goals. Given the assumptions above, PASS guarantees:\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets9\n1. Integrity:\nP\nu∈U\nL[u][α]≤ extDep(α) for all α, i.e., no assets can be created\nor double-spent internally.\n2. Correctness: If Allow(u,α,x) holds, then u can eventually realize x via\nWithdraw.\n3. Privacy on-chain: InternalTransfer operations do not affect externalTrace(W ),\nand to external observers, a PASS wallet is indistinguishable from an EOA.\n4. Liveness: For any authorized op ∈ Ops, if one enclave and quorum remain\nhonest, then ∃τ s.t. Exec(c, op) =⊤ within τ\n4.2 Privacy and Safety\nAfter establishing the threat model of PASS, we will address the central privacy\nand safety guarantees in our formal verification model. We sketch three central\nlemmas here, and create mechanized proofs in Lean, discussed in Appendix ??.\nProposition 1 (Internal Transfer Privacy). If two public states W\n1\n,W\n2\nshare the same pk, identical Outbox (T,ν), and equal per-asset totals in A, then\nexternalTrace(W\n1\n) = externalTrace(W\n2\n).\nProof Sketch. InternalTransfer updates only (L,H), never O or total on-chain\nbalances. OutboxProcessing in Figure ?? emits on-chain actions solely from O\n(lines 2–4), hence the trace depends only on O.\nCorollary: EOA indistinguishability. If W\npass\nand W\neoa\nshare the same pk,\nOutbox, and per-asset totals, then\nexternalTrace(W\npass\n) = externalTrace(W\neoa\n).\nThus, from an external observer’s perspective, a PASS account is indistinguish-\nable from a standard EOA: internal transfers leave no observable footprint.\nProposition 2 (Asset Accessibility). For any asset α, letting L = {u |\nL[u][α] > 0},\nX\nu∈L\nL[u][α] = totalBalance(α),\nand each u∈ L can spend its full balance subject to checkAllow.\nProof Sketch. ClaimInbox creditsL; InternalTransfer preserves the sum over u;\nWithdraw debitsL and enqueues toO, which OutboxProcessing realizes on-chain.\ncheckAllow enforces reachability from provenance in H.\nProposition 3 (Provenance Integrity). Let extDep(α) be net external de-\nposits (deposits minus realized withdrawals). For all reachable states,\nX\nu\nL[u][α] ≤ extDep(α).\n10J. Yu\nProof Sketch. Induct on transitions. InboxDeposit increases extDep only; Claim-\nInbox moves already-deposited value into L; InternalTransfer conserves the sum\nover u; Withdraw decreases the sum, and after OutboxProcessing broadcasts,\nextDep is reduced accordingly.\nGeneral signable messages (GSM). Model GSM rights as a domain-\nscoped virtual asset class A\nGSM\n. Let α = (dom)∈A\nGSM\nand permit\nSignGSM(u, dom,m) iff Allow(u,α, 1).\nThen (P2)–(P3) lift to GSM: there is always at least one domain signer, and\nGSM “balances” obey provenance conservation under transfers in H.\n4.3 Liveness\nWe define liveness as the property that any authorized operation remains even-\ntually executable, despite enclave crashes, vendor compromise, or partial gover-\nnance failure. Our model assumes deployment of PASS access logic on dstack,\nimplemented in Section ?? and detailed in Appendix ??.\nLet E denote active enclaves, C containerized wallet backends, and P gover-\nnance policies. Each container c∈C stores sealed state\nσ\nc\n=⟨S,k\nc\n, meta⟩ with S = (pk, sk,ν,I,O,L,H),\nwhere k\nc\n= Derive(K,c) is derived from an MPC-managed KMS and meta records\nattestation. An operation op ∈ Ops (deposit claim, transfer, withdrawal) ex-\necutes as: Exec(c, op) = ⊤ iff Attested(c)∧ Γ (S), where Attested(c) checks σ\nc\nagainst registry R and Γ is the quorum predicate over P. To ensure vendor-\nagnostic portability, state migration μ :E →E satisfies\n∀e\ni\n,e\nj\n∈E, e\nj\n.decrypt(σ\nc,e\ni\n,k\nc\n) = σ\nc,e\ni\n,\nTheorem 1 (Liveness Theorem). If (i) the MPC KMS tolerates f\nKMS\nfaults\nin a t-of-n threshold, (ii) governance quorums are f\ngov\n-resilient, and (iii) at least\none enclave is uncompromised, then every op∈ Ops executes within bounded time\nτ :\n∀op∈ Ops, ∃τ ≥ 0 : Exec(c, op) =⊤.\nProof Sketch. Progress follows from three guarantees: (1) the MPC KMS\nensures k\nc\nis always recoverable under threshold availability; (2) Γ encodes quo-\nrum rules that eventually relax after timeout ∆t, ensuring some subset S satisfies\nΓ (S) = ⊤; (3) migration μ allows any enclave to re-host σ\nc\n, preventing vendor\nlock-in or enclave failure from blocking execution. Algorithm ?? formalizes re-\ncovery and execution under these assumptions.\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets11\nAlgorithm 1 RecoverAndExecute(c, op)\n1: Verify enclave e attestation Q\ne\nagainst R.\n2: Derive k\nc\n← Derive(K,c); decrypt σ\nc\n.\n3: if CompromiseDetected(e\n′\n) then\n4:Rotate k\nc\nand re-encrypt σ\nc\n.\n5: end if\n6: Ensure Γ (S) =⊤ for S ⊆P(c).\n7: Execute op; append to H.\nKey Properties. (1) Portability: any attested enclave can recover σ\nc\n, in-\ndependent of vendor; (2) Monotonic Recovery: recovery steps form ρ : S → S\nwith ρ(s)⪰ s; (3) Domain Continuity: certificates remain bound to R(c) under\nmigration μ(c), preventing hijack or replay.\nImplementation details of container orchestration, attestation, and KMS pro-\ntocols are given in Appendix ??.\n5 Practical Implementations\n5.1 Prototype Implementations\nTo demonstrate feasibility, we have implemented a prototype of PASS that cap-\ntures the core architectural components.\n5\nThe prototype consists of:\n– Provenanced Access Model, the core PASS architecture outlined in Sec-\ntion ?? with the Inbox-Outbox structure, asset ledgers, and provenanced\nrule as a Rust executable.\n– Web Application Frontend, an AWS-hosted Typescript interface that\nallows users to deposit assets, initiate internal transfers, generate on-chain\ntransactions, and sign arbitrary messages on Ethereum Sepolia testnet.\n6\n– Multi-vendor TEE deployment, we deploy the PASS enclave executable\nin both AWS Nitro Enclaves and Intel TDX with the dstack framework.\nWe evaluate these two enclave deployments as complementary deployment\npaths, each with distinct tradeoffs.\nAWS Nitro Enclaves. In this design, PASS runs inside a Nitro enclave in the\nAWS cloud. The enclave executes the Inbox–Outbox logic, enforces provenance\nchecks, and signs transactions, while the provenance ledger is stored externally.\nNitro’s attestation and AWS integration simplify deployment, but reliance on a\nsingle vendor limits portability and concentrates trust. As a result, some guaran-\ntees of PASS, particularly liveness and asset accessibility, may be weaker under\nthis model.\n5\nPrototype can be found here: https://github.com/jayyu23/pass-wallet-app\n6\nWeb application: https://pass-wallet.jayyu.xyz/\n12J. Yu\nIntel TDX with dstack. dstack provides a portable, open-source runtime for\nTEEs across diverse hardware. PASS can be deployed on enclaves run by decen-\ntralized operators, with key material secured via MPC-based key management.\nBoth Inbox–Outbox logic and the provenance ledger execute inside dstack, pre-\nserving the full security properties of Section ?? and reducing vendor lock-in.\nThe tradeoff is added governance complexity over operator authorization and\npolicy enforcement.\nBlockchain Connectivity. To ensure reliable blockchain interaction, PASS inte-\ngrates Helios [?], a consensus-verified light client, within the TEE. Rather than\ntrusting external RPC endpoints, Helios cryptographically verifies all blockchain\ndata against consensus layer proofs before serving it locally. This approach elimi-\nnates the trust assumptions typically associated with centralized RPC providers\nwhile maintaining the performance characteristics necessary for real-time wallet\noperations. The light client architecture ensures that PASS’s Outbox mecha-\nnism operates on verified blockchain state, preserving the security guarantees\neven when external network providers are compromised or unreliable.\n5.2 Performance Benchmarks\nTo evaluate PASS, we benchmarked both AWS Nitro Enclaves and Intel TDX\nbackends across common operations: balance queries, transfers, withdrawals,\nclaims, wallet creation, provenance queries, and an end-to-end workflow. Each\noperation was run 100 times over 10 trials per environment, measuring through-\nput in ops/sec. Both environments used identical 4-core, 2.5 GHz, 16 GB VMs\nto ensure fair comparison. Table ?? summarizes our results, with full details\navailable in Appendix ??.\nFig. 4. Internal PASS operation throughput (ops/sec) across AWS Nitro Enclaves\nand Intel TDX. All operations are in-memory state changes within the TEE with no\nblockchain interaction. Each value represents the average of 100 operations repeated\n10 times per environment.\nOperationAWS Nitro Intel TDX\nWallet Creation6,53114,970\nAccount Balance Queries530,943935,428\nInbox-to-Subaccount Claims14,85633,064\nInternal Subaccount Transfers32,95371,292\nWithdrawal Request Creation18,29139,702\nEnd-to-End Workflow\n7\n35,66378,433\nTransaction History Queries3,7577,685\nMulti-threaded Operations (5 threads)32,18955,124\nLarge Dataset Processing481724\nThe observed performance differences between AWS Nitro Enclaves and In-\ntel TDX primarily stem from their distinct hardware architectures. AWS Nitro\nEnclaves employ a disaggregated system design, where the host server and the\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets13\nTEE hardware are physically separated. Communication between the host and\nthe enclave occurs via vsock, and the enclave itself runs on a dedicated, lower-\nperformance coprocessor. In contrast, Intel TDX leverages a special instruction\nset to provide enclave functionality directly on the main processor, eliminating\nthe need for a separate coprocessor and avoiding the overhead of data transfer\nbetween disparate components. As a result, Intel TDX is able to deliver sig-\nnificantly higher throughput for in-enclave operations compared to AWS Nitro\nEnclaves, as reflected in our benchmark results.\nThese preliminary benchmarks show that both Nitro and TDX backends can\nsustain high throughput for critical wallet operations, confirming that PASS is\npractical for real-world deployment.\nComparison with Related Work. To contextualize our performance results, we\ncompare PASS with other TEE-based blockchain systems and traditional custo-\ndial solutions.\nLiquefaction. The Liquefaction system [?] demonstrates significantly higher\nlatencies than PASS due to its reliance on blockchain oracles for transaction\nvalidation. Liquefaction exhibits mean latencies of 49 seconds for latest block\nconfirmation, 648.7 seconds ( 11 minutes) for justified confirmation, and 1,036.9\nseconds ( 17 minutes) for finalized confirmation. These delays stem from Liq-\nuefaction’s architectural requirement to wait for block confirmations on an ex-\nternal TEE-blockchain oracle before authorizing subsequent operations. In con-\ntrast, PASS performs all operations within the off-chain TEE worker without\nblockchain dependencies, achieving sub-millisecond latencies for internal opera-\ntions (e.g., 14,856-33,064 ops/sec for claims, 32,953-71,292 ops/sec for transfers).\nThis fundamental architectural difference—off-chain TEE computation versus\nblockchain-dependent validation—enables PASS to provide near-instantaneous\nuser experiences while maintaining strong security guarantees.\nTraditional Custodians. While custodial solutions do not publish detailed\nperformance benchmarks, prior work demonstrates that TEE overhead typically\nintroduces only 5-7% performance degradation compared to native execution [?].\nGiven that modern custodial systems can process thousands of operations per\nsecond, TEE-based solutions like PASS should achieve comparable throughput\nwhile providing significantly stronger security properties. Our benchmark results\nsupport this expectation, with PASS demonstrating high-throughput operation\nprocessing that would be suitable for production custodial workloads, while offer-\ning the additional benefits of cryptographic auditability, decentralized operation,\nand reduced single points of failure.\nFurther evaluation of latency distributions, concurrency scaling, and memory\nfootprint is left for future work.\n6 Applications\nPASS is a powerful primitive that enables several classes of applications across\nidentity scoping, enterprise settings, and scalability concerns.\n14J. Yu\nCategoryApplicationContextPASS Enables\nIdentities\nAI Agent\nWallets\nAutonomous agents\ninteracting with crypto\nassets [?] need signing\naccess guardrails.\nScoped subaccounts grant limited\nbalances and domain signing rights,\nenabling safe delegation without\nexposing the root key\nDAO Voting\nDelegation\nDAOs depend on\naddress-based voting and\nproxy delegation [?].\nFine-grained voting rights delegation\nthat remains auditable via provenance;\ndelegation can be restricted to specific\nDApps or domains.\nSubdomain\nProfile Pages\nOrganizations delegate\ncontrol over web or\norganizational\nsubdomains (e.g.,\nmyprofile.company.com) to\nindividuals or teams.\nEach subaccount holds scoped signing\nrights for its assigned subdomain, with\nbalances and authorities tracked in\nprovenance under a shared\norganizational identity.\nEnterprise\nPrivate PayrollOn-chain payrolls reveal\nsensitive salary\ninformation [?].\nSalary distribution through internal\ngasless transfers with audit logs;\nexternal payouts are periodically\nbatched via the Outbox.\nCompliant Org\nWallets\nFirms must maintain\ninternal accountability\nand BSA\nrecordkeeping [?].\nDepartmental and individual\nsubaccounts with explicit budgets;\nprovenance ensures regulator-grade\nauditability without exposing internal\nflows.\nPrivate B2B\nNetting\nSupply-chain and\nrecurring multi-party\npayments require\nconfidentiality.\nVendor subaccounts allow internal\nnetting of obligations, with PASS\nacting as a temporary clearing house.\nOnly net settlements exit via the\nOutbox, reducing leakage while\nretaining auditability.\nAudit / Proof\nExplorer\nRegulators and auditors\nrequire verifiable yet\nprivacy-preserving\ntransparency.\nPublic proofs derived from the\nprovenance log H, enabling compliance\nchecks and audits without disclosing\ninternal ledger state.\nScalability\nGasless\nAppchain\nHigh-throughput\napplications (e.g., trading\nengines) face prohibitive\ngas costs on-chain.\nInternalize application logic as\nsubaccount transitions; Outbox emits\nverifiable batch settlements, ensuring\ncorrectness with minimal gas.\nCross-chain\nBridges\nBridges require strong\ncustody and coordination\nof operators [?].\nInbox-Outbox abstractions enforce\nprovenance across domains; FIFO\nnonce handling prevents replay or race\nconditions.\nL2 ComposabilityRollups and L2s fragment\nassets and user\nexperience [?].\nTreat each L2 as a scoped subaccount;\nmaintain private balance transfers\ninternally, and settle externally only\nwhen crossing domains.\nFig. 5. Applications of PASS across identities, enterprise settings, and scalability so-\nlutions. We highlight a flagship application in each category.\nIdentities and Agent Delegation. PASS’s multi-user subaccount model\nallows for flexible permission scopes. As AI agents start managing crypto as-\nsets, there is a need to constrain their access. An AI agent could be given a\nsub-account that only holds limited funds or certain asset types. The AI can op-\nerate freely within those bounds, but cannot exceed its allotted assets or misuse\nother wallet assets. If compromised, damage is capped to its sub-account. This\nis much safer than giving AI the keys to an entire wallet. Similarly, PASS can\nallow for delegation-based DAO voting by giving the delegate signature rights\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets15\nover particular voting DApps, without giving access to actually transfer the as-\nsets. Subaccounts can also get scoped signing rights over particular enterprise\nsubdomains.\nEnterprise Applications. PASS’s features of internal privacy, in-built per-\nmissioning, and provenance auditability make it uniquely suited for enterprise\napplciations. A flagship use case for PASS is private payroll. On-chain salary pay-\nments today risk exposing sensitive information such as individual compensation,\ndepartmental budgets, or timing patterns. With PASS, salaries are distributed\ninternally through gasless subaccount transfers, leaving a clear provenance log for\nauditability, but without revealing per-employee details on-chain. Only periodic,\non-demand payouts exit via the Outbox, ensuring both regulatory accountability\nand privacy for internal flows. Beyond payroll, PASS supports other enterprise\nneeds: compliant organizational wallets with departmental subaccounts that en-\nforce explicit budgets, private B2B netting where vendors settle obligations inter-\nnally and only net payments leave the wallet, and auditable proof explorers that\nprovide regulators with verifiable, privacy-preserving compliance proofs derived\nfrom the provenance log.\nScalability Solutions. PASS also supports scaling use cases where on-chain\ncosts or coordination overhead make existing approaches impractical. A flagship\nexample is gasless appchains, such as for Central Limit Orderbooks (CLOBs).\nHigh-throughput applications such as CLOBs cannot afford per-transaction gas\nfees, but PASS internalizes application logic as private subaccount transitions.\nThe Outbox then emits verifiable batch settlements with minimal gas, preserv-\ning correctness while keeping costs predictable. Beyond appchains, PASS enables\ncross-chain bridges by enforcing provenance across domains and sequencing with-\ndrawals via a FIFO nonce to prevent replay or race conditions, and supports L2\ncomposability by treating each rollup or sidechain as a scoped subaccount, main-\ntaining private balance transfers internally and settling externally only when\ncrossing domains.\n7 Discussion and Future Work\n7.1 Composability and InterPASS Transactions\nWhile PASS provides privacy and provenance guarantees for a single wallet in-\nstance, an important question is how multiple PASS wallets may interact. This\nis important in supply-chain use cases where each PASS represents a single com-\npany in the supply chain.\nTrivially, PASS A can send an on-chain transaction from its Outbox to PASS\nB’s EOA account, and this will land in the Inbox of PASS B, ready to claim.\nHowever, this undermines the privacy guarantees that PASS offers at the EOA\nlevel, and is undesirable in cases where inter-organizational asset transfers con-\ntain sensitive information, such as order details.\nWe propose a non-trivial approach inspired by cross-Payment Channel Net-\nwork (PCN) protocols such as XTransfer [?]. We can treat each PASS instance\n16J. Yu\nakin to a PCN hub node, with state L and transaction history H. As with\nXTransfer, we can assume a star topology of PASS nodes, with a central PASS\nHub in communciation with all PASS nodes. The PASS Hub will aggregate all\nInterPASS transactions T := {(a\ni\n,x\ni\n,s\ni\n,r\ni\n)}\nn\ni=1\n, where (a\ni\n,x\ni\n,s\ni\n,r\ni\n) represent\nthe asset, amount, sender, and receiver, each signed by the s\ni\nOutbox.\nThe Hub aggregates these signed payment intents, computes a netted settle-\nment plan S, and coordinates a secure multi-party update protocol to commit\nthe resulting balances, similar to Thora [?]. In the optimistic case, this process\ncompletes entirely off-chain, and each participant’s balance is updated in the\nPASS ledger without revealing the underlying transaction graph. If a dispute or\nfailure occurs, any participant may trigger an on-chain enforcement transaction\nthat finalizes S atomically via the direct transfer mechanism, thus guaranteeing\nsafety.\nThis approach leverages PASS ’s provenance and state design to make each\ninstance an atomic node in PCN-style systems like X-Transfer. Here, we outline\nhow PASS Hubs can enable confidential, auditable cross-organization transfers,\nwhile full formal specification and protocol implementation is deferred for future\nwork.\n7.2 Instantiation on zkVM\nThe PASS design presented in this paper relies primarily on trusted execution\nenvironments (TEEs) to enforce provenance rules, where the enclave isolates the\nglobal secret key and mediates all access through the Inbox–Outbox mechanism.\nWhile TEEs provide strong privacy and efficiency guarantees, their trust model\ndepends on hardware attestation and vendor integrity, which may be insufficient\nin regulatory or adversarial settings that demand independent verification.\nzkVMs provide a natural next step by enabling provenance-based control to\nbe verified through succinct cryptographic proofs rather than trusted hardware.\nBy batching transitions over L, H, I, and O and producing a proof π, a mini-\nmalist verifier contract can update commitments and enforce outbox execution\nwhile preserving privacy. This direction complements the Chainless stack ar-\nchitecture [?], suggesting a path toward modular, interoperable deployments of\nPASS with stronger external verifiability and broader applicability.\n8 Conclusion\nWe presented PASS, a Provenanced Access Subaccount System, as a new wallet\narchitecture that enforces access by provenance rather than by identity or role.\nThe Inbox–Outbox mechanism ensures all assets have a verifiable lineage, while\ninternal transfers remain private and indistinguishable from a standard EOA\naccount.\nOur contributions are threefold: (i) a formal model in Lean 4 proving pri-\nvacy, accessibility, and provenance integrity; (ii) a working prototype with en-\nclave backends on AWS Nitro Enclaves and Intel TDX via dstack, integrated\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets17\nwith WalletConnect; and (iii) initial benchmarks showing the feasibility of high-\nthroughput operation. These results demonstrate that provenance-based control\ncan be realized today with mainstream blockchain tools.\nLooking forward, richer evaluations across multi-vendor TEEs, integration\nwith zero-knowledge VMs, and exploration of organizational and agent-based\ncustody are promising directions. By combining rigorous formal guarantees with\ndeployable prototypes, PASS advances the design space between strict self-\ncustody and flexible shared access, offering a path toward practical, privacy-\npreserving wallet security.\nA Formal Verification\nWe consider the formal model introduced in Section ?? of PASS as a state\nmachine in Lean4. Our goal is to prove that, under the PASS design, several\ncritical security properties always hold. We outline these properties and our\napproach to verifying them.\nA.1 Property: Privacy of Internal Transfers\nIn the PASS design, the InternalTransfer operation updates only the off-chain\nledgerL and the provenance historyH. It never modifies the OutboxO, meaning\nthere is no on-chain transaction triggered by an internal transfer. Consequently,\nexternal observers see no change in on-chain state. We formalize this by consid-\nering the on-chain view that an external party has for a given PASS Wallet. We\ncan model this visible on-chain state as a triple:\nW\npub\n=\n\u0000\npk, O, A\n\u0001\n,\nwhere:\npk is the externally owned account (EOA) address,\nO = (T,ν) is the external view of the outbox, where T is a list of enqueued\ntransactions and ν is a nonce,\nA is the external view of the Asset ledgerL, containing a list of asset entries,\neach of the form (α,x) with a unique identifier α and total balance x.\nExternal Trace. The external trace of a PassAccount state W\npub\nis the list of\nexternally visible actions, obtained by mapping each transaction in the outbox\nT to an on-chain action:\nexternalTrace(W\npub\n) =\n\b\noutboxTx(t) | t∈ T\n\t\n.\nNo internal transfers appear in externalTrace(·).\n18J. Yu\nStates That Differ Only by Internal Transfers. We say that two PassAccount\nstates W\n1\n= (pk\n1\n,O\n1\n,A\n1\n) and W\n2\n= (pk\n2\n,O\n2\n,A\n2\n) differ only by internal trans-\nfers if:\n1. pk\n1\n= pk\n2\n,\n2. O\n1\n= O\n2\n(i.e. both the list of outbox transactions and the nonce are the\nsame),\n3. For every asset identifier α, the total balance of that asset in A\n1\nequals the\ntotal balance of the same asset in A\n2\n.\nLetting getAsset(W,α) return the asset α within state W or ⊥, we require ∀α:\ntotalBalance\n\u0000\ngetAsset(W\n1\n,α)\n\u0001\n= totalBalance\n\u0000\ngetAsset(W\n2\n,α)\n\u0001\n.\nTheorem 2 (Privacy of Internal Transfers). If two PassAccount states W\n1\nand W\n2\ndiffer only by internal transfers, then their externally visible traces are\nidentical:\nexternalTrace(W\n1\n) = externalTrace(W\n2\n).\nProof. By assumption, O\n1\n= O\n2\n. Hence both states have the same outbox trans-\naction list T . Since\nexternalTrace(W\ni\n) = map\n\u0000\noutboxTx, T\ni\n\u0001\nfor i∈{1, 2},\nand T\n1\n= T\n2\n, it follows that externalTrace(W\n1\n) and externalTrace(W\n2\n) are iden-\ntical.\nThus, any sequence of purely internal transfers, changing only the private ledger\nL in PASS, is invisible to an external observer, preserving the privacy of how\nassets move within the wallet.\nA corollary of this Internal Transfer property is that a PASS account is\nindistinguishable from a regular EOA account.\nCorollary 1 (Indistinguishability from EOA). Let W\npass\nbe a PASS state\nthat (i) has the same public key pk, (ii) the same outbox, including nonce and\ntransaction list, and (iii) the same total balances of each asset as a reference\nEOA state W\neoa\n. Then\nexternalTrace(W\npass\n) = externalTrace(W\neoa\n).\nIn particular, an external observer cannot distinguish W\npass\nfrom W\neoa\n.\nProof. By assumption, the only potential differences betweenW\npass\nandW\neoa\nlie\nin internal ledger details. From Theorem 1, such internal transfers do not affect\nthe externally visible outbox transactions or total on-chain balances. Thus, their\nexternal traces coincide, and W\npass\nis indistinguishable from W\neoa\n.\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets19\nA.2 Property: Asset Accessibility\nIn addition to keeping internal transactions private, PASS should ensure that for\nevery asset in the system, there exists some sub-account that can access it and\nwithdraw it from the system. This prevents a situation where funds get ”stuck”\nwithout any reachable key or policy to move them. We define asset accessibility\nas follows:\nTheorem 3 (Asset Accessibility). For any PASS account W and asset iden-\ntified by α, there exists a list of addresses L such that:\n1. For every address u∈ L, the user can access their full balance:\ncheckBalance(s,α,u, balance(u)) = true\n2. The sum of all accessible balances equals the total balance of the asset:\nX\nu∈L\nL[u][α] = totalBalance(α)\nProof. We construct L as the set of all addresses with non-zero balances in the\nbalance map for α:\nL ={u|L[u][α] > 0}\nFor the first property, given any u∈ L, the definition of checkBalance verifies\nif the user has sufficient balance for the specified amount. When checking against\nthe user’s own balance, this is trivially satisfied since L[u][α]≥L[u][α] for all u.\nFor the second property, we observe that totalBalance is defined as the sum\nof all balances in the asset’s balance map:\ntotalBalance(α) =\nX\nu∈L\nL[u][α]\nBy construction, L contains the only nonzero values u∈L, so:\nX\nu∈L\nL[u][α] = totalBalance(α)\nTherefore, both properties hold for our constructed list L.\nWe can prove a similar trait for General Signable Messages, showing that for\nany inbound GSM, there is some subaccount signer that has access to it.\nTheorem 4 (GSM Accessibility). For any GSM and domain, there exists a\nuser with signing access to that domain.\nProof. For any domain d, we can directly construct a user u who has signing\naccess to d as follows:\nu = getSigner(d)\nBy definition, getSigner returns either:\n– A specifically assigned signer if one exists in the domain-address map, or\n– The default signer otherwise\nTherefore, every domain is guaranteed to have at least one user with signing\naccess, ensuring no GSM domain becomes inaccessible.\n20J. Yu\nA.3 Property: Provenance Integrity\nProvenance integrity specifies that every asset held by any sub-account in PASS\nmust have an origin traceable to an external deposit into the Inbox. At any\nstate of the system, for each asset entry in a sub-account’s balance, we can find\na sequence of internal transfers that leads back to an Inbox deposit from an\nexternal address. This property ensures no sub-account can conjure funds from\nnothing, such as through double-spending or inflation within the system, and\nthat the internal ledger is consistent with on-chain reality. In Lean, we model\nthe state of the PASS wallet including Inbox, Outbox, and all sub-accounts and\nprove an invariant that whenever a sub-account has x units of asset α, the global\nstate contains a record of at least x units of α having been deposited, minus any\nthat have been withdrawn.\nTheorem 5 (Provenance Integrity).\nFor any PASS account S =\n\u0000\npk, sk,ν,I,O,L,H\n\u0001\nand any asset α, the total\namount of α held across all subaccounts can never exceed the total amount of\nexternal deposits (minus any that have already been withdrawn). Formally,\nX\nu∈U\nL[u][α] ≤ externalDeposits(α),\nwhere U is the set of subaccounts in the system, and externalDeposits(α) is\nthe net total of asset α that has been introduced into the wallet from outside\naddresses, recorded in the inbox I.\nProof. We model the system’s state (pk, sk,ν,I,O,L,H) as in Figure ??, includ-\ning the Inbox I, Outbox O, and the internal ledger L. We define a provenance\nrecord P (α,u) that captures the total amount of asset α subaccount u is autho-\nrized to hold, based on Inbox claims and internal transfers.\nBase Case: Immediately after CreatePassWallet, no assets have been de-\nposited, and no subaccount balances exist:\n∀u, L[u][α] = 0, ∀α, externalDeposits(α) = 0.\nHence,\nX\nu∈U\nL[u][α] = 0 ≤ 0 = externalDeposits(α).\nInductive Step: Assume the invariant holds after n− 1 operations. We prove it\nremains valid after the nth operation, for each possible type of operation:\n(1) External Deposit: Suppose an amount x of asset α is deposited into the\nwallet:\nexternalDeposits(α) ← externalDeposits(α) + x.\nNo subaccount balances L[u][α] change. Thus, the left side of our inequality\n(sum of subaccount balances) is unchanged, while the right side strictly\nincreases by x, so the invariant continues to hold.\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets21\n(2) Inbox Claim: If subaccount u claims amount x of asset α from the Inbox\nI:\nL[u][α] ← L[u][α] + x, P (α,u) ← P (α,u) + x.\nSince x was already accounted for in externalDeposits(α) (but not yet allo-\ncated to any subaccount), the total subaccount balances remain≤ externalDeposits(α).\n(3) Internal Transfer: If subaccount u\n1\ntransfers x of α to subaccount u\n2\n:\nL[u\n1\n][α] ← L[u\n1\n][α]− x, L[u\n2\n][α] ← L[u\n2\n][α] + x,\nand P (α,u\n2\n) increases by x. Because the sum of all subaccount balances\ndoes not change, our invariant is preserved.\n(4) Withdrawal: If subaccount u withdraws x of α:\nL[u][α] ← L[u][α]− x,\nwhich reduces the total subaccount balances. Since externalDeposits(α)\nremains unchanged (assets have simply exited the wallet), the inequality still\nholds.\nThus, by induction over all possible operations,\nX\nu∈U\nL[u][α] ≤ externalDeposits(α)\nfor every reachable state. No subaccount can create new assets out of nothing,\nand all assets in the system are fully accounted for by provenanced deposits.\nB Dstack Architecture and Execution Model\nB.1 Component Overview\n– Dstack-OS: Minimal Linux-based VM image with a verifiable boot chain.\nMeasures bootloader, kernel, root filesystem (RootFs) via RTMR registers.\nIntegrates dm-verity for data integrity and monotonic counters for anti-\nrollback.\n– Dstack-KMS: Blockchain-governed MPC network for key derivation and\nrotation. Provides:\nk\nc\n= HMAC\nk\nroot\n(c\nid\n),\nk\nTLS\n= ECDSA(k\nroot\n).\nRotation is triggered via governance (t-of-n threshold).\n– Dstack-Gateway/Ingress: TLS termination inside TEEs, ZT-TLS bind-\ning X\nc\nto R(c), enabling verifiable HTTPS ingress.\n22J. Yu\nB.2 Governance Layer\nTwo contracts form the trust base:\n– KmsAuth: Global registry of KMS nodes and application digests.\n– AppAuth: Per-application contract specifying quorum rules, allowed image\nhashes, and authorized enclaves.\nB.3 Workflow Phases\n1. Attestation: Enclave e produces quote Q\ne\n; verified against R.\n2. Secret Provisioning: MPC nodes compute k\nc\n, release to e if Q\ne\nis valid.\n3. Container Launch: Dstack-OS mounts RootFs, decrypts state σ\nc\nwith k\nc\n.\n4. Ingress Binding: TLS certificate X\nc\ngenerated inside e; bound to R(c).\n5. Audit Logging: Migration, key rotation, and governance events appended\nto H.\nB.4 Fault Tolerance\n– Vendor failure: μ enables re-deployment across Intel/AMD TEEs.\n– KMS compromise: key rotation via MPC thresholds restores forward/backward\nsecrecy.\n– Governance deadlock: ∆t fallback in Γ ensures quorum reduction and progress.\nB.5 Liveness Proof Sketch\nCombining MPC-based key recovery, quorum fallback, and portable containers\nyields:\n∀op∈O\nc\n,Pr[Exec(c, op) =⊤] = 1\nunder assumptions of f -resilient MPC nodes and at least one uncompromised\nTEE instance.\nC Detailed Benchmark Results\nThis appendix provides comprehensive benchmark statistics for both AWS Nitro\nEnclaves and Intel TDX environments. All operations are internal PASS state\nchanges that occur within the TEE with no blockchain network interaction.\nEach operation was executed 100 times per trial, with 10 independent trials\nper environment. The tables below show summary statistics including mean,\nstandard deviation, and range.\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets23\nTable 1. AWS Nitro Enclaves benchmark statistics (ops/sec) across 10 trials\nOperationMean Std Dev Min Max\nWallet Creation6,5315315,4467,042\nAccount Balance Queries530,943675 530,216 531,915\nInbox-to-Subaccount Claims14,856476 14,326 15,504\nInternal Subaccount Transfers32,9531,322 31,447 35,088\nWithdrawal Request Creation18,2911,254 15,873 19,608\nEnd-to-End Workflow35,6636,234 21,739 40,650\nTransaction History Queries3,757453,6503,802\nMulti-threaded Operations (5 threads) 32,189884 31,200 34,364\nLarge Dataset Processing48113467497\nTable 2. Phala dStack benchmark statistics (ops/sec) across 10 trials\nOperationMean Std Dev Min Max\nWallet Creation14,9704,6528,69624,390\nAccount Balance Queries935,428338,450 383,142 1,470,588\nInbox-to-Subaccount Claims33,0645,197 25,44541,667\nInternal Subaccount Transfers71,29217,623 47,170 101,010\nWithdrawal Request Creation39,7027,434 29,15551,813\nEnd-to-End Workflow78,43317,403 59,524 110,497\nTransaction History Queries7,6858726,4528,929\nMulti-threaded Operations (5 threads) 55,12416,744 28,32981,301\nLarge Dataset Processing72481636893\nC.1 AWS Nitro Enclaves Results\nC.2 Intel TDX Results\nC.3 Performance Analysis\nThe statistical analysis reveals several key insights about PASS’s internal oper-\nation performance:\n– Performance Consistency: AWS Nitro Enclaves demonstrate superior\nconsistency with lower standard deviations across all operations. The co-\nefficient of variation ranges from 0.1% (Account Balance Queries) to 17.5%\n(End-to-End Workflow).\n– Peak Performance: Intel TDX achieves higher mean throughput but with\nsignificantly greater variance. Standard deviations are 10-500x larger than\nNitro, indicating less predictable performance.\n– Production Considerations: These internal operation benchmarks demon-\nstrate PASS’s ability to handle thousands of wallet operations per second\nwithin the TEE, with the actual deployment bottleneck being blockchain\ntransaction submission rather than internal processing.\nThe statistical summary confirms that both platforms support practical PASS\ndeployment, with Nitro offering predictable performance and Intel TDX provid-\ning higher peak throughput at the cost of consistency.\n24J. Yu\nD Design Extensions\nD.1 Composability and InterPASS Transactions\nWhile PASS provides privacy and provenance guarantees for a single wallet in-\nstance, an important question is how multiple PASS wallets may interact. This\nis important in supply-chain use cases where each PASS represents a single com-\npany in the supply chain.\nTrivially, PASS A can send an on-chain transaction from its Outbox to PASS\nB’s EOA account, and this will land in the Inbox of PASS B, ready to claim.\nHowever, this undermines the privacy guarantees that PASS offers at the EOA\nlevel, and is undesirable in cases where inter-organizational asset transfers con-\ntain sensitive information, such as order details.\nWe propose a non-trivial approach inspired by cross-Payment Channel Net-\nwork (PCN) protocols such as XTransfer [?]. We can treat each PASS instance\nakin to a PCN hub node, with state L and transaction history H. As with\nXTransfer, we can assume a star topology of PASS nodes, with a central PASS\nHub in communciation with all PASS nodes. The PASS Hub will aggregate all\nInterPASS transactions T := {(a\ni\n,x\ni\n,s\ni\n,r\ni\n)}\nn\ni=1\n, where (a\ni\n,x\ni\n,s\ni\n,r\ni\n) represent\nthe asset, amount, sender, and receiver, each signed by the s\ni\nOutbox.\nThe Hub aggregates these signed payment intents, computes a netted settle-\nment plan S, and coordinates a secure multi-party update protocol to commit\nthe resulting balances, similar to Thora [?]. In the optimistic case, this process\ncompletes entirely off-chain, and each participant’s balance is updated in the\nPASS ledger without revealing the underlying transaction graph. If a dispute or\nfailure occurs, any participant may trigger an on-chain enforcement transaction\nthat finalizes S atomically via the direct transfer mechanism, thus guaranteeing\nsafety.\nThis approach leverages PASS ’s provenance and state design to make each\ninstance an atomic node in PCN-style systems like X-Transfer. Here, we outline\nhow PASS Hubs can enable confidential, auditable cross-organization transfers,\nwhile full formal specification and protocol implementation is deferred for future\nwork.\nD.2 Instantiation on zkVM\nThe design of PASS presented thus far relies on trusted execution environments\n(TEEs) such as AWS Nitro or Intel TDX to enforce provenance-based control.\nTEEs provide strong isolation and efficient execution, allowing internal transfers\nto remain private while ensuring that every outbox action has a verifiable lin-\neage. However, the trust model is anchored in hardware attestation: users and\nregulators must accept that the enclave executes the correct code as claimed.\nWhile sufficient for many organizational custody scenarios, this assumption lim-\nits transparency and long-term auditability. To address this limitation, we ex-\nplore an alternative instantiation of PASS in a zero-knowledge virtual machine\n(zkVM), replacing hardware trust with cryptographic proofs of correctness.\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets25\nZero-knowledge virtual machines (zkVMs) provide a proving environment in\nwhich arbitrary state machines can run with strong correctness guarantees [?].\nBy producing a succinct proof π of execution, zkVMs offer integrity assurances\nsimilar to TEEs but without reliance on vendor-specific hardware. This shift\nmakes zkVMs particularly suitable for contexts such as institutional custody,\nmulti-party supply chains, or inter-organizational accounting where external ver-\nifiability and regulator-grade auditability are paramount.\nIn a zkVM instantiation of PASS, the execution pipeline mirrors the enclave-\nbased design but replaces attestation with cryptographic proofs. The process\nproceeds in four stages:\n1. Batch formation. Transaction requests (claims, transfers, withdrawals) are\nfirst queued off-chain into a batch.\n2. zkVM execution. The zkVM program takes as private inputs: (i) the prior\nbatch’s commitments of the ledger L and provenance log H, (ii) the queued\ntransitions, including inbox I deposits and outbox O withdrawals, and (iii)\nthe proposed new commitments (L\n′\n,H\n′\n). Inside the zkVM, the transition\nfunction is replayed deterministically: starting from the previous roots, ap-\nplying all operations in sequence, updating balances and provenance entries,\nand checking consistency constraints.\n3. Proof generation. The zkVM outputs a succinct proof π certifying that the\nclaimed new roots (L\n′\n,H\n′\n) are correct with respect to the given transition\nset.\n4. On-chain verification. A minimalist verifier contract validates π, updates\nthe recorded commitments, and enforces any pending outbox operations.\nThis ensures that every external action has a verifiable provenance path\nwhile internal transfers remain private.\nCompared to TEEs, zkVMs strengthen the verifiability model by eliminat-\ning hardware trust assumptions, but incur higher computational and financial\ncosts due to proof generation and on-chain verification. Batching amortizes these\ncosts, raising open research questions about optimal batch sizes, data availabil-\nity strategies, and proof system selection. zkVM backends such as Risc0, SP1,\nor Plonky3 offer different tradeoffs in proof size, verification cost, and latency.\nHybrid deployments are also possible: TEEs can serve as fast-path executors for\nintra-day operations, with zkVM proofs generated periodically to provide cryp-\ntographic audit trails. This hybrid pattern resembles optimistic rollups, where\nfast execution is combined with verifiable settlement.\nFinally, this instantiation aligns closely with the Chainless stack architec-\nture [?], which emphasizes the separation of execution, trust, bridging, and set-\ntlement. In this view, zkVM proofs naturally inhabit the execution and trust\nlayers, Inbox/Outbox commitments integrate with bridging, and the verifier\ncontract finalizes settlement. This layered design opens the door to modular,\ninteroperable deployments of PASS across heterogeneous chains and domains.\nFull formal specification, performance benchmarking, and exploration of hybrid\nzkVM–TEE implementations remain important avenues for future work.\n26J. Yu\nFig. 6. PASS instantiation inside a zkVM: Inbox I and Outbox O transitions are\napplied to the Ledger L and Provenance H, producing new state commitments. The\nzkVM outputs a proof π, which the on-chain verifier checks before updating roots and\nenforcing outbox operations."
}
]
}
]Response:
要逻辑严密地说明“introduction”中提到的三个场景（AI代理钱包、企业工资隐私、CLOB/交易撮合）都无法被现有主流方案（如EOA、Multisig、智能合约钱包、托管、Liquefaction等）有效解决，并顺畅引出provenance和基于TEE的PASS方案，建议采用如下结构：
---
**1. 明确每个场景的核心需求和挑战**
- **AI/智能代理钱包**：需要对代理行为加以限制与可验证授权，防止越权或滥用；且代理的行为应可溯源，便于追责，但又不能暴露全部内部操作细节。
- **企业工资隐私**：既要实现对员工/部门的工资分发，又要保证内部资金流动不被外部窥探，满足隐私与合规双重需求。
- **CLOB/高频撮合**：要求高吞吐、低延迟的交易撮合，同时普通用户不愿意自管密钥，且希望撮合行为对外不可见，只有最终结算上链。
---
**2. 分析现有主流方案的逻辑局限**
- **EOA/单一私钥钱包**
- 单点失效，无法实现多方协作或权限分离。
- 所有操作都公开上链，毫无隐私。
- 无法追踪资产内部流转的“责任链”，更谈不上细粒度授权和可验证代理。
- **Multisig/多签钱包**
- 只支持简单的t-of-n审批，所有多方逻辑都暴露在链上。
- 权限划分粗放，无法区分子账户、代理、部门等精细角色。
- 每次操作都需链上审批，高延迟、高成本，难以支持CLOB等高频场景。
- 不支持内部隐私：所有审批和资金流动都可被链上观察者完全还原。
- **智能合约钱包/Account Abstraction (ERC-4337等)**
- 虽然支持自定义逻辑，但所有规则都需上链，全部公开。
- 每次内部操作都需消耗Gas，无法实现“免费”或隐秘的内部转账。
- 隐私与灵活性无法兼得；复杂策略导致攻击面和实现负担激增。
- 依赖特定链生态支持，兼容性不足。
- **托管/企业级RBAC/ABAC**
- 策略和资产控制逻辑完全由中心化API/服务托管，信任边界大幅扩大。
- 托管方可监控全部内部操作，隐私无保障。
- 政策语言、API各异，互操作性差，且引入额外安全风险。
- 多数无法做到链上可验证的“资产溯源”或操作责任分离。
- **Liquefaction/TEE-based Key Encumbrance**
- 仅能实现“密钥受限”与部分权限树，难以灵活表达复杂的资产流转溯源规则。
- 依赖特定链和TEE平台（如Oasis），可移植性差。
- 缺乏形式化证明和标准接口，难以与现有钱包生态无缝集成。
---
**3. 归纳总结：现有方法的共性缺陷**
- 无法在保证原生EOA兼容性的同时，实现强隐私、灵活细粒度权限及可验证的责任链（provenance）。
- 要么过度公开（智能合约、multisig），要么过度中心化（托管），无法平衡隐私、可追溯性、灵活性和可用性。
- 缺乏对“资产来源—流转—使用”全链路的可验证控制与审计机制。
---
**4. 顺势引出provenance+TEE的PASS方案**
因此，针对上述痛点，**provenance-based control**（基于资产流转溯源的权限管理）成为唯一能够兼顾：
- 资产责任链的可验证性（谁存入、如何内部流转、谁用掉），
- 内部操作的强隐私（对外不可见，类似EOA），
- 灵活的细粒度子账户/代理权限分配（每笔资产都可溯源到合法子账户），
- 以及与现有钱包/链生态的原生兼容性（不引入新合约或链级变更），
的方案。
而要实现上述目标，**必须依托TEE等可信硬件**，将私钥和内部账本隔离于硬件安全环境下，所有授权、签名和责任溯源逻辑均在TEE中私密执行。这样才能保证：
- 外部只看到总进出账，内部流转完全隐匿；
- 任何对外操作都可溯源至合法的存入和内部授权链；
- 权限和策略灵活可扩展（可内嵌RBAC/ABAC等辅助规则，但不破坏溯源原则）；
- 形式化安全可证明，兼容主流链钱包接口。
**PASS**（Provenanced Access Subaccount System）正是对这种需求的系统性回应。
---
**推荐表述模板（可直接修改用于论文正文）：**
> 尽管已有多种区块链钱包与资产管理方案，但在AI智能代理、企业隐私工资分发以及高性能CLOB等新兴场景下，现有方法均存在根本性局限：要么无法实现细粒度、可追溯的权限隔离（如EOA/Multisig），要么牺牲了隐私和可扩展性（如智能合约钱包），或过度依赖中心化托管（RBAC/ABAC Custodian），难以兼顾隐私保护、操作灵活与安全责任的可验证。
>
> 本质原因在于，传统方案均以“身份/角色”为控制粒度，忽略了区块链资产“外源性”与流转链路的天然可验证特性。唯有将“资产的合法使用权”与其可追溯的流转链（provenance）绑定，并将所有内部授权与操作隔离于可信硬件（TEE）环境中，才能在保证EOA兼容性与高性能的同时，实现细粒度、强隐私、可审计的多方协作钱包。
>
> 因此，本文提出的PASS系统，以provenance为核心权限基础，辅以TEE实现的Inbox–Outbox架构，有效填补了自托管与灵活共享访问之间的设计空白，为上述典型场景提供了理论严密、实践高效的解决方案。
---
如需进一步细化某一场景的论证链条，可继续深入。整体逻辑应保持“需求—现有方案失败—新范式（provenance+TEE）唯一满足需求—PASS实例化”的演绎顺序。
Model: gpt-4.1-nano-2025-04-142025-09-15 12:24:19
Context:
[
{
"role": "system",
"content": "You are an assistant who is good at conversation. You need to summarize the user's conversation into a title of 10 characters or less. It should be in the format of \"Action - Title\". Some examples:\n1. Learn - Bitcoin 2. Code - Web Server 3. Write - An Article"
},
{
"role": "user",
"content": "[{\"role\":\"user\",\"mainText\":\"根据introduction和background的内容作为背景，和我讨论问题。\\n\\n我想说明对introduction中提到的三个场景，现有的方法都没办法有效的解决。你觉得怎么说比较好。\",\"files\":[\"main.pdf\"]},{\"role\":\"assistant\",\"mainText\":\"要论证**introduction**中提到的三个场景（AI代理钱包、企业工资隐私、消费级链上限价订单簿），现有方法都无法有效解决，应该采用如下结构化、\"}]"
}
]Response:
Discuss - 背景问题
Model: gpt-4.1-2025-04-142025-09-14 02:19:49
Context:
[
{
"role": "user",
"content": [
{
"type": "text",
"text": "Custodial Key Management and Policies 和PASS在效果上有什么区别，PASS能解决什么额外的问题"
},
{
"type": "text",
"text": "main.pdf\nPASS: A Provenanced Access Subaccount\nSystem\nfor Blockchain Wallets\nJay Yu\n1,2\n1\nStanford University [email protected]\n2\nPantera Capital [email protected]\nAbstract. Blockchain wallets still follow a single-entity ownership model:\npossession of a private key grants unilateral control. This assumption is\nbrittle for emerging settings such as organizational custody, shared gov-\nernance, and AI agent wallets, where multiple actors must coordinate\nwithout exposing secrets or leaking internal activity.\nWe present PASS, a Provenanced Access Subaccount System\nthat replaces role or identity-based control with provenance-based con-\ntrol: assets can only be used by subaccounts that can trace custody back\nto a valid deposit. A simple Inbox–Outbox mechanism ensures all exter-\nnal actions have verifiable lineage, while internal transfers remain private\nand indistinguishable from ordinary EOAs.\nWe formalize PASS in Lean 4 and prove core invariants, including\nprivacy of internal transfers, asset accessibility, and provenance integrity.\nWe implement a prototype with enclave backends on AWS Nitro Enclaves\nand dstack Intel TDX, integrate with WalletConnect, and benchmark\nthroughput across wallet operations. These results show that provenance-\nbased wallets are both implementable and efficient. PASS bridges today’s\ngap between strict self-custody and flexible shared access, advancing the\ndesign space for practical, privacy-preserving custody.\n1 Introduction\nCryptocurrency wallets conventionally assume one key, one owner. In this single-\nentity ownership (SEAO) model, whoever holds the private key gains permanent\nand total control of the address. This paradigm underpins EOAs, multisigs, and\ncustodial policy engines, but it struggles in emerging scenarios such as orga-\nnizational treasuries, DAO governance, or delegating bounded authority to AI\nagents.\nThe limitation stems from a mismatch of models. Traditional access-control\nframeworks such as RBAC and ABAC assume an endogenous setting: users\ncreate and manage their own files, objects, or services, and policies are attached\nto these identities or roles. Blockchains are fundamentally exogenous: assets are\ncreated outside the wallet by smart contracts and transferred permissionlessly\nin. In this setting, identity or role-based rules are awkward to express and brittle\n2J. Yu\nto enforce. What matters instead is provenance: who deposited an asset, and how\nit flowed within the wallet.\nWe propose PASS, a Provenanced Access Subaccount System that enforces\ncontrol directly by provenance. The core mechanism is simple: an Inbox records\nexternal deposits, an Outbox signs and broadcasts withdrawals, and all internal\nmovements remain private and fee-less. Every unit of value inside the wallet has\na verifiable lineage to an on-chain deposit, while externally a PASS wallet is\nindistinguishable from a standard EOA. Our contributions include:\n– A provenance-based access model aligned with blockchain’s exogenous asset\ncreation, enforced through an Inbox–Outbox design.\n– A formal model in Lean 4 proving privacy, accessibility, and provenance\nintegrity.\n– A prototype with enclave backends (AWS Nitro, Phala dStack), integrated\nwith WalletConnect, together with throughput benchmarks.\n– Application scenarios, including organizational custody, privacy-preserving\ntransfers, and safe delegation to AI agents.\nPASS thus bridges the gap between strict self-custody and flexible shared\naccess, combining strong privacy guarantees with practical deployability.\n2 Background and Related Work\nGrowing retail and institutional adoption of digital assets [?,?,?] has spurred di-\nverse wallet designs [?]. In this section, we provide an overview of the mainstream\nwallet designs in Ethereum Virtual Machine (EVM) blockchains.\nExternally Owned Accounts and Multisignature Wallets In the EVM, assets are\ncommonly held in Externally Owned Accounts (EOAs), where possession of the\nprivate key confers unilateral, persistent control [?]. Key compromise has driven\nmany high-profile incidents [?,?]. Hardware wallets and mnemonic backups im-\nprove key custody but preserve the single-owner assumption [?].\nMultisignature wallets (e.g., Safe) distribute trust by requiring multiple ap-\nprovals [?], and are widely used for treasuries, bridges, and exchanges [?,?,?].\nTheir drawbacks include quorum overhead, largely symmetric authority, and\npublic on-chain logic with centralized frontends that can be attacked [?]. In con-\ntrast, PASS enables fine-grained, scoped permissioning without deploying new\ncontracts.\nSmart Contract Wallets and Account Abstraction Smart contract wallets such\nas Argent and Loopring add programmability such as social recovery and spend\nlimits via on-chain logic [?,?,?]. Ethereum’s ERC-4337 enables validation logic\nin a UserOperation contract [?], and EIP-7702 allows EOAs to also call smart\naccount logic defined in ERC-4337 [?]. These approaches increase flexibility but\nincur on-chain overhead and expose policy and transactions publicly, which is\nill-suited to use cases like institutional payroll.\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets3\nModelControl basisOn-chain\noverhead\nInternal\nPrivacy\nCompatibility\nEOASingle private keyNoneNoneNative EOA\nMultisigt-of-n co-signersHigh; quorum per\naction\nNone; logic\npublic\nSmart\ncontract based\nERC-4337\nSmart\nAccounts\nOn-chain policy\nlogic\nMedium to high;\ncustom logic and\ngas\nNone; logic\npublic\nRequires\nERC-4337\nchain support\nCustodiansCustom RBAC or\nABAC languages\nNone; Off-chain\nenforcement\nCustodian sees\nall activity\nAPI mediated\nLiquefactionTEE key\nencumbrance;\npolicy trees\nMedium; Oasis\ncontracts and gas\nStrong; TEE\nhides\nsubpolicies\nRequires Oasis\ndeployment\nPASS\n(ours)\nProvenance via\nInbox-Outbox\nNone; EOA\ncompatible\nStrong;\ninternal\ntransfers\ninvisible\nNative EOA\nplus off the\nshelf TEEs\nFig. 1. Comparison of wallet architectures. PASS features provenance-based control,\noff-chain privacy, and native EOA compatibility.\nPASS instead enforces policy off-chain in a TEE, achieving intent–execution\nseparation akin to account abstraction but without revealing rules or consuming\nchain resources.\nCustodial Key Management and Policies Institutional custody platforms (eg.,\nFireblocks, Turnkey, Privy) control key use with Role-Based Access Control\n(RBAC) or Attribute Based Access Control (ABAC) engines with custom pol-\nicy languages [?,?]. PASS adopts a provenance-centric alternative: authority fol-\nlows asset origin and transfer history, similar to a UTXO model. This reduces\npolicy-surface complexity, as no additional policy language is required, while\nmaintaining composability with additional rules such as whitelists and black-\nlists.\nTrusted Execution Environments and Liquefaction Trusted Execution Environ-\nments (TEEs) provide a hardware-isolated context for secure key storage and\ncomputation, shielding sensitive logic from the host system while providing re-\nmote attestation capabilities [?,?]. Liquefaction [?] keeps the wallet key inside a\nTEE and enforces multi-user sub-policies via key encumbrance, yielding strong\nprivacy. PASS extends this line of research by (i) providing Lean 4 formalization\nof core security invariants, (ii) simplifying access enforcement to a provenance\nrule realized through two special subaccounts (Inbox/Outbox) rather than a\nbespoke policy tree, and (iii) operating with a standard EOA and no new con-\ntracts to improve composability with mainstream TEE systems, in contrast to\nLiquefaction’s reliance on Oasis smart contracts [?]. To further demonstrate the\ngenerality of our approach, we implement PASS on two distinct TEE hard-\nware platforms: AWS Nitro Enclaves and Intel TDX, leveraging the open-source\n4J. Yu\ndstack TEE toolkit for the latter, and showcase prototype applications of PASS,\nincluding an AI agent wallet framework, private payrolls and supply chains, and\nsecure DAO voting.\nOther Related Models Centralized exchanges often pool funds in omnibus ad-\ndresses and track balances off-chain [?]; privacy mixers (eg., Tornado Cash) sever\ndeposit–withdrawal linkages [?]. PASS similarly preserves off-chain privacy for\ninternal transfers while maintaining an internal provenance ledger for account-\nability and regulatory workflows; external observers still see only deposits to and\nwithdrawals from the public EOA.\n3 System Model and Design\nFig. 2. Overview of PASS. External deposits enter the Inbox and are claimed by sub-\naccounts. Internal transfers are private and off-chain. Egress occurs via the Outbox,\nwhich signs and broadcasts on-chain transactions. All on-chain activity has clear prove-\nnance; internal movements remain private.\n3.1 High level system model\nPASS is a multi-user wallet on a single EOA (sk, pk). The wallet maintains a\nfinite set of subaccounts U ={u\n1\n,...,u\nn\n} and a set of assets A (e.g., ERC-20).\nA subaccount u ∈ U has authority over an amount x of asset α ∈ A iff it can\nobtain a signature from the global sk via the enclave; sk resides only inside a TEE\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets5\nand is never directly accessible. We give the intuitive model here and formalize\nit in Section ??.\nInternally, PASS tracks balances with a map L : U ×A →Z\n≥0\n(accessed\nvia L[u][α]), an Inbox multiset I of unclaimed deposits (α,x,m), an Outbox\nFIFO queueO of pending on-chain actions (α,x, extDst,ν) together with a global\nnonce ν ∈N, and an append-only provenance logH. The core principles of PASS,\nas shown in Figure ?? are as follows:\n1. Access follows provenance. A unit of value is usable by u only if there\nexists a custody chain in H from an external deposit to u. Informally,\nAllow(u,α,x) means balance x is reachable for u via provenance in H. This\nimplies consistency : for every α, the total internal balance equals the on-\nchain balance at pk, i.e.,\nP\nu∈U\nL[u][α] = B\non\n(α). Incoming deposits (α,x,m)∈\nI are “wrapped” and must be explicitly claimed before use by the sender\naddress.\n2. Off-chain privacy. Internal transfers u→ v update only L and H; they do\nnot touch O or the on-chain balance B\non\n, so internal flow is invisible and\nfee-less.\n3. First-come, first-served. Outbox transactions are sequenced by a FIFO queue,\nwhich maintains and increments a global nonce ν and directly sends enclave-\nsigned transactions to a RPC node to prevent nonce conflicts and replay\nattacks.\nOrganizational Ownership Model. PASS operates under an organizational own-\nership model, where an entity such as a company, individual, or DAO manages\nshared control over blockchain assets. We detail the threat model in Section ??.\nInbox-Outbox Gateway External senders transfer assets to pk, creating Inbox en-\ntries (α,x,m)∈I. A user performs claim(u,α,x,m) to move value intoL[u][α],\nconceptually “wrapping” the deposit. To withdraw or interact with a contract,\na subaccount first performs an internal transfer to the Outbox, which enqueues\n(α,x, extDst,ν); the enclave then signs the concrete transaction with sk and im-\nmediately broadcasts it, incrementing ν. The FIFO discipline and global nonce\nserialize actions and prevent races and double-spends. Because subaccounts never\nreceive pre-signed transactions, pre-signing misuse is mitigated.\nComposable policy scheme. Deposits are claims fromI; internal transfers require\nAllow(u,α,x) and update (L,H); withdrawals are internal transfers toO followed\nby submission. Additional constraints (eg., RBAC or ABAC checks, whitelists\nand blacklists) can be incorporated as conjuncts to Allow without changing the\nprovenance-centric rule or its consistency and privacy effects.\n3.2 Formal Model\nWe formalize PASS as a transition system in Lean 4\n3\n, an interactive theorem\nprover with a rich dependent type system [?], suitable for policy verification (eg.,\n3\nLean 4 model: https://github.com/pass-wallet/pass-lean4-proofs\n6J. Yu\nAWS Cedar [?]). In this section, we introduce the formal system we modeled in\nlean, and in Section ?? we will discuss security invariants modeled. An extended\ndiscussion of our formal verification system can be found in Appendix ??.\nState. A wallet state is S =\n\u0000\npk, sk,ν,I,O,L,H\n\u0001\nwhere (pk, sk,ν) are the EOA\npublic key, private key (generated and held in the TEE), and global nonce; I\nand O are Inbox and Outbox; L is the internal balance map L[u][α] ∈Z\n≥0\n;\nandH is the provenance history. For privacy arguments we also use the external\nview W\npub\n= (pk,O,A), where O contains the Outbox queue and nonce and A\nrecords total on-chain balances by asset.\nTransitions. Operations op∈ T update S with type-checked rules: InboxDeposit\nadds an unclaimed (α,x,m) to I; ClaimInbox moves (α,x,m) from I to L[u][α]\nand appends toH; InternalTransfer moves value between subaccounts; Withdraw\ndebits L[u][α], enqueues (α,x, extDst,ν) in O, and logs; SignGSM authorizes\ndomain-scoped signable messages. A representative rule is:\n\u0000\npk, sk,ν,I,O,L,H\n\u0001\ntransfer(α,x,u\ns\n,u\nr\n)\n−−−−−−−−−−−→\n\u0000\npk, sk,ν,I,O,L\n′\n,H\n′\n\u0001\nwith\nif L[u\ns\n][α] < x or ¬checkAllow(u\ns\n,α,x,H) then ⊥;\nL\n′\n[u\ns\n][α] =L[u\ns\n][α]− x, L\n′\n[u\nr\n][α] =L[u\nr\n][α] + x;\nH\n′\n=H\n\f\n\f\n\u0000\nop = transfer,α,x,u\ns\n,u\nr\n\u0001\n.\nHere checkAllow queries provenance inH and can be extended with auxiliary\nconstraints such as user whitelists or blacklists, without changing the core rule.\nFigure ?? provides a formal specification of the methods in a PASS wallet.\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets7\nPASS Wallet Management Functionality F\nΣ\nPASS\nfor wallet W\nGlobal State:\npk : public address (EOA)\nsk : private key (in TEE)\nν: global nonce for on-chain transactions\nI (Inbox): set of unclaimed deposits (α : asset,x : amount,m : depositId)\nO (Outbox): FIFO queue (α,x, extDst,ν)\nL (Asset Ledger): internal map L[u][α]∈ Z\n≥0\n, where u is each user’s ID in the system\nH (Provenance History): a list of transaction records appended whenever ClaimInbox,\nInternalTransfer, or Withdraw is invoked\nCreatePassWallet (creator ):\nI← ∅, O← ∅, L←{}; ν← 0\n(pk, sk )← TEE\nKeyGen()\nReturn new W with S =\n\u0000\npk, sk,ν,I,O,L,H\n\u0001\nand reference to creator\nInboxDeposit (α,x,m) from external P :\nI ← I ∪ {(α,x,m)}\nReturn success\nClaimInbox (α,x, depositId) from u:\nIf no (α,x,m) with depositId in I, return ⊥\nRemove (α,x,m) from I\nL[u][α]←L[u][α] + x\nH←H| (op = claim,α,x, depositId,u)\nReturn success\nCheckAllow (u\nsend\n,α,x,H):\nIf H.GetProvenance(α, u\nsend\n)≥ x,\nreturn true; else return false\nInternalTransfer (α,x,u\nsend\n,u\nrecv\n):\nIf L[u\nsend\n][α] < x or ¬checkAllow(u\nsend\n,α,x,H), return ⊥\nL[u\nsend\n][α]←L[u\nsend\n][α]− x\nL[u\nrecv\n][α]←L[u\nrecv\n][α] + x\nH←H\n\f\n\f\n\u0000\nop = transfer,α,x,u\nsend\n,u\nrecv\n\u0001\nReturn success\nWithdraw (α,x,u\nsend\n, extDst):\nIf L[u\nsend\n][α] < x or ¬checkAllow(u\nsend\n,α,x,H), return ⊥\nL[u\nsend\n][α]←L[u\nsend\n][α]− x\nO ←O∪{(α,x, extDst,ν)}\nH←H | (op = withdraw,α,x,u\nsend\n, extDst)\nReturn success\nSignGSM (dom, msg,u):\nIf u lacks sign-right for (dom, msg), return ⊥\nσ ← (sk, msg)\nReturn σ\n(Outbox Processing) (periodic or on demand):\nIf O ̸= ∅, dequeue (α,x, extDst,ν)\nBuild tx τ : transfer x of α to extDst, nonce = ν\nσ ← (sk, τ ); broadcast (τ,σ)\nν←ν + 1\nReturn broadcasted + txHash\nFig. 3. Formal Model of PASS wallet functionality, including CreatePassWallet for\ninitializing a fresh instance. On creation, pk is set to a chosen EOA address eoa, the\nTEE generates a hidden private key sk , and global data structures are initialized.\nExternal deposits enter I (Inbox), while subaccount transfers update L (Ledger) off-\nchain. Withdrawals queue items in O (Outbox), and GSM operations are signed using\nsk .\n3.3 Asset Model and General Signable Messages\nPASS provides an authorization scheme over a heterogenous set of assets A, in-\ncluding fungible tokens, such as ether and ERC-20 tokens, ERC-721 non-fungible\ntokens, and “general signable messages” across a variety of DApps for sign-in\n8J. Yu\nand identity verification. Each asset α ∈ A has a well-defined custody path in\nthe provenance log H, and a subaccount u ∈ U has usable balance x of α iff\nAllow(u,α,x) holds.\nToken assets. For token assets such as ether, ERC-20, and ERC-721, deposits are\ncaptured as Inbox entries (α,x,m)∈I. Claims allocate balance intoL[u][α], in-\nternal transfers updateL andH privately, and withdrawals enqueue (α,x, extDst,ν)\ninto O for enclave signing and on-chain broadcast, ensuring consistency where:\n∀α∈A\ntokens\n:\nX\nu∈U\nL[u][α] = B\non\n(α, pk).\nIn particular, ERC-721 tokens are modeled as unitary balances (x ∈ {0, 1})\nwhose transfers preserve uniqueness under provenance.\nGeneral Signable Messages (GSMs). In addition to on-chain assets, wallets often\nsign arbitrary messages, such as for EIP-4361 [?] logins and off-chain DAO votes\n[?]. PASS models these as a special class A\nGSM\nof virtual assets. Each GSM\nasset is scoped to a domain dom, so holding α = (dom) represents authority to\nsign messages from that domain. A signature operation:\nSignGSM(u, dom,m)7→ σ\nis permitted iff Allow(u, dom, 1) holds in H. At key generation, the wallet\ncreator is endowed with default signing authority over all domains, represented\nas an initial allocation of every α = (dom)∈A\nGSM\nto the root subaccount. These\ndomain assets can be internally transferred to delegate signing authority. Thus\nprovenance of GSMs begins at the owner and flows through transfers, providing\na well defined provenance path in H as with token assets.\nBy treating both tokens and GSMs as types of elements ofA, PASS provides\na unified provenance rule for subaccount authorization. A subaccount cannot\nspend an ERC-20 token, transfer an NFT, or sign a domain message unless it\npossesses the corresponding asset under L and H. This unified authorization\nscheme allows for fine-grained delegation, (eg., giving u rights over example.com\nwhile withholding ERC–20 funds) and consistent enforcement across on-chain\nand off-chain actions.\n4 Properties of PASS\n4.1 Threat Model\nPASS assumes an organizational ownership model, where a single entity, such\nas a company, individual, or DAO manages the EOA (pk,sk), brokers access\nbetween many users in that entity, and chooses the TEE infrastructure vendor\n(eg. AWS Nitro, dstack Intel TDX, self-hosted hardware). This model is typical\nfor use cases such as private payroll, supply chains, and AI delegation described\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets9\nin Section ??. Protected assets in PASS include the private key sk, the balance\nledger L and provenance log H, and the correctness of Allow(u,α,x) for all\nu∈ U,α∈A,x. In our model, we make the following trust assumptions:\n1. TEE integrity. Hardware isolation is sound; sk never leaves the enclave.\nRemote attestation guarantees that the enclave runs the genuine PASS bi-\nnary.\n2. Cryptography. Standard primitives (signatures, hash functions, PRFs) are\nsecure against polynomial-time adversaries.\n3. Governance majority. The deploying entity holds majority control in the\ngovernance mechanism (via DAO vote or admin privileges), ensuring it can\ninvoke the blockchain-governed KMS for MPC-based key recovery and trig-\nger fallback contracts when needed.\nAdversary Model. An adversaryA may control the host OS and network, observe\nor modify all communication with enclaves, and submit arbitrary transaction\nrequests. In particular, A may attempt to:\n– Exploit software bugs in the PASS implementation or TEE runtime,\n– Forge or replay transactions to break consistency of H,\n– Subvert provenance by violating Allow(u,α,x)\nThreats Out of Scope. On the other hand, PASS does not protect against:\n– Physical compromise of TEE hardware (tampering, microarchitectural side-\nchannels, chip decapsulation),\n– Supply-chain backdoors in TEE manufacturing,\n– Fully malicious operators with unrestricted physical access.\nThese are excluded because the organizational model assumes controlled facilities\nand vetted hardware.\nSecurity Goals. Given the assumptions above, PASS guarantees:\n1. Integrity:\nP\nu∈U\nL[u][α]≤ extDep(α) for all α, i.e., no assets can be created\nor double-spent internally.\n2. Correctness: If Allow(u,α,x) holds, then u can eventually realize x via\nWithdraw.\n3. Privacy on-chain: InternalTransfer operations do not affect externalTrace(W ),\nand to external observers, a PASS wallet is indistinguishable from an EOA.\n4. Liveness: For any authorized op ∈ Ops, if one enclave and quorum remain\nhonest, then ∃τ s.t. Exec(c, op) =⊤ within τ\n4.2 Privacy and Safety\nAfter establishing the threat model of PASS, we will address the central pri-\nvacy and safety guarantees. We sketch three central lemmas here, and create\nmechanized proofs in Lean, discussed in Appendix ??.\n10J. Yu\nProposition 1 (Internal Transfer Privacy). If two public states W\n1\n,W\n2\nshare the same pk, identical Outbox (T,ν), and equal per-asset totals in A, then\nexternalTrace(W\n1\n) = externalTrace(W\n2\n).\nProof Sketch. InternalTransfer updates only (L,H), never O or total on-chain\nbalances. OutboxProcessing in Figure ?? emits on-chain actions solely from O\n(lines 2–4), hence the trace depends only on O.\nCorollary: EOA indistinguishability. If W\npass\nand W\neoa\nshare the same pk,\nOutbox, and per-asset totals, then\nexternalTrace(W\npass\n) = externalTrace(W\neoa\n).\nThus, from an external observer’s perspective, a PASS account is indistinguish-\nable from a standard EOA: internal transfers leave no observable footprint.\nProposition 2 (Asset Accessibility). For any asset α, letting L = {u |\nL[u][α] > 0},\nX\nu∈L\nL[u][α] = totalBalance(α),\nand each u∈ L can spend its full balance subject to checkAllow.\nProof Sketch. ClaimInbox creditsL; InternalTransfer preserves the sum over u;\nWithdraw debitsL and enqueues toO, which OutboxProcessing realizes on-chain.\ncheckAllow enforces reachability from provenance in H.\nProposition 3 (Provenance Integrity). Let extDep(α) be net external de-\nposits (deposits minus realized withdrawals). For all reachable states,\nX\nu\nL[u][α] ≤ extDep(α).\nProof Sketch. Induct on transitions. InboxDeposit increases extDep only; Claim-\nInbox moves already-deposited value into L; InternalTransfer conserves the sum\nover u; Withdraw decreases the sum, and after OutboxProcessing broadcasts,\nextDep is reduced accordingly.\nGeneral signable messages (GSM). Model GSM rights as a domain-scoped vir-\ntual asset class A\nGSM\n. Let α = (dom)∈A\nGSM\nand permit\nSignGSM(u, dom,m) iff Allow(u,α, 1).\nThen (P2)–(P3) lift to GSM: there is always at least one domain signer, and\nGSM “balances” obey provenance conservation under transfers in H.\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets11\n4.3 Liveness\nWe define liveness as the property that any authorized operation remains even-\ntually executable, despite enclave crashes, vendor compromise, or partial gover-\nnance failure. Our model assumes deployment of PASS access logic on dstack,\nimplemented in Section ?? and detailed in Appendix ??.\nLet E denote active enclaves, C containerized wallet backends, and P gover-\nnance policies. Each container c∈C stores sealed state\nσ\nc\n=⟨S,k\nc\n, meta⟩ with S = (pk, sk,ν,I,O,L,H),\nwhere k\nc\n= Derive(K,c) is derived from an MPC-managed KMS and meta records\nattestation. An operation op ∈ Ops (deposit claim, transfer, withdrawal) ex-\necutes as: Exec(c, op) = ⊤ iff Attested(c)∧ Γ (S), where Attested(c) checks σ\nc\nagainst registry R and Γ is the quorum predicate over P. To ensure vendor-\nagnostic portability, state migration μ :E →E satisfies\n∀e\ni\n,e\nj\n∈E, e\nj\n.decrypt(σ\nc,e\ni\n,k\nc\n) = σ\nc,e\ni\n,\nTheorem 1 (Liveness Theorem). If (i) the MPC KMS tolerates f\nKMS\nfaults\nin a t-of-n threshold, (ii) governance quorums are f\ngov\n-resilient, and (iii) at least\none enclave is uncompromised, then every op∈ Ops executes within bounded time\nτ :\n∀op∈ Ops, ∃τ ≥ 0 : Exec(c, op) =⊤.\nProof Sketch. Progress follows from three guarantees: (1) the MPC KMS ensures\nk\nc\nis always recoverable under threshold availability; (2) Γ encodes quorum rules\nthat eventually relax after timeout ∆t, ensuring some subset S satisfies Γ (S) =\n⊤; (3) migration μ allows any enclave to re-host σ\nc\n, preventing vendor lock-in or\nenclave failure from blocking execution. Algorithm ?? formalizes recovery and\nexecution under these assumptions.\nAlgorithm 1 RecoverAndExecute(c, op)\n1: Verify enclave e attestation Q\ne\nagainst R.\n2: Derive k\nc\n← Derive(K,c); decrypt σ\nc\n.\n3: if CompromiseDetected(e\n′\n) then\n4:Rotate k\nc\nand re-encrypt σ\nc\n.\n5: end if\n6: Ensure Γ (S) =⊤ for S ⊆P(c).\n7: Execute op; append to H.\nKey Properties. (1) Portability: any attested enclave can recover σ\nc\n, independent\nof vendor; (2) Monotonic Recovery: recovery steps form ρ :S →S with ρ(s)⪰ s;\n(3) Domain Continuity: certificates remain bound toR(c) under migration μ(c),\npreventing hijack or replay.\nImplementation details of container orchestration, attestation, and KMS pro-\ntocols are given in Appendix ??.\n12J. Yu\n5 Practical Implementations\n5.1 Prototype Implementations\nTo demonstrate feasibility, we have implemented a prototype of PASS that cap-\ntures the core architectural components.\n4\nThe prototype consists of:\n– Provenanced Access Model, the core PASS architecture outlined in Sec-\ntion ?? with the Inbox-Outbox structure, asset ledgers, and provenanced\nrule as a Rust executable.\n– Web Application Frontend, an AWS-hosted Typescript interface that\nallows users to deposit assets, initiate internal transfers, generate on-chain\ntransactions, and sign arbitrary messages on Ethereum Sepolia testnet.\n5\n– Multi-vendor TEE deployment, we deploy the PASS enclave executable\nin both AWS Nitro Enclaves and Intel TDX with the dstack framework.\nWe evaluate these two enclave deployments as complementary deployment\npaths, each with distinct tradeoffs.\nAWS Nitro Enclaves. In this design, PASS runs inside a Nitro enclave in the\nAWS cloud. The enclave executes the Inbox–Outbox logic, enforces provenance\nchecks, and signs transactions, while the provenance ledger is stored externally.\nNitro’s attestation and AWS integration simplify deployment, but reliance on a\nsingle vendor limits portability and concentrates trust. As a result, some guaran-\ntees of PASS, particularly liveness and asset accessibility, may be weaker under\nthis model.\nIntel TDX with dstack. dstack provides a portable, open-source runtime for\nTEEs across diverse hardware. PASS can be deployed on enclaves run by decen-\ntralized operators, with key material secured via MPC-based key management.\nBoth Inbox–Outbox logic and the provenance ledger execute inside dstack, pre-\nserving the full security properties of Section ?? and reducing vendor lock-in.\nThe tradeoff is added governance complexity over operator authorization and\npolicy enforcement.\n5.2 Performance Benchmarks\nTo evaluate PASS, we benchmarked both AWS Nitro Enclaves and Intel TDX\nbackends across common operations: balance queries, transfers, withdrawals,\nclaims, wallet creation, provenance queries, and an end-to-end workflow. Each\noperation was run 100 times over 10 trials per environment, measuring through-\nput in ops/sec. Both environments used identical 4-core, 2.5 GHz, 16 GB VMs\nto ensure fair comparison. Table ?? summarizes our results, with full details\navailable in Appendix ??.\n4\nPrototype can be found here: https://github.com/jayyu23/pass-wallet-app\n5\nWeb application: https://pass-wallet.jayyu.xyz/\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets13\nFig. 4. Internal PASS operation throughput (ops/sec) across AWS Nitro Enclaves\nand Intel TDX. All operations are in-memory state changes within the TEE with no\nblockchain interaction. Each value represents the average of 100 operations repeated\n10 times per environment.\nOperationAWS Nitro Intel TDX\nWallet Creation6,53114,970\nAccount Balance Queries530,943935,428\nInbox-to-Subaccount Claims14,85633,064\nInternal Subaccount Transfers32,95371,292\nWithdrawal Request Creation18,29139,702\nEnd-to-End Workflow\n6\n35,66378,433\nTransaction History Queries3,7577,685\nMulti-threaded Operations (5 threads)32,18955,124\nLarge Dataset Processing481724\nThe observed performance differences between AWS Nitro Enclaves and In-\ntel TDX primarily stem from their distinct hardware architectures. AWS Nitro\nEnclaves employ a disaggregated system design, where the host server and the\nTEE hardware are physically separated. Communication between the host and\nthe enclave occurs via vsock, and the enclave itself runs on a dedicated, lower-\nperformance coprocessor. In contrast, Intel TDX leverages a special instruction\nset to provide enclave functionality directly on the main processor, eliminating\nthe need for a separate coprocessor and avoiding the overhead of data transfer\nbetween disparate components. As a result, Intel TDX is able to deliver sig-\nnificantly higher throughput for in-enclave operations compared to AWS Nitro\nEnclaves, as reflected in our benchmark results.\nThese preliminary benchmarks show that both Nitro and TDX backends can\nsustain high throughput for critical wallet operations, confirming that PASS is\npractical for real-world deployment. Further evaluation of latency distributions,\nconcurrency scaling, and memory footprint is left for future work. [Jay: Make prose\nremarks on Liquefaction performance, and why PASS is better]\n6 Applications\nPASS is a powerful primitive that enables several classes of applications.\n[Jay: To clean up and think better on how to frame directions - maybe (1) delegating\nto AI agents, (2) private payroll and supply chain, (3) DAO voting, (3) cross chain bridge\n+ CLOB exchange. Maybe a small application table?]\nOrganizational Wallets and Institutional Custody. An organization (company,\nuniversity, DAO) often needs to manage a single blockchain address for branding\nor transparency reasons (e.g., stanford.eth) while delegating control to multi-\nple individuals internally. The university could maintain stanford.eth as the\nmain address, and issue sub-accounts [email protected], [email protected]\n14J. Yu\nCategoryApplicationContextPASS Enables\nDelegation\nAI Agents\nDelegation\nAI agents increasingly\ninteract with crypto\nassets and\nprotocols [?].\nScoped subaccounts holding limited\nfunds or domain-scoped signing rights;\ndelegate safely to agents without\nexposing the wallet’s root key; revoke\nby moving balances out.\nDAO VotingDAOs rely on\naddress-based voting\nand delegation [?].\nPrivate sub-delegation of voting rights,\nprovenance keeps delegation auditable\nwithin PASS. Can also domain-restrict\ndelegators to voting DApps only.\nSubdomain\nProfile Pages\nOrganizations map\nENS or sub-identities\nto individuals/teams.\nMultiple subaccounts under one public\nidentity (e.g., [email protected]);\nper-subaccount balances and signing\nscopes with internal provenance.\nEnterprise\nPrivate\nPayroll\nOn-chain payroll can\nleak sensitive\ncompensation data.\nSalary distribution via internal\ntransfers (gasless, private) with an\nauditable internal log; withdrawals\nbatch via Outbox when needed.\nCompliant\nOrganization\nWallets\nOrganizations have a\npublic address with\ninternal access control\nand BSA\nrecordkeeping [?].\nDepartment and individual\nsubaccounts with explicit budget\nallocations. Provenance-based asset\naccountability upon regulator request.\nPrivate\nSupply Chains\nMulti-party B2B\npayments often\nrequire confidentiality\nacross tiers.\nSubaccount-based vendor channels\nwith private internal netting; only net\nsettlements leave via Outbox, reducing\nleakage while retaining internal\nauditability.\nCross Chain\nCross-chain\nBridge\nBridges require\ncustodial control and\ncareful key\ngovernance [?].\nInbox/Outbox enforce provenance\nboundaries across chains; scoped\nsubaccounts for operators; FIFO nonce\nhandling to avoid race conditions.\nGasless CLOB\nExchange\nFrequent on-chain\norder placement is\ngas-heavy for users.\nInternalize order matching/settlement\nbetween subaccounts off-chain;\nperiodically net out via Outbox so end\nusers experience gasless trading.\nL2\nComposability\nRollups/L2s fragment\nassets and UX [?].\nTreat L2s (or other domains) as\nscoped subaccounts; balance privately\nacross internal ledgers; settle\nexternally only when crossing domains.\nFig. 5. Applications of PASS across delegation, enterprise, and cross-chain contexts.\nfor different departments or team members. Each person gets a sub-account with\ncertain assets allocated or certain transaction rights. They can transact inter-\nnally for accounting without fees, and when needed, withdraw funds to external\nvendors. The provenance log ensures every outgoing fund can be traced to which\ninternal sub-account, aiding accountability, while external parties only interact\nwith the official address.\nDelegating to AI or Smart Agents. As autonomous agents start managing crypto\nassets for trading or DAO governance, there is a need to constrain their access.\nAn AI agent could be given a sub-account that only holds limited funds or\ncertain asset types. The AI can operate freely within those bounds, but cannot\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets15\nexceed its allotted assets or misuse other wallet assets. If compromised, damage\nis capped to its sub-account. This is much safer than giving AI the keys to an\nentire wallet.\nOrganizational Privacy Enhancement. Within the organizational ownership model,\nPASS provides privacy benefits for legitimate internal operations. Because in-\nternal transfers are off-chain, organizations can maintain confidentiality around\ntheir internal fund allocations and departmental transfers while still providing\nfull transparency for external interactions. This is particularly valuable for or-\nganizations that need to balance internal operational privacy with external ac-\ncountability requirements. Unlike general privacy mixing systems, this applica-\ntion aligns with the organizational ownership model where the entity controlling\nthe TEE has legitimate oversight of all activities within the system.\nIntegration with Off-chain Scaling Solutions. The concept of segregating internal\ntransfers from on-chain actions is analogous to how rollups and sidechains work\n(off-chain transactions batched into occasional on-chain commitments). PASS\ncould potentially integrate with Layer-2 networks by treating a whole sidechain\nor rollup as a “sub-account” or by using PASS ’s provenance model to bridge\nassets. For example, depositing funds into a rollup could be managed via an\nInbox-like mechanism, and withdrawing via an Outbox, with PASS ensuring\nthat assets are not double-spent across L1 and L2. While speculative, modeling\na rollup’s internal accounts using PASS might provide a unified view of assets\nacross layers, or allow a user to move assets between L2s through an enclave\nwithout trusting a centralized exchange. This is an area for future exploration.\nOrganizational TEE Management. PASS’s security model assumes that orga-\nnizations have the capability to properly manage TEE infrastructure. While\nthis eliminates concerns about physical attacks (as organizations can implement\nappropriate security controls), it requires organizations to maintain proper op-\nerational security practices. Organizations must ensure TEE software integrity\nthrough remote attestation, implement secure key management policies, and\nmaintain appropriate governance frameworks. For organizations without suffi-\ncient technical expertise or security infrastructure, partnering with specialized\nTEE service providers may be necessary. This organizational responsibility rep-\nresents both a strength (simplified threat model) and a limitation (requires or-\nganizational technical capability) of the PASS approach.\n7 Future Work\n7.1 Composability and InterPASS Transactions\nWhile PASS provides privacy and provenance guarantees for a single wallet in-\nstance, an important question is how multiple PASS wallets may interact. This\nis important in supply-chain use cases where each PASS represents a single com-\npany in the supply chain.\n16J. Yu\nTrivially, PASS A can send an on-chain transaction from its Outbox to PASS\nB’s EOA account, and this will land in the Inbox of PASS B, ready to claim.\nHowever, this undermines the privacy guarantees that PASS offers at the EOA\nlevel, and is undesirable in cases where inter-organizational asset transfers con-\ntain sensitive information, such as order details.\nWe propose a non-trivial approach inspired by cross-Payment Channel Net-\nwork (PCN) protocols such as XTransfer [?]. We can treat each PASS instance\nakin to a PCN hub node, with state L and transaction history H. As with\nXTransfer, we can assume a star topology of PASS nodes, with a central PASS\nHub in communciation with all PASS nodes. The PASS Hub will aggregate all\nInterPASS transactions T := {(a\ni\n,x\ni\n,s\ni\n,r\ni\n)}\nn\ni=1\n, where (a\ni\n,x\ni\n,s\ni\n,r\ni\n) represent\nthe asset, amount, sender, and receiver, each signed by the s\ni\nOutbox.\nThe Hub aggregates these signed payment intents, computes a netted settle-\nment plan S, and coordinates a secure multi-party update protocol to commit\nthe resulting balances, similar to Thora [?]. In the optimistic case, this process\ncompletes entirely off-chain, and each participant’s balance is updated in the\nPASS ledger without revealing the underlying transaction graph. If a dispute or\nfailure occurs, any participant may trigger an on-chain enforcement transaction\nthat finalizes S atomically via the direct transfer mechanism, thus guaranteeing\nsafety.\nThis approach leverages PASS ’s provenance and state design to make each\ninstance an atomic node in PCN-style systems like X-Transfer. Here, we outline\nhow PASS Hubs can enable confidential, auditable cross-organization transfers,\nwhile full formal specification and protocol implementation is deferred for future\nwork.\n7.2 Instantiation on zkVM\nZero-knowledge virtual machines (zkVMs) provide a proving environment where\narbitrary state machines can run with strong correctness guarantees [Jay: cite].\nBy producing a succinct proof π of execution, zkVMs offer integrity assurances\nsimilar to TEEs but without hardware attestation. This makes them especially\nsuited for financial custody and inter-organizational accounting, where external\nverifiability and regulator-grade auditability are critical.\nTo realize PASS within a zkVM, transaction requests are first queued outside\nof the proving environment. Once a batch is formed, the zkVM program takes\nas its private inputs the prior batch’s commitments of the ledger L and prove-\nnance log H, the set of state transitions in the current batch, including inbox\nI deposits and outbox O withdrawals, and the proposed new commitments for\nL and H. The zkVM then replays the computation: it begins from the previous\nroots, applies all queued transitions in sequence, and recomputes both balances\nand provenance entries. The proof π attests that these recomputations match\nthe declared new commitments and that all outbox deltas are consistent. A min-\nimalist verifier contract on chain simply checks π, updates the recorded roots,\nand enforces outbox execution. In this way, the privacy and provenance guar-\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets17\nantees of the original PASS design are preserved while augmenting them with\nrigorous computational proofs of correctness.\nThis formulation aligns with the Chainless stack architecture [?], which em-\nphasizes clear separation of execution, trust, bridging, and settlement. By sit-\nuating zkVM-based PASS execution within such a layered model, integration\nwith external systems can be achieved in a modular and interoperable manner.\nWe defer full formal implementation and specification for future work.\nFig. 6. PASS instantiation inside a zkVM: Inbox I and Outbox O transitions are\napplied to the Ledger L and Provenance H, producing new state commitments. The\nzkVM outputs a proof π, which the on-chain verifier checks before updating roots and\nenforcing outbox operations.\n7.3 Expansion of Formal Model and Further Benchmarks\n[Jay: TODO]\n18J. Yu\n8 Conclusion\nWe presented PASS, a Provenanced Access Subaccount System, as a new wallet\narchitecture that enforces access by provenance rather than by identity or role.\nThe Inbox–Outbox mechanism ensures all assets have a verifiable lineage, while\ninternal transfers remain private and indistinguishable from a standard EOA\naccount.\nOur contributions are threefold: (i) a formal model in Lean 4 proving pri-\nvacy, accessibility, and provenance integrity; (ii) a working prototype with en-\nclave backends on AWS Nitro Enclaves and Intel TDX via dstack, integrated\nwith WalletConnect; and (iii) initial benchmarks showing the feasibility of high-\nthroughput operation. These results demonstrate that provenance-based control\ncan be realized today with mainstream blockchain tools.\nLooking forward, richer evaluations across multi-vendor TEEs, integration\nwith zero-knowledge VMs, and exploration of organizational and agent-based\ncustody are promising directions. By combining rigorous formal guarantees with\ndeployable prototypes, PASS advances the design space between strict self-\ncustody and flexible shared access, offering a path toward practical, privacy-\npreserving wallet security.\nA Formal Verification\nWe consider the formal model introduced in Section ?? of PASS as a state\nmachine in Lean4. Our goal is to prove that, under the PASS design, several\ncritical security properties always hold. We outline these properties and our\napproach to verifying them.\nA.1 Property: Privacy of Internal Transfers\nIn the PASS design, the InternalTransfer operation updates only the off-chain\nledgerL and the provenance historyH. It never modifies the OutboxO, meaning\nthere is no on-chain transaction triggered by an internal transfer. Consequently,\nexternal observers see no change in on-chain state. We formalize this by consid-\nering the on-chain view that an external party has for a given PASS Wallet. We\ncan model this visible on-chain state as a triple:\nW\npub\n=\n\u0000\npk, O, A\n\u0001\n,\nwhere:\npk is the externally owned account (EOA) address,\nO = (T,ν) is the external view of the outbox, where T is a list of enqueued\ntransactions and ν is a nonce,\nA is the external view of the Asset ledgerL, containing a list of asset entries,\neach of the form (α,x) with a unique identifier α and total balance x.\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets19\nExternal Trace. The external trace of a PassAccount state W\npub\nis the list of\nexternally visible actions, obtained by mapping each transaction in the outbox\nT to an on-chain action:\nexternalTrace(W\npub\n) =\n\b\noutboxTx(t) | t∈ T\n\t\n.\nNo internal transfers appear in externalTrace(·).\nStates That Differ Only by Internal Transfers. We say that two PassAccount\nstates W\n1\n= (pk\n1\n,O\n1\n,A\n1\n) and W\n2\n= (pk\n2\n,O\n2\n,A\n2\n) differ only by internal trans-\nfers if:\n1. pk\n1\n= pk\n2\n,\n2. O\n1\n= O\n2\n(i.e. both the list of outbox transactions and the nonce are the\nsame),\n3. For every asset identifier α, the total balance of that asset in A\n1\nequals the\ntotal balance of the same asset in A\n2\n.\nLetting getAsset(W,α) return the asset α within state W or ⊥, we require ∀α:\ntotalBalance\n\u0000\ngetAsset(W\n1\n,α)\n\u0001\n= totalBalance\n\u0000\ngetAsset(W\n2\n,α)\n\u0001\n.\nTheorem 2 (Privacy of Internal Transfers). If two PassAccount states W\n1\nand W\n2\ndiffer only by internal transfers, then their externally visible traces are\nidentical:\nexternalTrace(W\n1\n) = externalTrace(W\n2\n).\nProof. By assumption, O\n1\n= O\n2\n. Hence both states have the same outbox trans-\naction list T . Since\nexternalTrace(W\ni\n) = map\n\u0000\noutboxTx, T\ni\n\u0001\nfor i∈{1, 2},\nand T\n1\n= T\n2\n, it follows that externalTrace(W\n1\n) and externalTrace(W\n2\n) are iden-\ntical.\nThus, any sequence of purely internal transfers, changing only the private ledger\nL in PASS, is invisible to an external observer, preserving the privacy of how\nassets move within the wallet.\nA corollary of this Internal Transfer property is that a PASS account is\nindistinguishable from a regular EOA account.\nCorollary 1 (Indistinguishability from EOA). Let W\npass\nbe a PASS state\nthat (i) has the same public key pk, (ii) the same outbox, including nonce and\ntransaction list, and (iii) the same total balances of each asset as a reference\nEOA state W\neoa\n. Then\nexternalTrace(W\npass\n) = externalTrace(W\neoa\n).\nIn particular, an external observer cannot distinguish W\npass\nfrom W\neoa\n.\nProof. By assumption, the only potential differences betweenW\npass\nandW\neoa\nlie\nin internal ledger details. From Theorem 1, such internal transfers do not affect\nthe externally visible outbox transactions or total on-chain balances. Thus, their\nexternal traces coincide, and W\npass\nis indistinguishable from W\neoa\n.\n20J. Yu\nA.2 Property: Asset Accessibility\nIn addition to keeping internal transactions private, PASS should ensure that for\nevery asset in the system, there exists some sub-account that can access it and\nwithdraw it from the system. This prevents a situation where funds get ”stuck”\nwithout any reachable key or policy to move them. We define asset accessibility\nas follows:\nTheorem 3 (Asset Accessibility). For any PASS account W and asset iden-\ntified by α, there exists a list of addresses L such that:\n1. For every address u∈ L, the user can access their full balance:\ncheckBalance(s,α,u, balance(u)) = true\n2. The sum of all accessible balances equals the total balance of the asset:\nX\nu∈L\nL[u][α] = totalBalance(α)\nProof. We construct L as the set of all addresses with non-zero balances in the\nbalance map for α:\nL ={u|L[u][α] > 0}\nFor the first property, given any u∈ L, the definition of checkBalance verifies\nif the user has sufficient balance for the specified amount. When checking against\nthe user’s own balance, this is trivially satisfied since L[u][α]≥L[u][α] for all u.\nFor the second property, we observe that totalBalance is defined as the sum\nof all balances in the asset’s balance map:\ntotalBalance(α) =\nX\nu∈L\nL[u][α]\nBy construction, L contains the only nonzero values u∈L, so:\nX\nu∈L\nL[u][α] = totalBalance(α)\nTherefore, both properties hold for our constructed list L.\nWe can prove a similar trait for General Signable Messages, showing that for\nany inbound GSM, there is some subaccount signer that has access to it.\nTheorem 4 (GSM Accessibility). For any GSM and domain, there exists a\nuser with signing access to that domain.\nProof. For any domain d, we can directly construct a user u who has signing\naccess to d as follows:\nu = getSigner(d)\nBy definition, getSigner returns either:\n– A specifically assigned signer if one exists in the domain-address map, or\n– The default signer otherwise\nTherefore, every domain is guaranteed to have at least one user with signing\naccess, ensuring no GSM domain becomes inaccessible.\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets21\nA.3 Property: Provenance Integrity\nProvenance integrity specifies that every asset held by any sub-account in PASS\nmust have an origin traceable to an external deposit into the Inbox. At any\nstate of the system, for each asset entry in a sub-account’s balance, we can find\na sequence of internal transfers that leads back to an Inbox deposit from an\nexternal address. This property ensures no sub-account can conjure funds from\nnothing, such as through double-spending or inflation within the system, and\nthat the internal ledger is consistent with on-chain reality. In Lean, we model\nthe state of the PASS wallet including Inbox, Outbox, and all sub-accounts and\nprove an invariant that whenever a sub-account has x units of asset α, the global\nstate contains a record of at least x units of α having been deposited, minus any\nthat have been withdrawn.\nTheorem 5 (Provenance Integrity).\nFor any PASS account S =\n\u0000\npk, sk,ν,I,O,L,H\n\u0001\nand any asset α, the total\namount of α held across all subaccounts can never exceed the total amount of\nexternal deposits (minus any that have already been withdrawn). Formally,\nX\nu∈U\nL[u][α] ≤ externalDeposits(α),\nwhere U is the set of subaccounts in the system, and externalDeposits(α) is\nthe net total of asset α that has been introduced into the wallet from outside\naddresses, recorded in the inbox I.\nProof. We model the system’s state (pk, sk,ν,I,O,L,H) as in Figure ??, includ-\ning the Inbox I, Outbox O, and the internal ledger L. We define a provenance\nrecord P (α,u) that captures the total amount of asset α subaccount u is autho-\nrized to hold, based on Inbox claims and internal transfers.\nBase Case: Immediately after CreatePassWallet, no assets have been de-\nposited, and no subaccount balances exist:\n∀u, L[u][α] = 0, ∀α, externalDeposits(α) = 0.\nHence,\nX\nu∈U\nL[u][α] = 0 ≤ 0 = externalDeposits(α).\nInductive Step: Assume the invariant holds after n− 1 operations. We prove it\nremains valid after the nth operation, for each possible type of operation:\n(1) External Deposit: Suppose an amount x of asset α is deposited into the\nwallet:\nexternalDeposits(α) ← externalDeposits(α) + x.\nNo subaccount balances L[u][α] change. Thus, the left side of our inequality\n(sum of subaccount balances) is unchanged, while the right side strictly\nincreases by x, so the invariant continues to hold.\n22J. Yu\n(2) Inbox Claim: If subaccount u claims amount x of asset α from the Inbox\nI:\nL[u][α] ← L[u][α] + x, P (α,u) ← P (α,u) + x.\nSince x was already accounted for in externalDeposits(α) (but not yet allo-\ncated to any subaccount), the total subaccount balances remain≤ externalDeposits(α).\n(3) Internal Transfer: If subaccount u\n1\ntransfers x of α to subaccount u\n2\n:\nL[u\n1\n][α] ← L[u\n1\n][α]− x, L[u\n2\n][α] ← L[u\n2\n][α] + x,\nand P (α,u\n2\n) increases by x. Because the sum of all subaccount balances\ndoes not change, our invariant is preserved.\n(4) Withdrawal: If subaccount u withdraws x of α:\nL[u][α] ← L[u][α]− x,\nwhich reduces the total subaccount balances. Since externalDeposits(α)\nremains unchanged (assets have simply exited the wallet), the inequality still\nholds.\nThus, by induction over all possible operations,\nX\nu∈U\nL[u][α] ≤ externalDeposits(α)\nfor every reachable state. No subaccount can create new assets out of nothing,\nand all assets in the system are fully accounted for by provenanced deposits.\nB Dstack Architecture and Execution Model\nB.1 Component Overview\n– Dstack-OS: Minimal Linux-based VM image with a verifiable boot chain.\nMeasures bootloader, kernel, root filesystem (RootFs) via RTMR registers.\nIntegrates dm-verity for data integrity and monotonic counters for anti-\nrollback.\n– Dstack-KMS: Blockchain-governed MPC network for key derivation and\nrotation. Provides:\nk\nc\n= HMAC\nk\nroot\n(c\nid\n),\nk\nTLS\n= ECDSA(k\nroot\n).\nRotation is triggered via governance (t-of-n threshold).\n– Dstack-Gateway/Ingress: TLS termination inside TEEs, ZT-TLS bind-\ning X\nc\nto R(c), enabling verifiable HTTPS ingress.\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets23\nB.2 Governance Layer\nTwo contracts form the trust base:\n– KmsAuth: Global registry of KMS nodes and application digests.\n– AppAuth: Per-application contract specifying quorum rules, allowed image\nhashes, and authorized enclaves.\nB.3 Workflow Phases\n1. Attestation: Enclave e produces quote Q\ne\n; verified against R.\n2. Secret Provisioning: MPC nodes compute k\nc\n, release to e if Q\ne\nis valid.\n3. Container Launch: Dstack-OS mounts RootFs, decrypts state σ\nc\nwith k\nc\n.\n4. Ingress Binding: TLS certificate X\nc\ngenerated inside e; bound to R(c).\n5. Audit Logging: Migration, key rotation, and governance events appended\nto H.\nB.4 Fault Tolerance\n– Vendor failure: μ enables re-deployment across Intel/AMD TEEs.\n– KMS compromise: key rotation via MPC thresholds restores forward/backward\nsecrecy.\n– Governance deadlock: ∆t fallback in Γ ensures quorum reduction and progress.\nB.5 Liveness Proof Sketch\nCombining MPC-based key recovery, quorum fallback, and portable containers\nyields:\n∀op∈O\nc\n,Pr[Exec(c, op) =⊤] = 1\nunder assumptions of f -resilient MPC nodes and at least one uncompromised\nTEE instance.\nC Detailed Benchmark Results\nThis appendix provides comprehensive benchmark statistics for both AWS Nitro\nEnclaves and Intel TDX environments. All operations are internal PASS state\nchanges that occur within the TEE with no blockchain network interaction.\nEach operation was executed 100 times per trial, with 10 independent trials\nper environment. The tables below show summary statistics including mean,\nstandard deviation, and range.\n24J. Yu\nTable 1. AWS Nitro Enclaves benchmark statistics (ops/sec) across 10 trials\nOperationMean Std Dev Min Max\nWallet Creation6,5315315,4467,042\nAccount Balance Queries530,943675 530,216 531,915\nInbox-to-Subaccount Claims14,856476 14,326 15,504\nInternal Subaccount Transfers32,9531,322 31,447 35,088\nWithdrawal Request Creation18,2911,254 15,873 19,608\nEnd-to-End Workflow35,6636,234 21,739 40,650\nTransaction History Queries3,757453,6503,802\nMulti-threaded Operations (5 threads) 32,189884 31,200 34,364\nLarge Dataset Processing48113467497\nTable 2. Phala dStack benchmark statistics (ops/sec) across 10 trials\nOperationMean Std Dev Min Max\nWallet Creation14,9704,6528,69624,390\nAccount Balance Queries935,428338,450 383,142 1,470,588\nInbox-to-Subaccount Claims33,0645,197 25,44541,667\nInternal Subaccount Transfers71,29217,623 47,170 101,010\nWithdrawal Request Creation39,7027,434 29,15551,813\nEnd-to-End Workflow78,43317,403 59,524 110,497\nTransaction History Queries7,6858726,4528,929\nMulti-threaded Operations (5 threads) 55,12416,744 28,32981,301\nLarge Dataset Processing72481636893\nC.1 AWS Nitro Enclaves Results\nC.2 Intel TDX Results\nC.3 Performance Analysis\nThe statistical analysis reveals several key insights about PASS’s internal oper-\nation performance:\n– Performance Consistency: AWS Nitro Enclaves demonstrate superior\nconsistency with lower standard deviations across all operations. The co-\nefficient of variation ranges from 0.1% (Account Balance Queries) to 17.5%\n(End-to-End Workflow).\n– Peak Performance: Intel TDX achieves higher mean throughput but with\nsignificantly greater variance. Standard deviations are 10-500x larger than\nNitro, indicating less predictable performance.\n– Production Considerations: These internal operation benchmarks demon-\nstrate PASS’s ability to handle thousands of wallet operations per second\nwithin the TEE, with the actual deployment bottleneck being blockchain\ntransaction submission rather than internal processing.\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets25\nThe statistical summary confirms that both platforms support practical PASS\ndeployment, with Nitro offering predictable performance and Intel TDX provid-\ning higher peak throughput at the cost of consistency.\nD Design Extensions\nD.1 Composability and InterPASS Transactions\nWhile PASS provides privacy and provenance guarantees for a single wallet in-\nstance, an important question is how multiple PASS wallets may interact. This\nis important in supply-chain use cases where each PASS represents a single com-\npany in the supply chain.\nTrivially, PASS A can send an on-chain transaction from its Outbox to PASS\nB’s EOA account, and this will land in the Inbox of PASS B, ready to claim.\nHowever, this undermines the privacy guarantees that PASS offers at the EOA\nlevel, and is undesirable in cases where inter-organizational asset transfers con-\ntain sensitive information, such as order details.\nWe propose a non-trivial approach inspired by cross-Payment Channel Net-\nwork (PCN) protocols such as XTransfer [?]. We can treat each PASS instance\nakin to a PCN hub node, with state L and transaction history H. As with\nXTransfer, we can assume a star topology of PASS nodes, with a central PASS\nHub in communciation with all PASS nodes. The PASS Hub will aggregate all\nInterPASS transactions T := {(a\ni\n,x\ni\n,s\ni\n,r\ni\n)}\nn\ni=1\n, where (a\ni\n,x\ni\n,s\ni\n,r\ni\n) represent\nthe asset, amount, sender, and receiver, each signed by the s\ni\nOutbox.\nThe Hub aggregates these signed payment intents, computes a netted settle-\nment plan S, and coordinates a secure multi-party update protocol to commit\nthe resulting balances, similar to Thora [?]. In the optimistic case, this process\ncompletes entirely off-chain, and each participant’s balance is updated in the\nPASS ledger without revealing the underlying transaction graph. If a dispute or\nfailure occurs, any participant may trigger an on-chain enforcement transaction\nthat finalizes S atomically via the direct transfer mechanism, thus guaranteeing\nsafety.\nThis approach leverages PASS ’s provenance and state design to make each\ninstance an atomic node in PCN-style systems like X-Transfer. Here, we outline\nhow PASS Hubs can enable confidential, auditable cross-organization transfers,\nwhile full formal specification and protocol implementation is deferred for future\nwork.\nD.2 Instantiation on zkVM\nZero-knowledge virtual machines (zkVMs) provide a proving environment where\narbitrary state machines can run with strong correctness guarantees [?]. By pro-\nducing a succinct proof π of execution, zkVMs offer integrity assurances similar\nto TEEs but without hardware attestation. This makes them especially suited\nfor financial custody and inter-organizational accounting, where external verifi-\nability and regulator-grade auditability are critical.\n26J. Yu\nTo realize PASS within a zkVM, transaction requests are first queued outside\nof the proving environment. Once a batch is formed, the zkVM program takes\nas its private inputs the prior batch’s commitments of the ledger L and prove-\nnance log H, the set of state transitions in the current batch, including inbox\nI deposits and outbox O withdrawals, and the proposed new commitments for\nL and H. The zkVM then replays the computation: it begins from the previous\nroots, applies all queued transitions in sequence, and recomputes both balances\nand provenance entries. The proof π attests that these recomputations match\nthe declared new commitments and that all outbox deltas are consistent. A min-\nimalist verifier contract on chain simply checks π, updates the recorded roots,\nand enforces outbox execution. In this way, the privacy and provenance guar-\nantees of the original PASS design are preserved while augmenting them with\nrigorous computational proofs of correctness.\nThis formulation aligns with the Chainless stack architecture [?], which em-\nphasizes clear separation of execution, trust, bridging, and settlement. By sit-\nuating zkVM-based PASS execution within such a layered model, integration\nwith external systems can be achieved in a modular and interoperable manner.\nWe defer full formal implementation and specification for future work.\nFig. 7. PASS instantiation inside a zkVM: Inbox I and Outbox O transitions are\napplied to the Ledger L and Provenance H, producing new state commitments. The\nzkVM outputs a proof π, which the on-chain verifier checks before updating roots and\nenforcing outbox operations."
}
]
},
{
"role": "assistant",
"content": "你的问题是：\n**Custodial Key Management and Policies（传统托管密钥管理与策略）和PASS在效果上有什么区别？PASS能解决什么额外的问题？**\n\n下面我帮你梳理二者的核心区别、PASS的额外优势，以及它能解决的实际问题。\n\n---\n\n## 1. Custodial Key Management and Policies（传统托管密钥管理与策略）\n\n### 机制简介\n- 机构（如Fireblocks、Turnkey等）托管资产私钥。\n- 通过RBAC（基于角色的访问控制）、ABAC（基于属性的访问控制）等策略引擎，决定谁可以对资产做什么操作。\n- 这些策略通常在链下由托管方的软件/服务执行，用户通过API接口与托管方交互。\n\n### 优缺点\n**优点：**\n- 灵活、可编程，可实现复杂的审批流程。\n- 适合大机构的合规和审计需求。\n\n**缺点：**\n- 策略语言/配置复杂，策略面广，易出错或有未覆盖的“漏洞”。\n- 托管方可见所有操作和内部活动，隐私性较差。\n- 资产的“归属”与“流转”靠人为配置，难以追溯资金实际流向。\n- 需要信任托管方不会泄露密钥或作恶。\n\n---\n\n## 2. PASS（Provenanced Access Subaccount System）\n\n### 机制简介\n- 资产由单一EOA（外部拥有账户）控制，密钥仅存在于TEE（可信执行环境）中。\n- 钱包内部有多个“子账户”，每个子账户可以分配不同资产或权限。\n- **核心特性：所有权和使用权基于“资产溯源(provenance)”而不是“身份/角色”：** \n 只有能证明资产链路（从外部存入至当前子账户）的子账户，才能动用这些资产。\n- **Inbox–Outbox机制：** \n - 外部资产进入Inbox，需由子账户Claim。\n - 内部子账户之间转账完全私密、无gas消耗、不可链上追踪。\n - 只有Outbox里的提现/外部操作才被签名并广播到链上。\n- **隐私与可组合性：** \n - 内部转账对外不可见，外部观察者无法区分PASS钱包和普通EOA。\n - 可以与主流TEE系统、钱包协议（如WalletConnect）无缝集成。\n\n### 优缺点\n**优点：**\n- **极简策略面**：只需维护资产的溯源链路，减少复杂的策略语言和配置。\n- **强隐私**：内部资产流转完全不可见于链上，外部只见到EOA的收支。\n- **可追溯与审计**：每笔资产都能追溯到最初的外部存入，便于合规与内部审计。\n- **灵活子账户**：可为AI、员工、部门等分配独立额度与权限，且可随时回收。\n- **TEE保障密钥安全**：密钥永不出TEE，攻击面小。\n- **与现有生态兼容性高**：无需新合约，兼容EOA及主流链。\n\n**缺点：**\n- 仍需信任TEE厂商安全性。\n- 需要一定的组织级硬件/运维能力。\n- 若TEE被攻破，风险同样严重。\n\n---\n\n## 3. PASS能解决的额外问题\n\n### 3.1 内部隐私\n- 传统托管方案下，托管方可见所有内部转账与操作。\n- PASS内部转账完全私密（只在TEE内部账本和溯源日志中体现），对外不可见，保护了组织的薪资、预算分配等敏感信息。\n\n### 3.2 极简化的权限管理\n- 传统托管方案需要设计和维护复杂的RBAC/ABAC策略。\n- PASS只关心资产的“溯源链路”，子账户能否操作资产只看是否有对应的资产流转链条，简化了权限模型，减少配置和审计负担。\n\n### 3.3 更强的资产可追溯性和合规性\n- 每一笔资金的流入、流转、流出都可内部溯源，便于合规审计和责任追查。\n- 可满足如BSA（美国银行保密法）等需要资产流向明细的合规需求。\n\n### 3.4 降低托管方信任风险\n- 传统托管方案下，托管方可见全部密钥和操作，存在作恶和泄露风险。\n- PASS密钥仅在TEE中，托管方不可见密钥，也不可篡改溯源账本，信任基础更强。\n\n### 3.5 灵活的子账户与AI/自动化支持\n- 子账户可细粒度分配资产或签名权，便于委托AI agent、部门、员工等，且可随时回收权限。\n- 传统托管方案灵活性有限，容易发生“越权”或“权限滥用”。\n\n### 3.6 统一的隐私与可组合性\n- PASS可同时满足多子账户、多资产、多签名场景，且与当前EOA账户、钱包协议和TEE系统兼容，实现“隐私+可用性”两全。\n\n---\n\n## 4. 总结对比表\n\n| 方案 | 权限/策略基础 | 内部隐私 | 可追溯性 | 策略复杂度 | 兼容性 | 易用性 | 典型适用场景 |\n|----------------------|------------|--------|--------|--------|------|------|----------|\n| Custodial (RBAC/ABAC) | 角色/属性 | 差 | 一般 | 高 | 较好 | 需维护策略 | 传统机构托管 |\n| PASS | 溯源链路 | 强 | 强 | 极低 | 极好 | 易用 | 组织钱包、AI托管、私密分账 |\n\n---\n\n## 5. 结论\n\n- **PASS不是简单的托管密钥管理，而是基于“资产溯源”的新型权限与隐私体系。**\n- **它不仅解决了传统托管方案的隐私、可组合性和策略复杂性问题，还极大提升了安全性与可审计性。**\n- **适用于需要多方协作、内部隐私、细粒度权限分配和强合规追踪的场景。**\n\n---\n\n如需更细致的应用举例或对某一条特性深入解读，欢迎补充更多场景！"
},
{
"role": "user",
"content": "所以核心优势是在于1. 隐私 2. 溯源链路模型的优势吗"
},
{
"role": "assistant",
"content": "是的，你的理解**非常准确**，PASS的核心优势正是：\n\n---\n\n## 1. **隐私**\n\n- **内部操作隐私**：PASS将所有内部子账户之间的资产流转都放在TEE内部账本中，完全不在链上暴露，外部无法看到资产在组织内部的流动细节（如部门工资分配、团队拨款、AI agent操作等），只有最终出入账（Inbox/Outbox）才会上链。这比传统托管方案（托管方可见所有细节，链上合约钱包则全部公开）隐私性大幅提升。\n- **对外不可区分**：PASS账户对外表现为普通EOA地址，外部无法区分其内部结构和操作，增强了隐私和安全。\n\n---\n\n## 2. **溯源链路模型（Provenance-based model）**\n\n- **权限分配极简**：PASS不是靠“谁是什么角色/属性”来授权，而是**谁能证明资产流经自己**就能操作该资产。这样权限分配天然与资产流转绑定，避免了复杂的策略语言和配置，也更容易审计和验证。\n- **天然可追溯**：每一笔资产都能追溯到最早的外部存入（Inbox），内部所有权变化都在TEE的溯源账本中有记录。既能满足合规性，也能在内部追查责任和审计。\n- **合规与安全兼顾**：溯源链路模型易于配合合规需求（如反洗钱、资金流向追踪），同时又不牺牲内部隐私。\n\n---\n\n## 对比传统托管方案\n\n- 传统托管更像是“配置权限规则+记录日志”，但权限和资产流动是解耦的，策略面复杂且易错，内部操作隐私差。\n- PASS的“溯源链路”将权限和资产天然绑定，极大简化权限管理，提升安全性和可审计性，同时保护内部隐私。\n\n---\n\n## 其他优势（次要）\n\n- **TEE密钥托管，减少信任边界**。\n- **易与现有区块链生态兼容**，无需新合约。\n- **方便AI代理、组织多方协作等新兴场景**。\n\n---\n\n**总结**：\n> PASS的最大创新和核心优势，就是将“隐私”与“溯源链路模型”结合起来，既保护了内部操作的隐私，又用极简的溯源模型赋予了强安全性和可追溯性，超越了传统托管方案的能力。\n\n如果你要用一句话总结PASS的亮点，可以说：\n> **“PASS用资产溯源链路实现了权限极简、强隐私、强可追溯的新型托管模式。”**\n\n如需更详细的对比表或应用场景举例，可继续提问！"
},
{
"role": "user",
"content": "怎么突出溯源链路模型的优势呢 “这样权限分配天然与资产流转绑定，避免了复杂的策略语言和配置，也更容易审计和验证。”你说这样的话需要论据"
}
]Response:
当然！你想突出**“溯源链路模型”的优势**，需要有**论据**和**具体对比**来支撑。下面我帮你梳理论据和论证思路：
---
## 1. 权限与资产流转天然绑定——论据与对比
### 传统托管（RBAC/ABAC）的问题
- **权限配置与资产分配是两套体系**：
- 权限配置（如“张三有权转账1000美元”）和资产实际流转（资金到底分给了谁，怎么分）是分离的。
- 需要维护一套复杂的策略语言/规则，且这些规则容易出错或有遗漏。
- 资产归属和权限关系，往往只能靠日志事后追溯，难以做到实时强一致。
- **权限滥用风险**：
- 有权限的人可以操作所有资产（只要策略允许），一旦策略配置有误或被绕过，容易引发越权转账等安全事故。
- **审计复杂**：
- 审计时要同时查权限配置和实际资金流动，二者未必能一一对应，容易产生“权限漂移”或“账实不符”。
### 溯源链路模型的优势（PASS）
- **权限分配自动随资产流转**：
- 谁“Claim”了Inbox的资产，谁就拥有这笔资产的内部所有权和使用权。
- 资产的“所有权”与“可操作权”一体化，无需额外配置权限规则。
- 例如：Alice通过Claim获得10ETH，这10ETH在内部流转到Bob，则Bob自动获得这10ETH的操作权，无需修改权限策略。
- **权限边界清晰、强一致**：
- 子账户只能操作其溯源链路上属于自己的资产，绝无越权空间（除非篡改溯源账本，这在TEE内不可行）。
- 没有“全局权限”或“策略配置漂移”的隐患。
- **审计极其简单**：
- 只需追溯资产的溯源链路（从Inbox到各子账户再到Outbox），即可一目了然资产流向，谁动用了什么资金全都有据可查。
- 不需要同时分析权限配置+操作日志，降低了合规和安全风险。
- **无需复杂策略语言**：
- 不用再设计和维护繁琐的RBAC/ABAC规则，减少了配置和维护成本，提升了安全性和运维效率。
#### 论证举例
> 比如在传统托管系统中，如果需要给AI Agent一个“只能转账不超过1ETH”的权限，需要写一条ABAC规则，还要不断更新和检查。而在PASS中，只需把1ETH资产Claim到AI Agent的子账户，其权限天然限定于这1ETH，根本不可能动用其他资金。
---
## 2. 更容易审计与验证——论据
- **资产与操作强绑定**：每一笔资产的流向在溯源账本里都可追溯，且不可篡改。
- **形式化证明**：PASS在论文中用Lean 4形式化证明了“Provenance Integrity”，即对于任意时刻，所有子账户资产的总和，绝不会超过外部存入的总额，且每笔资产都能溯源到外部存入。
- **简化合规**：合规/审计时，只需导出溯源账本即可，无需解析复杂的权限配置和操作日志。
---
## 3. 总结一句话
> **溯源链路模型的最大优势在于，资产的所有权和可操作权与资产流转天然绑定，省去复杂的权限配置，杜绝权限漂移和越权，极大简化了审计和合规流程。**
---
## 4. 参考论文中的相关论据
- “This reduces policy-surface complexity, as no additional policy language is required, while maintaining composability with additional rules such as whitelists and blacklists.”
（这减少了策略面的复杂度，不需要额外的策略语言，同时还能组合其他规则）
- “Every unit of value inside the wallet has a verifiable lineage to an on-chain deposit...”
（每一单位资产都有可验证的溯源链路）
- “no subaccount can conjure funds from nothing, and all assets in the system are fully accounted for by provenanced deposits.”
（没有子账户可以凭空产生资产，所有资产都能追溯到真实存入）
---
## 5. 你的表达建议
你可以这样表达（可直接用在PPT或文档）：
> 传统托管方案的权限与资产流转分离，带来策略配置复杂、权限漂移和审计难的问题。而PASS的溯源链路模型，将权限与每一笔资产的流转天然绑定——谁能证明资产流经自己，谁就有权操作该资产，无需复杂策略语言，权限边界清晰，极大简化了权限管理和审计流程。所有资产的归属和流转都可一键溯源，合规和安全性大幅提升。
---
如需更具体的对比表、实际案例，或者需要引用论文中某个公式、图表来做支撑，请继续补充问题！
Model: gpt-4.1-2025-04-142025-09-14 02:18:50
Context:
[
{
"role": "user",
"content": [
{
"type": "text",
"text": "Custodial Key Management and Policies 和PASS在效果上有什么区别，PASS能解决什么额外的问题"
},
{
"type": "text",
"text": "main.pdf\nPASS: A Provenanced Access Subaccount\nSystem\nfor Blockchain Wallets\nJay Yu\n1,2\n1\nStanford University [email protected]\n2\nPantera Capital [email protected]\nAbstract. Blockchain wallets still follow a single-entity ownership model:\npossession of a private key grants unilateral control. This assumption is\nbrittle for emerging settings such as organizational custody, shared gov-\nernance, and AI agent wallets, where multiple actors must coordinate\nwithout exposing secrets or leaking internal activity.\nWe present PASS, a Provenanced Access Subaccount System\nthat replaces role or identity-based control with provenance-based con-\ntrol: assets can only be used by subaccounts that can trace custody back\nto a valid deposit. A simple Inbox–Outbox mechanism ensures all exter-\nnal actions have verifiable lineage, while internal transfers remain private\nand indistinguishable from ordinary EOAs.\nWe formalize PASS in Lean 4 and prove core invariants, including\nprivacy of internal transfers, asset accessibility, and provenance integrity.\nWe implement a prototype with enclave backends on AWS Nitro Enclaves\nand dstack Intel TDX, integrate with WalletConnect, and benchmark\nthroughput across wallet operations. These results show that provenance-\nbased wallets are both implementable and efficient. PASS bridges today’s\ngap between strict self-custody and flexible shared access, advancing the\ndesign space for practical, privacy-preserving custody.\n1 Introduction\nCryptocurrency wallets conventionally assume one key, one owner. In this single-\nentity ownership (SEAO) model, whoever holds the private key gains permanent\nand total control of the address. This paradigm underpins EOAs, multisigs, and\ncustodial policy engines, but it struggles in emerging scenarios such as orga-\nnizational treasuries, DAO governance, or delegating bounded authority to AI\nagents.\nThe limitation stems from a mismatch of models. Traditional access-control\nframeworks such as RBAC and ABAC assume an endogenous setting: users\ncreate and manage their own files, objects, or services, and policies are attached\nto these identities or roles. Blockchains are fundamentally exogenous: assets are\ncreated outside the wallet by smart contracts and transferred permissionlessly\nin. In this setting, identity or role-based rules are awkward to express and brittle\n2J. Yu\nto enforce. What matters instead is provenance: who deposited an asset, and how\nit flowed within the wallet.\nWe propose PASS, a Provenanced Access Subaccount System that enforces\ncontrol directly by provenance. The core mechanism is simple: an Inbox records\nexternal deposits, an Outbox signs and broadcasts withdrawals, and all internal\nmovements remain private and fee-less. Every unit of value inside the wallet has\na verifiable lineage to an on-chain deposit, while externally a PASS wallet is\nindistinguishable from a standard EOA. Our contributions include:\n– A provenance-based access model aligned with blockchain’s exogenous asset\ncreation, enforced through an Inbox–Outbox design.\n– A formal model in Lean 4 proving privacy, accessibility, and provenance\nintegrity.\n– A prototype with enclave backends (AWS Nitro, Phala dStack), integrated\nwith WalletConnect, together with throughput benchmarks.\n– Application scenarios, including organizational custody, privacy-preserving\ntransfers, and safe delegation to AI agents.\nPASS thus bridges the gap between strict self-custody and flexible shared\naccess, combining strong privacy guarantees with practical deployability.\n2 Background and Related Work\nGrowing retail and institutional adoption of digital assets [?,?,?] has spurred di-\nverse wallet designs [?]. In this section, we provide an overview of the mainstream\nwallet designs in Ethereum Virtual Machine (EVM) blockchains.\nExternally Owned Accounts and Multisignature Wallets In the EVM, assets are\ncommonly held in Externally Owned Accounts (EOAs), where possession of the\nprivate key confers unilateral, persistent control [?]. Key compromise has driven\nmany high-profile incidents [?,?]. Hardware wallets and mnemonic backups im-\nprove key custody but preserve the single-owner assumption [?].\nMultisignature wallets (e.g., Safe) distribute trust by requiring multiple ap-\nprovals [?], and are widely used for treasuries, bridges, and exchanges [?,?,?].\nTheir drawbacks include quorum overhead, largely symmetric authority, and\npublic on-chain logic with centralized frontends that can be attacked [?]. In con-\ntrast, PASS enables fine-grained, scoped permissioning without deploying new\ncontracts.\nSmart Contract Wallets and Account Abstraction Smart contract wallets such\nas Argent and Loopring add programmability such as social recovery and spend\nlimits via on-chain logic [?,?,?]. Ethereum’s ERC-4337 enables validation logic\nin a UserOperation contract [?], and EIP-7702 allows EOAs to also call smart\naccount logic defined in ERC-4337 [?]. These approaches increase flexibility but\nincur on-chain overhead and expose policy and transactions publicly, which is\nill-suited to use cases like institutional payroll.\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets3\nModelControl basisOn-chain\noverhead\nInternal\nPrivacy\nCompatibility\nEOASingle private keyNoneNoneNative EOA\nMultisigt-of-n co-signersHigh; quorum per\naction\nNone; logic\npublic\nSmart\ncontract based\nERC-4337\nSmart\nAccounts\nOn-chain policy\nlogic\nMedium to high;\ncustom logic and\ngas\nNone; logic\npublic\nRequires\nERC-4337\nchain support\nCustodiansCustom RBAC or\nABAC languages\nNone; Off-chain\nenforcement\nCustodian sees\nall activity\nAPI mediated\nLiquefactionTEE key\nencumbrance;\npolicy trees\nMedium; Oasis\ncontracts and gas\nStrong; TEE\nhides\nsubpolicies\nRequires Oasis\ndeployment\nPASS\n(ours)\nProvenance via\nInbox-Outbox\nNone; EOA\ncompatible\nStrong;\ninternal\ntransfers\ninvisible\nNative EOA\nplus off the\nshelf TEEs\nFig. 1. Comparison of wallet architectures. PASS features provenance-based control,\noff-chain privacy, and native EOA compatibility.\nPASS instead enforces policy off-chain in a TEE, achieving intent–execution\nseparation akin to account abstraction but without revealing rules or consuming\nchain resources.\nCustodial Key Management and Policies Institutional custody platforms (eg.,\nFireblocks, Turnkey, Privy) control key use with Role-Based Access Control\n(RBAC) or Attribute Based Access Control (ABAC) engines with custom pol-\nicy languages [?,?]. PASS adopts a provenance-centric alternative: authority fol-\nlows asset origin and transfer history, similar to a UTXO model. This reduces\npolicy-surface complexity, as no additional policy language is required, while\nmaintaining composability with additional rules such as whitelists and black-\nlists.\nTrusted Execution Environments and Liquefaction Trusted Execution Environ-\nments (TEEs) provide a hardware-isolated context for secure key storage and\ncomputation, shielding sensitive logic from the host system while providing re-\nmote attestation capabilities [?,?]. Liquefaction [?] keeps the wallet key inside a\nTEE and enforces multi-user sub-policies via key encumbrance, yielding strong\nprivacy. PASS extends this line of research by (i) providing Lean 4 formalization\nof core security invariants, (ii) simplifying access enforcement to a provenance\nrule realized through two special subaccounts (Inbox/Outbox) rather than a\nbespoke policy tree, and (iii) operating with a standard EOA and no new con-\ntracts to improve composability with mainstream TEE systems, in contrast to\nLiquefaction’s reliance on Oasis smart contracts [?]. To further demonstrate the\ngenerality of our approach, we implement PASS on two distinct TEE hard-\nware platforms: AWS Nitro Enclaves and Intel TDX, leveraging the open-source\n4J. Yu\ndstack TEE toolkit for the latter, and showcase prototype applications of PASS,\nincluding an AI agent wallet framework, private payrolls and supply chains, and\nsecure DAO voting.\nOther Related Models Centralized exchanges often pool funds in omnibus ad-\ndresses and track balances off-chain [?]; privacy mixers (eg., Tornado Cash) sever\ndeposit–withdrawal linkages [?]. PASS similarly preserves off-chain privacy for\ninternal transfers while maintaining an internal provenance ledger for account-\nability and regulatory workflows; external observers still see only deposits to and\nwithdrawals from the public EOA.\n3 System Model and Design\nFig. 2. Overview of PASS. External deposits enter the Inbox and are claimed by sub-\naccounts. Internal transfers are private and off-chain. Egress occurs via the Outbox,\nwhich signs and broadcasts on-chain transactions. All on-chain activity has clear prove-\nnance; internal movements remain private.\n3.1 High level system model\nPASS is a multi-user wallet on a single EOA (sk, pk). The wallet maintains a\nfinite set of subaccounts U ={u\n1\n,...,u\nn\n} and a set of assets A (e.g., ERC-20).\nA subaccount u ∈ U has authority over an amount x of asset α ∈ A iff it can\nobtain a signature from the global sk via the enclave; sk resides only inside a TEE\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets5\nand is never directly accessible. We give the intuitive model here and formalize\nit in Section ??.\nInternally, PASS tracks balances with a map L : U ×A →Z\n≥0\n(accessed\nvia L[u][α]), an Inbox multiset I of unclaimed deposits (α,x,m), an Outbox\nFIFO queueO of pending on-chain actions (α,x, extDst,ν) together with a global\nnonce ν ∈N, and an append-only provenance logH. The core principles of PASS,\nas shown in Figure ?? are as follows:\n1. Access follows provenance. A unit of value is usable by u only if there\nexists a custody chain in H from an external deposit to u. Informally,\nAllow(u,α,x) means balance x is reachable for u via provenance in H. This\nimplies consistency : for every α, the total internal balance equals the on-\nchain balance at pk, i.e.,\nP\nu∈U\nL[u][α] = B\non\n(α). Incoming deposits (α,x,m)∈\nI are “wrapped” and must be explicitly claimed before use by the sender\naddress.\n2. Off-chain privacy. Internal transfers u→ v update only L and H; they do\nnot touch O or the on-chain balance B\non\n, so internal flow is invisible and\nfee-less.\n3. First-come, first-served. Outbox transactions are sequenced by a FIFO queue,\nwhich maintains and increments a global nonce ν and directly sends enclave-\nsigned transactions to a RPC node to prevent nonce conflicts and replay\nattacks.\nOrganizational Ownership Model. PASS operates under an organizational own-\nership model, where an entity such as a company, individual, or DAO manages\nshared control over blockchain assets. We detail the threat model in Section ??.\nInbox-Outbox Gateway External senders transfer assets to pk, creating Inbox en-\ntries (α,x,m)∈I. A user performs claim(u,α,x,m) to move value intoL[u][α],\nconceptually “wrapping” the deposit. To withdraw or interact with a contract,\na subaccount first performs an internal transfer to the Outbox, which enqueues\n(α,x, extDst,ν); the enclave then signs the concrete transaction with sk and im-\nmediately broadcasts it, incrementing ν. The FIFO discipline and global nonce\nserialize actions and prevent races and double-spends. Because subaccounts never\nreceive pre-signed transactions, pre-signing misuse is mitigated.\nComposable policy scheme. Deposits are claims fromI; internal transfers require\nAllow(u,α,x) and update (L,H); withdrawals are internal transfers toO followed\nby submission. Additional constraints (eg., RBAC or ABAC checks, whitelists\nand blacklists) can be incorporated as conjuncts to Allow without changing the\nprovenance-centric rule or its consistency and privacy effects.\n3.2 Formal Model\nWe formalize PASS as a transition system in Lean 4\n3\n, an interactive theorem\nprover with a rich dependent type system [?], suitable for policy verification (eg.,\n3\nLean 4 model: https://github.com/pass-wallet/pass-lean4-proofs\n6J. Yu\nAWS Cedar [?]). In this section, we introduce the formal system we modeled in\nlean, and in Section ?? we will discuss security invariants modeled. An extended\ndiscussion of our formal verification system can be found in Appendix ??.\nState. A wallet state is S =\n\u0000\npk, sk,ν,I,O,L,H\n\u0001\nwhere (pk, sk,ν) are the EOA\npublic key, private key (generated and held in the TEE), and global nonce; I\nand O are Inbox and Outbox; L is the internal balance map L[u][α] ∈Z\n≥0\n;\nandH is the provenance history. For privacy arguments we also use the external\nview W\npub\n= (pk,O,A), where O contains the Outbox queue and nonce and A\nrecords total on-chain balances by asset.\nTransitions. Operations op∈ T update S with type-checked rules: InboxDeposit\nadds an unclaimed (α,x,m) to I; ClaimInbox moves (α,x,m) from I to L[u][α]\nand appends toH; InternalTransfer moves value between subaccounts; Withdraw\ndebits L[u][α], enqueues (α,x, extDst,ν) in O, and logs; SignGSM authorizes\ndomain-scoped signable messages. A representative rule is:\n\u0000\npk, sk,ν,I,O,L,H\n\u0001\ntransfer(α,x,u\ns\n,u\nr\n)\n−−−−−−−−−−−→\n\u0000\npk, sk,ν,I,O,L\n′\n,H\n′\n\u0001\nwith\nif L[u\ns\n][α] < x or ¬checkAllow(u\ns\n,α,x,H) then ⊥;\nL\n′\n[u\ns\n][α] =L[u\ns\n][α]− x, L\n′\n[u\nr\n][α] =L[u\nr\n][α] + x;\nH\n′\n=H\n\f\n\f\n\u0000\nop = transfer,α,x,u\ns\n,u\nr\n\u0001\n.\nHere checkAllow queries provenance inH and can be extended with auxiliary\nconstraints such as user whitelists or blacklists, without changing the core rule.\nFigure ?? provides a formal specification of the methods in a PASS wallet.\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets7\nPASS Wallet Management Functionality F\nΣ\nPASS\nfor wallet W\nGlobal State:\npk : public address (EOA)\nsk : private key (in TEE)\nν: global nonce for on-chain transactions\nI (Inbox): set of unclaimed deposits (α : asset,x : amount,m : depositId)\nO (Outbox): FIFO queue (α,x, extDst,ν)\nL (Asset Ledger): internal map L[u][α]∈ Z\n≥0\n, where u is each user’s ID in the system\nH (Provenance History): a list of transaction records appended whenever ClaimInbox,\nInternalTransfer, or Withdraw is invoked\nCreatePassWallet (creator ):\nI← ∅, O← ∅, L←{}; ν← 0\n(pk, sk )← TEE\nKeyGen()\nReturn new W with S =\n\u0000\npk, sk,ν,I,O,L,H\n\u0001\nand reference to creator\nInboxDeposit (α,x,m) from external P :\nI ← I ∪ {(α,x,m)}\nReturn success\nClaimInbox (α,x, depositId) from u:\nIf no (α,x,m) with depositId in I, return ⊥\nRemove (α,x,m) from I\nL[u][α]←L[u][α] + x\nH←H| (op = claim,α,x, depositId,u)\nReturn success\nCheckAllow (u\nsend\n,α,x,H):\nIf H.GetProvenance(α, u\nsend\n)≥ x,\nreturn true; else return false\nInternalTransfer (α,x,u\nsend\n,u\nrecv\n):\nIf L[u\nsend\n][α] < x or ¬checkAllow(u\nsend\n,α,x,H), return ⊥\nL[u\nsend\n][α]←L[u\nsend\n][α]− x\nL[u\nrecv\n][α]←L[u\nrecv\n][α] + x\nH←H\n\f\n\f\n\u0000\nop = transfer,α,x,u\nsend\n,u\nrecv\n\u0001\nReturn success\nWithdraw (α,x,u\nsend\n, extDst):\nIf L[u\nsend\n][α] < x or ¬checkAllow(u\nsend\n,α,x,H), return ⊥\nL[u\nsend\n][α]←L[u\nsend\n][α]− x\nO ←O∪{(α,x, extDst,ν)}\nH←H | (op = withdraw,α,x,u\nsend\n, extDst)\nReturn success\nSignGSM (dom, msg,u):\nIf u lacks sign-right for (dom, msg), return ⊥\nσ ← (sk, msg)\nReturn σ\n(Outbox Processing) (periodic or on demand):\nIf O ̸= ∅, dequeue (α,x, extDst,ν)\nBuild tx τ : transfer x of α to extDst, nonce = ν\nσ ← (sk, τ ); broadcast (τ,σ)\nν←ν + 1\nReturn broadcasted + txHash\nFig. 3. Formal Model of PASS wallet functionality, including CreatePassWallet for\ninitializing a fresh instance. On creation, pk is set to a chosen EOA address eoa, the\nTEE generates a hidden private key sk , and global data structures are initialized.\nExternal deposits enter I (Inbox), while subaccount transfers update L (Ledger) off-\nchain. Withdrawals queue items in O (Outbox), and GSM operations are signed using\nsk .\n3.3 Asset Model and General Signable Messages\nPASS provides an authorization scheme over a heterogenous set of assets A, in-\ncluding fungible tokens, such as ether and ERC-20 tokens, ERC-721 non-fungible\ntokens, and “general signable messages” across a variety of DApps for sign-in\n8J. Yu\nand identity verification. Each asset α ∈ A has a well-defined custody path in\nthe provenance log H, and a subaccount u ∈ U has usable balance x of α iff\nAllow(u,α,x) holds.\nToken assets. For token assets such as ether, ERC-20, and ERC-721, deposits are\ncaptured as Inbox entries (α,x,m)∈I. Claims allocate balance intoL[u][α], in-\nternal transfers updateL andH privately, and withdrawals enqueue (α,x, extDst,ν)\ninto O for enclave signing and on-chain broadcast, ensuring consistency where:\n∀α∈A\ntokens\n:\nX\nu∈U\nL[u][α] = B\non\n(α, pk).\nIn particular, ERC-721 tokens are modeled as unitary balances (x ∈ {0, 1})\nwhose transfers preserve uniqueness under provenance.\nGeneral Signable Messages (GSMs). In addition to on-chain assets, wallets often\nsign arbitrary messages, such as for EIP-4361 [?] logins and off-chain DAO votes\n[?]. PASS models these as a special class A\nGSM\nof virtual assets. Each GSM\nasset is scoped to a domain dom, so holding α = (dom) represents authority to\nsign messages from that domain. A signature operation:\nSignGSM(u, dom,m)7→ σ\nis permitted iff Allow(u, dom, 1) holds in H. At key generation, the wallet\ncreator is endowed with default signing authority over all domains, represented\nas an initial allocation of every α = (dom)∈A\nGSM\nto the root subaccount. These\ndomain assets can be internally transferred to delegate signing authority. Thus\nprovenance of GSMs begins at the owner and flows through transfers, providing\na well defined provenance path in H as with token assets.\nBy treating both tokens and GSMs as types of elements ofA, PASS provides\na unified provenance rule for subaccount authorization. A subaccount cannot\nspend an ERC-20 token, transfer an NFT, or sign a domain message unless it\npossesses the corresponding asset under L and H. This unified authorization\nscheme allows for fine-grained delegation, (eg., giving u rights over example.com\nwhile withholding ERC–20 funds) and consistent enforcement across on-chain\nand off-chain actions.\n4 Properties of PASS\n4.1 Threat Model\nPASS assumes an organizational ownership model, where a single entity, such\nas a company, individual, or DAO manages the EOA (pk,sk), brokers access\nbetween many users in that entity, and chooses the TEE infrastructure vendor\n(eg. AWS Nitro, dstack Intel TDX, self-hosted hardware). This model is typical\nfor use cases such as private payroll, supply chains, and AI delegation described\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets9\nin Section ??. Protected assets in PASS include the private key sk, the balance\nledger L and provenance log H, and the correctness of Allow(u,α,x) for all\nu∈ U,α∈A,x. In our model, we make the following trust assumptions:\n1. TEE integrity. Hardware isolation is sound; sk never leaves the enclave.\nRemote attestation guarantees that the enclave runs the genuine PASS bi-\nnary.\n2. Cryptography. Standard primitives (signatures, hash functions, PRFs) are\nsecure against polynomial-time adversaries.\n3. Governance majority. The deploying entity holds majority control in the\ngovernance mechanism (via DAO vote or admin privileges), ensuring it can\ninvoke the blockchain-governed KMS for MPC-based key recovery and trig-\nger fallback contracts when needed.\nAdversary Model. An adversaryA may control the host OS and network, observe\nor modify all communication with enclaves, and submit arbitrary transaction\nrequests. In particular, A may attempt to:\n– Exploit software bugs in the PASS implementation or TEE runtime,\n– Forge or replay transactions to break consistency of H,\n– Subvert provenance by violating Allow(u,α,x)\nThreats Out of Scope. On the other hand, PASS does not protect against:\n– Physical compromise of TEE hardware (tampering, microarchitectural side-\nchannels, chip decapsulation),\n– Supply-chain backdoors in TEE manufacturing,\n– Fully malicious operators with unrestricted physical access.\nThese are excluded because the organizational model assumes controlled facilities\nand vetted hardware.\nSecurity Goals. Given the assumptions above, PASS guarantees:\n1. Integrity:\nP\nu∈U\nL[u][α]≤ extDep(α) for all α, i.e., no assets can be created\nor double-spent internally.\n2. Correctness: If Allow(u,α,x) holds, then u can eventually realize x via\nWithdraw.\n3. Privacy on-chain: InternalTransfer operations do not affect externalTrace(W ),\nand to external observers, a PASS wallet is indistinguishable from an EOA.\n4. Liveness: For any authorized op ∈ Ops, if one enclave and quorum remain\nhonest, then ∃τ s.t. Exec(c, op) =⊤ within τ\n4.2 Privacy and Safety\nAfter establishing the threat model of PASS, we will address the central pri-\nvacy and safety guarantees. We sketch three central lemmas here, and create\nmechanized proofs in Lean, discussed in Appendix ??.\n10J. Yu\nProposition 1 (Internal Transfer Privacy). If two public states W\n1\n,W\n2\nshare the same pk, identical Outbox (T,ν), and equal per-asset totals in A, then\nexternalTrace(W\n1\n) = externalTrace(W\n2\n).\nProof Sketch. InternalTransfer updates only (L,H), never O or total on-chain\nbalances. OutboxProcessing in Figure ?? emits on-chain actions solely from O\n(lines 2–4), hence the trace depends only on O.\nCorollary: EOA indistinguishability. If W\npass\nand W\neoa\nshare the same pk,\nOutbox, and per-asset totals, then\nexternalTrace(W\npass\n) = externalTrace(W\neoa\n).\nThus, from an external observer’s perspective, a PASS account is indistinguish-\nable from a standard EOA: internal transfers leave no observable footprint.\nProposition 2 (Asset Accessibility). For any asset α, letting L = {u |\nL[u][α] > 0},\nX\nu∈L\nL[u][α] = totalBalance(α),\nand each u∈ L can spend its full balance subject to checkAllow.\nProof Sketch. ClaimInbox creditsL; InternalTransfer preserves the sum over u;\nWithdraw debitsL and enqueues toO, which OutboxProcessing realizes on-chain.\ncheckAllow enforces reachability from provenance in H.\nProposition 3 (Provenance Integrity). Let extDep(α) be net external de-\nposits (deposits minus realized withdrawals). For all reachable states,\nX\nu\nL[u][α] ≤ extDep(α).\nProof Sketch. Induct on transitions. InboxDeposit increases extDep only; Claim-\nInbox moves already-deposited value into L; InternalTransfer conserves the sum\nover u; Withdraw decreases the sum, and after OutboxProcessing broadcasts,\nextDep is reduced accordingly.\nGeneral signable messages (GSM). Model GSM rights as a domain-scoped vir-\ntual asset class A\nGSM\n. Let α = (dom)∈A\nGSM\nand permit\nSignGSM(u, dom,m) iff Allow(u,α, 1).\nThen (P2)–(P3) lift to GSM: there is always at least one domain signer, and\nGSM “balances” obey provenance conservation under transfers in H.\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets11\n4.3 Liveness\nWe define liveness as the property that any authorized operation remains even-\ntually executable, despite enclave crashes, vendor compromise, or partial gover-\nnance failure. Our model assumes deployment of PASS access logic on dstack,\nimplemented in Section ?? and detailed in Appendix ??.\nLet E denote active enclaves, C containerized wallet backends, and P gover-\nnance policies. Each container c∈C stores sealed state\nσ\nc\n=⟨S,k\nc\n, meta⟩ with S = (pk, sk,ν,I,O,L,H),\nwhere k\nc\n= Derive(K,c) is derived from an MPC-managed KMS and meta records\nattestation. An operation op ∈ Ops (deposit claim, transfer, withdrawal) ex-\necutes as: Exec(c, op) = ⊤ iff Attested(c)∧ Γ (S), where Attested(c) checks σ\nc\nagainst registry R and Γ is the quorum predicate over P. To ensure vendor-\nagnostic portability, state migration μ :E →E satisfies\n∀e\ni\n,e\nj\n∈E, e\nj\n.decrypt(σ\nc,e\ni\n,k\nc\n) = σ\nc,e\ni\n,\nTheorem 1 (Liveness Theorem). If (i) the MPC KMS tolerates f\nKMS\nfaults\nin a t-of-n threshold, (ii) governance quorums are f\ngov\n-resilient, and (iii) at least\none enclave is uncompromised, then every op∈ Ops executes within bounded time\nτ :\n∀op∈ Ops, ∃τ ≥ 0 : Exec(c, op) =⊤.\nProof Sketch. Progress follows from three guarantees: (1) the MPC KMS ensures\nk\nc\nis always recoverable under threshold availability; (2) Γ encodes quorum rules\nthat eventually relax after timeout ∆t, ensuring some subset S satisfies Γ (S) =\n⊤; (3) migration μ allows any enclave to re-host σ\nc\n, preventing vendor lock-in or\nenclave failure from blocking execution. Algorithm ?? formalizes recovery and\nexecution under these assumptions.\nAlgorithm 1 RecoverAndExecute(c, op)\n1: Verify enclave e attestation Q\ne\nagainst R.\n2: Derive k\nc\n← Derive(K,c); decrypt σ\nc\n.\n3: if CompromiseDetected(e\n′\n) then\n4:Rotate k\nc\nand re-encrypt σ\nc\n.\n5: end if\n6: Ensure Γ (S) =⊤ for S ⊆P(c).\n7: Execute op; append to H.\nKey Properties. (1) Portability: any attested enclave can recover σ\nc\n, independent\nof vendor; (2) Monotonic Recovery: recovery steps form ρ :S →S with ρ(s)⪰ s;\n(3) Domain Continuity: certificates remain bound toR(c) under migration μ(c),\npreventing hijack or replay.\nImplementation details of container orchestration, attestation, and KMS pro-\ntocols are given in Appendix ??.\n12J. Yu\n5 Practical Implementations\n5.1 Prototype Implementations\nTo demonstrate feasibility, we have implemented a prototype of PASS that cap-\ntures the core architectural components.\n4\nThe prototype consists of:\n– Provenanced Access Model, the core PASS architecture outlined in Sec-\ntion ?? with the Inbox-Outbox structure, asset ledgers, and provenanced\nrule as a Rust executable.\n– Web Application Frontend, an AWS-hosted Typescript interface that\nallows users to deposit assets, initiate internal transfers, generate on-chain\ntransactions, and sign arbitrary messages on Ethereum Sepolia testnet.\n5\n– Multi-vendor TEE deployment, we deploy the PASS enclave executable\nin both AWS Nitro Enclaves and Intel TDX with the dstack framework.\nWe evaluate these two enclave deployments as complementary deployment\npaths, each with distinct tradeoffs.\nAWS Nitro Enclaves. In this design, PASS runs inside a Nitro enclave in the\nAWS cloud. The enclave executes the Inbox–Outbox logic, enforces provenance\nchecks, and signs transactions, while the provenance ledger is stored externally.\nNitro’s attestation and AWS integration simplify deployment, but reliance on a\nsingle vendor limits portability and concentrates trust. As a result, some guaran-\ntees of PASS, particularly liveness and asset accessibility, may be weaker under\nthis model.\nIntel TDX with dstack. dstack provides a portable, open-source runtime for\nTEEs across diverse hardware. PASS can be deployed on enclaves run by decen-\ntralized operators, with key material secured via MPC-based key management.\nBoth Inbox–Outbox logic and the provenance ledger execute inside dstack, pre-\nserving the full security properties of Section ?? and reducing vendor lock-in.\nThe tradeoff is added governance complexity over operator authorization and\npolicy enforcement.\n5.2 Performance Benchmarks\nTo evaluate PASS, we benchmarked both AWS Nitro Enclaves and Intel TDX\nbackends across common operations: balance queries, transfers, withdrawals,\nclaims, wallet creation, provenance queries, and an end-to-end workflow. Each\noperation was run 100 times over 10 trials per environment, measuring through-\nput in ops/sec. Both environments used identical 4-core, 2.5 GHz, 16 GB VMs\nto ensure fair comparison. Table ?? summarizes our results, with full details\navailable in Appendix ??.\n4\nPrototype can be found here: https://github.com/jayyu23/pass-wallet-app\n5\nWeb application: https://pass-wallet.jayyu.xyz/\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets13\nFig. 4. Internal PASS operation throughput (ops/sec) across AWS Nitro Enclaves\nand Intel TDX. All operations are in-memory state changes within the TEE with no\nblockchain interaction. Each value represents the average of 100 operations repeated\n10 times per environment.\nOperationAWS Nitro Intel TDX\nWallet Creation6,53114,970\nAccount Balance Queries530,943935,428\nInbox-to-Subaccount Claims14,85633,064\nInternal Subaccount Transfers32,95371,292\nWithdrawal Request Creation18,29139,702\nEnd-to-End Workflow\n6\n35,66378,433\nTransaction History Queries3,7577,685\nMulti-threaded Operations (5 threads)32,18955,124\nLarge Dataset Processing481724\nThe observed performance differences between AWS Nitro Enclaves and In-\ntel TDX primarily stem from their distinct hardware architectures. AWS Nitro\nEnclaves employ a disaggregated system design, where the host server and the\nTEE hardware are physically separated. Communication between the host and\nthe enclave occurs via vsock, and the enclave itself runs on a dedicated, lower-\nperformance coprocessor. In contrast, Intel TDX leverages a special instruction\nset to provide enclave functionality directly on the main processor, eliminating\nthe need for a separate coprocessor and avoiding the overhead of data transfer\nbetween disparate components. As a result, Intel TDX is able to deliver sig-\nnificantly higher throughput for in-enclave operations compared to AWS Nitro\nEnclaves, as reflected in our benchmark results.\nThese preliminary benchmarks show that both Nitro and TDX backends can\nsustain high throughput for critical wallet operations, confirming that PASS is\npractical for real-world deployment. Further evaluation of latency distributions,\nconcurrency scaling, and memory footprint is left for future work. [Jay: Make prose\nremarks on Liquefaction performance, and why PASS is better]\n6 Applications\nPASS is a powerful primitive that enables several classes of applications.\n[Jay: To clean up and think better on how to frame directions - maybe (1) delegating\nto AI agents, (2) private payroll and supply chain, (3) DAO voting, (3) cross chain bridge\n+ CLOB exchange. Maybe a small application table?]\nOrganizational Wallets and Institutional Custody. An organization (company,\nuniversity, DAO) often needs to manage a single blockchain address for branding\nor transparency reasons (e.g., stanford.eth) while delegating control to multi-\nple individuals internally. The university could maintain stanford.eth as the\nmain address, and issue sub-accounts [email protected], [email protected]\n14J. Yu\nCategoryApplicationContextPASS Enables\nDelegation\nAI Agents\nDelegation\nAI agents increasingly\ninteract with crypto\nassets and\nprotocols [?].\nScoped subaccounts holding limited\nfunds or domain-scoped signing rights;\ndelegate safely to agents without\nexposing the wallet’s root key; revoke\nby moving balances out.\nDAO VotingDAOs rely on\naddress-based voting\nand delegation [?].\nPrivate sub-delegation of voting rights,\nprovenance keeps delegation auditable\nwithin PASS. Can also domain-restrict\ndelegators to voting DApps only.\nSubdomain\nProfile Pages\nOrganizations map\nENS or sub-identities\nto individuals/teams.\nMultiple subaccounts under one public\nidentity (e.g., [email protected]);\nper-subaccount balances and signing\nscopes with internal provenance.\nEnterprise\nPrivate\nPayroll\nOn-chain payroll can\nleak sensitive\ncompensation data.\nSalary distribution via internal\ntransfers (gasless, private) with an\nauditable internal log; withdrawals\nbatch via Outbox when needed.\nCompliant\nOrganization\nWallets\nOrganizations have a\npublic address with\ninternal access control\nand BSA\nrecordkeeping [?].\nDepartment and individual\nsubaccounts with explicit budget\nallocations. Provenance-based asset\naccountability upon regulator request.\nPrivate\nSupply Chains\nMulti-party B2B\npayments often\nrequire confidentiality\nacross tiers.\nSubaccount-based vendor channels\nwith private internal netting; only net\nsettlements leave via Outbox, reducing\nleakage while retaining internal\nauditability.\nCross Chain\nCross-chain\nBridge\nBridges require\ncustodial control and\ncareful key\ngovernance [?].\nInbox/Outbox enforce provenance\nboundaries across chains; scoped\nsubaccounts for operators; FIFO nonce\nhandling to avoid race conditions.\nGasless CLOB\nExchange\nFrequent on-chain\norder placement is\ngas-heavy for users.\nInternalize order matching/settlement\nbetween subaccounts off-chain;\nperiodically net out via Outbox so end\nusers experience gasless trading.\nL2\nComposability\nRollups/L2s fragment\nassets and UX [?].\nTreat L2s (or other domains) as\nscoped subaccounts; balance privately\nacross internal ledgers; settle\nexternally only when crossing domains.\nFig. 5. Applications of PASS across delegation, enterprise, and cross-chain contexts.\nfor different departments or team members. Each person gets a sub-account with\ncertain assets allocated or certain transaction rights. They can transact inter-\nnally for accounting without fees, and when needed, withdraw funds to external\nvendors. The provenance log ensures every outgoing fund can be traced to which\ninternal sub-account, aiding accountability, while external parties only interact\nwith the official address.\nDelegating to AI or Smart Agents. As autonomous agents start managing crypto\nassets for trading or DAO governance, there is a need to constrain their access.\nAn AI agent could be given a sub-account that only holds limited funds or\ncertain asset types. The AI can operate freely within those bounds, but cannot\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets15\nexceed its allotted assets or misuse other wallet assets. If compromised, damage\nis capped to its sub-account. This is much safer than giving AI the keys to an\nentire wallet.\nOrganizational Privacy Enhancement. Within the organizational ownership model,\nPASS provides privacy benefits for legitimate internal operations. Because in-\nternal transfers are off-chain, organizations can maintain confidentiality around\ntheir internal fund allocations and departmental transfers while still providing\nfull transparency for external interactions. This is particularly valuable for or-\nganizations that need to balance internal operational privacy with external ac-\ncountability requirements. Unlike general privacy mixing systems, this applica-\ntion aligns with the organizational ownership model where the entity controlling\nthe TEE has legitimate oversight of all activities within the system.\nIntegration with Off-chain Scaling Solutions. The concept of segregating internal\ntransfers from on-chain actions is analogous to how rollups and sidechains work\n(off-chain transactions batched into occasional on-chain commitments). PASS\ncould potentially integrate with Layer-2 networks by treating a whole sidechain\nor rollup as a “sub-account” or by using PASS ’s provenance model to bridge\nassets. For example, depositing funds into a rollup could be managed via an\nInbox-like mechanism, and withdrawing via an Outbox, with PASS ensuring\nthat assets are not double-spent across L1 and L2. While speculative, modeling\na rollup’s internal accounts using PASS might provide a unified view of assets\nacross layers, or allow a user to move assets between L2s through an enclave\nwithout trusting a centralized exchange. This is an area for future exploration.\nOrganizational TEE Management. PASS’s security model assumes that orga-\nnizations have the capability to properly manage TEE infrastructure. While\nthis eliminates concerns about physical attacks (as organizations can implement\nappropriate security controls), it requires organizations to maintain proper op-\nerational security practices. Organizations must ensure TEE software integrity\nthrough remote attestation, implement secure key management policies, and\nmaintain appropriate governance frameworks. For organizations without suffi-\ncient technical expertise or security infrastructure, partnering with specialized\nTEE service providers may be necessary. This organizational responsibility rep-\nresents both a strength (simplified threat model) and a limitation (requires or-\nganizational technical capability) of the PASS approach.\n7 Future Work\n7.1 Composability and InterPASS Transactions\nWhile PASS provides privacy and provenance guarantees for a single wallet in-\nstance, an important question is how multiple PASS wallets may interact. This\nis important in supply-chain use cases where each PASS represents a single com-\npany in the supply chain.\n16J. Yu\nTrivially, PASS A can send an on-chain transaction from its Outbox to PASS\nB’s EOA account, and this will land in the Inbox of PASS B, ready to claim.\nHowever, this undermines the privacy guarantees that PASS offers at the EOA\nlevel, and is undesirable in cases where inter-organizational asset transfers con-\ntain sensitive information, such as order details.\nWe propose a non-trivial approach inspired by cross-Payment Channel Net-\nwork (PCN) protocols such as XTransfer [?]. We can treat each PASS instance\nakin to a PCN hub node, with state L and transaction history H. As with\nXTransfer, we can assume a star topology of PASS nodes, with a central PASS\nHub in communciation with all PASS nodes. The PASS Hub will aggregate all\nInterPASS transactions T := {(a\ni\n,x\ni\n,s\ni\n,r\ni\n)}\nn\ni=1\n, where (a\ni\n,x\ni\n,s\ni\n,r\ni\n) represent\nthe asset, amount, sender, and receiver, each signed by the s\ni\nOutbox.\nThe Hub aggregates these signed payment intents, computes a netted settle-\nment plan S, and coordinates a secure multi-party update protocol to commit\nthe resulting balances, similar to Thora [?]. In the optimistic case, this process\ncompletes entirely off-chain, and each participant’s balance is updated in the\nPASS ledger without revealing the underlying transaction graph. If a dispute or\nfailure occurs, any participant may trigger an on-chain enforcement transaction\nthat finalizes S atomically via the direct transfer mechanism, thus guaranteeing\nsafety.\nThis approach leverages PASS ’s provenance and state design to make each\ninstance an atomic node in PCN-style systems like X-Transfer. Here, we outline\nhow PASS Hubs can enable confidential, auditable cross-organization transfers,\nwhile full formal specification and protocol implementation is deferred for future\nwork.\n7.2 Instantiation on zkVM\nZero-knowledge virtual machines (zkVMs) provide a proving environment where\narbitrary state machines can run with strong correctness guarantees [Jay: cite].\nBy producing a succinct proof π of execution, zkVMs offer integrity assurances\nsimilar to TEEs but without hardware attestation. This makes them especially\nsuited for financial custody and inter-organizational accounting, where external\nverifiability and regulator-grade auditability are critical.\nTo realize PASS within a zkVM, transaction requests are first queued outside\nof the proving environment. Once a batch is formed, the zkVM program takes\nas its private inputs the prior batch’s commitments of the ledger L and prove-\nnance log H, the set of state transitions in the current batch, including inbox\nI deposits and outbox O withdrawals, and the proposed new commitments for\nL and H. The zkVM then replays the computation: it begins from the previous\nroots, applies all queued transitions in sequence, and recomputes both balances\nand provenance entries. The proof π attests that these recomputations match\nthe declared new commitments and that all outbox deltas are consistent. A min-\nimalist verifier contract on chain simply checks π, updates the recorded roots,\nand enforces outbox execution. In this way, the privacy and provenance guar-\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets17\nantees of the original PASS design are preserved while augmenting them with\nrigorous computational proofs of correctness.\nThis formulation aligns with the Chainless stack architecture [?], which em-\nphasizes clear separation of execution, trust, bridging, and settlement. By sit-\nuating zkVM-based PASS execution within such a layered model, integration\nwith external systems can be achieved in a modular and interoperable manner.\nWe defer full formal implementation and specification for future work.\nFig. 6. PASS instantiation inside a zkVM: Inbox I and Outbox O transitions are\napplied to the Ledger L and Provenance H, producing new state commitments. The\nzkVM outputs a proof π, which the on-chain verifier checks before updating roots and\nenforcing outbox operations.\n7.3 Expansion of Formal Model and Further Benchmarks\n[Jay: TODO]\n18J. Yu\n8 Conclusion\nWe presented PASS, a Provenanced Access Subaccount System, as a new wallet\narchitecture that enforces access by provenance rather than by identity or role.\nThe Inbox–Outbox mechanism ensures all assets have a verifiable lineage, while\ninternal transfers remain private and indistinguishable from a standard EOA\naccount.\nOur contributions are threefold: (i) a formal model in Lean 4 proving pri-\nvacy, accessibility, and provenance integrity; (ii) a working prototype with en-\nclave backends on AWS Nitro Enclaves and Intel TDX via dstack, integrated\nwith WalletConnect; and (iii) initial benchmarks showing the feasibility of high-\nthroughput operation. These results demonstrate that provenance-based control\ncan be realized today with mainstream blockchain tools.\nLooking forward, richer evaluations across multi-vendor TEEs, integration\nwith zero-knowledge VMs, and exploration of organizational and agent-based\ncustody are promising directions. By combining rigorous formal guarantees with\ndeployable prototypes, PASS advances the design space between strict self-\ncustody and flexible shared access, offering a path toward practical, privacy-\npreserving wallet security.\nA Formal Verification\nWe consider the formal model introduced in Section ?? of PASS as a state\nmachine in Lean4. Our goal is to prove that, under the PASS design, several\ncritical security properties always hold. We outline these properties and our\napproach to verifying them.\nA.1 Property: Privacy of Internal Transfers\nIn the PASS design, the InternalTransfer operation updates only the off-chain\nledgerL and the provenance historyH. It never modifies the OutboxO, meaning\nthere is no on-chain transaction triggered by an internal transfer. Consequently,\nexternal observers see no change in on-chain state. We formalize this by consid-\nering the on-chain view that an external party has for a given PASS Wallet. We\ncan model this visible on-chain state as a triple:\nW\npub\n=\n\u0000\npk, O, A\n\u0001\n,\nwhere:\npk is the externally owned account (EOA) address,\nO = (T,ν) is the external view of the outbox, where T is a list of enqueued\ntransactions and ν is a nonce,\nA is the external view of the Asset ledgerL, containing a list of asset entries,\neach of the form (α,x) with a unique identifier α and total balance x.\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets19\nExternal Trace. The external trace of a PassAccount state W\npub\nis the list of\nexternally visible actions, obtained by mapping each transaction in the outbox\nT to an on-chain action:\nexternalTrace(W\npub\n) =\n\b\noutboxTx(t) | t∈ T\n\t\n.\nNo internal transfers appear in externalTrace(·).\nStates That Differ Only by Internal Transfers. We say that two PassAccount\nstates W\n1\n= (pk\n1\n,O\n1\n,A\n1\n) and W\n2\n= (pk\n2\n,O\n2\n,A\n2\n) differ only by internal trans-\nfers if:\n1. pk\n1\n= pk\n2\n,\n2. O\n1\n= O\n2\n(i.e. both the list of outbox transactions and the nonce are the\nsame),\n3. For every asset identifier α, the total balance of that asset in A\n1\nequals the\ntotal balance of the same asset in A\n2\n.\nLetting getAsset(W,α) return the asset α within state W or ⊥, we require ∀α:\ntotalBalance\n\u0000\ngetAsset(W\n1\n,α)\n\u0001\n= totalBalance\n\u0000\ngetAsset(W\n2\n,α)\n\u0001\n.\nTheorem 2 (Privacy of Internal Transfers). If two PassAccount states W\n1\nand W\n2\ndiffer only by internal transfers, then their externally visible traces are\nidentical:\nexternalTrace(W\n1\n) = externalTrace(W\n2\n).\nProof. By assumption, O\n1\n= O\n2\n. Hence both states have the same outbox trans-\naction list T . Since\nexternalTrace(W\ni\n) = map\n\u0000\noutboxTx, T\ni\n\u0001\nfor i∈{1, 2},\nand T\n1\n= T\n2\n, it follows that externalTrace(W\n1\n) and externalTrace(W\n2\n) are iden-\ntical.\nThus, any sequence of purely internal transfers, changing only the private ledger\nL in PASS, is invisible to an external observer, preserving the privacy of how\nassets move within the wallet.\nA corollary of this Internal Transfer property is that a PASS account is\nindistinguishable from a regular EOA account.\nCorollary 1 (Indistinguishability from EOA). Let W\npass\nbe a PASS state\nthat (i) has the same public key pk, (ii) the same outbox, including nonce and\ntransaction list, and (iii) the same total balances of each asset as a reference\nEOA state W\neoa\n. Then\nexternalTrace(W\npass\n) = externalTrace(W\neoa\n).\nIn particular, an external observer cannot distinguish W\npass\nfrom W\neoa\n.\nProof. By assumption, the only potential differences betweenW\npass\nandW\neoa\nlie\nin internal ledger details. From Theorem 1, such internal transfers do not affect\nthe externally visible outbox transactions or total on-chain balances. Thus, their\nexternal traces coincide, and W\npass\nis indistinguishable from W\neoa\n.\n20J. Yu\nA.2 Property: Asset Accessibility\nIn addition to keeping internal transactions private, PASS should ensure that for\nevery asset in the system, there exists some sub-account that can access it and\nwithdraw it from the system. This prevents a situation where funds get ”stuck”\nwithout any reachable key or policy to move them. We define asset accessibility\nas follows:\nTheorem 3 (Asset Accessibility). For any PASS account W and asset iden-\ntified by α, there exists a list of addresses L such that:\n1. For every address u∈ L, the user can access their full balance:\ncheckBalance(s,α,u, balance(u)) = true\n2. The sum of all accessible balances equals the total balance of the asset:\nX\nu∈L\nL[u][α] = totalBalance(α)\nProof. We construct L as the set of all addresses with non-zero balances in the\nbalance map for α:\nL ={u|L[u][α] > 0}\nFor the first property, given any u∈ L, the definition of checkBalance verifies\nif the user has sufficient balance for the specified amount. When checking against\nthe user’s own balance, this is trivially satisfied since L[u][α]≥L[u][α] for all u.\nFor the second property, we observe that totalBalance is defined as the sum\nof all balances in the asset’s balance map:\ntotalBalance(α) =\nX\nu∈L\nL[u][α]\nBy construction, L contains the only nonzero values u∈L, so:\nX\nu∈L\nL[u][α] = totalBalance(α)\nTherefore, both properties hold for our constructed list L.\nWe can prove a similar trait for General Signable Messages, showing that for\nany inbound GSM, there is some subaccount signer that has access to it.\nTheorem 4 (GSM Accessibility). For any GSM and domain, there exists a\nuser with signing access to that domain.\nProof. For any domain d, we can directly construct a user u who has signing\naccess to d as follows:\nu = getSigner(d)\nBy definition, getSigner returns either:\n– A specifically assigned signer if one exists in the domain-address map, or\n– The default signer otherwise\nTherefore, every domain is guaranteed to have at least one user with signing\naccess, ensuring no GSM domain becomes inaccessible.\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets21\nA.3 Property: Provenance Integrity\nProvenance integrity specifies that every asset held by any sub-account in PASS\nmust have an origin traceable to an external deposit into the Inbox. At any\nstate of the system, for each asset entry in a sub-account’s balance, we can find\na sequence of internal transfers that leads back to an Inbox deposit from an\nexternal address. This property ensures no sub-account can conjure funds from\nnothing, such as through double-spending or inflation within the system, and\nthat the internal ledger is consistent with on-chain reality. In Lean, we model\nthe state of the PASS wallet including Inbox, Outbox, and all sub-accounts and\nprove an invariant that whenever a sub-account has x units of asset α, the global\nstate contains a record of at least x units of α having been deposited, minus any\nthat have been withdrawn.\nTheorem 5 (Provenance Integrity).\nFor any PASS account S =\n\u0000\npk, sk,ν,I,O,L,H\n\u0001\nand any asset α, the total\namount of α held across all subaccounts can never exceed the total amount of\nexternal deposits (minus any that have already been withdrawn). Formally,\nX\nu∈U\nL[u][α] ≤ externalDeposits(α),\nwhere U is the set of subaccounts in the system, and externalDeposits(α) is\nthe net total of asset α that has been introduced into the wallet from outside\naddresses, recorded in the inbox I.\nProof. We model the system’s state (pk, sk,ν,I,O,L,H) as in Figure ??, includ-\ning the Inbox I, Outbox O, and the internal ledger L. We define a provenance\nrecord P (α,u) that captures the total amount of asset α subaccount u is autho-\nrized to hold, based on Inbox claims and internal transfers.\nBase Case: Immediately after CreatePassWallet, no assets have been de-\nposited, and no subaccount balances exist:\n∀u, L[u][α] = 0, ∀α, externalDeposits(α) = 0.\nHence,\nX\nu∈U\nL[u][α] = 0 ≤ 0 = externalDeposits(α).\nInductive Step: Assume the invariant holds after n− 1 operations. We prove it\nremains valid after the nth operation, for each possible type of operation:\n(1) External Deposit: Suppose an amount x of asset α is deposited into the\nwallet:\nexternalDeposits(α) ← externalDeposits(α) + x.\nNo subaccount balances L[u][α] change. Thus, the left side of our inequality\n(sum of subaccount balances) is unchanged, while the right side strictly\nincreases by x, so the invariant continues to hold.\n22J. Yu\n(2) Inbox Claim: If subaccount u claims amount x of asset α from the Inbox\nI:\nL[u][α] ← L[u][α] + x, P (α,u) ← P (α,u) + x.\nSince x was already accounted for in externalDeposits(α) (but not yet allo-\ncated to any subaccount), the total subaccount balances remain≤ externalDeposits(α).\n(3) Internal Transfer: If subaccount u\n1\ntransfers x of α to subaccount u\n2\n:\nL[u\n1\n][α] ← L[u\n1\n][α]− x, L[u\n2\n][α] ← L[u\n2\n][α] + x,\nand P (α,u\n2\n) increases by x. Because the sum of all subaccount balances\ndoes not change, our invariant is preserved.\n(4) Withdrawal: If subaccount u withdraws x of α:\nL[u][α] ← L[u][α]− x,\nwhich reduces the total subaccount balances. Since externalDeposits(α)\nremains unchanged (assets have simply exited the wallet), the inequality still\nholds.\nThus, by induction over all possible operations,\nX\nu∈U\nL[u][α] ≤ externalDeposits(α)\nfor every reachable state. No subaccount can create new assets out of nothing,\nand all assets in the system are fully accounted for by provenanced deposits.\nB Dstack Architecture and Execution Model\nB.1 Component Overview\n– Dstack-OS: Minimal Linux-based VM image with a verifiable boot chain.\nMeasures bootloader, kernel, root filesystem (RootFs) via RTMR registers.\nIntegrates dm-verity for data integrity and monotonic counters for anti-\nrollback.\n– Dstack-KMS: Blockchain-governed MPC network for key derivation and\nrotation. Provides:\nk\nc\n= HMAC\nk\nroot\n(c\nid\n),\nk\nTLS\n= ECDSA(k\nroot\n).\nRotation is triggered via governance (t-of-n threshold).\n– Dstack-Gateway/Ingress: TLS termination inside TEEs, ZT-TLS bind-\ning X\nc\nto R(c), enabling verifiable HTTPS ingress.\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets23\nB.2 Governance Layer\nTwo contracts form the trust base:\n– KmsAuth: Global registry of KMS nodes and application digests.\n– AppAuth: Per-application contract specifying quorum rules, allowed image\nhashes, and authorized enclaves.\nB.3 Workflow Phases\n1. Attestation: Enclave e produces quote Q\ne\n; verified against R.\n2. Secret Provisioning: MPC nodes compute k\nc\n, release to e if Q\ne\nis valid.\n3. Container Launch: Dstack-OS mounts RootFs, decrypts state σ\nc\nwith k\nc\n.\n4. Ingress Binding: TLS certificate X\nc\ngenerated inside e; bound to R(c).\n5. Audit Logging: Migration, key rotation, and governance events appended\nto H.\nB.4 Fault Tolerance\n– Vendor failure: μ enables re-deployment across Intel/AMD TEEs.\n– KMS compromise: key rotation via MPC thresholds restores forward/backward\nsecrecy.\n– Governance deadlock: ∆t fallback in Γ ensures quorum reduction and progress.\nB.5 Liveness Proof Sketch\nCombining MPC-based key recovery, quorum fallback, and portable containers\nyields:\n∀op∈O\nc\n,Pr[Exec(c, op) =⊤] = 1\nunder assumptions of f -resilient MPC nodes and at least one uncompromised\nTEE instance.\nC Detailed Benchmark Results\nThis appendix provides comprehensive benchmark statistics for both AWS Nitro\nEnclaves and Intel TDX environments. All operations are internal PASS state\nchanges that occur within the TEE with no blockchain network interaction.\nEach operation was executed 100 times per trial, with 10 independent trials\nper environment. The tables below show summary statistics including mean,\nstandard deviation, and range.\n24J. Yu\nTable 1. AWS Nitro Enclaves benchmark statistics (ops/sec) across 10 trials\nOperationMean Std Dev Min Max\nWallet Creation6,5315315,4467,042\nAccount Balance Queries530,943675 530,216 531,915\nInbox-to-Subaccount Claims14,856476 14,326 15,504\nInternal Subaccount Transfers32,9531,322 31,447 35,088\nWithdrawal Request Creation18,2911,254 15,873 19,608\nEnd-to-End Workflow35,6636,234 21,739 40,650\nTransaction History Queries3,757453,6503,802\nMulti-threaded Operations (5 threads) 32,189884 31,200 34,364\nLarge Dataset Processing48113467497\nTable 2. Phala dStack benchmark statistics (ops/sec) across 10 trials\nOperationMean Std Dev Min Max\nWallet Creation14,9704,6528,69624,390\nAccount Balance Queries935,428338,450 383,142 1,470,588\nInbox-to-Subaccount Claims33,0645,197 25,44541,667\nInternal Subaccount Transfers71,29217,623 47,170 101,010\nWithdrawal Request Creation39,7027,434 29,15551,813\nEnd-to-End Workflow78,43317,403 59,524 110,497\nTransaction History Queries7,6858726,4528,929\nMulti-threaded Operations (5 threads) 55,12416,744 28,32981,301\nLarge Dataset Processing72481636893\nC.1 AWS Nitro Enclaves Results\nC.2 Intel TDX Results\nC.3 Performance Analysis\nThe statistical analysis reveals several key insights about PASS’s internal oper-\nation performance:\n– Performance Consistency: AWS Nitro Enclaves demonstrate superior\nconsistency with lower standard deviations across all operations. The co-\nefficient of variation ranges from 0.1% (Account Balance Queries) to 17.5%\n(End-to-End Workflow).\n– Peak Performance: Intel TDX achieves higher mean throughput but with\nsignificantly greater variance. Standard deviations are 10-500x larger than\nNitro, indicating less predictable performance.\n– Production Considerations: These internal operation benchmarks demon-\nstrate PASS’s ability to handle thousands of wallet operations per second\nwithin the TEE, with the actual deployment bottleneck being blockchain\ntransaction submission rather than internal processing.\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets25\nThe statistical summary confirms that both platforms support practical PASS\ndeployment, with Nitro offering predictable performance and Intel TDX provid-\ning higher peak throughput at the cost of consistency.\nD Design Extensions\nD.1 Composability and InterPASS Transactions\nWhile PASS provides privacy and provenance guarantees for a single wallet in-\nstance, an important question is how multiple PASS wallets may interact. This\nis important in supply-chain use cases where each PASS represents a single com-\npany in the supply chain.\nTrivially, PASS A can send an on-chain transaction from its Outbox to PASS\nB’s EOA account, and this will land in the Inbox of PASS B, ready to claim.\nHowever, this undermines the privacy guarantees that PASS offers at the EOA\nlevel, and is undesirable in cases where inter-organizational asset transfers con-\ntain sensitive information, such as order details.\nWe propose a non-trivial approach inspired by cross-Payment Channel Net-\nwork (PCN) protocols such as XTransfer [?]. We can treat each PASS instance\nakin to a PCN hub node, with state L and transaction history H. As with\nXTransfer, we can assume a star topology of PASS nodes, with a central PASS\nHub in communciation with all PASS nodes. The PASS Hub will aggregate all\nInterPASS transactions T := {(a\ni\n,x\ni\n,s\ni\n,r\ni\n)}\nn\ni=1\n, where (a\ni\n,x\ni\n,s\ni\n,r\ni\n) represent\nthe asset, amount, sender, and receiver, each signed by the s\ni\nOutbox.\nThe Hub aggregates these signed payment intents, computes a netted settle-\nment plan S, and coordinates a secure multi-party update protocol to commit\nthe resulting balances, similar to Thora [?]. In the optimistic case, this process\ncompletes entirely off-chain, and each participant’s balance is updated in the\nPASS ledger without revealing the underlying transaction graph. If a dispute or\nfailure occurs, any participant may trigger an on-chain enforcement transaction\nthat finalizes S atomically via the direct transfer mechanism, thus guaranteeing\nsafety.\nThis approach leverages PASS ’s provenance and state design to make each\ninstance an atomic node in PCN-style systems like X-Transfer. Here, we outline\nhow PASS Hubs can enable confidential, auditable cross-organization transfers,\nwhile full formal specification and protocol implementation is deferred for future\nwork.\nD.2 Instantiation on zkVM\nZero-knowledge virtual machines (zkVMs) provide a proving environment where\narbitrary state machines can run with strong correctness guarantees [?]. By pro-\nducing a succinct proof π of execution, zkVMs offer integrity assurances similar\nto TEEs but without hardware attestation. This makes them especially suited\nfor financial custody and inter-organizational accounting, where external verifi-\nability and regulator-grade auditability are critical.\n26J. Yu\nTo realize PASS within a zkVM, transaction requests are first queued outside\nof the proving environment. Once a batch is formed, the zkVM program takes\nas its private inputs the prior batch’s commitments of the ledger L and prove-\nnance log H, the set of state transitions in the current batch, including inbox\nI deposits and outbox O withdrawals, and the proposed new commitments for\nL and H. The zkVM then replays the computation: it begins from the previous\nroots, applies all queued transitions in sequence, and recomputes both balances\nand provenance entries. The proof π attests that these recomputations match\nthe declared new commitments and that all outbox deltas are consistent. A min-\nimalist verifier contract on chain simply checks π, updates the recorded roots,\nand enforces outbox execution. In this way, the privacy and provenance guar-\nantees of the original PASS design are preserved while augmenting them with\nrigorous computational proofs of correctness.\nThis formulation aligns with the Chainless stack architecture [?], which em-\nphasizes clear separation of execution, trust, bridging, and settlement. By sit-\nuating zkVM-based PASS execution within such a layered model, integration\nwith external systems can be achieved in a modular and interoperable manner.\nWe defer full formal implementation and specification for future work.\nFig. 7. PASS instantiation inside a zkVM: Inbox I and Outbox O transitions are\napplied to the Ledger L and Provenance H, producing new state commitments. The\nzkVM outputs a proof π, which the on-chain verifier checks before updating roots and\nenforcing outbox operations."
}
]
},
{
"role": "assistant",
"content": "你的问题是：\n**Custodial Key Management and Policies（传统托管密钥管理与策略）和PASS在效果上有什么区别？PASS能解决什么额外的问题？**\n\n下面我帮你梳理二者的核心区别、PASS的额外优势，以及它能解决的实际问题。\n\n---\n\n## 1. Custodial Key Management and Policies（传统托管密钥管理与策略）\n\n### 机制简介\n- 机构（如Fireblocks、Turnkey等）托管资产私钥。\n- 通过RBAC（基于角色的访问控制）、ABAC（基于属性的访问控制）等策略引擎，决定谁可以对资产做什么操作。\n- 这些策略通常在链下由托管方的软件/服务执行，用户通过API接口与托管方交互。\n\n### 优缺点\n**优点：**\n- 灵活、可编程，可实现复杂的审批流程。\n- 适合大机构的合规和审计需求。\n\n**缺点：**\n- 策略语言/配置复杂，策略面广，易出错或有未覆盖的“漏洞”。\n- 托管方可见所有操作和内部活动，隐私性较差。\n- 资产的“归属”与“流转”靠人为配置，难以追溯资金实际流向。\n- 需要信任托管方不会泄露密钥或作恶。\n\n---\n\n## 2. PASS（Provenanced Access Subaccount System）\n\n### 机制简介\n- 资产由单一EOA（外部拥有账户）控制，密钥仅存在于TEE（可信执行环境）中。\n- 钱包内部有多个“子账户”，每个子账户可以分配不同资产或权限。\n- **核心特性：所有权和使用权基于“资产溯源(provenance)”而不是“身份/角色”：** \n 只有能证明资产链路（从外部存入至当前子账户）的子账户，才能动用这些资产。\n- **Inbox–Outbox机制：** \n - 外部资产进入Inbox，需由子账户Claim。\n - 内部子账户之间转账完全私密、无gas消耗、不可链上追踪。\n - 只有Outbox里的提现/外部操作才被签名并广播到链上。\n- **隐私与可组合性：** \n - 内部转账对外不可见，外部观察者无法区分PASS钱包和普通EOA。\n - 可以与主流TEE系统、钱包协议（如WalletConnect）无缝集成。\n\n### 优缺点\n**优点：**\n- **极简策略面**：只需维护资产的溯源链路，减少复杂的策略语言和配置。\n- **强隐私**：内部资产流转完全不可见于链上，外部只见到EOA的收支。\n- **可追溯与审计**：每笔资产都能追溯到最初的外部存入，便于合规与内部审计。\n- **灵活子账户**：可为AI、员工、部门等分配独立额度与权限，且可随时回收。\n- **TEE保障密钥安全**：密钥永不出TEE，攻击面小。\n- **与现有生态兼容性高**：无需新合约，兼容EOA及主流链。\n\n**缺点：**\n- 仍需信任TEE厂商安全性。\n- 需要一定的组织级硬件/运维能力。\n- 若TEE被攻破，风险同样严重。\n\n---\n\n## 3. PASS能解决的额外问题\n\n### 3.1 内部隐私\n- 传统托管方案下，托管方可见所有内部转账与操作。\n- PASS内部转账完全私密（只在TEE内部账本和溯源日志中体现），对外不可见，保护了组织的薪资、预算分配等敏感信息。\n\n### 3.2 极简化的权限管理\n- 传统托管方案需要设计和维护复杂的RBAC/ABAC策略。\n- PASS只关心资产的“溯源链路”，子账户能否操作资产只看是否有对应的资产流转链条，简化了权限模型，减少配置和审计负担。\n\n### 3.3 更强的资产可追溯性和合规性\n- 每一笔资金的流入、流转、流出都可内部溯源，便于合规审计和责任追查。\n- 可满足如BSA（美国银行保密法）等需要资产流向明细的合规需求。\n\n### 3.4 降低托管方信任风险\n- 传统托管方案下，托管方可见全部密钥和操作，存在作恶和泄露风险。\n- PASS密钥仅在TEE中，托管方不可见密钥，也不可篡改溯源账本，信任基础更强。\n\n### 3.5 灵活的子账户与AI/自动化支持\n- 子账户可细粒度分配资产或签名权，便于委托AI agent、部门、员工等，且可随时回收权限。\n- 传统托管方案灵活性有限，容易发生“越权”或“权限滥用”。\n\n### 3.6 统一的隐私与可组合性\n- PASS可同时满足多子账户、多资产、多签名场景，且与当前EOA账户、钱包协议和TEE系统兼容，实现“隐私+可用性”两全。\n\n---\n\n## 4. 总结对比表\n\n| 方案 | 权限/策略基础 | 内部隐私 | 可追溯性 | 策略复杂度 | 兼容性 | 易用性 | 典型适用场景 |\n|----------------------|------------|--------|--------|--------|------|------|----------|\n| Custodial (RBAC/ABAC) | 角色/属性 | 差 | 一般 | 高 | 较好 | 需维护策略 | 传统机构托管 |\n| PASS | 溯源链路 | 强 | 强 | 极低 | 极好 | 易用 | 组织钱包、AI托管、私密分账 |\n\n---\n\n## 5. 结论\n\n- **PASS不是简单的托管密钥管理，而是基于“资产溯源”的新型权限与隐私体系。**\n- **它不仅解决了传统托管方案的隐私、可组合性和策略复杂性问题，还极大提升了安全性与可审计性。**\n- **适用于需要多方协作、内部隐私、细粒度权限分配和强合规追踪的场景。**\n\n---\n\n如需更细致的应用举例或对某一条特性深入解读，欢迎补充更多场景！"
},
{
"role": "user",
"content": "所以核心优势是在于1. 隐私 2. 溯源链路模型的优势吗"
}
]Response:
是的，你的理解**非常准确**，PASS的核心优势正是：
---
## 1. **隐私**
- **内部操作隐私**：PASS将所有内部子账户之间的资产流转都放在TEE内部账本中，完全不在链上暴露，外部无法看到资产在组织内部的流动细节（如部门工资分配、团队拨款、AI agent操作等），只有最终出入账（Inbox/Outbox）才会上链。这比传统托管方案（托管方可见所有细节，链上合约钱包则全部公开）隐私性大幅提升。
- **对外不可区分**：PASS账户对外表现为普通EOA地址，外部无法区分其内部结构和操作，增强了隐私和安全。
---
## 2. **溯源链路模型（Provenance-based model）**
- **权限分配极简**：PASS不是靠“谁是什么角色/属性”来授权，而是**谁能证明资产流经自己**就能操作该资产。这样权限分配天然与资产流转绑定，避免了复杂的策略语言和配置，也更容易审计和验证。
- **天然可追溯**：每一笔资产都能追溯到最早的外部存入（Inbox），内部所有权变化都在TEE的溯源账本中有记录。既能满足合规性，也能在内部追查责任和审计。
- **合规与安全兼顾**：溯源链路模型易于配合合规需求（如反洗钱、资金流向追踪），同时又不牺牲内部隐私。
---
## 对比传统托管方案
- 传统托管更像是“配置权限规则+记录日志”，但权限和资产流动是解耦的，策略面复杂且易错，内部操作隐私差。
- PASS的“溯源链路”将权限和资产天然绑定，极大简化权限管理，提升安全性和可审计性，同时保护内部隐私。
---
## 其他优势（次要）
- **TEE密钥托管，减少信任边界**。
- **易与现有区块链生态兼容**，无需新合约。
- **方便AI代理、组织多方协作等新兴场景**。
---
**总结**：
> PASS的最大创新和核心优势，就是将“隐私”与“溯源链路模型”结合起来，既保护了内部操作的隐私，又用极简的溯源模型赋予了强安全性和可追溯性，超越了传统托管方案的能力。
如果你要用一句话总结PASS的亮点，可以说：
> **“PASS用资产溯源链路实现了权限极简、强隐私、强可追溯的新型托管模式。”**
如需更详细的对比表或应用场景举例，可继续提问！
Model: gpt-4.1-2025-04-142025-09-14 02:16:24
Context:
[
{
"role": "user",
"content": [
{
"type": "text",
"text": "Custodial Key Management and Policies 和PASS在效果上有什么区别，PASS能解决什么额外的问题"
},
{
"type": "text",
"text": "main.pdf\nPASS: A Provenanced Access Subaccount\nSystem\nfor Blockchain Wallets\nJay Yu\n1,2\n1\nStanford University [email protected]\n2\nPantera Capital [email protected]\nAbstract. Blockchain wallets still follow a single-entity ownership model:\npossession of a private key grants unilateral control. This assumption is\nbrittle for emerging settings such as organizational custody, shared gov-\nernance, and AI agent wallets, where multiple actors must coordinate\nwithout exposing secrets or leaking internal activity.\nWe present PASS, a Provenanced Access Subaccount System\nthat replaces role or identity-based control with provenance-based con-\ntrol: assets can only be used by subaccounts that can trace custody back\nto a valid deposit. A simple Inbox–Outbox mechanism ensures all exter-\nnal actions have verifiable lineage, while internal transfers remain private\nand indistinguishable from ordinary EOAs.\nWe formalize PASS in Lean 4 and prove core invariants, including\nprivacy of internal transfers, asset accessibility, and provenance integrity.\nWe implement a prototype with enclave backends on AWS Nitro Enclaves\nand dstack Intel TDX, integrate with WalletConnect, and benchmark\nthroughput across wallet operations. These results show that provenance-\nbased wallets are both implementable and efficient. PASS bridges today’s\ngap between strict self-custody and flexible shared access, advancing the\ndesign space for practical, privacy-preserving custody.\n1 Introduction\nCryptocurrency wallets conventionally assume one key, one owner. In this single-\nentity ownership (SEAO) model, whoever holds the private key gains permanent\nand total control of the address. This paradigm underpins EOAs, multisigs, and\ncustodial policy engines, but it struggles in emerging scenarios such as orga-\nnizational treasuries, DAO governance, or delegating bounded authority to AI\nagents.\nThe limitation stems from a mismatch of models. Traditional access-control\nframeworks such as RBAC and ABAC assume an endogenous setting: users\ncreate and manage their own files, objects, or services, and policies are attached\nto these identities or roles. Blockchains are fundamentally exogenous: assets are\ncreated outside the wallet by smart contracts and transferred permissionlessly\nin. In this setting, identity or role-based rules are awkward to express and brittle\n2J. Yu\nto enforce. What matters instead is provenance: who deposited an asset, and how\nit flowed within the wallet.\nWe propose PASS, a Provenanced Access Subaccount System that enforces\ncontrol directly by provenance. The core mechanism is simple: an Inbox records\nexternal deposits, an Outbox signs and broadcasts withdrawals, and all internal\nmovements remain private and fee-less. Every unit of value inside the wallet has\na verifiable lineage to an on-chain deposit, while externally a PASS wallet is\nindistinguishable from a standard EOA. Our contributions include:\n– A provenance-based access model aligned with blockchain’s exogenous asset\ncreation, enforced through an Inbox–Outbox design.\n– A formal model in Lean 4 proving privacy, accessibility, and provenance\nintegrity.\n– A prototype with enclave backends (AWS Nitro, Phala dStack), integrated\nwith WalletConnect, together with throughput benchmarks.\n– Application scenarios, including organizational custody, privacy-preserving\ntransfers, and safe delegation to AI agents.\nPASS thus bridges the gap between strict self-custody and flexible shared\naccess, combining strong privacy guarantees with practical deployability.\n2 Background and Related Work\nGrowing retail and institutional adoption of digital assets [?,?,?] has spurred di-\nverse wallet designs [?]. In this section, we provide an overview of the mainstream\nwallet designs in Ethereum Virtual Machine (EVM) blockchains.\nExternally Owned Accounts and Multisignature Wallets In the EVM, assets are\ncommonly held in Externally Owned Accounts (EOAs), where possession of the\nprivate key confers unilateral, persistent control [?]. Key compromise has driven\nmany high-profile incidents [?,?]. Hardware wallets and mnemonic backups im-\nprove key custody but preserve the single-owner assumption [?].\nMultisignature wallets (e.g., Safe) distribute trust by requiring multiple ap-\nprovals [?], and are widely used for treasuries, bridges, and exchanges [?,?,?].\nTheir drawbacks include quorum overhead, largely symmetric authority, and\npublic on-chain logic with centralized frontends that can be attacked [?]. In con-\ntrast, PASS enables fine-grained, scoped permissioning without deploying new\ncontracts.\nSmart Contract Wallets and Account Abstraction Smart contract wallets such\nas Argent and Loopring add programmability such as social recovery and spend\nlimits via on-chain logic [?,?,?]. Ethereum’s ERC-4337 enables validation logic\nin a UserOperation contract [?], and EIP-7702 allows EOAs to also call smart\naccount logic defined in ERC-4337 [?]. These approaches increase flexibility but\nincur on-chain overhead and expose policy and transactions publicly, which is\nill-suited to use cases like institutional payroll.\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets3\nModelControl basisOn-chain\noverhead\nInternal\nPrivacy\nCompatibility\nEOASingle private keyNoneNoneNative EOA\nMultisigt-of-n co-signersHigh; quorum per\naction\nNone; logic\npublic\nSmart\ncontract based\nERC-4337\nSmart\nAccounts\nOn-chain policy\nlogic\nMedium to high;\ncustom logic and\ngas\nNone; logic\npublic\nRequires\nERC-4337\nchain support\nCustodiansCustom RBAC or\nABAC languages\nNone; Off-chain\nenforcement\nCustodian sees\nall activity\nAPI mediated\nLiquefactionTEE key\nencumbrance;\npolicy trees\nMedium; Oasis\ncontracts and gas\nStrong; TEE\nhides\nsubpolicies\nRequires Oasis\ndeployment\nPASS\n(ours)\nProvenance via\nInbox-Outbox\nNone; EOA\ncompatible\nStrong;\ninternal\ntransfers\ninvisible\nNative EOA\nplus off the\nshelf TEEs\nFig. 1. Comparison of wallet architectures. PASS features provenance-based control,\noff-chain privacy, and native EOA compatibility.\nPASS instead enforces policy off-chain in a TEE, achieving intent–execution\nseparation akin to account abstraction but without revealing rules or consuming\nchain resources.\nCustodial Key Management and Policies Institutional custody platforms (eg.,\nFireblocks, Turnkey, Privy) control key use with Role-Based Access Control\n(RBAC) or Attribute Based Access Control (ABAC) engines with custom pol-\nicy languages [?,?]. PASS adopts a provenance-centric alternative: authority fol-\nlows asset origin and transfer history, similar to a UTXO model. This reduces\npolicy-surface complexity, as no additional policy language is required, while\nmaintaining composability with additional rules such as whitelists and black-\nlists.\nTrusted Execution Environments and Liquefaction Trusted Execution Environ-\nments (TEEs) provide a hardware-isolated context for secure key storage and\ncomputation, shielding sensitive logic from the host system while providing re-\nmote attestation capabilities [?,?]. Liquefaction [?] keeps the wallet key inside a\nTEE and enforces multi-user sub-policies via key encumbrance, yielding strong\nprivacy. PASS extends this line of research by (i) providing Lean 4 formalization\nof core security invariants, (ii) simplifying access enforcement to a provenance\nrule realized through two special subaccounts (Inbox/Outbox) rather than a\nbespoke policy tree, and (iii) operating with a standard EOA and no new con-\ntracts to improve composability with mainstream TEE systems, in contrast to\nLiquefaction’s reliance on Oasis smart contracts [?]. To further demonstrate the\ngenerality of our approach, we implement PASS on two distinct TEE hard-\nware platforms: AWS Nitro Enclaves and Intel TDX, leveraging the open-source\n4J. Yu\ndstack TEE toolkit for the latter, and showcase prototype applications of PASS,\nincluding an AI agent wallet framework, private payrolls and supply chains, and\nsecure DAO voting.\nOther Related Models Centralized exchanges often pool funds in omnibus ad-\ndresses and track balances off-chain [?]; privacy mixers (eg., Tornado Cash) sever\ndeposit–withdrawal linkages [?]. PASS similarly preserves off-chain privacy for\ninternal transfers while maintaining an internal provenance ledger for account-\nability and regulatory workflows; external observers still see only deposits to and\nwithdrawals from the public EOA.\n3 System Model and Design\nFig. 2. Overview of PASS. External deposits enter the Inbox and are claimed by sub-\naccounts. Internal transfers are private and off-chain. Egress occurs via the Outbox,\nwhich signs and broadcasts on-chain transactions. All on-chain activity has clear prove-\nnance; internal movements remain private.\n3.1 High level system model\nPASS is a multi-user wallet on a single EOA (sk, pk). The wallet maintains a\nfinite set of subaccounts U ={u\n1\n,...,u\nn\n} and a set of assets A (e.g., ERC-20).\nA subaccount u ∈ U has authority over an amount x of asset α ∈ A iff it can\nobtain a signature from the global sk via the enclave; sk resides only inside a TEE\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets5\nand is never directly accessible. We give the intuitive model here and formalize\nit in Section ??.\nInternally, PASS tracks balances with a map L : U ×A →Z\n≥0\n(accessed\nvia L[u][α]), an Inbox multiset I of unclaimed deposits (α,x,m), an Outbox\nFIFO queueO of pending on-chain actions (α,x, extDst,ν) together with a global\nnonce ν ∈N, and an append-only provenance logH. The core principles of PASS,\nas shown in Figure ?? are as follows:\n1. Access follows provenance. A unit of value is usable by u only if there\nexists a custody chain in H from an external deposit to u. Informally,\nAllow(u,α,x) means balance x is reachable for u via provenance in H. This\nimplies consistency : for every α, the total internal balance equals the on-\nchain balance at pk, i.e.,\nP\nu∈U\nL[u][α] = B\non\n(α). Incoming deposits (α,x,m)∈\nI are “wrapped” and must be explicitly claimed before use by the sender\naddress.\n2. Off-chain privacy. Internal transfers u→ v update only L and H; they do\nnot touch O or the on-chain balance B\non\n, so internal flow is invisible and\nfee-less.\n3. First-come, first-served. Outbox transactions are sequenced by a FIFO queue,\nwhich maintains and increments a global nonce ν and directly sends enclave-\nsigned transactions to a RPC node to prevent nonce conflicts and replay\nattacks.\nOrganizational Ownership Model. PASS operates under an organizational own-\nership model, where an entity such as a company, individual, or DAO manages\nshared control over blockchain assets. We detail the threat model in Section ??.\nInbox-Outbox Gateway External senders transfer assets to pk, creating Inbox en-\ntries (α,x,m)∈I. A user performs claim(u,α,x,m) to move value intoL[u][α],\nconceptually “wrapping” the deposit. To withdraw or interact with a contract,\na subaccount first performs an internal transfer to the Outbox, which enqueues\n(α,x, extDst,ν); the enclave then signs the concrete transaction with sk and im-\nmediately broadcasts it, incrementing ν. The FIFO discipline and global nonce\nserialize actions and prevent races and double-spends. Because subaccounts never\nreceive pre-signed transactions, pre-signing misuse is mitigated.\nComposable policy scheme. Deposits are claims fromI; internal transfers require\nAllow(u,α,x) and update (L,H); withdrawals are internal transfers toO followed\nby submission. Additional constraints (eg., RBAC or ABAC checks, whitelists\nand blacklists) can be incorporated as conjuncts to Allow without changing the\nprovenance-centric rule or its consistency and privacy effects.\n3.2 Formal Model\nWe formalize PASS as a transition system in Lean 4\n3\n, an interactive theorem\nprover with a rich dependent type system [?], suitable for policy verification (eg.,\n3\nLean 4 model: https://github.com/pass-wallet/pass-lean4-proofs\n6J. Yu\nAWS Cedar [?]). In this section, we introduce the formal system we modeled in\nlean, and in Section ?? we will discuss security invariants modeled. An extended\ndiscussion of our formal verification system can be found in Appendix ??.\nState. A wallet state is S =\n\u0000\npk, sk,ν,I,O,L,H\n\u0001\nwhere (pk, sk,ν) are the EOA\npublic key, private key (generated and held in the TEE), and global nonce; I\nand O are Inbox and Outbox; L is the internal balance map L[u][α] ∈Z\n≥0\n;\nandH is the provenance history. For privacy arguments we also use the external\nview W\npub\n= (pk,O,A), where O contains the Outbox queue and nonce and A\nrecords total on-chain balances by asset.\nTransitions. Operations op∈ T update S with type-checked rules: InboxDeposit\nadds an unclaimed (α,x,m) to I; ClaimInbox moves (α,x,m) from I to L[u][α]\nand appends toH; InternalTransfer moves value between subaccounts; Withdraw\ndebits L[u][α], enqueues (α,x, extDst,ν) in O, and logs; SignGSM authorizes\ndomain-scoped signable messages. A representative rule is:\n\u0000\npk, sk,ν,I,O,L,H\n\u0001\ntransfer(α,x,u\ns\n,u\nr\n)\n−−−−−−−−−−−→\n\u0000\npk, sk,ν,I,O,L\n′\n,H\n′\n\u0001\nwith\nif L[u\ns\n][α] < x or ¬checkAllow(u\ns\n,α,x,H) then ⊥;\nL\n′\n[u\ns\n][α] =L[u\ns\n][α]− x, L\n′\n[u\nr\n][α] =L[u\nr\n][α] + x;\nH\n′\n=H\n\f\n\f\n\u0000\nop = transfer,α,x,u\ns\n,u\nr\n\u0001\n.\nHere checkAllow queries provenance inH and can be extended with auxiliary\nconstraints such as user whitelists or blacklists, without changing the core rule.\nFigure ?? provides a formal specification of the methods in a PASS wallet.\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets7\nPASS Wallet Management Functionality F\nΣ\nPASS\nfor wallet W\nGlobal State:\npk : public address (EOA)\nsk : private key (in TEE)\nν: global nonce for on-chain transactions\nI (Inbox): set of unclaimed deposits (α : asset,x : amount,m : depositId)\nO (Outbox): FIFO queue (α,x, extDst,ν)\nL (Asset Ledger): internal map L[u][α]∈ Z\n≥0\n, where u is each user’s ID in the system\nH (Provenance History): a list of transaction records appended whenever ClaimInbox,\nInternalTransfer, or Withdraw is invoked\nCreatePassWallet (creator ):\nI← ∅, O← ∅, L←{}; ν← 0\n(pk, sk )← TEE\nKeyGen()\nReturn new W with S =\n\u0000\npk, sk,ν,I,O,L,H\n\u0001\nand reference to creator\nInboxDeposit (α,x,m) from external P :\nI ← I ∪ {(α,x,m)}\nReturn success\nClaimInbox (α,x, depositId) from u:\nIf no (α,x,m) with depositId in I, return ⊥\nRemove (α,x,m) from I\nL[u][α]←L[u][α] + x\nH←H| (op = claim,α,x, depositId,u)\nReturn success\nCheckAllow (u\nsend\n,α,x,H):\nIf H.GetProvenance(α, u\nsend\n)≥ x,\nreturn true; else return false\nInternalTransfer (α,x,u\nsend\n,u\nrecv\n):\nIf L[u\nsend\n][α] < x or ¬checkAllow(u\nsend\n,α,x,H), return ⊥\nL[u\nsend\n][α]←L[u\nsend\n][α]− x\nL[u\nrecv\n][α]←L[u\nrecv\n][α] + x\nH←H\n\f\n\f\n\u0000\nop = transfer,α,x,u\nsend\n,u\nrecv\n\u0001\nReturn success\nWithdraw (α,x,u\nsend\n, extDst):\nIf L[u\nsend\n][α] < x or ¬checkAllow(u\nsend\n,α,x,H), return ⊥\nL[u\nsend\n][α]←L[u\nsend\n][α]− x\nO ←O∪{(α,x, extDst,ν)}\nH←H | (op = withdraw,α,x,u\nsend\n, extDst)\nReturn success\nSignGSM (dom, msg,u):\nIf u lacks sign-right for (dom, msg), return ⊥\nσ ← (sk, msg)\nReturn σ\n(Outbox Processing) (periodic or on demand):\nIf O ̸= ∅, dequeue (α,x, extDst,ν)\nBuild tx τ : transfer x of α to extDst, nonce = ν\nσ ← (sk, τ ); broadcast (τ,σ)\nν←ν + 1\nReturn broadcasted + txHash\nFig. 3. Formal Model of PASS wallet functionality, including CreatePassWallet for\ninitializing a fresh instance. On creation, pk is set to a chosen EOA address eoa, the\nTEE generates a hidden private key sk , and global data structures are initialized.\nExternal deposits enter I (Inbox), while subaccount transfers update L (Ledger) off-\nchain. Withdrawals queue items in O (Outbox), and GSM operations are signed using\nsk .\n3.3 Asset Model and General Signable Messages\nPASS provides an authorization scheme over a heterogenous set of assets A, in-\ncluding fungible tokens, such as ether and ERC-20 tokens, ERC-721 non-fungible\ntokens, and “general signable messages” across a variety of DApps for sign-in\n8J. Yu\nand identity verification. Each asset α ∈ A has a well-defined custody path in\nthe provenance log H, and a subaccount u ∈ U has usable balance x of α iff\nAllow(u,α,x) holds.\nToken assets. For token assets such as ether, ERC-20, and ERC-721, deposits are\ncaptured as Inbox entries (α,x,m)∈I. Claims allocate balance intoL[u][α], in-\nternal transfers updateL andH privately, and withdrawals enqueue (α,x, extDst,ν)\ninto O for enclave signing and on-chain broadcast, ensuring consistency where:\n∀α∈A\ntokens\n:\nX\nu∈U\nL[u][α] = B\non\n(α, pk).\nIn particular, ERC-721 tokens are modeled as unitary balances (x ∈ {0, 1})\nwhose transfers preserve uniqueness under provenance.\nGeneral Signable Messages (GSMs). In addition to on-chain assets, wallets often\nsign arbitrary messages, such as for EIP-4361 [?] logins and off-chain DAO votes\n[?]. PASS models these as a special class A\nGSM\nof virtual assets. Each GSM\nasset is scoped to a domain dom, so holding α = (dom) represents authority to\nsign messages from that domain. A signature operation:\nSignGSM(u, dom,m)7→ σ\nis permitted iff Allow(u, dom, 1) holds in H. At key generation, the wallet\ncreator is endowed with default signing authority over all domains, represented\nas an initial allocation of every α = (dom)∈A\nGSM\nto the root subaccount. These\ndomain assets can be internally transferred to delegate signing authority. Thus\nprovenance of GSMs begins at the owner and flows through transfers, providing\na well defined provenance path in H as with token assets.\nBy treating both tokens and GSMs as types of elements ofA, PASS provides\na unified provenance rule for subaccount authorization. A subaccount cannot\nspend an ERC-20 token, transfer an NFT, or sign a domain message unless it\npossesses the corresponding asset under L and H. This unified authorization\nscheme allows for fine-grained delegation, (eg., giving u rights over example.com\nwhile withholding ERC–20 funds) and consistent enforcement across on-chain\nand off-chain actions.\n4 Properties of PASS\n4.1 Threat Model\nPASS assumes an organizational ownership model, where a single entity, such\nas a company, individual, or DAO manages the EOA (pk,sk), brokers access\nbetween many users in that entity, and chooses the TEE infrastructure vendor\n(eg. AWS Nitro, dstack Intel TDX, self-hosted hardware). This model is typical\nfor use cases such as private payroll, supply chains, and AI delegation described\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets9\nin Section ??. Protected assets in PASS include the private key sk, the balance\nledger L and provenance log H, and the correctness of Allow(u,α,x) for all\nu∈ U,α∈A,x. In our model, we make the following trust assumptions:\n1. TEE integrity. Hardware isolation is sound; sk never leaves the enclave.\nRemote attestation guarantees that the enclave runs the genuine PASS bi-\nnary.\n2. Cryptography. Standard primitives (signatures, hash functions, PRFs) are\nsecure against polynomial-time adversaries.\n3. Governance majority. The deploying entity holds majority control in the\ngovernance mechanism (via DAO vote or admin privileges), ensuring it can\ninvoke the blockchain-governed KMS for MPC-based key recovery and trig-\nger fallback contracts when needed.\nAdversary Model. An adversaryA may control the host OS and network, observe\nor modify all communication with enclaves, and submit arbitrary transaction\nrequests. In particular, A may attempt to:\n– Exploit software bugs in the PASS implementation or TEE runtime,\n– Forge or replay transactions to break consistency of H,\n– Subvert provenance by violating Allow(u,α,x)\nThreats Out of Scope. On the other hand, PASS does not protect against:\n– Physical compromise of TEE hardware (tampering, microarchitectural side-\nchannels, chip decapsulation),\n– Supply-chain backdoors in TEE manufacturing,\n– Fully malicious operators with unrestricted physical access.\nThese are excluded because the organizational model assumes controlled facilities\nand vetted hardware.\nSecurity Goals. Given the assumptions above, PASS guarantees:\n1. Integrity:\nP\nu∈U\nL[u][α]≤ extDep(α) for all α, i.e., no assets can be created\nor double-spent internally.\n2. Correctness: If Allow(u,α,x) holds, then u can eventually realize x via\nWithdraw.\n3. Privacy on-chain: InternalTransfer operations do not affect externalTrace(W ),\nand to external observers, a PASS wallet is indistinguishable from an EOA.\n4. Liveness: For any authorized op ∈ Ops, if one enclave and quorum remain\nhonest, then ∃τ s.t. Exec(c, op) =⊤ within τ\n4.2 Privacy and Safety\nAfter establishing the threat model of PASS, we will address the central pri-\nvacy and safety guarantees. We sketch three central lemmas here, and create\nmechanized proofs in Lean, discussed in Appendix ??.\n10J. Yu\nProposition 1 (Internal Transfer Privacy). If two public states W\n1\n,W\n2\nshare the same pk, identical Outbox (T,ν), and equal per-asset totals in A, then\nexternalTrace(W\n1\n) = externalTrace(W\n2\n).\nProof Sketch. InternalTransfer updates only (L,H), never O or total on-chain\nbalances. OutboxProcessing in Figure ?? emits on-chain actions solely from O\n(lines 2–4), hence the trace depends only on O.\nCorollary: EOA indistinguishability. If W\npass\nand W\neoa\nshare the same pk,\nOutbox, and per-asset totals, then\nexternalTrace(W\npass\n) = externalTrace(W\neoa\n).\nThus, from an external observer’s perspective, a PASS account is indistinguish-\nable from a standard EOA: internal transfers leave no observable footprint.\nProposition 2 (Asset Accessibility). For any asset α, letting L = {u |\nL[u][α] > 0},\nX\nu∈L\nL[u][α] = totalBalance(α),\nand each u∈ L can spend its full balance subject to checkAllow.\nProof Sketch. ClaimInbox creditsL; InternalTransfer preserves the sum over u;\nWithdraw debitsL and enqueues toO, which OutboxProcessing realizes on-chain.\ncheckAllow enforces reachability from provenance in H.\nProposition 3 (Provenance Integrity). Let extDep(α) be net external de-\nposits (deposits minus realized withdrawals). For all reachable states,\nX\nu\nL[u][α] ≤ extDep(α).\nProof Sketch. Induct on transitions. InboxDeposit increases extDep only; Claim-\nInbox moves already-deposited value into L; InternalTransfer conserves the sum\nover u; Withdraw decreases the sum, and after OutboxProcessing broadcasts,\nextDep is reduced accordingly.\nGeneral signable messages (GSM). Model GSM rights as a domain-scoped vir-\ntual asset class A\nGSM\n. Let α = (dom)∈A\nGSM\nand permit\nSignGSM(u, dom,m) iff Allow(u,α, 1).\nThen (P2)–(P3) lift to GSM: there is always at least one domain signer, and\nGSM “balances” obey provenance conservation under transfers in H.\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets11\n4.3 Liveness\nWe define liveness as the property that any authorized operation remains even-\ntually executable, despite enclave crashes, vendor compromise, or partial gover-\nnance failure. Our model assumes deployment of PASS access logic on dstack,\nimplemented in Section ?? and detailed in Appendix ??.\nLet E denote active enclaves, C containerized wallet backends, and P gover-\nnance policies. Each container c∈C stores sealed state\nσ\nc\n=⟨S,k\nc\n, meta⟩ with S = (pk, sk,ν,I,O,L,H),\nwhere k\nc\n= Derive(K,c) is derived from an MPC-managed KMS and meta records\nattestation. An operation op ∈ Ops (deposit claim, transfer, withdrawal) ex-\necutes as: Exec(c, op) = ⊤ iff Attested(c)∧ Γ (S), where Attested(c) checks σ\nc\nagainst registry R and Γ is the quorum predicate over P. To ensure vendor-\nagnostic portability, state migration μ :E →E satisfies\n∀e\ni\n,e\nj\n∈E, e\nj\n.decrypt(σ\nc,e\ni\n,k\nc\n) = σ\nc,e\ni\n,\nTheorem 1 (Liveness Theorem). If (i) the MPC KMS tolerates f\nKMS\nfaults\nin a t-of-n threshold, (ii) governance quorums are f\ngov\n-resilient, and (iii) at least\none enclave is uncompromised, then every op∈ Ops executes within bounded time\nτ :\n∀op∈ Ops, ∃τ ≥ 0 : Exec(c, op) =⊤.\nProof Sketch. Progress follows from three guarantees: (1) the MPC KMS ensures\nk\nc\nis always recoverable under threshold availability; (2) Γ encodes quorum rules\nthat eventually relax after timeout ∆t, ensuring some subset S satisfies Γ (S) =\n⊤; (3) migration μ allows any enclave to re-host σ\nc\n, preventing vendor lock-in or\nenclave failure from blocking execution. Algorithm ?? formalizes recovery and\nexecution under these assumptions.\nAlgorithm 1 RecoverAndExecute(c, op)\n1: Verify enclave e attestation Q\ne\nagainst R.\n2: Derive k\nc\n← Derive(K,c); decrypt σ\nc\n.\n3: if CompromiseDetected(e\n′\n) then\n4:Rotate k\nc\nand re-encrypt σ\nc\n.\n5: end if\n6: Ensure Γ (S) =⊤ for S ⊆P(c).\n7: Execute op; append to H.\nKey Properties. (1) Portability: any attested enclave can recover σ\nc\n, independent\nof vendor; (2) Monotonic Recovery: recovery steps form ρ :S →S with ρ(s)⪰ s;\n(3) Domain Continuity: certificates remain bound toR(c) under migration μ(c),\npreventing hijack or replay.\nImplementation details of container orchestration, attestation, and KMS pro-\ntocols are given in Appendix ??.\n12J. Yu\n5 Practical Implementations\n5.1 Prototype Implementations\nTo demonstrate feasibility, we have implemented a prototype of PASS that cap-\ntures the core architectural components.\n4\nThe prototype consists of:\n– Provenanced Access Model, the core PASS architecture outlined in Sec-\ntion ?? with the Inbox-Outbox structure, asset ledgers, and provenanced\nrule as a Rust executable.\n– Web Application Frontend, an AWS-hosted Typescript interface that\nallows users to deposit assets, initiate internal transfers, generate on-chain\ntransactions, and sign arbitrary messages on Ethereum Sepolia testnet.\n5\n– Multi-vendor TEE deployment, we deploy the PASS enclave executable\nin both AWS Nitro Enclaves and Intel TDX with the dstack framework.\nWe evaluate these two enclave deployments as complementary deployment\npaths, each with distinct tradeoffs.\nAWS Nitro Enclaves. In this design, PASS runs inside a Nitro enclave in the\nAWS cloud. The enclave executes the Inbox–Outbox logic, enforces provenance\nchecks, and signs transactions, while the provenance ledger is stored externally.\nNitro’s attestation and AWS integration simplify deployment, but reliance on a\nsingle vendor limits portability and concentrates trust. As a result, some guaran-\ntees of PASS, particularly liveness and asset accessibility, may be weaker under\nthis model.\nIntel TDX with dstack. dstack provides a portable, open-source runtime for\nTEEs across diverse hardware. PASS can be deployed on enclaves run by decen-\ntralized operators, with key material secured via MPC-based key management.\nBoth Inbox–Outbox logic and the provenance ledger execute inside dstack, pre-\nserving the full security properties of Section ?? and reducing vendor lock-in.\nThe tradeoff is added governance complexity over operator authorization and\npolicy enforcement.\n5.2 Performance Benchmarks\nTo evaluate PASS, we benchmarked both AWS Nitro Enclaves and Intel TDX\nbackends across common operations: balance queries, transfers, withdrawals,\nclaims, wallet creation, provenance queries, and an end-to-end workflow. Each\noperation was run 100 times over 10 trials per environment, measuring through-\nput in ops/sec. Both environments used identical 4-core, 2.5 GHz, 16 GB VMs\nto ensure fair comparison. Table ?? summarizes our results, with full details\navailable in Appendix ??.\n4\nPrototype can be found here: https://github.com/jayyu23/pass-wallet-app\n5\nWeb application: https://pass-wallet.jayyu.xyz/\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets13\nFig. 4. Internal PASS operation throughput (ops/sec) across AWS Nitro Enclaves\nand Intel TDX. All operations are in-memory state changes within the TEE with no\nblockchain interaction. Each value represents the average of 100 operations repeated\n10 times per environment.\nOperationAWS Nitro Intel TDX\nWallet Creation6,53114,970\nAccount Balance Queries530,943935,428\nInbox-to-Subaccount Claims14,85633,064\nInternal Subaccount Transfers32,95371,292\nWithdrawal Request Creation18,29139,702\nEnd-to-End Workflow\n6\n35,66378,433\nTransaction History Queries3,7577,685\nMulti-threaded Operations (5 threads)32,18955,124\nLarge Dataset Processing481724\nThe observed performance differences between AWS Nitro Enclaves and In-\ntel TDX primarily stem from their distinct hardware architectures. AWS Nitro\nEnclaves employ a disaggregated system design, where the host server and the\nTEE hardware are physically separated. Communication between the host and\nthe enclave occurs via vsock, and the enclave itself runs on a dedicated, lower-\nperformance coprocessor. In contrast, Intel TDX leverages a special instruction\nset to provide enclave functionality directly on the main processor, eliminating\nthe need for a separate coprocessor and avoiding the overhead of data transfer\nbetween disparate components. As a result, Intel TDX is able to deliver sig-\nnificantly higher throughput for in-enclave operations compared to AWS Nitro\nEnclaves, as reflected in our benchmark results.\nThese preliminary benchmarks show that both Nitro and TDX backends can\nsustain high throughput for critical wallet operations, confirming that PASS is\npractical for real-world deployment. Further evaluation of latency distributions,\nconcurrency scaling, and memory footprint is left for future work. [Jay: Make prose\nremarks on Liquefaction performance, and why PASS is better]\n6 Applications\nPASS is a powerful primitive that enables several classes of applications.\n[Jay: To clean up and think better on how to frame directions - maybe (1) delegating\nto AI agents, (2) private payroll and supply chain, (3) DAO voting, (3) cross chain bridge\n+ CLOB exchange. Maybe a small application table?]\nOrganizational Wallets and Institutional Custody. An organization (company,\nuniversity, DAO) often needs to manage a single blockchain address for branding\nor transparency reasons (e.g., stanford.eth) while delegating control to multi-\nple individuals internally. The university could maintain stanford.eth as the\nmain address, and issue sub-accounts [email protected], [email protected]\n14J. Yu\nCategoryApplicationContextPASS Enables\nDelegation\nAI Agents\nDelegation\nAI agents increasingly\ninteract with crypto\nassets and\nprotocols [?].\nScoped subaccounts holding limited\nfunds or domain-scoped signing rights;\ndelegate safely to agents without\nexposing the wallet’s root key; revoke\nby moving balances out.\nDAO VotingDAOs rely on\naddress-based voting\nand delegation [?].\nPrivate sub-delegation of voting rights,\nprovenance keeps delegation auditable\nwithin PASS. Can also domain-restrict\ndelegators to voting DApps only.\nSubdomain\nProfile Pages\nOrganizations map\nENS or sub-identities\nto individuals/teams.\nMultiple subaccounts under one public\nidentity (e.g., [email protected]);\nper-subaccount balances and signing\nscopes with internal provenance.\nEnterprise\nPrivate\nPayroll\nOn-chain payroll can\nleak sensitive\ncompensation data.\nSalary distribution via internal\ntransfers (gasless, private) with an\nauditable internal log; withdrawals\nbatch via Outbox when needed.\nCompliant\nOrganization\nWallets\nOrganizations have a\npublic address with\ninternal access control\nand BSA\nrecordkeeping [?].\nDepartment and individual\nsubaccounts with explicit budget\nallocations. Provenance-based asset\naccountability upon regulator request.\nPrivate\nSupply Chains\nMulti-party B2B\npayments often\nrequire confidentiality\nacross tiers.\nSubaccount-based vendor channels\nwith private internal netting; only net\nsettlements leave via Outbox, reducing\nleakage while retaining internal\nauditability.\nCross Chain\nCross-chain\nBridge\nBridges require\ncustodial control and\ncareful key\ngovernance [?].\nInbox/Outbox enforce provenance\nboundaries across chains; scoped\nsubaccounts for operators; FIFO nonce\nhandling to avoid race conditions.\nGasless CLOB\nExchange\nFrequent on-chain\norder placement is\ngas-heavy for users.\nInternalize order matching/settlement\nbetween subaccounts off-chain;\nperiodically net out via Outbox so end\nusers experience gasless trading.\nL2\nComposability\nRollups/L2s fragment\nassets and UX [?].\nTreat L2s (or other domains) as\nscoped subaccounts; balance privately\nacross internal ledgers; settle\nexternally only when crossing domains.\nFig. 5. Applications of PASS across delegation, enterprise, and cross-chain contexts.\nfor different departments or team members. Each person gets a sub-account with\ncertain assets allocated or certain transaction rights. They can transact inter-\nnally for accounting without fees, and when needed, withdraw funds to external\nvendors. The provenance log ensures every outgoing fund can be traced to which\ninternal sub-account, aiding accountability, while external parties only interact\nwith the official address.\nDelegating to AI or Smart Agents. As autonomous agents start managing crypto\nassets for trading or DAO governance, there is a need to constrain their access.\nAn AI agent could be given a sub-account that only holds limited funds or\ncertain asset types. The AI can operate freely within those bounds, but cannot\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets15\nexceed its allotted assets or misuse other wallet assets. If compromised, damage\nis capped to its sub-account. This is much safer than giving AI the keys to an\nentire wallet.\nOrganizational Privacy Enhancement. Within the organizational ownership model,\nPASS provides privacy benefits for legitimate internal operations. Because in-\nternal transfers are off-chain, organizations can maintain confidentiality around\ntheir internal fund allocations and departmental transfers while still providing\nfull transparency for external interactions. This is particularly valuable for or-\nganizations that need to balance internal operational privacy with external ac-\ncountability requirements. Unlike general privacy mixing systems, this applica-\ntion aligns with the organizational ownership model where the entity controlling\nthe TEE has legitimate oversight of all activities within the system.\nIntegration with Off-chain Scaling Solutions. The concept of segregating internal\ntransfers from on-chain actions is analogous to how rollups and sidechains work\n(off-chain transactions batched into occasional on-chain commitments). PASS\ncould potentially integrate with Layer-2 networks by treating a whole sidechain\nor rollup as a “sub-account” or by using PASS ’s provenance model to bridge\nassets. For example, depositing funds into a rollup could be managed via an\nInbox-like mechanism, and withdrawing via an Outbox, with PASS ensuring\nthat assets are not double-spent across L1 and L2. While speculative, modeling\na rollup’s internal accounts using PASS might provide a unified view of assets\nacross layers, or allow a user to move assets between L2s through an enclave\nwithout trusting a centralized exchange. This is an area for future exploration.\nOrganizational TEE Management. PASS’s security model assumes that orga-\nnizations have the capability to properly manage TEE infrastructure. While\nthis eliminates concerns about physical attacks (as organizations can implement\nappropriate security controls), it requires organizations to maintain proper op-\nerational security practices. Organizations must ensure TEE software integrity\nthrough remote attestation, implement secure key management policies, and\nmaintain appropriate governance frameworks. For organizations without suffi-\ncient technical expertise or security infrastructure, partnering with specialized\nTEE service providers may be necessary. This organizational responsibility rep-\nresents both a strength (simplified threat model) and a limitation (requires or-\nganizational technical capability) of the PASS approach.\n7 Future Work\n7.1 Composability and InterPASS Transactions\nWhile PASS provides privacy and provenance guarantees for a single wallet in-\nstance, an important question is how multiple PASS wallets may interact. This\nis important in supply-chain use cases where each PASS represents a single com-\npany in the supply chain.\n16J. Yu\nTrivially, PASS A can send an on-chain transaction from its Outbox to PASS\nB’s EOA account, and this will land in the Inbox of PASS B, ready to claim.\nHowever, this undermines the privacy guarantees that PASS offers at the EOA\nlevel, and is undesirable in cases where inter-organizational asset transfers con-\ntain sensitive information, such as order details.\nWe propose a non-trivial approach inspired by cross-Payment Channel Net-\nwork (PCN) protocols such as XTransfer [?]. We can treat each PASS instance\nakin to a PCN hub node, with state L and transaction history H. As with\nXTransfer, we can assume a star topology of PASS nodes, with a central PASS\nHub in communciation with all PASS nodes. The PASS Hub will aggregate all\nInterPASS transactions T := {(a\ni\n,x\ni\n,s\ni\n,r\ni\n)}\nn\ni=1\n, where (a\ni\n,x\ni\n,s\ni\n,r\ni\n) represent\nthe asset, amount, sender, and receiver, each signed by the s\ni\nOutbox.\nThe Hub aggregates these signed payment intents, computes a netted settle-\nment plan S, and coordinates a secure multi-party update protocol to commit\nthe resulting balances, similar to Thora [?]. In the optimistic case, this process\ncompletes entirely off-chain, and each participant’s balance is updated in the\nPASS ledger without revealing the underlying transaction graph. If a dispute or\nfailure occurs, any participant may trigger an on-chain enforcement transaction\nthat finalizes S atomically via the direct transfer mechanism, thus guaranteeing\nsafety.\nThis approach leverages PASS ’s provenance and state design to make each\ninstance an atomic node in PCN-style systems like X-Transfer. Here, we outline\nhow PASS Hubs can enable confidential, auditable cross-organization transfers,\nwhile full formal specification and protocol implementation is deferred for future\nwork.\n7.2 Instantiation on zkVM\nZero-knowledge virtual machines (zkVMs) provide a proving environment where\narbitrary state machines can run with strong correctness guarantees [Jay: cite].\nBy producing a succinct proof π of execution, zkVMs offer integrity assurances\nsimilar to TEEs but without hardware attestation. This makes them especially\nsuited for financial custody and inter-organizational accounting, where external\nverifiability and regulator-grade auditability are critical.\nTo realize PASS within a zkVM, transaction requests are first queued outside\nof the proving environment. Once a batch is formed, the zkVM program takes\nas its private inputs the prior batch’s commitments of the ledger L and prove-\nnance log H, the set of state transitions in the current batch, including inbox\nI deposits and outbox O withdrawals, and the proposed new commitments for\nL and H. The zkVM then replays the computation: it begins from the previous\nroots, applies all queued transitions in sequence, and recomputes both balances\nand provenance entries. The proof π attests that these recomputations match\nthe declared new commitments and that all outbox deltas are consistent. A min-\nimalist verifier contract on chain simply checks π, updates the recorded roots,\nand enforces outbox execution. In this way, the privacy and provenance guar-\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets17\nantees of the original PASS design are preserved while augmenting them with\nrigorous computational proofs of correctness.\nThis formulation aligns with the Chainless stack architecture [?], which em-\nphasizes clear separation of execution, trust, bridging, and settlement. By sit-\nuating zkVM-based PASS execution within such a layered model, integration\nwith external systems can be achieved in a modular and interoperable manner.\nWe defer full formal implementation and specification for future work.\nFig. 6. PASS instantiation inside a zkVM: Inbox I and Outbox O transitions are\napplied to the Ledger L and Provenance H, producing new state commitments. The\nzkVM outputs a proof π, which the on-chain verifier checks before updating roots and\nenforcing outbox operations.\n7.3 Expansion of Formal Model and Further Benchmarks\n[Jay: TODO]\n18J. Yu\n8 Conclusion\nWe presented PASS, a Provenanced Access Subaccount System, as a new wallet\narchitecture that enforces access by provenance rather than by identity or role.\nThe Inbox–Outbox mechanism ensures all assets have a verifiable lineage, while\ninternal transfers remain private and indistinguishable from a standard EOA\naccount.\nOur contributions are threefold: (i) a formal model in Lean 4 proving pri-\nvacy, accessibility, and provenance integrity; (ii) a working prototype with en-\nclave backends on AWS Nitro Enclaves and Intel TDX via dstack, integrated\nwith WalletConnect; and (iii) initial benchmarks showing the feasibility of high-\nthroughput operation. These results demonstrate that provenance-based control\ncan be realized today with mainstream blockchain tools.\nLooking forward, richer evaluations across multi-vendor TEEs, integration\nwith zero-knowledge VMs, and exploration of organizational and agent-based\ncustody are promising directions. By combining rigorous formal guarantees with\ndeployable prototypes, PASS advances the design space between strict self-\ncustody and flexible shared access, offering a path toward practical, privacy-\npreserving wallet security.\nA Formal Verification\nWe consider the formal model introduced in Section ?? of PASS as a state\nmachine in Lean4. Our goal is to prove that, under the PASS design, several\ncritical security properties always hold. We outline these properties and our\napproach to verifying them.\nA.1 Property: Privacy of Internal Transfers\nIn the PASS design, the InternalTransfer operation updates only the off-chain\nledgerL and the provenance historyH. It never modifies the OutboxO, meaning\nthere is no on-chain transaction triggered by an internal transfer. Consequently,\nexternal observers see no change in on-chain state. We formalize this by consid-\nering the on-chain view that an external party has for a given PASS Wallet. We\ncan model this visible on-chain state as a triple:\nW\npub\n=\n\u0000\npk, O, A\n\u0001\n,\nwhere:\npk is the externally owned account (EOA) address,\nO = (T,ν) is the external view of the outbox, where T is a list of enqueued\ntransactions and ν is a nonce,\nA is the external view of the Asset ledgerL, containing a list of asset entries,\neach of the form (α,x) with a unique identifier α and total balance x.\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets19\nExternal Trace. The external trace of a PassAccount state W\npub\nis the list of\nexternally visible actions, obtained by mapping each transaction in the outbox\nT to an on-chain action:\nexternalTrace(W\npub\n) =\n\b\noutboxTx(t) | t∈ T\n\t\n.\nNo internal transfers appear in externalTrace(·).\nStates That Differ Only by Internal Transfers. We say that two PassAccount\nstates W\n1\n= (pk\n1\n,O\n1\n,A\n1\n) and W\n2\n= (pk\n2\n,O\n2\n,A\n2\n) differ only by internal trans-\nfers if:\n1. pk\n1\n= pk\n2\n,\n2. O\n1\n= O\n2\n(i.e. both the list of outbox transactions and the nonce are the\nsame),\n3. For every asset identifier α, the total balance of that asset in A\n1\nequals the\ntotal balance of the same asset in A\n2\n.\nLetting getAsset(W,α) return the asset α within state W or ⊥, we require ∀α:\ntotalBalance\n\u0000\ngetAsset(W\n1\n,α)\n\u0001\n= totalBalance\n\u0000\ngetAsset(W\n2\n,α)\n\u0001\n.\nTheorem 2 (Privacy of Internal Transfers). If two PassAccount states W\n1\nand W\n2\ndiffer only by internal transfers, then their externally visible traces are\nidentical:\nexternalTrace(W\n1\n) = externalTrace(W\n2\n).\nProof. By assumption, O\n1\n= O\n2\n. Hence both states have the same outbox trans-\naction list T . Since\nexternalTrace(W\ni\n) = map\n\u0000\noutboxTx, T\ni\n\u0001\nfor i∈{1, 2},\nand T\n1\n= T\n2\n, it follows that externalTrace(W\n1\n) and externalTrace(W\n2\n) are iden-\ntical.\nThus, any sequence of purely internal transfers, changing only the private ledger\nL in PASS, is invisible to an external observer, preserving the privacy of how\nassets move within the wallet.\nA corollary of this Internal Transfer property is that a PASS account is\nindistinguishable from a regular EOA account.\nCorollary 1 (Indistinguishability from EOA). Let W\npass\nbe a PASS state\nthat (i) has the same public key pk, (ii) the same outbox, including nonce and\ntransaction list, and (iii) the same total balances of each asset as a reference\nEOA state W\neoa\n. Then\nexternalTrace(W\npass\n) = externalTrace(W\neoa\n).\nIn particular, an external observer cannot distinguish W\npass\nfrom W\neoa\n.\nProof. By assumption, the only potential differences betweenW\npass\nandW\neoa\nlie\nin internal ledger details. From Theorem 1, such internal transfers do not affect\nthe externally visible outbox transactions or total on-chain balances. Thus, their\nexternal traces coincide, and W\npass\nis indistinguishable from W\neoa\n.\n20J. Yu\nA.2 Property: Asset Accessibility\nIn addition to keeping internal transactions private, PASS should ensure that for\nevery asset in the system, there exists some sub-account that can access it and\nwithdraw it from the system. This prevents a situation where funds get ”stuck”\nwithout any reachable key or policy to move them. We define asset accessibility\nas follows:\nTheorem 3 (Asset Accessibility). For any PASS account W and asset iden-\ntified by α, there exists a list of addresses L such that:\n1. For every address u∈ L, the user can access their full balance:\ncheckBalance(s,α,u, balance(u)) = true\n2. The sum of all accessible balances equals the total balance of the asset:\nX\nu∈L\nL[u][α] = totalBalance(α)\nProof. We construct L as the set of all addresses with non-zero balances in the\nbalance map for α:\nL ={u|L[u][α] > 0}\nFor the first property, given any u∈ L, the definition of checkBalance verifies\nif the user has sufficient balance for the specified amount. When checking against\nthe user’s own balance, this is trivially satisfied since L[u][α]≥L[u][α] for all u.\nFor the second property, we observe that totalBalance is defined as the sum\nof all balances in the asset’s balance map:\ntotalBalance(α) =\nX\nu∈L\nL[u][α]\nBy construction, L contains the only nonzero values u∈L, so:\nX\nu∈L\nL[u][α] = totalBalance(α)\nTherefore, both properties hold for our constructed list L.\nWe can prove a similar trait for General Signable Messages, showing that for\nany inbound GSM, there is some subaccount signer that has access to it.\nTheorem 4 (GSM Accessibility). For any GSM and domain, there exists a\nuser with signing access to that domain.\nProof. For any domain d, we can directly construct a user u who has signing\naccess to d as follows:\nu = getSigner(d)\nBy definition, getSigner returns either:\n– A specifically assigned signer if one exists in the domain-address map, or\n– The default signer otherwise\nTherefore, every domain is guaranteed to have at least one user with signing\naccess, ensuring no GSM domain becomes inaccessible.\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets21\nA.3 Property: Provenance Integrity\nProvenance integrity specifies that every asset held by any sub-account in PASS\nmust have an origin traceable to an external deposit into the Inbox. At any\nstate of the system, for each asset entry in a sub-account’s balance, we can find\na sequence of internal transfers that leads back to an Inbox deposit from an\nexternal address. This property ensures no sub-account can conjure funds from\nnothing, such as through double-spending or inflation within the system, and\nthat the internal ledger is consistent with on-chain reality. In Lean, we model\nthe state of the PASS wallet including Inbox, Outbox, and all sub-accounts and\nprove an invariant that whenever a sub-account has x units of asset α, the global\nstate contains a record of at least x units of α having been deposited, minus any\nthat have been withdrawn.\nTheorem 5 (Provenance Integrity).\nFor any PASS account S =\n\u0000\npk, sk,ν,I,O,L,H\n\u0001\nand any asset α, the total\namount of α held across all subaccounts can never exceed the total amount of\nexternal deposits (minus any that have already been withdrawn). Formally,\nX\nu∈U\nL[u][α] ≤ externalDeposits(α),\nwhere U is the set of subaccounts in the system, and externalDeposits(α) is\nthe net total of asset α that has been introduced into the wallet from outside\naddresses, recorded in the inbox I.\nProof. We model the system’s state (pk, sk,ν,I,O,L,H) as in Figure ??, includ-\ning the Inbox I, Outbox O, and the internal ledger L. We define a provenance\nrecord P (α,u) that captures the total amount of asset α subaccount u is autho-\nrized to hold, based on Inbox claims and internal transfers.\nBase Case: Immediately after CreatePassWallet, no assets have been de-\nposited, and no subaccount balances exist:\n∀u, L[u][α] = 0, ∀α, externalDeposits(α) = 0.\nHence,\nX\nu∈U\nL[u][α] = 0 ≤ 0 = externalDeposits(α).\nInductive Step: Assume the invariant holds after n− 1 operations. We prove it\nremains valid after the nth operation, for each possible type of operation:\n(1) External Deposit: Suppose an amount x of asset α is deposited into the\nwallet:\nexternalDeposits(α) ← externalDeposits(α) + x.\nNo subaccount balances L[u][α] change. Thus, the left side of our inequality\n(sum of subaccount balances) is unchanged, while the right side strictly\nincreases by x, so the invariant continues to hold.\n22J. Yu\n(2) Inbox Claim: If subaccount u claims amount x of asset α from the Inbox\nI:\nL[u][α] ← L[u][α] + x, P (α,u) ← P (α,u) + x.\nSince x was already accounted for in externalDeposits(α) (but not yet allo-\ncated to any subaccount), the total subaccount balances remain≤ externalDeposits(α).\n(3) Internal Transfer: If subaccount u\n1\ntransfers x of α to subaccount u\n2\n:\nL[u\n1\n][α] ← L[u\n1\n][α]− x, L[u\n2\n][α] ← L[u\n2\n][α] + x,\nand P (α,u\n2\n) increases by x. Because the sum of all subaccount balances\ndoes not change, our invariant is preserved.\n(4) Withdrawal: If subaccount u withdraws x of α:\nL[u][α] ← L[u][α]− x,\nwhich reduces the total subaccount balances. Since externalDeposits(α)\nremains unchanged (assets have simply exited the wallet), the inequality still\nholds.\nThus, by induction over all possible operations,\nX\nu∈U\nL[u][α] ≤ externalDeposits(α)\nfor every reachable state. No subaccount can create new assets out of nothing,\nand all assets in the system are fully accounted for by provenanced deposits.\nB Dstack Architecture and Execution Model\nB.1 Component Overview\n– Dstack-OS: Minimal Linux-based VM image with a verifiable boot chain.\nMeasures bootloader, kernel, root filesystem (RootFs) via RTMR registers.\nIntegrates dm-verity for data integrity and monotonic counters for anti-\nrollback.\n– Dstack-KMS: Blockchain-governed MPC network for key derivation and\nrotation. Provides:\nk\nc\n= HMAC\nk\nroot\n(c\nid\n),\nk\nTLS\n= ECDSA(k\nroot\n).\nRotation is triggered via governance (t-of-n threshold).\n– Dstack-Gateway/Ingress: TLS termination inside TEEs, ZT-TLS bind-\ning X\nc\nto R(c), enabling verifiable HTTPS ingress.\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets23\nB.2 Governance Layer\nTwo contracts form the trust base:\n– KmsAuth: Global registry of KMS nodes and application digests.\n– AppAuth: Per-application contract specifying quorum rules, allowed image\nhashes, and authorized enclaves.\nB.3 Workflow Phases\n1. Attestation: Enclave e produces quote Q\ne\n; verified against R.\n2. Secret Provisioning: MPC nodes compute k\nc\n, release to e if Q\ne\nis valid.\n3. Container Launch: Dstack-OS mounts RootFs, decrypts state σ\nc\nwith k\nc\n.\n4. Ingress Binding: TLS certificate X\nc\ngenerated inside e; bound to R(c).\n5. Audit Logging: Migration, key rotation, and governance events appended\nto H.\nB.4 Fault Tolerance\n– Vendor failure: μ enables re-deployment across Intel/AMD TEEs.\n– KMS compromise: key rotation via MPC thresholds restores forward/backward\nsecrecy.\n– Governance deadlock: ∆t fallback in Γ ensures quorum reduction and progress.\nB.5 Liveness Proof Sketch\nCombining MPC-based key recovery, quorum fallback, and portable containers\nyields:\n∀op∈O\nc\n,Pr[Exec(c, op) =⊤] = 1\nunder assumptions of f -resilient MPC nodes and at least one uncompromised\nTEE instance.\nC Detailed Benchmark Results\nThis appendix provides comprehensive benchmark statistics for both AWS Nitro\nEnclaves and Intel TDX environments. All operations are internal PASS state\nchanges that occur within the TEE with no blockchain network interaction.\nEach operation was executed 100 times per trial, with 10 independent trials\nper environment. The tables below show summary statistics including mean,\nstandard deviation, and range.\n24J. Yu\nTable 1. AWS Nitro Enclaves benchmark statistics (ops/sec) across 10 trials\nOperationMean Std Dev Min Max\nWallet Creation6,5315315,4467,042\nAccount Balance Queries530,943675 530,216 531,915\nInbox-to-Subaccount Claims14,856476 14,326 15,504\nInternal Subaccount Transfers32,9531,322 31,447 35,088\nWithdrawal Request Creation18,2911,254 15,873 19,608\nEnd-to-End Workflow35,6636,234 21,739 40,650\nTransaction History Queries3,757453,6503,802\nMulti-threaded Operations (5 threads) 32,189884 31,200 34,364\nLarge Dataset Processing48113467497\nTable 2. Phala dStack benchmark statistics (ops/sec) across 10 trials\nOperationMean Std Dev Min Max\nWallet Creation14,9704,6528,69624,390\nAccount Balance Queries935,428338,450 383,142 1,470,588\nInbox-to-Subaccount Claims33,0645,197 25,44541,667\nInternal Subaccount Transfers71,29217,623 47,170 101,010\nWithdrawal Request Creation39,7027,434 29,15551,813\nEnd-to-End Workflow78,43317,403 59,524 110,497\nTransaction History Queries7,6858726,4528,929\nMulti-threaded Operations (5 threads) 55,12416,744 28,32981,301\nLarge Dataset Processing72481636893\nC.1 AWS Nitro Enclaves Results\nC.2 Intel TDX Results\nC.3 Performance Analysis\nThe statistical analysis reveals several key insights about PASS’s internal oper-\nation performance:\n– Performance Consistency: AWS Nitro Enclaves demonstrate superior\nconsistency with lower standard deviations across all operations. The co-\nefficient of variation ranges from 0.1% (Account Balance Queries) to 17.5%\n(End-to-End Workflow).\n– Peak Performance: Intel TDX achieves higher mean throughput but with\nsignificantly greater variance. Standard deviations are 10-500x larger than\nNitro, indicating less predictable performance.\n– Production Considerations: These internal operation benchmarks demon-\nstrate PASS’s ability to handle thousands of wallet operations per second\nwithin the TEE, with the actual deployment bottleneck being blockchain\ntransaction submission rather than internal processing.\nPASS: A Provenanced Access Subaccount System for Blockchain Wallets25\nThe statistical summary confirms that both platforms support practical PASS\ndeployment, with Nitro offering predictable performance and Intel TDX provid-\ning higher peak throughput at the cost of consistency.\nD Design Extensions\nD.1 Composability and InterPASS Transactions\nWhile PASS provides privacy and provenance guarantees for a single wallet in-\nstance, an important question is how multiple PASS wallets may interact. This\nis important in supply-chain use cases where each PASS represents a single com-\npany in the supply chain.\nTrivially, PASS A can send an on-chain transaction from its Outbox to PASS\nB’s EOA account, and this will land in the Inbox of PASS B, ready to claim.\nHowever, this undermines the privacy guarantees that PASS offers at the EOA\nlevel, and is undesirable in cases where inter-organizational asset transfers con-\ntain sensitive information, such as order details.\nWe propose a non-trivial approach inspired by cross-Payment Channel Net-\nwork (PCN) protocols such as XTransfer [?]. We can treat each PASS instance\nakin to a PCN hub node, with state L and transaction history H. As with\nXTransfer, we can assume a star topology of PASS nodes, with a central PASS\nHub in communciation with all PASS nodes. The PASS Hub will aggregate all\nInterPASS transactions T := {(a\ni\n,x\ni\n,s\ni\n,r\ni\n)}\nn\ni=1\n, where (a\ni\n,x\ni\n,s\ni\n,r\ni\n) represent\nthe asset, amount, sender, and receiver, each signed by the s\ni\nOutbox.\nThe Hub aggregates these signed payment intents, computes a netted settle-\nment plan S, and coordinates a secure multi-party update protocol to commit\nthe resulting balances, similar to Thora [?]. In the optimistic case, this process\ncompletes entirely off-chain, and each participant’s balance is updated in the\nPASS ledger without revealing the underlying transaction graph. If a dispute or\nfailure occurs, any participant may trigger an on-chain enforcement transaction\nthat finalizes S atomically via the direct transfer mechanism, thus guaranteeing\nsafety.\nThis approach leverages PASS ’s provenance and state design to make each\ninstance an atomic node in PCN-style systems like X-Transfer. Here, we outline\nhow PASS Hubs can enable confidential, auditable cross-organization transfers,\nwhile full formal specification and protocol implementation is deferred for future\nwork.\nD.2 Instantiation on zkVM\nZero-knowledge virtual machines (zkVMs) provide a proving environment where\narbitrary state machines can run with strong correctness guarantees [?]. By pro-\nducing a succinct proof π of execution, zkVMs offer integrity assurances similar\nto TEEs but without hardware attestation. This makes them especially suited\nfor financial custody and inter-organizational accounting, where external verifi-\nability and regulator-grade auditability are critical.\n26J. Yu\nTo realize PASS within a zkVM, transaction requests are first queued outside\nof the proving environment. Once a batch is formed, the zkVM program takes\nas its private inputs the prior batch’s commitments of the ledger L and prove-\nnance log H, the set of state transitions in the current batch, including inbox\nI deposits and outbox O withdrawals, and the proposed new commitments for\nL and H. The zkVM then replays the computation: it begins from the previous\nroots, applies all queued transitions in sequence, and recomputes both balances\nand provenance entries. The proof π attests that these recomputations match\nthe declared new commitments and that all outbox deltas are consistent. A min-\nimalist verifier contract on chain simply checks π, updates the recorded roots,\nand enforces outbox execution. In this way, the privacy and provenance guar-\nantees of the original PASS design are preserved while augmenting them with\nrigorous computational proofs of correctness.\nThis formulation aligns with the Chainless stack architecture [?], which em-\nphasizes clear separation of execution, trust, bridging, and settlement. By sit-\nuating zkVM-based PASS execution within such a layered model, integration\nwith external systems can be achieved in a modular and interoperable manner.\nWe defer full formal implementation and specification for future work.\nFig. 7. PASS instantiation inside a zkVM: Inbox I and Outbox O transitions are\napplied to the Ledger L and Provenance H, producing new state commitments. The\nzkVM outputs a proof π, which the on-chain verifier checks before updating roots and\nenforcing outbox operations."
}
]
}
]Response:
你的问题是：
**Custodial Key Management and Policies（传统托管密钥管理与策略）和PASS在效果上有什么区别？PASS能解决什么额外的问题？**
下面我帮你梳理二者的核心区别、PASS的额外优势，以及它能解决的实际问题。
---
## 1. Custodial Key Management and Policies（传统托管密钥管理与策略）
### 机制简介
- 机构（如Fireblocks、Turnkey等）托管资产私钥。
- 通过RBAC（基于角色的访问控制）、ABAC（基于属性的访问控制）等策略引擎，决定谁可以对资产做什么操作。
- 这些策略通常在链下由托管方的软件/服务执行，用户通过API接口与托管方交互。
### 优缺点
**优点：**
- 灵活、可编程，可实现复杂的审批流程。
- 适合大机构的合规和审计需求。
**缺点：**
- 策略语言/配置复杂，策略面广，易出错或有未覆盖的“漏洞”。
- 托管方可见所有操作和内部活动，隐私性较差。
- 资产的“归属”与“流转”靠人为配置，难以追溯资金实际流向。
- 需要信任托管方不会泄露密钥或作恶。
---
## 2. PASS（Provenanced Access Subaccount System）
### 机制简介
- 资产由单一EOA（外部拥有账户）控制，密钥仅存在于TEE（可信执行环境）中。
- 钱包内部有多个“子账户”，每个子账户可以分配不同资产或权限。
- **核心特性：所有权和使用权基于“资产溯源(provenance)”而不是“身份/角色”：**
只有能证明资产链路（从外部存入至当前子账户）的子账户，才能动用这些资产。
- **Inbox–Outbox机制：**
- 外部资产进入Inbox，需由子账户Claim。
- 内部子账户之间转账完全私密、无gas消耗、不可链上追踪。
- 只有Outbox里的提现/外部操作才被签名并广播到链上。
- **隐私与可组合性：**
- 内部转账对外不可见，外部观察者无法区分PASS钱包和普通EOA。
- 可以与主流TEE系统、钱包协议（如WalletConnect）无缝集成。
### 优缺点
**优点：**
- **极简策略面**：只需维护资产的溯源链路，减少复杂的策略语言和配置。
- **强隐私**：内部资产流转完全不可见于链上，外部只见到EOA的收支。
- **可追溯与审计**：每笔资产都能追溯到最初的外部存入，便于合规与内部审计。
- **灵活子账户**：可为AI、员工、部门等分配独立额度与权限，且可随时回收。
- **TEE保障密钥安全**：密钥永不出TEE，攻击面小。
- **与现有生态兼容性高**：无需新合约，兼容EOA及主流链。
**缺点：**
- 仍需信任TEE厂商安全性。
- 需要一定的组织级硬件/运维能力。
- 若TEE被攻破，风险同样严重。
---
## 3. PASS能解决的额外问题
### 3.1 内部隐私
- 传统托管方案下，托管方可见所有内部转账与操作。
- PASS内部转账完全私密（只在TEE内部账本和溯源日志中体现），对外不可见，保护了组织的薪资、预算分配等敏感信息。
### 3.2 极简化的权限管理
- 传统托管方案需要设计和维护复杂的RBAC/ABAC策略。
- PASS只关心资产的“溯源链路”，子账户能否操作资产只看是否有对应的资产流转链条，简化了权限模型，减少配置和审计负担。
### 3.3 更强的资产可追溯性和合规性
- 每一笔资金的流入、流转、流出都可内部溯源，便于合规审计和责任追查。
- 可满足如BSA（美国银行保密法）等需要资产流向明细的合规需求。
### 3.4 降低托管方信任风险
- 传统托管方案下，托管方可见全部密钥和操作，存在作恶和泄露风险。
- PASS密钥仅在TEE中，托管方不可见密钥，也不可篡改溯源账本，信任基础更强。
### 3.5 灵活的子账户与AI/自动化支持
- 子账户可细粒度分配资产或签名权，便于委托AI agent、部门、员工等，且可随时回收权限。
- 传统托管方案灵活性有限，容易发生“越权”或“权限滥用”。
### 3.6 统一的隐私与可组合性
- PASS可同时满足多子账户、多资产、多签名场景，且与当前EOA账户、钱包协议和TEE系统兼容，实现“隐私+可用性”两全。
---
## 4. 总结对比表
| 方案 | 权限/策略基础 | 内部隐私 | 可追溯性 | 策略复杂度 | 兼容性 | 易用性 | 典型适用场景 |
|----------------------|------------|--------|--------|--------|------|------|----------|
| Custodial (RBAC/ABAC) | 角色/属性 | 差 | 一般 | 高 | 较好 | 需维护策略 | 传统机构托管 |
| PASS | 溯源链路 | 强 | 强 | 极低 | 极好 | 易用 | 组织钱包、AI托管、私密分账 |
---
## 5. 结论
- **PASS不是简单的托管密钥管理，而是基于“资产溯源”的新型权限与隐私体系。**
- **它不仅解决了传统托管方案的隐私、可组合性和策略复杂性问题，还极大提升了安全性与可审计性。**
- **适用于需要多方协作、内部隐私、细粒度权限分配和强合规追踪的场景。**
---
如需更细致的应用举例或对某一条特性深入解读，欢迎补充更多场景！
Model: gpt-4.1-nano-2025-04-142025-09-14 02:15:09
Context:
[
{
"role": "system",
"content": "You are an assistant who is good at conversation. You need to summarize the user's conversation into a title of 10 characters or less. It should be in the format of \"Action - Title\". Some examples:\n1. Learn - Bitcoin 2. Code - Web Server 3. Write - An Article"
},
{
"role": "user",
"content": "[{\"role\":\"user\",\"mainText\":\"阅读这篇文章 然后和我讨论\",\"files\":[\"main.pdf\"]},{\"role\":\"assistant\",\"mainText\":\"非常\"}]"
}
]Response:
Read - Article
Model: gpt-4.1-nano-2025-04-142025-09-11 13:37:11
Context:
[
{
"role": "system",
"content": "You are an assistant who is good at conversation. You need to summarize the user's conversation into a title of 10 characters or less. It should be in the format of \"Action - Title\". Some examples:\n1. Learn - Bitcoin 2. Code - Web Server 3. Write - An Article"
},
{
"role": "user",
"content": "[{\"role\":\"user\",\"mainText\":\"dstack\\n8-21-2025\\nDraft Project Governance Documents\\n\\n\\nThank you for your interest in hosting a project at the Linux Foundation. We have prepared an initial set of documents for you to review:\\n\\nTechnical Charter Draft\\nContribution Agreement Draft\\nSeries Agreement Draft\\n\\nPlease review these materials and let us know if you have any questions. To give you some background on these materials:\\n\\n\\tTechnical Project Charter Template\\n\\nA technical charter is created for all new projects to define both the project operations and the IP policy. This document is used to set up an LLC entity, and this becomes the core governance of that LLC. We have proposed technical oversight for the project falls to a “Technical Steering Committee” made up of the project’s committers. At a later date the TSC is free to evolve how membership on the TSC is determined to accommodate project growth and the evolution of its governance. \\n\\n\\tProject Contribution Agreement\\n\\nIn order to enable collaboration across organizations, the Linux Foundation and its project hosting entities hold project names, logos and key accounts (e.g., domain names, GitHub accounts, etc.) for the benefit of the project community. The way we do this is through the execution of the Project Contribution Agreement with the project’s founding organization or, in some cases, individual. While companies transferring project names and logos to us can continue use those names and logos in accordance with our trademark usage guidelines (please see https://lfprojects.org/policies/trademark-policy/), project names should not be used as part of a commercial product name. If you are currently using the name of the project as part of a product name, please let us know.\\n\\nWhile the Project Contribution Agreement will ask about any trademark registrations, please note your organization may have common law trademark rights in a project name even if a registration has not been filed. Therefore, unless the project name has never been used publicly, we have Project Contribution Agreements signed even if there are no trademark registrations.\\n\\n\\tSeries Agreement\\n\\nYou will note that the Technical Charter refers to the project as being organized as a “series” of LF Projects, LLC. LF Projects, LLC is one of our project hosting entities, and is a Delaware series limited liability company. Using LF Projects, LLC allows us to give a form of legal identity to projects. The document that gives existence to the project as a series of LF Projects, LLC, is the ‘Series Agreement’. The Series Agreement is a document signed by LF personnel, and no action is required on your part in creation of the series. We are including a copy of the Series Agreement in this packet because the Technical Charter will include references to the Series Agreement and the Series Manager (an LF employee who can act on behalf of the series). \\n\\nNext Steps\\n\\nPlease review our FAQ on Project formation.\\n\\nIn terms of moving forward, the next steps are as follows:\\n\\nCome to agreement on the finalized language for the Technical Charter. \\nTransfer ownership of any related assets to be neutrally held by the Project, if not already held by a Linux Foundation entity:\\nAdd ‘thelinuxfoundation’ as an owner of the GitHub org\\nTransfer domain(s) here\\nSend .svg of existing logo to [email protected]\\nIf you have at least 5 organizations supporting the project, we will reach out to you to prepare an announcement concerning the project launching at the LF\\nOnboard into the LFX platform to take advantage of LFX platform tools – we will reach out to you on this.\\nAdd the following as a website footer in tandem with announcement:\\n\\nCopyright © dstack a Series of LF Projects, LLC\\nFor web site terms of use, trademark policy and other project policies please see https://lfprojects.org.\\n\\nShould you have any questions, please do not hesitate to contact us. If you’d like to set up time to discuss these documents in further detail, please let us know a few suitable times.\\n\\nProject Formation Contacts\\n\\nIf you have any questions about the process of bringing your project to the LF, please reach out to Scott Nicholas, VP of Project Formation, and Todd Benzies, Senior Director of Project Formation, at [email protected]. \\n\\nThank you!\\n\\n\\nThe Project Formation Team of the Linux Foundation\\n\\n帮我翻译并总结这份文档\"},{\"role\":\"assistant\",\"mainText\":\"当然可以！以下是对你提供的这份 Linux Foundation 项目治理文件草案说明的中文翻译与总结：\\n\\n---\\n\\n## 中文翻译与总结\\n\\n### 文档摘要\\n\\n这份文档来自 Linux Foundation 项目组，是为您希望在 Linux Foundation 托管项目而准备的初步治理文件，包括：\\n\\n- 技术章程草案（Technical Charter Draft）\\n- 项目贡献协议草案（Contribution Agreement Draft）\\n- 系列协议草案（Series Agreement Draft）\\n\\n#### 1. 技术项目章程模板（Technical Project Charter Template）\\n\\n- 每个新项目都会制定技术章程，明确项目运作和知识产权政策。\\n- 章程用于设立 LLC 实体，并成为该 LLC 的核心治理文件。\\n- 建议项目由“技术指导委员会（TSC）”负责技术监督，TSC 由项目提交者组成，未来可根据项目发展调整 TSC 成员资格。\\n\\n#### 2. 项目贡献协议（Project Contribution Agreement）\\n\\n- Linux Foundation 及其托管实体会代表社区持有项目名称、Logo、关键账号（如域名、GitHub 账号等）。\\n- 通过与项目发起方（组织或个人）签署项目贡献协议来实现上述目的。\\n- 即使没有注册商标，只要项目名被公开使用过，也需签署贡献协议（可能拥有普通法商标权）。\\n- 项目名称不能用作商业产品名，如有此情况需告知对方。\\n\\n#### 3. 系列协议（Series Agreement）\\n\\n- 技术章程中会提到项目作为 LF Projects, LLC 的一个“系列”进行组织。\\n- LF Projects, LLC 是一个特拉华州系列有限责任公司，为项目提供法律身份。\\n- “系列协议”是由 LF 员工签署的，无需你方操作，仅供参考（因章程会引用）。\\n\\n#### 下一步\\n\\n1. 共同确认技术章程的最终内容。\\n2. 转让相关资产，以便项目由中立实体持有（如尚未完成）：\\n - 将 GitHub 组织的拥有者添加 “thelinuxfoundation”\\n - 转移域名\\n - 将现有 Logo 的 SVG 文件发送至 [email protected]\\n3. 若有至少 5 个组织支持项目，LF 会协助准备项目启动公告。\\n4. 接入 LFX 平台，享受相关工具服务。\\n5. 项目网站页脚需添加如下内容：\\n\\n```\\nCopyright © dstack a Series of LF Projects, LLC\\nFor web site terms of use, trademark policy and other project policies please see https://lfprojects.org.\\n```\\n\\n如有疑问可联系 Scott Nicholas（项目组副总裁）和 Todd Benzies（高级总监），邮箱 [email protected]。\\n\\n---\\n\\n### 总结\\n\\n这份文档主要介绍了 dstack 项目加入 Linux Foundation 的治理和法律流程，说明了三份核心文件（技术章程、贡献协议、系列协议）的作用，以及项目资产转移、网站备案、公告准备等后续步骤。项目方需确认章程、完成资产转移，并按要求准备材料，后续可联系 LF 项目组协助推进。\\n\\n---\\n\\n如需进一步详细翻译每一节内容，请告知！\"}]"
}
]Response:
Manage - 项目指南