feat: tansu-DAO-gated registry manager contract

[willemneal]

Summary

Adds contracts/registry-tansu-manager/, a Soroban contract that gates manager-authed operations on the on-chain registry behind approved Tansu DAO proposals. Single entry point: trigger(proposal_id). Single transaction, end-to-end:

user.tx
  └── manager.trigger(proposal_id)
        ├── read proposal from Tansu under our project_key       ← gate
        ├── env.authorize_as_current_contract(outcome_call)      ← pre-auth
        └── invoke_contract(Tansu, "execute", [self, project_key, id, _, _])
              ├── auth_maintainers: manager.require_auth         ← implicit (direct caller)
              ├── tally votes → flip status → Approved
              └── try_invoke_contract(outcome)                   ← registry.publish_hash/deploy(args)
                    └── manager.require_auth                     ← matched by pre-auth
                          → outcome runs in the same tx

Key properties:

• Config (tansu, project_key, registry) is set immutably in __constructor. Wrong-project callers can't piggyback — trigger reads the proposal under our configured project_key and pre-authorizes only that one outcome.
• The manager must be the Tansu project's sole maintainer (set up at deploy time via Tansu::register(…, maintainers=[manager]) or update_config). That way the manager is the direct caller of Tansu.execute, so Tansu's internal maintainer.require_auth() is satisfied by Soroban's contract-implicit auth — no auth entry needed and no enable_non_root_authorization simulator dance.
• The registry's manager.require_auth() is satisfied by env.authorize_as_current_contract. The pre-auth is scoped to one specific (contract, fn, args) triple — nothing else gets authorized.
• No on-manager replay guard. Tansu's own if proposal.status != Active { panic } (rejected on replay with #402 ProposalActive) is the source of truth.

Tansu's Proposal / OutcomeContract / ProposalStatus types are derived at compile time from tansu-stub's wasm spec via stellar_registry::import_contract_client!(tansu_stub) — tansu-stub carries the canonical contracttype layout, mirroring upstream Consulting-Manao/tansu. We'd have liked to contractimport! the live Tansu wasm directly, but its v2.0.2 spec emits both a pub trait Contract (the interface) and a #[contracttype] pub struct Contract (used as a typed-Address wrapper in set_nqg_contract etc.) into the same generated module, which collides — tracked in Consulting-Manao/tansu#152. The stub also gains a Tansu-shaped execute(maintainer, project_key, proposal_id, _, _) -> ProposalStatus that auto-invokes the outcome the way real Tansu does, so harnesses that target the stub exercise the full trigger chain.

Supporting pieces:

