This thought pattern leads to crypto.
In that world there's a process called "staking" where you lock some tokens with a default lock expiry action and a method to unlock based on the signature from both participants.
It would work like this: Repo has a public key. Submitted uses a smart contract to sign the commit with along with the submission of a crypto. If the repo merges it then the smart contract returns the token to the submitter. Otherwise it goes to the repo.
It's technically quite elegant, and the infrastructure is all there (with some UX issues).
But don't do this!!!!
I did some work in crypto. It's made me realize that the love of money corrupts, and because crypto brings money so close to engineering it corrupts good product design.
It feels like the problem here comes from the reluctance to utilize a negative sum outcome for rejection. Instead of introducing accidental perverse incentives, if rejected your stake shouldn't go to the repo, 50% could be returned, and 50% deleted (specific values just for illustration). If it times out or gets approved you get 100% back. If a repo rejects too often or is seen doing so unfairly reputation would balance participation.