implement a require_auth() alternative to discard multiple calls for the same address, instead of panicking

[ozgunozerk]

What problem does your feature solve?

We’ve hit a limitation with require_auth() where multiple calls for the same account within a single call stack result in a panic — unless there are distinct auth entries. This becomes an issue when trying to combine higher-level access control macros (like #[only_owner], #[only_role], #[only_admin]) with functions that already include a require_auth().

#[only_role(from, "burner")]
fn burn(e: &Env, from: Address, token_id: u32) {
    Base::burn(e, &from, token_id); // call to `require_auth()` inside
}

In this case, both the macro and the function both end up calling require_auth(), and unless the developer has added multiple matching auth entries for the same address, the contract panics.

From a DevX perspective, this is a friction point. It blocks developers from cleanly composing abstractions, and it’s likely to confuse users who will either hit cryptic errors or be forced to use lower-level, less ergonomic patterns.

What would you like to see?

Ideally, instead of panicking when a duplicate require_auth() is called for the same account with identical arguments, the subsequent calls would just be silently ignored if there’s already a matching authorization present in the tree.

I fully acknowledge the flexibility this restricts — particularly the case where a contract author might actually want two independent authorizations from the same signer. But in practice, this behavior mostly ends up limiting the composability of access control patterns. And at the very least, it would be great to have a way to check whether an account has already been authorized, so contract authors can explicitly deduplicate as needed.

As @dmkozh suggested in our conversation earlier, implementing a helper function, or even better, a require_auth() alternative that supports this behavior would be much appreciated!

Thanks for considering — happy to discuss or clarify further.