If a user hosts their cards in an external wallet and wants to play them in a game on the Deckbound platform, they’re required to register those cards with a Deckbound player account. This happens automatically when the cards are exported to your own wallet (i.e. they’re associated with the exporting player's account). If you move the location of your cards (by sending to another wallet) the Deckbound player account system will pickup on this (via the change in the underlying bitbind object address) and ask you to re-register the cards. There will be a few methods for this, but it would normally be done by signing a transaction using the new wallet’s keys (the transaction doesn’t have to be published). In a multi-sig wallet that allows for 1-of-N key to sign this could be one of many users. Because the card registration can be against any Deckbound player account, it would be possible for many users (anybody with those keys) to change the registration of the cards to new Deckbound player accounts. However, because the cards are unique and recognised by the Deckbound game platform, all that would be happening in that circumstance is that the cards would be moved between player accounts. Because Deckbound games understand where cards are being used, it’s only possible to play one Deckbound game at a time with a single card. When you start a game on the platform the game launcher verifies that you currently have the ability to play with the cards in your chosen deck (either because they’re currently registered to your account or because you’ve borrowed them from the Nomad pool or similar service). Until the game is concluded (or times out) those cards are not available for play in any Deckbound game. In the example above where cards are regularly re-registered to different player accounts, it’s only possible to play the cards as frequently as you would if they were registered to a single account. There is no inherent advantage to this and the XP system is actually balanced for cards being played 24/7 (which is feasible given the Nomad pool, card lending and automated AI play features that we’re building).
There will be some exceptions to the single-concurrent-game-per-card mechanism for games that support offline play — specifically in that your collection will permit offline use in casual play modes, but experience gathered would be limited if when you went back online there were conflicting play results from multiple offline devices. In regard registration and offline modes, a user wouldn’t be able to re-register a card that was being played offline — or more specifically offline play that is synchronised after a card was re-registerd would not count toward experience or competitive results.
3rd party games that recognise Deckbound cards and use them in play (e.g. via our API) may choose to implement different registration, player account management and concurrent game use logic. We will provide best practice (and eventually services) to assist with this, but it is something 3rd parties would need to think about when developing games as we believe that a rewarding content discovery ecosystem and a trading/economy meta game is a key to engaging users in skills-based, collectible asset games.