docs: add PAS Quickstart and Architecture Overview#24
docs: add PAS Quickstart and Architecture Overview#24
Conversation
| ### Approval Matching | ||
|
|
||
| Approvals are matched by **type identity** using `TypeName`. The approval set must be **exactly equal** | ||
| (same types, same count, same order via `VecSet` insertion) to the Policy's required approvals. |
There was a problem hiding this comment.
Currently, in v1, you can only have a single approval. I wonder if we should clarify this.
There was a problem hiding this comment.
Added a callout clarifying that v1 only supports a single approval witness per action.
docs/pas-architecture.mdx
Outdated
| **Key insight**: Unlike SendFunds, the caller receives the funds and decides what to do with them | ||
| (burn, deposit elsewhere, etc.). | ||
|
|
||
| ### UnlockFunds (System Exit) |
There was a problem hiding this comment.
Closed Loop exit!
Maybe a warning that explains why this is a dangerous thing to allow.
There was a problem hiding this comment.
Renamed to "Closed-Loop Exit" and added a warning about assets leaving the system permanently with no further PAS restrictions.
| Templates store pre-built Move Call commands structures for client-side automation. They allow the SDK | ||
| to construct the correct Move calls for resolution of actions without hardcoding package IDs and function signatures. | ||
|
|
||
| ### Why Templates? |
There was a problem hiding this comment.
I like the direction, I'd also highlight some benefits like the fact that there's no need for updating all clients when there's a change in the resolution for a given witness.
I'd also ask them to be cautious as this is ONLY an off-chain utility, but it enables SDKs to be built generic + support arbitrary rules. We should emphasize this, as this is part of the beauty of pas.
There was a problem hiding this comment.
Added a callout emphasizing templates are purely off-chain and what makes generic SDK support possible. Also added a "key benefit" section about how updating a template on-chain means zero client-side changes.
| └── Balance<MyCoin> stored via balance::send_funds(balance, chest_object_address) | ||
| ``` | ||
|
|
||
| Balances are **not** stored as fields on the Chest struct. They're stored as object balance |
There was a problem hiding this comment.
We should link the address balances docs in sui
There was a problem hiding this comment.
Linked to the Sui address balances migration guide. I didn’t find any other documentation besides the SIP.
docs/pas-architecture.mdx
Outdated
|
|
||
| --- | ||
|
|
||
| ## Versioning |
There was a problem hiding this comment.
Not sure if this needs to be part of the docs -- not really important for integrators
There was a problem hiding this comment.
Removed the standalone section, moved a brief mention into the trust boundaries table under the UpgradeCap holder row.
| request.approve(MyApproval()); | ||
|
|
||
| // 4. Resolve — sends Balance to recipient chest | ||
| send_funds::resolve_balance(request, &policy); |
There was a problem hiding this comment.
I'd do pas::send_funds::resolve_balance to avoid confusion with framework send_funds
2 participants
No description provided.