• contracts/hello/ — minimal hello-world contract used as the payload by all three e2e scripts.
• contracts/test/tansu-stub/ — stub Tansu (now with execute + a #402 ProposalActive error to mirror Tansu's replay guard).

Test plan

• cargo test -p registry-tansu-manager — 1 constructor smoke test. The integration behavior is covered by the e2e scripts below.
• cargo test -p hello -p tansu-stub — passes.
• cargo clippy -p registry-tansu-manager -p tansu-stub --all-targets -- -D warnings — clean.
• cargo fmt --all -- --check — clean.
• just build — wasm builds for registry, registry_tansu_manager, tansu_stub, and hello. Topo sort orders tansu-stub before the manager via [package.metadata.stellar] contract = true.
• Stub-based testnet via contracts/registry-tansu-manager/e2e-testnet.sh — see below.
• Custom-Tansu testnet via contracts/registry-tansu-manager/e2e-fast-tansu-testnet.sh (~2.5min wall-clock vs ~48h on live Tansu) — see below.
• Live-Tansu testnet via contracts/registry-tansu-manager/e2e-real-tansu-testnet.sh — phase 1 has run; phase 2 against live Tansu hasn't been re-verified post-pivot (24h voting + 24h execute timelock).

Stub-based testnet verification (e2e-testnet.sh)

Ran NETWORK=testnet ./contracts/registry-tansu-manager/e2e-testnet.sh end-to-end. All steps green:

1. Deploy fresh registry (admin as initial manager so the publisher can self-publish).
2. Upload hello.wasm and have admin-as-manager publish it on the author's behalf.
3. Deploy tansu-stub.
4. Deploy registry-tansu-manager pointing at stub + registry.
5. Admin swaps the registry's manager to the manager contract.
6. Plant an Approved deploy-proposal on the stub (outcome targets registry.deploy(...)).
7. manager.trigger(proposal_id) — pre-authorizes the outcome via authorize_as_current_contract, calls stub.execute(self, project_key, proposal_id, _, _); the stub auto-invokes the outcome; registry.deploy runs under the pre-auth; hello deploys.
8. hello(world) → "world" on the freshly deployed contract.
9. Re-trigger → #402 ProposalActive from the stub (mirroring Tansu's status guard).

Contracts deployed during the verification run:

Role	Address
registry	CA72QP7N6RTTMRYLMT7PUSYPWRBJGWMR5YOFDOSNTUOTX63SYNKU4445
registry-tansu-manager	CAG7UKI6FCZB6464GUDE2FRVEOZR5QRIZACNVNSQSA7UXTFMN3ZQMKRI
tansu-stub	CCBXY322ZYY4RLS3WEBD7BZPTMR4WEDGNTIS3OXTWVVJ2M4IG4OTRW2U
hello (deployed via proposal)	CATBV7SZS6Q57SKHKQWAGT3D2CBQQ522NUTZFKJPGTZJUSPYNKEBIIF4 (registered as hello-1780000169)

manager.trigger tx (single-tx flow including stub.execute → registry.deploy): 4c0bff33…ca87d.

Fast Tansu-fork testnet verification (e2e-fast-tansu-testnet.sh)

A custom build of Tansu (same Proposal/OutcomeContract wire shape; adds min_voting_period: Option<u64> and execute_delay: Option<u64> to register) is deployed at CDK7JBIIP6E75HOYLGRGWAHQLT6JUNUXQ7GNOYS3NAP26GISUXJ26UON on testnet. This collapses the ~48h voting+timelock window into the script-configurable MIN_VOTING_PERIOD + EXECUTE_DELAY (defaults: 60s + 60s).

End-to-end against that Tansu:

1–4. Register fresh project (min_voting_period=60, execute_delay=60), add members, upload hello.wasm, deploy registry, deploy manager.
5. set_manager(manager) on the registry, update_config(maintainers=[manager]) on Tansu so the manager is the sole project maintainer.
6. Create proposal whose outcome is registry.publish_hash(hello, …).
7. Vote Approve, wait through voting + execute_delay (~2 min).
8. manager.trigger(proposal_id) — one tx flips the proposal Approved, runs the outcome, registry publishes. Verify with registry.fetch_hash.
9. Replay → #402 ProposalActive.

manager.trigger tx end-to-end (Tansu.execute + Proposal collateral refund + outcome auto-invocation + registry.publish_hash, all in one): df2c8bab…ea360.

Live-Tansu testnet verification (e2e-real-tansu-testnet.sh)

Two-phase script that exercises the same flow against the live Tansu DAO on testnet (CBXKUSLQPVF35FYURR5C42BPYA5UOVDXX2ELKIM2CAJMCI6HXG2BHGZA) — real register / add_member / create_proposal / vote, full 24h voting + 24h timelock window:

• ./e2e-real-tansu-testnet.sh setup — registers project, auto-registers .xlm domain on SorobanDomain, deploys registry + manager, update_config to hand maintainership to the manager, create_proposal with registry.publish_hash(...) outcome, vote Approve, save state.
• ./e2e-real-tansu-testnet.sh finalize <state-file> — after voting + timelock ends, calls manager.trigger(proposal_id) and asserts registry.fetch_hash.

Phase 1 was verified on 2026-05-28 (see earlier commit messages). The trigger pivot landed today; phase 2 against live Tansu hasn't been re-run end-to-end yet (requires a fresh setup + 48h wait).

Out of scope (deliberate)

• Multi-outcome proposals. Rejected with MultipleOutcomes for v1.
• try_invoke_contract on the registry call from inside the manager. With authorize_as_current_contract, the registry's call is invoked by Tansu (not the manager), and a failure there propagates through Tansu's own try_invoke_contract as #403 OutcomeError. Acceptable for v1.
• Pure custom-account __check_auth design. Equivalent security model but blocked by stellar-cli 26.0.0 not exposing enable_non_root_authorization (recording-mode simulation can't synthesize a non-root auth entry for a custom account whose __check_auth would satisfy it). Revisit when CLI support lands; the trigger design works with current tooling and standard frontend SDKs.

[chadoh]

Also lands two supporting pieces for the e2e test:

• contracts/hello/ — minimal hello-world contract used as the published+deployed payload.

Seems like this should live in contracts/test or some other test-specific directory

[chadoh]

Started this review from the e2e test stuff and worked my way down. Would like to do another pass at the stuff at the top. But there's enough feedback here already that I figured I'd submit now.

[chadoh]

Should these be combined to use stellar registry publish instead? Or to at least call invoke -- publish directly, instead of invoke -- publish_hash?

[chadoh]

Also strikes me as a little odd that registry tests wouldn't use registry for all of these wasm uploads & contract deploys. Like, sure, we don't need to. But we've got a nifty naming tool, why aren't we using it?

That said, if it keeps the tests simpler/more minimal/focused to skip that, I'm fine keeping as-is.

[chadoh]

Can you explain why "re-exporting its #[contractimpl] functions into this stub's wasm" is a bad thing? To me it seems possibly preferable to duplicating and "keeping in lock-step" (how are we actually planning to keep these in lock-step?)

[willemneal]

This was a quick and dirty way. I think I'll update to use contract import instead. Basically when "importing" another contract you don't want to use an rlib because of the way the spec generation macros work. Essentially they all get pulled in even if your contract doesn't export those types just uses them. The preferred way is via Wasm imports so that you get the real spec and not need to copy/paste. I'll fix it.

[willemneal]

Now using stellar_registry::import_contract_client!(tansu_stub) from the manager — the stub crate is the single source of truth for the Tansu types, and the manager derives Proposal/OutcomeContract/ProposalStatus + a typed get_proposal Client from the stub's wasm spec (no rlib involved, so no #[contractimpl] re-export). One hand-copy remains — in this stub crate — mirroring the upstream Consulting-Manao/tansu types.

We tried to drop that copy too by importing the real Tansu wasm, but it has a Contract name collision (#[contract] pub struct Contract + #[contracttype] pub struct Contract) that crashes contractimport!. Filed Consulting-Manao/tansu#152 asking for the rename; once it ships, the stub stops needing its own copy and can contractimport! the real wasm directly.

[chadoh]

I wonder if using the real tansu would be more robust. The 24hr voting period is the real dealbreaker, but perhaps we can update Tansu to make this configurable via environment variable. Then we can compile a custom Tansu and deploy it as part of the e2e script.

3. Create a new project
4. Add minimum number of voters
5. Then we're good to go?

How complex is that?

How complex is it, compared to maintaining a long-lived stub in a separate repo that is (magically?) kept "in lock-step" with the real Tansu?

[willemneal]

I went back and forth on it. The tricky part with using a real contract is 1) the constructor is not simple, 2) won't require the rewrite as you say, and 3) adds a new dep.

My thoughts are that we will work on the contract itself later and it is better to just handle the current API with the stub (with one real one on testnet which shows a success with the 24 hours). Then once updated we can move it as a first class contract in the registry as we are planning and then handle the rewrite then which should be straight forward.

Since we are the maintainers of Tansu the changes won't spring up on us and we can use this as a vehicle for testing.

[chadoh]

Seems weird to me that we can't list contracts/* here. It makes me wonder if there's a more natural place to put these new tests, and everything in contracts/test/*.

But also w/e ¯\_(ツ)_/¯

[willemneal]

The issue is that contracts/* will fail on the contracts/tests/* because that folder doesn't have a Cargo.toml. I do agree we need to move the hello to the test folder.

[chadoh]

A couple small questions/notes, but nothing blocking!

[chadoh]

Why are we doing cross-contract calls this manual way? Instead of using our own import_contract_client! macro? Are we awaiting the completion of import_contract! to further simplify the interface?

[willemneal]

Switched to stellar_registry::import_contract_client!(tansu_stub) — the manager now gets a typed Client::get_proposal and the Proposal/OutcomeContract/ProposalStatus types from the stub's wasm spec. The forward call to the registry (env.invoke_contract(&registry, &oc.execute_fn, oc.args)) stays untyped on purpose: an approved proposal targets any registry method, and a typed client can't express an arbitrary-method forward.

We can't import the real Consulting-Manao/tansu wasm yet — its v2.0.2 spec contains both #[contract] pub struct Contract and #[contracttype] pub struct Contract (a typed-Address wrapper used in set_nqg_contract etc.). contractimport! then generates a pub trait Contract colliding with the contracttype struct in the same module. experimental_spec_shaking_v2 doesn't help (the type is reachable through the trait). Opened Consulting-Manao/tansu#152 proposing the upstream rename — once it lands in a release we re-pin and drop the stub-as-source-of-truth.

import_contract! (#419) is still the right end state on top of this.

[chadoh]

Do I understand correctly that we think there's a simpler way to do this, but we are choosing to not do it? Why?

[chadoh]

Seems like a misplaced comment (it is not relevant to the approved_proposal_cannot_be_replayed test below)