When to use which path
| Scenario | Recommended path |
|---|---|
| Standard QRC-20, QRC-721, or QRC-1155 token | Path A — managed API |
Permissioned regulated token using QRC-1400 or QRC-3643 | Path A — managed API |
Tokenized vault using QRC-4626 | Path A — managed API |
| Custom logic not covered by any template (custom hooks, custom maths) | Path B — advanced contracts |
| Migrating an existing audited contract from another chain | Path B — advanced contracts |
| Combining a token with non-token logic in the same contract | Path B — advanced contracts |
What Path B keeps
- The same Qustody approval policy gates the deployment transaction.
- The same post-quantum signing flow signs every transaction.
- The same audit log records every action.
- The same transaction state machine tracks lifecycle.
What Path B requires from you
- A Solidity toolchain (e.g.
solcor Foundry). - ABI encoding for every contract call.
- Manual mapping between contract events and your reconciliation pipeline.
- Verification of the deployed contract bytecode against your source.
QRC-compatible Solidity
Public docs refer to your custom contracts as QRC-compatible contracts. If your Solidity inherits from libraries whose internal symbol names useERC*, that is a build-time detail — keep your public-facing template ID, contract name, and operational documentation in the QRC vocabulary.