Now and into the future we are committed to improving the availability and development of PascalCoin. Here you can see our current broad-strokes roadmap for future development and progress of PascalCoin.

Recently we implemented the PascalCion Improvement Proposal (PIP) Process. Below you can see the PIPs currently being discussed by the community which will be voted upon soon. Anyone can submit a PIP, so if you think you have unique ideas to help improve the direction of PascalCoin, get involved by joining our Community Discord!

Current PascalCoin Improvement Proposals


PIP Purpose and Guidelines

A PascalCoin Improvement Proposal (PIP) is a design document for introducing features and/or information into PascalCoin. As of this publication date, this is the standard way for changes to be introduced into PascalCoin. Anyone can submit a PIP and all PIPs are evaluated through the PIP Workflow. PIPs are intended to be the primary mechanisms for proposing new features and documenting design decisions. It is the responsibility of the PIP author to document community consensus including dissenting opinions.

View PIP

In-protocol PASA Exchange

This PIP proposes in-protocol sale, purchase, settlment and exchange of PascalCoin accounts (PASA) in a totally decentralised manner.

View PIP

Infinite Scaling via Deletable Blockchain

This PIP proposes a fundamental change to the SafeBox allowing PascalCoin to achieve practically infinite running-time on finite and constant storage. This PIP proposes nodes discard blocks after the height of 100 whilst retaining the (SPV) cryptographic security of the full blockchain. This way, PascalCoin need only store the flow of transactions rather than the history -- a fundamental breakthrough in Blockchain technology.

View PIP

Account Names and Types

Allow accounts to have names similar to the Domain Name System, and to contain a type field.

View PIP

Stablised difficulty algorithm

A new difficulty adjustment algorithm is proposed to stablise sinusoidal volatility resulting from chaotic hashpower fluctuations.

View PIP

Salvage orphaned transactions

When a block is orphaned, it's containing transactions should be re-added back to the Pending Pool and relayed to connected nodes. This ensures that operations never disappear from the blockchain once re-added, since they will be re-mined in future blocks when orphaned.

View PIP

New Wallet GUI

Whilst fully functionality, PascalCoin's wallet GUI is overly complicated for most users and requires simplification. This PIP proposes a new wallet design.

View PIP

Hooks to start external programs

A hook to watch the paylod and invoke external functions when certain events occur.

View PIP

RandomHash: GPU & ASIC Resistant Hash Algorithm

A GPU and ASIC resistant hashing algorithm change is proposed in order to resolve the current mining centralization situation and to prevent future dual-mining centralization.

View PIP

50% Inflation Reduction

A 50% reduction in the PASC inflation schedule is proposed. This change can be introduced immediately by changing a single line-of-code and with unnoticeable impact to existing infrastructure.

View PIP

20% Developer Reward

It is proposed that 20% of the block-reward be portioned and allocated to the developers for the purposes of rapidly delivering the roadmap and supporting the project at large. The funding can be used for layer-1 protocol development, layer-2 development, anonymity R&D and implementation, marketing, infrastructure support and exchange listings. In practice, budgets will be proposed by and voted on by the community itself.

View PIP

Change account recovery to 10 years

It is proposed that the RECOVER operation be changed from 4 years to 10 and to include the account itself in the recovery.

View PIP

Allow nodes to pull pending operations

A new network operation called NET_OP_PULL_PENDING is proposed that allows nodes to pull some or all of the pending operations from other connected peers.

View PIP

New operation to certify accounts for extended recovery period

It is proposed to pay a fee to the development fund by an account holder in order to keep the account active for an extended period of time (20 years).

View PIP

Fast Block Propagation

A method to rapidly propagate blocks is proposed in order to minimize orphan rates. It involves propagating a block skeleton rather than the full block, reducing network traffic by 95%. Nodes can rebuild the full block by plugging operations from the Pending Pool into the skeleton.

View PIP

Layer-2 protocol support

A new operation DATA is propose to facilitate data exchange between accounts. This will allow clean enveloping of Layer-2 protocols inside Layer-1 much in the same way HTTP lives inside TCP.

View PIP

Anonymity via Transaction Mixing (phase-1)

A new operation called MULTI-TRANSACTION is proposed that allows a transfer of funds from N accounts to M accounts within in a single operation. This will immediately provide DASH-level anonymity and serve as foundational component for subsequent full anonymity.

View PIP

10% funding allocation for Lazarus/FPC

It is proposed that, if and when PIP-0011: 20% Developer Reward or a variant passes, that a portion of the funding be allocated towards development of Lazarus/FPC project so that the two ecosystems can mutually-benefit.

View PIP

Balance recovered from lost accounts to be sent to developers fund

It is proposed that, if and when PIP-0011: 20% Developer Reward or a variant passes, that a portion of the funding be allocated towards development of Lazarus/FPC project so that the two ecosystems can mutually-benefit.

View PIP