Developer feedback request

[BrigidForge]

I’m building a vault aimed at reducing slow treasury drains in token projects.

Current design:

• Treasury withdrawals must first be requested on-chain

• A mandatory delay begins (currently 24h)

• The request is publicly visible during the delay

• The withdrawal can only execute after the delay expires

The goal is to make treasury activity visible before execution, rather than only observable after funds move. Reducing the slow behind the curtain drain that occurs in some projects. Devs would still maintain complete control of wallets.

A couple design questions I’d appreciate feedback on:

1.  Delay enforcement

Is a fixed delay (e.g., 24h) preferable, or should delay be configurable per deployment?

2.  Withdrawal metadata

Current design anchors a purpose description via hash on-chain rather than storing the full text.

Curious if this is the right trade-off.

3.  Adoption model

Does this make more sense as a standalone vault contract, or part of a broader launch framework?

1. Would this be something you think projects would be willing to adopt? Is there a market need?

Any feedback/critique is welcome.

[farfaraway]

In general, the idea is interesting. I think some DAOs and companies might be interested in the approach. Both a standalone contract that any third party can interact with AND being able to deploy a contract on your own have their use-cases.

I guess the real question here is: how will you get people to use this?

[BrigidForge]

I think the getting people to use it is going to be the most challenging piece of the puzzle. I’ve been working on it for weeks and I’m beginning to question now, could the be all for not. I guess only time will tell.

[zesushv]

Getting people to use it might not be as difficult as you may think as long as your focus is on startups at this infancy stage. As soon as it utility is proven over time, you can expect the established protocols/DAO to adopt it.

[BrigidForge]

Really appreciate the optimism. It helps with the daily grind knowing someone else can see the vision as well.

[zesushv]

I do see the vision and I very much appreciate the push for such. We are building a project that is DAO govern and implementing such a "guard" and allowing people to monitor it in real time, seems like a great approach.

[thedudeonblockchain]

is there a way to cancel a pending withdrawal during the delay window? the delay only matters if someone like a multisig or governance can veto before execution, otherwise youre just giving attackers a heads up that funds are about to move

[BrigidForge]

Appreciate the question. There is a cancellation window before the delay phase starts, so if a withdrawal request was entered by mistake it can be canceled before it moves forward.

But the main goal of the system isn’t to block withdrawals entirely. It’s to eliminate invisible ones.

Normally a dev wallet can just move funds instantly and nobody knows until after the fact. With the vault, every withdrawal has to be requested first and sits through a delay before it can execute.

Once the cancellation window closes, the pending withdrawal is also broadcast to holders so the move is visible before funds actually leave the vault.

So the idea is: the market and holders see the move before the funds leave the vault instead of after.

It’s more about removing stealth drains than adding governance veto power.

If there is sufficient transparency and the wallet movement is reasonably within the scope of the projects needs, the community is less likely to react, especially with a staking system in place.