Token Transfer Restrictions
PIL tokens operate within a whitelisted transfer system. Transfers between non-approved wallets are rejected at the protocol level — this is enforced by a custom Polkadot SDK pallet, not by policy alone.
Why Restrictions Exist
PIL is a non-tradable utility token. Unrestricted transfers would create:
- Regulatory risk: Free transferability triggers e-money and MiCA "Asset-Referenced Token" classification, requiring licences Pilier does not have and does not seek
- Speculation risk: Tokens reaching secondary markets would undermine the 1 PIL = €1 operational policy
- Client exposure: End clients holding tokens creates wallet management complexity and potential liability
The whitelist ensures PIL remains what it is designed to be: an internal operational credit, not a financial instrument.
Who Can Hold PIL
Only Foundation-approved entities are permitted to hold and transfer PIL:
| Actor | Can Hold PIL | Can Transfer To |
|---|---|---|
| Pilier Foundation | ✅ | Any whitelisted wallet |
| Validator nodes | ✅ | Foundation treasury only |
| Approved SaaS partners | ✅ | Foundation treasury only |
| Approved civic partners | ✅ | Foundation treasury only |
| End clients (SMEs, users) | ❌ | — |
End clients never interact with tokens. They interact with their SaaS partner (e.g., Validité), which sponsors their transactions from its own PIL balance.
How It Works
Client model
End client pays subscription in EUR to SaaS partner
↓
SaaS partner holds whitelisted PIL wallet
↓
SaaS partner sponsors client transactions from PIL balance
↓
Client never sees, holds, or transfers tokens
Token flow
Foundation treasury
↓ (allocates PIL)
SaaS partner wallet ←──────────────────────────────┐
↓ (sponsors transactions) │
On-chain gas consumed │
↓ │
95% → validator wallets │
5% → Civic Treasury wallet │
↓ │
Validator returns excess to Foundation treasury ────┘
All movements are between whitelisted wallets. No PIL leaves this circuit.
Technical Implementation
Transfer restrictions are enforced via a custom pallet in the Pilier runtime — a transfer hook that checks both sender and recipient against an on-chain whitelist before allowing any PIL movement.
// Simplified logic
fn transfer(from: AccountId, to: AccountId, amount: Balance) -> DispatchResult {
ensure!(Whitelist::<T>::contains(&from), Error::<T>::NotWhitelisted);
ensure!(Whitelist::<T>::contains(&to), Error::<T>::NotWhitelisted);
// proceed with transfer
}
This means:
- Rejected transfers fail at the pallet level, not the application level
- No workaround exists via direct RPC calls
- The restriction cannot be bypassed by SaaS partners or validators
Whitelist Management
Who manages the whitelist
The whitelist is managed by the Foundation via governance:
| Phase | Who can modify whitelist |
|---|---|
| Phase 1 (Testnet) | Sudo key (Pilier multisig) |
| Phase 2 (Mainnet) | Foundation via governance proposal |
| Phase 3 (tPIL) | tPIL governance vote |
Adding a wallet
A new wallet can be added to the whitelist by:
- Foundation submitting a governance proposal
- tPIL vote passing (55% approval + 10% quorum for standard partners)
- On-chain execution adding the address to the whitelist pallet
Who gets added:
- New validator nodes (part of validator onboarding)
- New approved SaaS partners (after Foundation review)
- New civic partners (after Foundation approval)
Removing a wallet
A wallet can be removed via governance in cases of:
- Validator removal (Charter violation or voluntary exit)
- SaaS partner termination
- Civic partner inactivity or misuse
Effect of removal: The wallet can no longer send or receive PIL. Any PIL remaining in a removed wallet is effectively frozen until the Foundation resolves the situation via governance.
Implications for SaaS Partners
Partners building on Pilier must understand:
-
You hold the wallet, not your clients. Your clients get accounts in your system — they never have a PIL wallet or interact with tokens.
-
You cannot transfer PIL to arbitrary addresses. You can only send PIL back to the Foundation treasury (e.g., buyback payments, excess returns).
-
Your wallet is whitelisted during onboarding. The Foundation adds your address as part of the SaaS partner approval process.
-
If your wallet is compromised, notify foundation@pilier.org immediately. The Foundation can freeze the wallet via governance on an emergency basis.
Implications for Validators
- Your validator wallet is whitelisted during onboarding.
- You can only transfer PIL to the Foundation treasury (monthly exchange requests, excess returns).
- You cannot transfer PIL to personal wallets or any non-whitelisted address — including locking for tPIL from an unwhitelisted address. tPIL locking uses a dedicated Foundation-managed mechanism.
Regulatory Context
The whitelist system is a core component of Pilier's MiCA compliance positioning:
- PIL cannot be freely transferred → it is not a "transferable token" under MiCA Article 3
- No secondary market can form → no price discovery, no speculation
- End clients never hold tokens → no retail token distribution
- The Foundation controls all token flows → clear accountability
This design keeps PIL outside the scope of MiCA's ART (Asset-Referenced Token) and EMT (E-Money Token) categories, and outside the general "crypto-asset" classification that would require a CASP licence.
⚠️ This is not legal advice. Consult qualified EU crypto-asset counsel before making compliance representations to regulators or investors.
FAQ
Q: Can a SaaS partner transfer PIL to another SaaS partner?
No. Inter-partner PIL transfers are not permitted. All PIL flows through the Foundation treasury. If Partner A has excess PIL and Partner B needs more, the Foundation handles the reallocation.
Q: What if a validator accidentally sends PIL to a non-whitelisted address?
The transaction will be rejected by the pallet and will not execute. The PIL remains in the validator's wallet. No loss of funds.
Q: Can tPIL be transferred?
No. tPIL is non-transferable by design — it is a reputation score stored on-chain, not a token. It cannot be sent, sold, or delegated.
Q: Can the whitelist be removed in a future governance vote?
Technically possible, but it would require a supermajority tPIL vote and would fundamentally change Pilier's regulatory positioning. This is considered an irreversible architectural decision, not a routine parameter.
Related
- PIL Token Economics — token model overview
- Governance — whitelist management via tPIL
- Validator Compensation — PIL flow for validators
- Pilier Foundation — Foundation's role in whitelist management