EIP-712
Signatures that only fit here
Each signature names the vibe Collection domain and chain 4663, so the same bytes are dead on another contract or another network.
Contract review, first pass, in house
Contract security
controls
What the vibe Collection source enforces, which numbers go public the day it deploys, and the list of checks that has to clear before that day.
vibe / security4663
Deployment status
No address
on chain yet
Everything below describes what the source enforces. The deployment fields stay out of the page until an address exists on Robinhood Mainnet and this page reads it from a single config object.
Robinhood Mainnet · 4663
ERC-721
vibe Collection
not deployed yet
The state above is the whole answer for now. Address, transaction, block, owner, signer and bytecode fingerprint appear here as one table, written from a single config object, once a deployment on Robinhood Mainnet is verified on chain.
- Chain
- Robinhood Mainnet, 4663
- Contract address
- Deployment transaction
- Deployment block
- Deployment owner
- Authorized signer
- Runtime bytecode
- Bytecode fingerprint
Platform mint fee: 0
Per transaction limit: 50
Token standard: ERC-721
What the contract refuses to do
There is no open mint function to call. A batch moves only with an authorization that expires in minutes, works once, and names every parameter of the transaction it belongs to.
Nonce
One authorization, one mint
Every payer has a counter of its own. The mint moves it forward, which kills the signature that was just spent.
Pausable
A stop switch
The owner can halt minting while something is being looked at, then turn it back on.
Supply cap
A ceiling on supply
The total is fixed at deployment and the mint reverts once a batch would cross it.
Exact value
The price, to the wei
Whatever the contract quotes for that batch is what it accepts. A wei over or under reverts.
URI binding
The files are part of the promise
A hash of the ordered URI list rides inside the signature, so nobody can point a signed mint at different artwork.
No reentry. Minting and withdrawal both sit behind a guard, and a transfer that fails takes the whole call down with it.
What has to be checked first
Each row gets read against the verified source and against what the network actually reports. A row stays open until an address exists and someone repeats the check on it.
| Check | Status | Scope |
|---|---|---|
| Access control | pending deployment | The owner role reaches the pause switch, the signer address, the price and the withdrawal path. |
| Mint authorization | pending deployment | No batch mints without an EIP-712 authorization from the vibe publishing endpoint. |
| Replay protection | pending deployment | The payer counter moves on every mint, which retires the signature that used it. |
| Authorization expiry | pending deployment | A deadline travels in the signature and the call reverts past it. |
| Parameter binding | pending deployment | Seven fields sit inside the signature: who pays, who receives, the file hash, how many, how much, the counter, the deadline. |
| Supply and batch limits | pending deployment | Both the total ceiling and the size of one batch are checked by the contract. |
| Reentrancy protection | pending deployment | Minting and withdrawal are guarded, and a transfer that fails rolls the call back whole. |
What this page is not
You are reading a description of controls written into the source, plus the parameters that go live with a deployment. No outside firm has reviewed it. Read it as a statement of intent, not as a clean bill of health.
Source on the explorer
The verified source ships with its compiler build, its optimizer settings and the arguments it was deployed with.
Who holds which key
Ownership goes to a multisig. The mint signer lives on a separate key that gets rotated and watched.
Keeping the pipes up
Pinning, the RPC and the publish endpoint all need limits, alarms, copies and a written way back.