Contracts

Trust model

What the code guarantees, what it leaves to people, and what could go wrong.

Code versus people

Enforced by code

Creator fees can only go to the reserve and operations.
The reserve and its share are fixed at deployment.
Anyone can trigger a harvest.
Every withdrawal is numbered and public.
Boxes are appended in order and never deleted.
A swapped receipt or photo file is detectable by hash.

Trusted to people

That a withdrawal is spent on the box its memo names.
That receipts and photos are genuine.
That the boxes are stored safely and stay sealed.
That the next target follows the reserve policy.
That the owner keys are kept safe.
That the operations wallet the owner sets belongs to the team.

The physical side can't be enforced by a contract. That is why every step leaves a public trail and why the site checks what it can, like metadata hashes, every minute.

What Pons can do

Pons's owner can redirect any launch's creator fees, including ours, after a public three-day timelock. The proposal is visible on-chain for those three days before anyone can execute it. This is a protocol power, not ours, and it applies to every Pons launch. Pons also runs the operator that sweeps fees after graduation.

Risks

Contract bugs. The contracts are small and tested against real Pons, but not audited.
Key loss or theft. The owner should be a Safe multisig, which is live on Robinhood Chain.
Pons changes or outages. Fee policy is frozen per launch, but the platform itself could change.
Data outages. If the RPC or price feed fails, the site says so instead of showing stale numbers as fresh.
The boxes themselves. Sealed sets can lose value, get damaged, or be hard to sell.