Roadmap

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-0001draft

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
PIP-0002active

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
PIP-0003active

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
PIP-0004active

Account Names and Types

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

View PIP
PIP-0005active

Stablised difficulty algorithm

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

View PIP
PIP-0006active

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
PIP-0007draft

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
PIP-0008draft

Hooks to start external programs

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

View PIP
PIP-0009proposal

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
PIP-0010proposal

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
PIP-0011proposal

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
PIP-0012proposal

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
PIP-0013proposal

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
PIP-0014proposal

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
PIP-0015proposal

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
PIP-0016proposal

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
PIP-0017proposal

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
PIP-0018proposal

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
PIP-0019draft

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