Plyra Protocol: Private L1 Architecture Decision
- Version: 1.0.0
- Date: July 2026
- Author: Plyra Protocol Engineering
- Status: Active architecture decision
- Implementation Status: The dedicated L1 has not yet been provisioned
Decision
Plyra's production plan is a dedicated private Avalanche L1 using standard ERC-20 assets.
eERC is not part of the current architecture, roadmap, SDK, migration plan, or implementation work. The eERC work completed on Fuji is preserved as an archived Phase 3 research artifact, not as a planned product component.
System Boundary
| Surface | Current decision |
|---|---|
| Network | Dedicated private Avalanche L1 with restricted access |
| Assets | Standard ERC-20 tokens |
| Workbench | Offchain, access-controlled application environment |
| Onchain records | Approved outputs, hashes, attestations, and authorized transactions |
| Public representation | Standard ERC-20 by default |
| eERC | Not included |
The private L1 sets the main confidentiality boundary. It controls who can connect, validate, read chain data, and submit transactions. Standard ERC-20s are the simpler fit inside that restricted environment.
The Workbench remains offchain because loan tapes, underwriting files, findings, and credit-review materials do not belong in token state. Only the information needed for an approved onchain action moves to the L1.
C-Chain and Public Assets
Making an asset available on C-Chain does not create an eERC requirement. A public representation can use a standard ERC-20.
Token-level encryption would solve a narrower problem: hiding balances or transfer amounts from parties who are otherwise allowed to read the chain. Plyra does not currently have a validated deployment requirement for that additional control.
Reconsideration Gate
Any future eERC proposal starts as a new architecture decision. It is not a continuation of the archived Phase 3 work.
A review can begin only when a named deployment defines:
- The specific asset and fields that must remain confidential.
- The parties who may read the chain but must not see those fields.
- Why a private L1 with standard ERC-20s does not meet the requirement.
- How the required workflows fit eERC's proof-bearing operations.
- Auditor key custody, replacement, historical access, recovery, and compromise handling.
- Frontend proof generation, wallet behavior, failure recovery, adapters, and security review.
If eERC is reconsidered, replacing an auditor would change access for new encrypted records only. A replacement key would not grant the new auditor access to records encrypted for the old key, and removing the old auditor would not erase that auditor's historical access.
Implementation Status
The dedicated private L1 has not yet been provisioned. Production implementation begins with the private L1 and standard ERC-20 architecture described here.
The existing Fuji eERC contracts and proof pipeline remain valid evidence of completed research. They are not production dependencies and no eERC integration work is currently required.