Skip to main content

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:

ActorCan Hold PILCan Transfer To
Pilier FoundationAny whitelisted wallet
Validator nodesFoundation treasury only
Approved SaaS partnersFoundation treasury only
Approved civic partnersFoundation 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:

PhaseWho 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:

  1. Foundation submitting a governance proposal
  2. tPIL vote passing (55% approval + 10% quorum for standard partners)
  3. 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:

  1. You hold the wallet, not your clients. Your clients get accounts in your system — they never have a PIL wallet or interact with tokens.

  2. You cannot transfer PIL to arbitrary addresses. You can only send PIL back to the Foundation treasury (e.g., buyback payments, excess returns).

  3. Your wallet is whitelisted during onboarding. The Foundation adds your address as part of the SaaS partner approval process.

  4. 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

  1. Your validator wallet is whitelisted during onboarding.
  2. You can only transfer PIL to the Foundation treasury (monthly exchange requests, excess returns).
  3. 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.