Repository navigation
feat(APP-1165): Add native Safe governance proposals - #1437
thekidnamedkd wants to merge 12 commits into
Conversation
|
🚀 Preview Deployment: View Here |
|
E2E results (preview) Smoke
|
milosh86
left a comment
There was a problem hiding this comment.
just a couple of comments for now, I have more to check
| link: `${baseUrl}/members`, | ||
| icon: IconType.APP_MEMBERS, | ||
| hidden: !(isSupported && hasBodyPlugin), | ||
| hidden: !(isSupported && (hasBodyPlugin || hasSafeProcess)), |
There was a problem hiding this comment.
should we just mark safe plugin with isBody: true on the backend?
There was a problem hiding this comment.
yeah, now after reviewing the previous PR, I get that in the context of a workspace a Safe always is both a process and a body, but in the context of a DAO, it could be one or another. Also it seems that if it has EXECUTE permission and it is added as a process then it should automatically be a body too. In the other case, if it is a body in a SPP process, then it's just a body.
|
|
||
| const { result, isLoading } = useSimulateProposalCreation({ | ||
| plugin: process, | ||
| enabled: process.interfaceType !== PluginInterfaceType.SAFE, |
There was a problem hiding this comment.
can GOVERNANCE_BUILD_CREATE_PROPOSAL_DATA slot be implemented for Safe so we don't have this branching logic?
| useEffect(() => { | ||
| checkWalletConnected(); | ||
| }, [checkWalletConnected]); | ||
| if (enabled || checkWalletConnection) { |
There was a problem hiding this comment.
isn't checkWalletConnection always non-null?
| */ | ||
| fullExecuteOnly?: boolean; | ||
| /** Include native Safe accounts in proposal creation only. */ | ||
| allowNativeSafe?: boolean; |
There was a problem hiding this comment.
do we have a case where we don't want to show Safe process?
|
|
||
| return ( | ||
| <Page.Container> | ||
| <SafeDaoProposalDetails |
There was a problem hiding this comment.
An important question for workspaces: how much is this implementation tied to DAO? Is it easy to make a SafeProposalDetails which works for any Safe transaction?
Another question, does it make sense to port some of the safeTransaction->proposal mapping to backend so we consume a common abstraction?
|
Updated the description for Native signing is now verified with a real owner wallet: SAFE-11 on The first stored read after signing lagged the accepted confirmation. A captured-response browser replay confirmed that the existing poll updates Votes on the next 30-second cycle once the new snapshot is available. Live backend catch-up time remains unmeasured. Process-only signing and a live shared-Safe fixture remain coverage limits. This stays stacked on #1397 and needs review approval. |
Description
Implements APP-1165. Stacked on #1397; base branch is
safe-biz-logic.Safes with DAO Execute permission appear as governance processes. Their Proposals tab pages through stored pending and executed DAO transactions from backend #1587.
SAFE-<nonce>labels are display-only; links identify the Safe and transaction hash, so competing transactions remain separate. Old hash links also look up superseded and removed transactions.Creation uses the action-only wizard. Details show decoded DAO.execute actions and reuse the multisig voting presentation, with Safe envelope review and owner signing inside Aragon. Decoded actions are checked against the transaction's local action tuples; pending or mismatched decoding falls back to raw actions. Process settings and members reuse the Safe-body views. Assets and Transactions are unchanged.
The list verifies DAO.execute targets, including known MultiSend batches, and reports stale, partial or unindexed reads. Pagination remains usable when a backend page has no matching DAO actions or the next request fails. Signing retains fresh queue/history reconciliation and checks the reviewed hash, owner, chain and nonce.
Dependencies: #1397 supplies the Safe review/signing primitives and remains this PR's base. Execute-grant registration, stored transactions and decoded actions are available on dev. The earlier missing-process/404 fixture blocker no longer describes the current fixtures.
Verification updated 2026-10-16
e13d63207passes, including tests, deployment, E2E and CodeQL.0xE9C78Ac980BDfE01587FdC9a3ebdfA9243cc5f9fappears in Members with both owners; its owner-detail link preserves the Safe selection after reload.0x8442c05d620e11009bdaEDdefDA3b5303725c39A, transaction hash0x6f0490872ad26175c9b05bd56b133da65fa363eca6ac3f18458f3751bc723383, now has both owners' confirmations. This fixture has both body and process permissions; the interaction used the native-process route.Live signing on a process-only fixture and a shared-Safe/linked-DAO fixture remain untested. Existing development CSP/Permissions-Policy/WalletConnect warnings remain. No missing backend feature was identified by these checks; review approval and the existing review threads are still open.
Type of Change
Developer Checklist:
Review Checklist: