Skip to content

feat(APP-1165): Add native Safe governance proposals - #1437

Open
thekidnamedkd wants to merge 12 commits into
safe-biz-logicfrom
app-1165-safe-process-identity
Open

thekidnamedkd wants to merge 12 commits into
safe-biz-logicfrom
app-1165-safe-process-identity

Conversation

@thekidnamedkd

@thekidnamedkd thekidnamedkd commented Sep 30, 2026 •

Copy link
Copy Markdown
Contributor

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

  • Latest combined local checks passed 473 tests across 42 affected suites, app type-check, changed-file lint and changeset validation. Current-head CI at e13d63207 passes, including tests, deployment, E2E and CodeQL.
  • Live development checks covered stored pagination, retired transaction states, decoded actions and process-only discovery. The process-only Safe 0xE9C78Ac980BDfE01587FdC9a3ebdfA9243cc5f9f appears in Members with both owners; its owner-detail link preserves the Safe selection after reload.
  • A connected owner signed SAFE-11 from the native proposal page in the latest preview. Safe 0x8442c05d620e11009bdaEDdefDA3b5303725c39A, transaction hash 0x6f0490872ad26175c9b05bd56b133da65fa363eca6ac3f18458f3751bc723383, now has both owners' confirmations. This fixture has both body and process permissions; the interaction used the native-process route.
  • No execution was sent for SAFE-11. Its nonce is 11, the Safe's chain nonce remained 9, and the DAO metadata remained unchanged. The page correctly shows Waiting for earlier nonce. APP-1165 requires viewing and signing; executing this particular queued transaction is not required for that check.
  • The immediate post-sign stored read returned the older one-confirmation snapshot. A browser replay on the unchanged preview verified that the existing 30-second poll updates Votes when the two-confirmation snapshot becomes available. This does not measure live backend catch-up time or identify the historical cache layer.
  • Earlier browser checks covered the metadata-free wizard, disconnected-wallet connection, filtered-empty pagination and hash-addressed detail navigation. Linked-DAO routing and identity have deterministic coverage.

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

  • Minor: Feature (non-breaking change which adds new functionality)

Developer Checklist:

  • Manually smoke tested the functionality in a preview or locally
  • Confirmed there are no new warnings or errors in the browser console
  • (For User Stories only) Double-checked that all Acceptance Criteria are satisfied
  • Confirmed there are no new warnings on automated tests
  • Merged and published any dependent changes in downstream modules
  • Selected the correct base branch
  • Commented the code in hard-to-understand areas
  • Followed the code style guidelines of this project
  • Reviewed that the Files Changed in Github’s UI reflect my intended changes
  • Confirmed the pipeline checks are not failing

Review Checklist:

  • (For User Stories only) Tested in a preview or locally that all Acceptance Criteria are satisfied
  • Confirmed that changes follow the code style guidelines of this project

@thekidnamedkd
thekidnamedkd requested a review from a team as a code owner September 30, 2026 18:58
@linear-code

linear-code Bot commented Sep 30, 2026

Copy link
Copy Markdown

APP-1165

@thekidnamedkd
thekidnamedkd added this pull request to stack #1438 September 30, 2026 18:58
@github-actions

github-actions Bot commented Sep 30, 2026 •

Copy link
Copy Markdown

🚀 Preview Deployment: View Here

@github-actions

github-actions Bot commented Sep 30, 2026 •

Copy link
Copy Markdown

E2E results (preview)

Smoke

Base URL https://app-next-eaigihcsj-aragon-app.vercel.app
Suite smoke
Playwright result ✅ passed
Summary 86 passed
HTML report View report
GitHub job ✅ completed

View run #5571

@thekidnamedkd thekidnamedkd changed the title feat: Add native Safe governance proposals feat(APP-1165): Add native Safe governance proposals Oct 2, 2026

@milosh86 milosh86 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)),

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we just mark safe plugin with isBody: true on the backend?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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,

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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) {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

isn't checkWalletConnection always non-null?

*/
fullExecuteOnly?: boolean;
/** Include native Safe accounts in proposal creation only. */
allowNativeSafe?: boolean;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we have a case where we don't want to show Safe process?


return (
<Page.Container>
<SafeDaoProposalDetails

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

@thekidnamedkd

Copy link
Copy Markdown
Contributor Author

Updated the description for e13d63207. The missing-process/backend-fixture blocker has cleared, and current CI passes.

Native signing is now verified with a real owner wallet: SAFE-11 on 0x8442…c39A has 2/2 confirmations. This is a combined body/process Safe, using the native proposal page. No execution was sent; the transaction remains behind earlier nonces. Process-only discovery and Members were checked separately.

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.

This branch was successfully deployed

1 active deployment
preview — e13d6320 Deployed Oct 15, 2026 by thekidnamedkd via deploy / deploy #5571
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants